September 2022 - Wine-Devel

Re: fixing some fixme code

by Jin-oh Kang

Forwarding to wine-devel. Please remember to use the "reply all" button next time. Thank you! On Mon, Sep 12, 2022, 11:11 AM Owen Hogarth <gurenchan(a)gmail.com> wrote: > Hello guys, I am trying to get this program; R Trader Pro to work on Linux. > I installed winetricks and then I received some different errors. > > I would like to fix the problem but I would also like to avoid doing > unnecessary work, that's why I am asking on the development mailing list. > > Here's the new error log, is it possible to get the program working? > 017c:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 0174:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 0174:fixme:file:NtLockFile I/O completion on lock not implemented yet > 0174:fixme:ntdll:NtQuerySystemInformation info_class > SYSTEM_PERFORMANCE_INFORMATION > 0194:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0174:fixme:imm:ImeSetActiveContext (0x2ca590, 1): stub > 0174:fixme:imm:ImmReleaseContext (0004006E, 002CA590): stub > 017c:fixme:imm:ImeSetActiveContext (0x3c780, 0): stub > 017c:fixme:imm:ImmReleaseContext (0000000000020082, 000000000003C780): stub > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0174:err:richedit:ReadStyleSheet skipping optional destination > 0174:err:richedit:ReadStyleSheet skipping optional destination > 0174:err:richedit:ReadStyleSheet skipping optional destination > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0174:fixme:msi:ITERATE_CreateShortcuts poorly handled shortcut format, > advertised shortcut > 0174:fixme:msi:ITERATE_CreateShortcuts poorly handled shortcut format, > advertised shortcut > 0174:fixme:msi:ITERATE_CreateShortcuts poorly handled shortcut format, > advertised shortcut > 01e8:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 01f0:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 01e0:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 01f8:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > regsvr32: Successfully registered DLL 'C:\Program Files > (x86)\Rithmic\Rithmic Trader Pro\StockChartX.ocx' > 0174:fixme:msi:internal_ui_handler internal UI not implemented for message > 0x0b000000 (UI level = 5) > 0174:fixme:msi:internal_ui_handler internal UI not implemented for message > 0x0b000000 (UI level = 5) > 0174:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub > 0200:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling > back to RandR 1.0. Please consider using the Nouveau driver instead. > 0200:fixme:mscoree:parse_supported_runtime > sku=L".NETFramework,Version=v4.5.2" not implemented > 0200:fixme:mscoree:parse_supported_runtime > sku=L".NETFramework,Version=v4.5.2" not implemented > 0200:fixme:ntdll:NtQuerySystemInformation info_class > SYSTEM_PERFORMANCE_INFORMATION > 0200:fixme:nls:GetFileMUIPath stub: 0x10, > L"C:\\windows\\system32\\tzres.dll", (null), 0032EE98, 00DAA728, 0032EE9C, > 0032EE90 > 0200:fixme:nls:GetFileMUIPath stub: 0x10, > L"C:\\windows\\system32\\tzres.dll", (null), 0032EE98, 00DAA728, 0032EE9C, > 0032EE90 > 0200:fixme:nls:GetFileMUIPath stub: 0x10, > L"C:\\windows\\system32\\tzres.dll", (null), 0032EE98, 00DAA728, 0032EE9C, > 0032EE90 > 0200:fixme:imm:ImeSetActiveContext (0xdc41c0, 1): stub > 0200:fixme:imm:ImmReleaseContext (00030080, 00DC41C0): stub > 0200:fixme:winsock:errno_from_unix unknown error: Device or resource busy > 0200:err:winediag:getaddrinfo Failed to resolve your host name IP > 0218:fixme:wbemprox:wbem_locator_ConnectServer authentication not supported > 0218:fixme:wbemprox:wbem_locator_ConnectServer specific locale not > supported > 0218:fixme:wbemprox:wbem_locator_ConnectServer unsupported flags > 021c:fixme:wbemprox:wbem_locator_ConnectServer authentication not supported > 021c:fixme:wbemprox:wbem_locator_ConnectServer specific locale not > supported > 021c:fixme:wbemprox:wbem_locator_ConnectServer unsupported flags > wine: Read access denied for device L"\\??\\Z:\\", FS volume label and > serial are not available. > 0200:fixme:winsock:errno_from_unix unknown error: Device or resource busy > 0200:err:winediag:getaddrinfo Failed to resolve your host name IP > 0200:fixme:winsock:errno_from_unix unknown error: Device or resource busy > 0200:err:winediag:getaddrinfo Failed to resolve your host name IP > An error occured while contacting the license server. > > Raised in : com.omnesys.omne.om.OMField > Method : OMsetData > Error : no data > Raised in : 31004 1 unknown host 20014 1 unknown addr > > Method : OMaddData > Error : create error > Please contact Omnesys Technologies Inc., at www.omnesys.com. > > On Mon, Sep 12, 2022 at 8:51 AM Jin-oh Kang <jinoh.kang.kr(a)gmail.com> > wrote: > >> On Mon, Sep 12, 2022, 9:46 AM Zebediah Figura <zfigura(a)codeweavers.com> >> wrote: >> >>> On 9/11/22 19:38, Jin-oh Kang wrote: >>> >> and secondly because it's actually quite hard if not >>> >> impossible to implement (POSIX has no way to wait for a mandatory >>> lock, >>> >> for instance). >>> >> >>> > >>> > We don't use POSIX locks to implement file locks; they are emulated >>> > entirely in the server, which I guess is specifically designed to avoid >>> > that problem with POSIX file lock semantics. Thus, this won't be *that* >>> > hard to implement; nonetheless, asynchronous I/O is not really easy to >>> > implement in general, especially for those new to wine codebase. >>> >>> I don't see where you're getting that; we do indeed use POSIX locks. See >>> set_unix_lock() in server/fd.c. >> >> >> I stand corrected. >> >> There's no poll() for file locks, so it would have to busy-wait anyway. >> >> I did incorrectly use the term >>> "mandatory", though; we don't set mandatory locks on a file. >>> >>

