September 2022 - Wine-Devel

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

by Biswapriyo Nath

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…

Sept. 7, 2022

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

by Steve Lhomme

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

Re: [PATCH] ntdll: Complete error case in get_initial_environment

by Esme Povirk (any/all)

Patches are no longer picked up from wine-devel. You'll need to create a merge request at https://gitlab.winehq.org/. See https://wiki.winehq.org/Submitting_Patches for more detailed instructions. -- https://my.pronouns.page/are/any On Mon, Sep 5, 2022 at 2:06 AM Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > > GCC 12 (rightfully) would warn > dlls/ntdll/unix/env.c:1910:12: warning: 'env_pos' may be used uninitialized > > Signed-off-by: Gerald Pfeifer <gerald(a)pfeifer.com> > --- > dlls/ntdll/unix/env.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntdll/unix/env.c b/dlls/ntdll/unix/env.c > index 105038a34cb..cbbfb99f4b3 100644 > --- a/dlls/ntdll/unix/env.c > +++ b/dlls/ntdll/unix/env.c > @@ -920,7 +920,11 @@ static WCHAR *get_initial_environment( SIZE_T *pos, SIZE_T *size ) > *size = 1; > for (e = main_envp; *e; e++) *size += strlen(*e) + 1; > > - if (!(env = malloc( *size * sizeof(WCHAR) ))) return NULL; > + if (!(env = malloc( *size * sizeof(WCHAR) ))) > + { > + *pos = 0; > + return NULL; > + } > ptr = env; > end = env + *size - 1; > for (e = main_envp; *e && ptr < end; e++) > -- > 2.34.1 > >

Sept. 6, 2022

[PATCH] ntdll: Complete error case in get_initial_environment

by Gerald Pfeifer

GCC 12 (rightfully) would warn dlls/ntdll/unix/env.c:1910:12: warning: 'env_pos' may be used uninitialized Signed-off-by: Gerald Pfeifer <gerald(a)pfeifer.com> --- dlls/ntdll/unix/env.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/dlls/ntdll/unix/env.c b/dlls/ntdll/unix/env.c index 105038a34cb..cbbfb99f4b3 100644 --- a/dlls/ntdll/unix/env.c +++ b/dlls/ntdll/unix/env.c @@ -920,7 +920,11 @@ static WCHAR *get_initial_environment( SIZE_T *pos, SIZE_T *size ) *size = 1; for (e = main_envp; *e; e++) *size += strlen(*e) + 1; - if (!(env = malloc( *size * sizeof(WCHAR) ))) return NULL; + if (!(env = malloc( *size * sizeof(WCHAR) ))) + { + *pos = 0; + return NULL; + } ptr = env; end = env + *size - 1; for (e = main_envp; *e && ptr < end; e++) -- 2.34.1

Sept. 5, 2022

Re: RFC: Allow marking unreliable tests as flaky.

by Francois Gouget

On Fri, 2 Sep 2022, Huw Davies wrote: [...] > The issue is that we don't know that the tests are flakey when they > get committed; that only becomes apparent at some later stage. Whatever CI is used it should detect most flaky tests before they are committed. That's part of the point of running the test not once but multiple times (the other being to test multiple configurations). -- Francois Gouget <fgouget(a)codeweavers.com>

Sept. 2, 2022

Re: RFC: Allow marking unreliable tests as flaky.

by Huw Davies

On Fri, Sep 02, 2022 at 12:41:42PM +0200, Francois Gouget wrote: > On Thu, 1 Sep 2022, Zebediah Figura wrote: > [...] > > Why would we allow (intentionally) adding any flaky tests at all? My > > interpretation of "flaky" is that anything that currently has it is a bug and > > should be fixed. > > Initially we will need to add a bunch to deal with the current ~170 test > units (~20%) that fail on a regular basis. But yes, beyond that we may > ban adding more flaky tests entirely. In that case it would still be > useful to identify commits that add flaky tests but we would not need > the Flaky-Test mechanism. > > And should we need to add a flaky call anyway (maybe because a test is > restructured so that a single flaky call is split in two) then maybe the > author can ask Alexandre to manually cherry-pick from a GitLab > repository (or such cases fall back to email). The issue is that we don't know that the tests are flakey when they get committed; that only becomes apparent at some later stage. Huw.

