January 2022 - Wine-Devel - list.winehq.org

[PATCH] wininet: Use CHAR_BIT from msvcrt limits.h.

by Zebediah Figura

Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> --- dlls/wininet/urlcache.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/dlls/wininet/urlcache.c b/dlls/wininet/urlcache.c index d8b0d5fb037..22d0f5bf11d 100644 --- a/dlls/wininet/urlcache.c +++ b/dlls/wininet/urlcache.c @@ -27,6 +27,7 @@ #include "ws2tcpip.h" +#include <limits.h> #include <stdarg.h> #include <stdio.h> #include <stdlib.h> @@ -52,10 +53,6 @@ WINE_DEFAULT_DEBUG_CHANNEL(wininet); static const char urlcache_ver_prefix[] = "WINE URLCache Ver "; static const char urlcache_ver[] = "0.2012001"; -#ifndef CHAR_BIT -#define CHAR_BIT (8 * sizeof(CHAR)) -#endif - #define ENTRY_START_OFFSET 0x4000 #define DIR_LENGTH 8 #define MAX_DIR_NO 0x20 -- 2.34.1

Jan. 31, 2022

[PATCH] winsta: Remove useless IDL attributes from TS_ALL_PROCESSES_INFO.

by Zebediah Figura

Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> --- dlls/winsta/winsta.h | 4 ---- 1 file changed, 4 deletions(-) diff --git a/dlls/winsta/winsta.h b/dlls/winsta/winsta.h index d908aa855cc..c4f5e986f16 100644 --- a/dlls/winsta/winsta.h +++ b/dlls/winsta/winsta.h @@ -82,11 +82,7 @@ typedef struct _TS_ALL_PROCESSES_INFO { PTS_SYS_PROCESS_INFORMATION pTsProcessInfo; DWORD SizeOfSid; -#ifdef MIDL_PASS - [size_is(SizeOfSid)] PBYTE pSid; -#else PBYTE pSid; -#endif } TS_ALL_PROCESSES_INFO, *PTS_ALL_PROCESSES_INFO; BOOLEAN WINAPI WinStationEnumerateW(HANDLE,PSESSIONIDW *,PULONG); -- 2.34.1

Jan. 31, 2022

[PATCH] user32/tests: Remove unnecessary redefinitions of SPI_GETDESKWALLPAPER.

by Zebediah Figura

Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> --- dlls/user32/tests/sysparams.c | 4 ---- dlls/user32/tests/win.c | 4 ---- 2 files changed, 8 deletions(-) diff --git a/dlls/user32/tests/sysparams.c b/dlls/user32/tests/sysparams.c index 89a524407bf..f2d9694bd6f 100644 --- a/dlls/user32/tests/sysparams.c +++ b/dlls/user32/tests/sysparams.c @@ -30,10 +30,6 @@ #include "winuser.h" #include "winnls.h" -#ifndef SPI_GETDESKWALLPAPER -# define SPI_GETDESKWALLPAPER 0x0073 -#endif - static LONG (WINAPI *pChangeDisplaySettingsExA)(LPCSTR, LPDEVMODEA, HWND, DWORD, LPVOID); static BOOL (WINAPI *pIsProcessDPIAware)(void); static BOOL (WINAPI *pSetProcessDPIAware)(void); diff --git a/dlls/user32/tests/win.c b/dlls/user32/tests/win.c index ba9b16d89bd..5ce7eb02f1c 100644 --- a/dlls/user32/tests/win.c +++ b/dlls/user32/tests/win.c @@ -34,10 +34,6 @@ #include "wine/test.h" -#ifndef SPI_GETDESKWALLPAPER -#define SPI_GETDESKWALLPAPER 0x0073 -#endif - #ifndef WM_SYSTIMER #define WM_SYSTIMER 0x0118 #endif -- 2.34.1

Jan. 31, 2022

[PATCH] user32: Remove no longer needed assert() workarounds for MinGW.

by Zebediah Figura

We build with msvcrt, so we don't link against MinGW's assert() anymore. Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> --- dlls/user32/user_private.h | 6 ------ 1 file changed, 6 deletions(-) diff --git a/dlls/user32/user_private.h b/dlls/user32/user_private.h index 3b542ea1452..d1016780658 100644 --- a/dlls/user32/user_private.h +++ b/dlls/user32/user_private.h @@ -296,12 +296,6 @@ typedef struct extern int bitmap_info_size( const BITMAPINFO * info, WORD coloruse ) DECLSPEC_HIDDEN; extern BOOL get_icon_size( HICON handle, SIZE *size ) DECLSPEC_HIDDEN; -/* Mingw's assert() imports MessageBoxA and gets confused by user32 exporting it */ -#ifdef __MINGW32__ -#undef assert -#define assert(expr) ((void)0) -#endif - extern struct user_api_hook *user_api DECLSPEC_HIDDEN; LRESULT WINAPI USER_DefDlgProc(HWND, UINT, WPARAM, LPARAM, BOOL) DECLSPEC_HIDDEN; LRESULT WINAPI USER_ScrollBarProc(HWND, UINT, WPARAM, LPARAM, BOOL) DECLSPEC_HIDDEN; -- 2.34.1

Jan. 31, 2022

Re: Bug 52488, floating point denormal exception

by Zebediah Figura

On 1/31/22 11:45, Fabian Maurer wrote: > It's still the case that we can't really write tests for Win16, correct? For what it's worth, I've been working on a scheme to allow 16-bit tests using extensive generated between 16-bit and 32-bit code. I have a proof of concept, but I haven't come close to finishing the thunking generation yet, and I haven't got time to work onit recently... Just figured I'd throw that out there as well since we're discussing compilers.

Jan. 31, 2022

Re: Bug 52488, floating point denormal exception

by Saulius Krasuckas

* On 2022-01-31 22:18, Fabian Maurer wrote: >> The main blocker is the lack of a LGPL compatible compiler. Openwatcom >> can compile win16 binaries, but the license isn't compatible > > I don't really understand why that is. I mean, Wine isn't distributing > the > compiler? Or is the point that it's hard to get distros to ship > openwatcom > packages due to the license? IIRC the issue of the non-friendly license was that almost nobody was packaging / maintaining it on mainstream distros. Quick Google query says it's still probably the same: https://github.com/open-watcom/open-watcom-v2/discussions/487 Here I get only packages for Arch Linux and Haiku: https://repology.org/project/openwatcom/versions https://repology.org/project/openwatcom-v2/versions On the other hand, snap version seems to be available: https://snapcraft.io/open-watcom S.

Jan. 31, 2022

Re: [PATCH 3/4] wined3d: Keep track of whether a BO is persistently mapped in a per-BO field.

by Henri Verbeet

On Mon, 31 Jan 2022 at 19:02, Zebediah Figura <zfigura(a)codeweavers.com> wrote: > On 1/31/22 11:33, Henri Verbeet wrote: > > On Mon, 31 Jan 2022 at 18:22, Zebediah Figura <zfigura(a)codeweavers.com> wrote: > >> On 1/31/22 08:11, Henri Verbeet wrote: > >>> On Mon, 31 Jan 2022 at 04:05, Zebediah Figura <zfigura(a)codeweavers.com> wrote: > >>>> The ultimate idea being to set a cap on the amount of persistent BO memory, in > >>>> which case we need to arbitrarily mark BOs as persistent. > >>>> > >>> Could the "arbitrary" part be avoided? In particular, what would > >>> prevent us from unmapping less recently used mappings when we run into > >>> the cap? > >> > >> Nothing, really. We could relatively easily use an LRU list, or > >> periodically garbage-collect unused mappings, for two possibilities. > >> > >> I think it's a bit orthogonal to this patch, though. No matter what > >> criteria we use to determine whether a mapping is persistent in > >> wined3d_bo_*_map(), or to possibly unmap it later, we'll at least want > >> some of these users of bo->persistent. > >> > >> I'm also inclined to argue there's no reason not to accept 4/4 now, and > >> later (assuming we need to) implement a more complex and optimized > >> scheme on top of that. Although it could probably do with a bit more > >> factored out into the "adjust_mapped_memory" helpers. > > > > To some extent, yes. However, the follow-up question then becomes what > > the "persistent" field really means. Or put a different way, under > > what circumstances should we use "bo->persistent" instead of > > "bo->map_ptr"? > > Note that we use "bo->map_ptr" inconsistently between the OpenGL and > Vulkan backends—the OpenGL backend only sets it for persistent mappings, > whereas the Vulkan backend sets it for all mappings. This patch > standardizes on the latter behaviour. > > The reason we want this is basically patch 2/4. Namely, if the BO is > mapped, then wined3d_device_context_map() can return its map pointer to > the caller (assuming we just got it from a DISCARD map). If it is mapped > persistently, we can also store that map pointer and use it for > subsequent NOOVERWRITE maps. > The concern I have is that if we're using "persistent" in the sense the the bo is never going to be unmapped, that essentially precludes futures schemes where we do potentially unmap these. On the other hand, if these aren't all that persistent in practice, we only care whether the bo is currently mapped, but then also need to make sure we can invalidate e.g. client mappings when needed. (And note that in principle a bo can be currently mapped because a different bo in the same slab or chunk is currently mapped, regardless of what wined3d_map_persistent() returns.)

Jan. 31, 2022

Re: [PATCH 1/2] shell32: Only call HCR_GetFolderAttributes with simple pidls

by Fabian Maurer

Hello, Any news on this patch series? Regards, Fabian Maurer > The function returns false with not-simple pidls anyways. > This fixes an "ERR" message when opening a control panel applet from > explorer > > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/shell32/shlfolder.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/shell32/shlfolder.c b/dlls/shell32/shlfolder.c > index 10aafc160c0..8e3b561cfd1 100644 > --- a/dlls/shell32/shlfolder.c > +++ b/dlls/shell32/shlfolder.c > @@ -412,7 +412,7 @@ HRESULT SHELL32_GetItemAttributes (IShellFolder2 *psf, > LPCITEMIDLIST pidl, LPDWO if (_ILIsDrive (pidl)) { > *pdwAttributes &= > SFGAO_HASSUBFOLDER|SFGAO_FILESYSTEM|SFGAO_FOLDER|SFGAO_FILESYSANCESTOR| > SFGAO_DROPTARGET|SFGAO_HASPROPSHEET|SFGAO_CANLINK; > - } else if (has_guid && HCR_GetFolderAttributes(pidl, &dwAttributes)) { > + } else if (has_guid && _ILIsPidlSimple(pidl) && > HCR_GetFolderAttributes(pidl, &dwAttributes)) { *pdwAttributes = > dwAttributes; > } else if (_ILGetDataPointer (pidl)) { > DWORD file_attr = _ILGetFileAttributes (pidl, NULL, 0); > -- > 2.34.1

Jan. 31, 2022

Re: [PATCH vkd3d v4 1/6] tests: Test matrix multiplication.

by Zebediah Figura (she/her)

On 1/28/22 09:33, Giovanni Mascellani wrote: > Hi, > > Il 28/01/22 14:35, Francisco Casas ha scritto: >> It seems that mul checks whether it is a scalar-scalar, scalar-vector, >> scalar-matrix, vector-scalar, vector-vector, vector-matrix, >> matrix-scalar, >> matrix-vector, or matrix-matrix multiplication, using the equivalent >> to our >> hlsl_type_class. >> >> This difference makes me wonder whether we are wrong assuming float >> and float1 >> are the same in other parts of the codebase, for instance: > > As you say float and float1 are two different things in HLSL, but once > we are deep enough in the pipeline that all the relevant operations > (like mul()) have been lowered, then we can ignore the difference. Basically this, yes. I think we should preserve HLSL type information for the duration of yyparse(), so that we can do type checking, but as soon as we get out we shouldn't be caring at all. > As (I > think) I have said in another email, what I would like to happen is that > at some point everything is converted to vectors (so we don't have > scalars lingering around anymore), but it doesn't seem that the others > agree with me. I personally just don't see it as necessary. In particular there's not really much difference between type->class == HLSL_CLASS_VECTOR && type->dimx == 1 and type->class <= HLSL_CLASS_VECTOR && type->dimx == 1

Jan. 31, 2022

Re: [PATCH vkd3d v4 5/6] vkd3d-shader/hlsl: Parse bitwise XOR.

by Zebediah Figura (she/her)

Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com>

Jan. 31, 2022