Sept. 12, 2022

Re: fixing some fixme code

by Jin-oh Kang

On Mon, Sep 12, 2022, 9:46 AM Zebediah Figura <zfigura(a)codeweavers.com> wrote: > On 9/11/22 19:38, Jin-oh Kang wrote: > >> and secondly because it's actually quite hard if not > >> impossible to implement (POSIX has no way to wait for a mandatory lock, > >> for instance). > >> > > > > We don't use POSIX locks to implement file locks; they are emulated > > entirely in the server, which I guess is specifically designed to avoid > > that problem with POSIX file lock semantics. Thus, this won't be *that* > > hard to implement; nonetheless, asynchronous I/O is not really easy to > > implement in general, especially for those new to wine codebase. > > I don't see where you're getting that; we do indeed use POSIX locks. See > set_unix_lock() in server/fd.c. I stand corrected. There's no poll() for file locks, so it would have to busy-wait anyway. I did incorrectly use the term > "mandatory", though; we don't set mandatory locks on a file. >

Sept. 12, 2022

Re: fixing some fixme code

by Zebediah Figura

On 9/11/22 19:38, Jin-oh Kang wrote: >> and secondly because it's actually quite hard if not >> impossible to implement (POSIX has no way to wait for a mandatory lock, >> for instance). >> > > We don't use POSIX locks to implement file locks; they are emulated > entirely in the server, which I guess is specifically designed to avoid > that problem with POSIX file lock semantics. Thus, this won't be *that* > hard to implement; nonetheless, asynchronous I/O is not really easy to > implement in general, especially for those new to wine codebase. I don't see where you're getting that; we do indeed use POSIX locks. See set_unix_lock() in server/fd.c. I did incorrectly use the term "mandatory", though; we don't set mandatory locks on a file.

Sept. 12, 2022

Re: fixing some fixme code

by Jin-oh Kang