Sept. 2, 2022

Re: RFC: Allow marking unreliable tests as flaky.

by Francois Gouget

On Thu, 1 Sep 2022, Zebediah Figura wrote: [...] > Why would we allow (intentionally) adding any flaky tests at all? My > interpretation of "flaky" is that anything that currently has it is a bug and > should be fixed. Initially we will need to add a bunch to deal with the current ~170 test units (~20%) that fail on a regular basis. But yes, beyond that we may ban adding more flaky tests entirely. In that case it would still be useful to identify commits that add flaky tests but we would not need the Flaky-Test mechanism. And should we need to add a flaky call anyway (maybe because a test is restructured so that a single flaky call is split in two) then maybe the author can ask Alexandre to manually cherry-pick from a GitLab repository (or such cases fall back to email). -- Francois Gouget <fgouget(a)codeweavers.com>

Sept. 2, 2022

Re: RFC: Allow marking unreliable tests as flaky.

by Zebediah Figura

On 9/1/22 12:05, Francois Gouget wrote: > > I pushed a merge request with the latest version so you can also comment > there: > https://gitlab.winehq.org/wine/wine/-/merge_requests/764 > > See also my flaky-tests branch for some use cases: > https://gitlab.winehq.org/fgouget/wine/-/commits/flaky-tests/ > > > On to the next question: do we need to take special steps to make sure > one cannot just (sneakily?) add bad tests by prefixing them with flaky*? > > > One option is to do nothing and let reviewers deal with it. Certainly if > they spot a flaky addition they would scrutinize the patch and ask > questions as needed. And if bad flaky calls slip through, the > developer's trustiness would be adjusted accordingly. Why would we allow (intentionally) adding any flaky tests at all? My interpretation of "flaky" is that anything that currently has it is a bug and should be fixed.

Sept. 1, 2022

Re: RFC: Allow marking unreliable tests as flaky.

by Francois Gouget

I pushed a merge request with the latest version so you can also comment there: https://gitlab.winehq.org/wine/wine/-/merge_requests/764 See also my flaky-tests branch for some use cases: https://gitlab.winehq.org/fgouget/wine/-/commits/flaky-tests/ On to the next question: do we need to take special steps to make sure one cannot just (sneakily?) add bad tests by prefixing them with flaky*? One option is to do nothing and let reviewers deal with it. Certainly if they spot a flaky addition they would scrutinize the patch and ask questions as needed. And if bad flaky calls slip through, the developer's trustiness would be adjusted accordingly. But I think we could have a CI check that requires specific explanations for commits with flaky additions: - If there are more '^\+.*flaky' lines in a commit than there are '^-.*flaky' ones, then that commit has a flaky addition. - If so the CI check would require a 'Flaky-Tests' line in the commit message where the submitter explains why the additional flaky is needed. I mostly see a CI check as having three benefits: - Reduce the risk of reviewers missing a flaky addition. - Save a step for the reviewers by providing them with an explanation of why the flaky is needed from the get go. - Raise the inconvenience of using flaky so in most cases it's easier / less embarrassing to fix the test. Flaky tests are really buggy tests. So we could also require a Wine-Bug line in addition to the Flaky-Tests one for tracking progress on fixing that bug. That is unless Wine-Bug lines are only supposed to be used when fixing a bug. Another approach would be to put the bug URL on the Flaky-Tests line and leave the explanation in the bug. But that makes the commit message less directly useful and not self-sufficient. Also that line could be called Flaky-Test instead of Flaky-Tests. Depends if it's about the test unit or the individual ok() calls. -- Francois Gouget <fgouget(a)codeweavers.com>

Sept. 1, 2022