On Mon, Sep 12, 2022, 6:49 AM Zebediah Figura <zfigura(a)codeweavers.com> wrote: > Hello Owen, welcome to Wine! > > On 9/11/22 08:49, Owen Hogarth wrote: > > Hello, > > > > I tried to run an application and saw that there are a few unimplemented > > features, such as: > > 00d0:fixme:file:NtLockFile I/O completion on lock not implemented yet > > I would advise against trying to implement this—firstly because, despite > showing up in many applications, it's not actually known to break > anything, Yes, and many of the other fixmes you have probably already have stub implementations sensible enough for most applications to work. and secondly because it's actually quite hard if not > impossible to implement (POSIX has no way to wait for a mandatory lock, > for instance). > We don't use POSIX locks to implement file locks; they are emulated entirely in the server, which I guess is specifically designed to avoid that problem with POSIX file lock semantics. Thus, this won't be *that* hard to implement; nonetheless, asynchronous I/O is not really easy to implement in general, especially for those new to wine codebase. I recommend sending in a fix once you find something that is actually broken. ;) > In general it's better to look for an actually broken application, and > try to debug and fix it. > > --Zeb > > >

Sept. 12, 2022

Re: fixing some fixme code

by Zebediah Figura

Hello Owen, welcome to Wine! On 9/11/22 08:49, Owen Hogarth wrote: > Hello, > > I tried to run an application and saw that there are a few unimplemented > features, such as: > 00d0:fixme:file:NtLockFile I/O completion on lock not implemented yet I would advise against trying to implement this—firstly because, despite showing up in many applications, it's not actually known to break anything, and secondly because it's actually quite hard if not impossible to implement (POSIX has no way to wait for a mandatory lock, for instance). In general it's better to look for an actually broken application, and try to debug and fix it. --Zeb

Sept. 11, 2022

Re: [PATCH] include: disable some process/thread functions when in UAP mode

by Steve Lhomme

On 2022-09-07 18:42, Biswapriyo Nath wrote: > winbase.h in mingw-w64 is not imported from wine. This script has the > list of which files are imported to mingw-w64 from wine > https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-head… Uh, my bad. I was actually looking at the one in widl which is imported. The winbase.h one seems to be alright. Sorry for the noise.

Sept. 8, 2022

Re: [vkd3d] Handling object components within the HLSL compiler.

by Zebediah Figura

Sorry for the late reply; I had to think about this for a while... On 8/31/22 18:52, Francisco Casas wrote: > > On 31-08-22 14:12, Zebediah Figura wrote: >> I don't think I understand the point of splitting uniforms for sm4 but >> not sm1. If we need to determine (and potentially store) the actual type >> of a uniform per-component anyway, why would we need to do that >> differently for structs and arrays? >> > > Well, first, I don't think we should split uniforms completely, only > separate the object components as standalone variables. > > So, if we have, say > > struct { > float4 foo; > Texture2D tex[2]; > float4 bar; > } pou; > > We would be effectively end up with 3 variables: > > The original: > > --- > struct { > float4 foo; > Texture2D tex[2]; > float4 bar; > } pou; > --- > > and: > > --- > Texture2D "pou.tex[0]"; > Texture2D "pou.tex[1]"; > --- > > because we would be adding a store from the "pou.tex[0]" variable to > pou.tex[0], and from the "pou.tex[1]" variable to pou.tex[1], copy-prop > should replace all derefs to the Texture components to derefs to these > new variables. > > The pou variable no longer has to worry about the register allocation of > its Texture fields, because the new variables do that. > > Generalizing, variables should no longer care about their object > components, unless they are objects themselves. But this goes both ways. The struct variables still contain multiple object types, and they'll need to be able to allocate one while ignoring the other. This would make more sense if we were to remove the object types from the struct afterward. It's not perfectly clear to me that we want to do that vs. just keeping them there. A more interesting question is how this compares to cases in sm1 where a variable gets allocated to multiple register sets (float/int/bool). > > I think something similar happens under the hood in SM4, consider the > output of the following shader in the native compiler: > > --- > struct { > float4 foo; > Texture2D tex[2]; > float4 bar; > } pou; > > float4 main() : SV_TARGET > { > return pou.bar + pou.tex[0].Load(int3(1, 2, 3)) + > pou.tex[1].Load(int3(1, 2, 3)); > } > --- > > --- > // Buffer Definitions: > // > // cbuffer $Globals > // { > // > // struct <unnamed> > // { > // > // float4 foo; // Offset: 0 > // float4 bar; // Offset: 16 > // > // } pou; // Offset: 0 Size: 32 > // Textures: t0-t1 > // > // } > // > // > // Resource Bindings: > // > // Name Type Format Dim HLSL Bind Count > // --------------------- ---------- ------- -------- --------- ------ > // pou.tex[0] texture float4 2d t0 1 > // pou.tex[1] texture float4 2d t1 1 > // $Globals cbuffer NA NA cb0 1 > --- > > Object components are listed separately in the resource bindings, and > they are efectively removed (or ignored?) in the definition of pou. This is a more interesting reason. There are two caveats, though, one easy to handwave and one harder. Firstly, it's worth noting that this doesn't happen with 4.0 or 4.1, only 5.0 (and 5.1 is a different beast anyway). Putting objects in a struct is illegal in 4.x, even if you're not mixing them with numeric types, but you can see a similar difference if you just declare a global array of objects. Secondly, and more importantly, the original struct actually needs to retain some amount of information about the objects it contained, including which ones were actually used. Consider the following shader: struct { Texture2D one; Texture2D unused; float3 coords; } apple; struct { // Texture2D unused; Texture2D three; float3 coords; } banana; float4 main() : SV_TARGET { return apple.one.Load(apple.coords) + banana.three.Load(banana.coords); } If you move "unused" to the "banana" struct (as indicated by the comment), the shader itself stays the same, as does the binding table (in the RDEF section), but the constant buffers do not. The difference can be seen in the disassembly output, and corresponds to the "StartTexture" and "TextureSize" fields of D3D11_SHADER_VARIABLE_DESC. This means, notably, that I don't think we can just remove object variables from their structs. > With this, for both SM1 and SM4, each variable should only care about > the allocation of a single type of register, so we can use the register > offsets as we do now. Maybe, but on the other hand, could we just have multiple registers per struct variable? I.e. one per namespace (numeric, sampler, texture, uav...) > In the future we would probably want to remove the "offset" field from > the derefs, and make each hlsl_sm*.c compute the register offsets from > the derefs in their index path form. We definitely want to get rid of "offset" from the derefs.

Sept. 8, 2022

Re: Ubuntu 20.04 vs 32bit wine [-staging] - more detailed documentation?

by Floris Renaud

On woensdag 07 september 2022 19:18:19 (+02:00), Sebastian M. Ernst wrote: > Hi all, > > just burned *a lot* of time making Wine (Staging) for 64 and **32 bit** work on Ubuntu 20.04 (Ubuntu 22.04 was a little less painful) as part of a Github action of mine. > > The official documentation that is very commonly referred / pointed to ("if it does not work, you did not follow the instructions there to the letter") ... > > https://wiki.winehq.org/Ubuntu > > ... misses a few, apparently constantly shifting details on the 32 bit side of things. The "authoritative resource" on this topic appears to be this lovely long Github issue ... > > https://github.com/actions/runner-images/issues/4589 > > ... which thankfully also provides up-to-date workarounds (with rather significant side-effects), like the following as of July 26: > > ```bash > sudo rm -f /etc/apt/sources.list.d/microsoft-prod.list > sudo apt-get update -qq > sudo apt-get install -yqq --allow-downgrades libgd3/focal libpcre2-8-0/focal libpcre2-16-0/focal libpcre2-32-0/focal libpcre2-posix2/focal > sudo apt-get purge -yqq libmono* moby* mono* php* libgdiplus libpcre2-posix3 libzip4 > ``` > > See, in the following order: > > - https://github.com/actions/runner-images/issues/4589#issuecomment-980506595 > - https://github.com/actions/runner-images/issues/4589#issuecomment-1100899313 > - https://github.com/actions/runner-images/issues/4589#issuecomment-1123074635 > - https://github.com/actions/runner-images/issues/4589#issuecomment-1194891446 > > I am not sure if (or how) this belongs into your wiki (of if it can even be fixed / worked around partially within the dependencies of the packages from WineHQ's PPA). But since the above mentioned Github issue is not easy to find between a lot of other related but less helpful "noise" in online search results (and takes a while to comprehend), it might warrant creating a central, well known place that documents this behaviour in an up-to-date manner. > > Either way, in all honesty, thx to everybody who keeps 32 bit support running. For better or for worse, it is still badly needed. > > Best regards, > Sebastian > > > The WineHQ packages are created for a standard Ubuntu installation. The fact that a user also uses third-party PPAs is not supported. The deb.sury.org PPA is also often mentioned on the WineHQ forum as causing problems because it is not multiarch. While this is noted on the WineHQ Wiki [1], if I understand you correctly, this explanation could be more specific/ detailed. If you have any ideas on how to improve this text please post them on the forum [2]. Cheers, Floris [1] https://wiki.winehq.org/FAQ#How_do_I_solve_dependency_errors_when_trying_to… [2] https://forum.winehq.org/viewforum.php?f=11

Sept. 7, 2022

Ubuntu 20.04 vs 32bit wine [-staging] - more detailed documentation?

by Sebastian M. Ernst

Hi all, just burned *a lot* of time making Wine (Staging) for 64 and **32 bit** work on Ubuntu 20.04 (Ubuntu 22.04 was a little less painful) as part of a Github action of mine. The official documentation that is very commonly referred / pointed to ("if it does not work, you did not follow the instructions there to the letter") ... https://wiki.winehq.org/Ubuntu ... misses a few, apparently constantly shifting details on the 32 bit side of things. The "authoritative resource" on this topic appears to be this lovely long Github issue ... https://github.com/actions/runner-images/issues/4589 ... which thankfully also provides up-to-date workarounds (with rather significant side-effects), like the following as of July 26: ```bash sudo rm -f /etc/apt/sources.list.d/microsoft-prod.list sudo apt-get update -qq sudo apt-get install -yqq --allow-downgrades libgd3/focal libpcre2-8-0/focal libpcre2-16-0/focal libpcre2-32-0/focal libpcre2-posix2/focal sudo apt-get purge -yqq libmono* moby* mono* php* libgdiplus libpcre2-posix3 libzip4 ``` See, in the following order: - https://github.com/actions/runner-images/issues/4589#issuecomment-980506595 - https://github.com/actions/runner-images/issues/4589#issuecomment-1100899313 - https://github.com/actions/runner-images/issues/4589#issuecomment-1123074635 - https://github.com/actions/runner-images/issues/4589#issuecomment-1194891446 I am not sure if (or how) this belongs into your wiki (of if it can even be fixed / worked around partially within the dependencies of the packages from WineHQ's PPA). But since the above mentioned Github issue is not easy to find between a lot of other related but less helpful "noise" in online search results (and takes a while to comprehend), it might warrant creating a central, well known place that documents this behaviour in an up-to-date manner. Either way, in all honesty, thx to everybody who keeps 32 bit support running. For better or for worse, it is still badly needed. Best regards, Sebastian

Sept. 7, 2022

Re: [PATCH] include: disable some process/thread functions when in UAP mode

by Bernhard Kölbl

Hi, patches need to be submitted on GitLab now: https://gitlab.winehq.org/wine/wine/-/merge_requests Thanks Bernhard Am Mi., 7. Sept. 2022 um 10:38 Uhr schrieb Steve Lhomme <robux4(a)ycbcr.xyz>: > > Wine doesn't use the winapifamily.h features but this header is also used in > mingw-w64. These functions are also defined in processthreadsapi.h and many of > them are not supposed to be called by non desktop apps. > > In order to have mingw-w64 avoid making these functions public when they should > not, winbase.h need to match the mingw-w64 processthreadsapi.h. Either this is > fixed in Wine it will need careful update of winbase.h when imported in > mingw-w64. > --- > include/winbase.h | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/include/winbase.h b/include/winbase.h > index 0a8409c10e1..f8f04643637 100644 > --- a/include/winbase.h > +++ b/include/winbase.h > @@ -20,6 +20,7 @@ > #define __WINE_WINBASE_H > > #include <winerror.h> > +#include <winapifamily.h> > > #ifdef __cplusplus > extern "C" { > @@ -1901,15 +1902,19 @@ WINBASEAPI BOOL WINAPI CreateProcessA(LPCSTR,LPSTR,LPSECURITY_ATTRIBUTES, > WINBASEAPI BOOL WINAPI CreateProcessW(LPCWSTR,LPWSTR,LPSECURITY_ATTRIBUTES,LPSECURITY_ATTRIBUTES,BOOL,DWORD,LPVOID,LPCWSTR,LPSTARTUPINFOW,LPPROCESS_INFORMATION); > #define CreateProcess WINELIB_NAME_AW(CreateProcess) > WINADVAPI BOOL WINAPI CreateProcessAsUserA(HANDLE,LPCSTR,LPSTR,LPSECURITY_ATTRIBUTES,LPSECURITY_ATTRIBUTES,BOOL,DWORD,LPVOID,LPCSTR,LPSTARTUPINFOA,LPPROCESS_INFORMATION); > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINADVAPI BOOL WINAPI CreateProcessAsUserW(HANDLE,LPCWSTR,LPWSTR,LPSECURITY_ATTRIBUTES,LPSECURITY_ATTRIBUTES,BOOL,DWORD,LPVOID,LPCWSTR,LPSTARTUPINFOW,LPPROCESS_INFORMATION); > +#endif > #define CreateProcessAsUser WINELIB_NAME_AW(CreateProcessAsUser) > WINBASEAPI BOOL WINAPI CreateProcessInternalA(HANDLE,LPCSTR,LPSTR,LPSECURITY_ATTRIBUTES,LPSECURITY_ATTRIBUTES,BOOL,DWORD,LPVOID,LPCSTR,LPSTARTUPINFOA,LPPROCESS_INFORMATION,HANDLE*); > WINBASEAPI BOOL WINAPI CreateProcessInternalW(HANDLE,LPCWSTR,LPWSTR,LPSECURITY_ATTRIBUTES,LPSECURITY_ATTRIBUTES,BOOL,DWORD,LPVOID,LPCWSTR,LPSTARTUPINFOW,LPPROCESS_INFORMATION,HANDLE*); > #define CreateProcessInternal WINELIB_NAME_AW(CreateProcessInternal) > WINADVAPI BOOL WINAPI CreateProcessWithLogonW(LPCWSTR,LPCWSTR,LPCWSTR,DWORD,LPCWSTR,LPWSTR,DWORD,LPVOID,LPCWSTR,LPSTARTUPINFOW,LPPROCESS_INFORMATION); > WINADVAPI BOOL WINAPI CreateProcessWithTokenW(HANDLE,DWORD,LPCWSTR,LPWSTR,DWORD,void *,LPCWSTR,STARTUPINFOW *,PROCESS_INFORMATION *); > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINBASEAPI HANDLE WINAPI CreateRemoteThread(HANDLE,LPSECURITY_ATTRIBUTES,SIZE_T,LPTHREAD_START_ROUTINE,LPVOID,DWORD,LPDWORD); > WINBASEAPI HANDLE WINAPI CreateRemoteThreadEx(HANDLE,LPSECURITY_ATTRIBUTES,SIZE_T,LPTHREAD_START_ROUTINE,LPVOID,DWORD,LPPROC_THREAD_ATTRIBUTE_LIST,LPDWORD); > +#endif > WINADVAPI BOOL WINAPI CreateRestrictedToken(HANDLE,DWORD,DWORD,PSID_AND_ATTRIBUTES,DWORD,PLUID_AND_ATTRIBUTES,DWORD,PSID_AND_ATTRIBUTES,PHANDLE); > WINBASEAPI HANDLE WINAPI CreateSemaphoreA(LPSECURITY_ATTRIBUTES,LONG,LONG,LPCSTR); > WINBASEAPI HANDLE WINAPI CreateSemaphoreW(LPSECURITY_ATTRIBUTES,LONG,LONG,LPCWSTR); > @@ -1958,7 +1963,9 @@ WINBASEAPI void WINAPI DeleteFiber(LPVOID); > WINBASEAPI BOOL WINAPI DeleteFileA(LPCSTR); > WINBASEAPI BOOL WINAPI DeleteFileW(LPCWSTR); > #define DeleteFile WINELIB_NAME_AW(DeleteFile) > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINBASEAPI void WINAPI DeleteProcThreadAttributeList(struct _PROC_THREAD_ATTRIBUTE_LIST*); > +#endif > WINBASEAPI BOOL WINAPI DeleteTimerQueue(HANDLE); > WINBASEAPI BOOL WINAPI DeleteTimerQueueEx(HANDLE,HANDLE); > WINBASEAPI BOOL WINAPI DeleteTimerQueueTimer(HANDLE,HANDLE,HANDLE); > @@ -2248,12 +2255,16 @@ WINBASEAPI BOOL WINAPI GetLogicalProcessorInformation(PSYSTEM_LOGICAL_PRO > WINBASEAPI BOOL WINAPI GetLogicalProcessorInformationEx(LOGICAL_PROCESSOR_RELATIONSHIP,PSYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX,PDWORD); > WINBASEAPI DWORD WINAPI GetProcessHeaps(DWORD,PHANDLE); > WINBASEAPI DWORD WINAPI GetProcessId(HANDLE); > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINBASEAPI DWORD WINAPI GetProcessIdOfThread(HANDLE); > +#endif > WINBASEAPI BOOL WINAPI GetProcessIoCounters(HANDLE,PIO_COUNTERS); > WINBASEAPI BOOL WINAPI GetProcessPriorityBoost(HANDLE,PBOOL); > WINBASEAPI BOOL WINAPI GetProcessShutdownParameters(LPDWORD,LPDWORD); > WINBASEAPI BOOL WINAPI GetProcessTimes(HANDLE,LPFILETIME,LPFILETIME,LPFILETIME,LPFILETIME); > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINBASEAPI DWORD WINAPI GetProcessVersion(DWORD); > +#endif > WINBASEAPI BOOL WINAPI GetProcessWorkingSetSize(HANDLE,PSIZE_T,PSIZE_T); > WINBASEAPI BOOL WINAPI GetProcessWorkingSetSizeEx(HANDLE,SIZE_T*,SIZE_T*,DWORD*); > WINBASEAPI BOOL WINAPI GetProductInfo(DWORD,DWORD,DWORD,DWORD,PDWORD); > @@ -2282,7 +2293,9 @@ WINBASEAPI DWORD WINAPI GetShortPathNameA(LPCSTR,LPSTR,DWORD); > WINBASEAPI DWORD WINAPI GetShortPathNameW(LPCWSTR,LPWSTR,DWORD); > #define GetShortPathName WINELIB_NAME_AW(GetShortPathName) > WINBASEAPI VOID WINAPI GetStartupInfoA(LPSTARTUPINFOA); > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINBASEAPI VOID WINAPI GetStartupInfoW(LPSTARTUPINFOW); > +#endif > #define GetStartupInfo WINELIB_NAME_AW(GetStartupInfo) > WINBASEAPI HANDLE WINAPI GetStdHandle(DWORD); > WINBASEAPI BOOL WINAPI GetSystemCpuSetInformation(SYSTEM_CPU_SET_INFORMATION*,ULONG,ULONG*,HANDLE,ULONG); > @@ -2400,7 +2413,9 @@ WINBASEAPI BOOL WINAPI InitializeContext2(void *,DWORD,CONTEXT **,DWORD * > WINBASEAPI void WINAPI InitializeCriticalSection(CRITICAL_SECTION *lpCrit); > WINBASEAPI BOOL WINAPI InitializeCriticalSectionAndSpinCount(CRITICAL_SECTION *,DWORD); > WINBASEAPI BOOL WINAPI InitializeCriticalSectionEx(CRITICAL_SECTION *,DWORD,DWORD); > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINBASEAPI BOOL WINAPI InitializeProcThreadAttributeList(struct _PROC_THREAD_ATTRIBUTE_LIST*,DWORD,DWORD,SIZE_T*); > +#endif > WINADVAPI BOOL WINAPI InitializeSecurityDescriptor(PSECURITY_DESCRIPTOR,DWORD); > WINADVAPI BOOL WINAPI InitializeSid(PSID,PSID_IDENTIFIER_AUTHORITY,BYTE); > WINBASEAPI VOID WINAPI InitializeSListHead(PSLIST_HEADER); > @@ -2559,7 +2574,9 @@ WINBASEAPI VOID WINAPI OutputDebugStringW(LPCWSTR); > WINBASEAPI BOOL WINAPI PeekNamedPipe(HANDLE,PVOID,DWORD,PDWORD,PDWORD,PDWORD); > WINBASEAPI BOOL WINAPI PostQueuedCompletionStatus(HANDLE,DWORD,ULONG_PTR,LPOVERLAPPED); > WINBASEAPI DWORD WINAPI PrepareTape(HANDLE,DWORD,BOOL); > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINBASEAPI BOOL WINAPI ProcessIdToSessionId(DWORD,DWORD*); > +#endif > WINADVAPI BOOL WINAPI PrivilegeCheck(HANDLE,PPRIVILEGE_SET,LPBOOL); > WINADVAPI BOOL WINAPI PrivilegedServiceAuditAlarmA(LPCSTR,LPCSTR,HANDLE,PPRIVILEGE_SET,BOOL); > WINADVAPI BOOL WINAPI PrivilegedServiceAuditAlarmW(LPCWSTR,LPCWSTR,HANDLE,PPRIVILEGE_SET,BOOL); > @@ -2680,7 +2697,9 @@ WINADVAPI BOOL WINAPI SetPrivateObjectSecurity(SECURITY_INFORMATION,PSEC > WINADVAPI BOOL WINAPI SetPrivateObjectSecurityEx(SECURITY_INFORMATION,PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR*,ULONG,PGENERIC_MAPPING,HANDLE); > WINBASEAPI BOOL WINAPI SetProcessAffinityMask(HANDLE,DWORD_PTR); > WINBASEAPI BOOL WINAPI SetProcessPriorityBoost(HANDLE,BOOL); > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINBASEAPI BOOL WINAPI SetProcessShutdownParameters(DWORD,DWORD); > +#endif > WINBASEAPI BOOL WINAPI SetProcessWorkingSetSize(HANDLE,SIZE_T,SIZE_T); > WINBASEAPI BOOL WINAPI SetProcessWorkingSetSizeEx(HANDLE,SIZE_T,SIZE_T,DWORD); > WINBASEAPI BOOL WINAPI SetSearchPathMode(DWORD); > @@ -2698,7 +2717,9 @@ WINBASEAPI BOOL WINAPI SetSystemTimeAdjustment(DWORD,BOOL); > WINBASEAPI DWORD WINAPI SetTapeParameters(HANDLE,DWORD,LPVOID); > WINBASEAPI DWORD WINAPI SetTapePosition(HANDLE,DWORD,DWORD,DWORD,DWORD,BOOL); > WINBASEAPI DWORD_PTR WINAPI SetThreadAffinityMask(HANDLE,DWORD_PTR); > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINBASEAPI BOOL WINAPI SetThreadContext(HANDLE,const CONTEXT *); > +#endif > WINBASEAPI BOOL WINAPI SetThreadErrorMode(DWORD,LPDWORD); > WINBASEAPI DWORD WINAPI SetThreadExecutionState(EXECUTION_STATE); > WINBASEAPI DWORD WINAPI SetThreadIdealProcessor(HANDLE,DWORD); > @@ -2731,7 +2752,9 @@ WINBASEAPI BOOL WINAPI SwitchToThread(void); > WINBASEAPI BOOL WINAPI SystemTimeToFileTime(const SYSTEMTIME*,LPFILETIME); > WINBASEAPI BOOL WINAPI TerminateJobObject(HANDLE,UINT); > WINBASEAPI BOOL WINAPI TerminateProcess(HANDLE,DWORD); > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINBASEAPI BOOL WINAPI TerminateThread(HANDLE,DWORD); > +#endif > WINBASEAPI DWORD WINAPI TlsAlloc(void); > WINBASEAPI BOOL WINAPI TlsFree(DWORD); > WINBASEAPI LPVOID WINAPI TlsGetValue(DWORD); > @@ -2753,7 +2776,9 @@ WINBASEAPI BOOL WINAPI UmsThreadYield(void *); > WINBASEAPI HRESULT WINAPI UnregisterApplicationRestart(void); > WINBASEAPI BOOL WINAPI UnregisterWait(HANDLE); > WINBASEAPI BOOL WINAPI UnregisterWaitEx(HANDLE,HANDLE); > +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) > WINBASEAPI BOOL WINAPI UpdateProcThreadAttribute(struct _PROC_THREAD_ATTRIBUTE_LIST*,DWORD,DWORD_PTR,void*,SIZE_T,void*,SIZE_T*); > +#endif > WINBASEAPI BOOL WINAPI UpdateResourceA(HANDLE,LPCSTR,LPCSTR,WORD,LPVOID,DWORD); > WINBASEAPI BOOL WINAPI UpdateResourceW(HANDLE,LPCWSTR,LPCWSTR,WORD,LPVOID,DWORD); > #define UpdateResource WINELIB_NAME_AW(UpdateResource) > -- > 2.29.2 > >

Sept. 7, 2022