May 2019 - Wine-Devel - list.winehq.org

Re: widl: Set name return value (passed by reference) in the alias case alias case in get_user_type.
by Alexandre Julliard Nov. 22, 2020

Nov. 22, 2020

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > So, I admit I don't really know this code, but looking at it (triggered > by a warning issued by GCC development versions), I noticed that this > variable passed by reference is not initialized here. It's initialized when we return a type, and it doesn't need to be initialized on NULL return. The code is correct, but you could probably set the variable to NULL in the caller to silence the warning. -- Alexandre Julliard julliard(a)winehq.org

2 1

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer Nov. 22, 2020

Nov. 22, 2020

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

TestBot and graphics tests
by Francois Gouget Aug. 24, 2020

Aug. 24, 2020

Here are some things I've learned about PCI-passthrough recently, which would be one way (probably the best) to add "real hardware" to the TestBot. I don't want to give anyone false hopes though: this just went from "this is a mysterious thing I need to learn about" to "I think I know how to do it but have not tried it yet". So graphics card PCI-passthrough is now relatively well documented on the Internet and seems to have seen some use-cases that would indicate it may even be reasonably usable. * There are two machines intended to run real GPU tests for Wine: cw1-hd6800 and cw2-gtx560. For now they are only used to run WineTest daily on Windows 8.1, Windows 10 1507, 1709, 1809 and Linux. That's quite a bunch but it would be much better if they were integrated with the TestBot as that would allow developers to submit their own tests. So I had a look at what it would imply to convert them to VM hosts using QEmu + PCI-passthrough. * First one needs a processor with hardware virtualisation support. For Intel that's VT-d. Both machines have an Intel Core 2600 which supports VT-d. Good. * Second the motherboard too needs to support VT-d. Both machines have an ASRock P67 Extreme4 motherboard. Unfortunately UEFI says "unsupported" next to the "VT-d" setting for the motherboard :-( It looks like there was some confusion as to whether the P67 chipset supported VT-d initially. From what I gathered it's only Q67 that does but this caused some manufacturers, among which ASRock, to initially claim support and later retract it. * Then one needs to add the intel_iommu=on option to the kernel command line (resp. amd_iommu). This is should make all the PCI devices appear in /sys/kernel/iommu_groups. But that folder remains empty which confirms that full VT-d support is missing. * Another important aspect is to have a graphics card which is hot-restartable. In some cases when a VM's graphics card is crashed the only way to reset it is to reboot the host. The TestBot is likely to crash the graphics card, particularly if we do a hard-power off on the VMs like we currently do, and it would relaly be annoying to have to reboot the host everytime the graphics card goes belly up. I don't know if the AMD HD6800 and Nvidia GTX560 are suitable but it's quite possible they are not. All I know for now is that we should avoid AMD's R9 line of graphics cards. I still need to find a couple of suitable reasonably lower power graphics cards: one AMD and one Nvidia. * Then one needs to prevent the host from using the graphics card. Usually that's done by having the host use the processor's IGP and dedicating the discrete GPU to the VMs. Unfortunately the 2600's IGP cannot be active when there's a discrete card so that route is denied to us. Fortunately there's quite a bit of documentation on how to shut down not just X but also the Linux virtual consoles to free the GPU and hand it over to the VMs after boot. Doing so means losing KVM access to the host which is a bit annoying in case something goes wrong. So ideally we'd make sure this does not happen in grub's "safe mode" boot option. * Although I have not done any test yet I'm reasonably certain that PCI-passthrough rules out live snapshots: QEmu would have no way to restore the graphics card's internal state. - For Windows VMs that's not an issue: if we provide a power off snapshot the TestBot already knows how to power on the VM and wait for it to boot (as long as the boot is shorter than the connection timeout but it works out usually). - For Linux VM's that's more of an issue: the TestBot will power on the VM as usual. The problem is when it updates Wine: after recompiling everything it deletes the old snapshot and creates a new one from the current state of the VM, which means a live snapshot. So the TestBot will need to be modified so it knows when and how to power off the VM and take a powered off snapshot. * Since the VM has full control of the graphics card QEmu has no access to the content of the screen. That's not an issue for the normal TestBot operation, just for the initial VM setup. Fortunately the graphics card is connected to a KVM so the screen can be accessed through that means. It does mean assigning the mouse and keyboard to the VM too. Should that prove impractical there are a bunch of other options too: VNC, LookingGlass, Synergy, etc. But the less needs to be installed in the VMs the better. * Also the TestBot uses QEmu to take the screenshots. But QEmu does not have access to the content of the screen. The fix is to use a tool to take the screenshots from within the VM and use TestAgent to retrieve them. On Linux there are standard tools we can use. On Windows there's code floating around we can use. So the next steps would be: * Maybe test on my box using the builtin IGP. But that likely won't be very conclusive beyond confirming the snapshot issues, screen access, etc. * Find a suitable AMD or Nvidia graphics card and test that on my box. That would allow me to fully test integration with the TestBot, check for stability issues, etc. * Then see what can be done with the existing cw1 and cw2 boxes. -- Francois Gouget <fgouget(a)codeweavers.com>

4 10

Call for WineConf 2019 presentations
by Aric Stewart Sept. 9, 2019

Sept. 9, 2019

Hello, Again this year I am helping coordinate the talks and presentations! I hope that people find it helpful and useful! Last work worked out well enough that I am sticking to the same rough format. I think it worked for most other people as well! If you would like to give a presentation! Please e-mail wineconf(a)winehq.org or me directly! I will keep the Wiki updated with presentations and scheduling as we get it worked out. When you propose your talk if you have a preference toward a time slot and Saturday or Sunday please express that. General Guidelines: * Please provide an estimate of how long your talk will be. We are shooting for approximate 40 minute slots with between 15-20 minutes of talk and with likely an equal amount of question and discussion time afterward. Generally shorter talks are not an issue, however longer talks will need to be discussed and will be considered based on the rest of the schedule. * Topics should obviously be of interest to the other attendees, i.e., the broader Wine community, but note that that doesn't imply the talk has to be about Wine itself * If you have a preferred time and date for your talk please indicate that to me when you submit your talk. We will try to make it work as best we can. Here are the rough proposed slots, They will be changed and modified as required by the addenda as it gets fleshed out. Understand that even with this shift toward a scheduled day we will not disrupt productive conversation to fit to the schedule. The schedule will warp and flow as required to facilitate the talk, not force the talks to conform to it. This does mean if you are planing to try to attend a given talk you will likely want to arrive a bit early and understand if when you arrive the schedule is either behind or ahead of plan. Daily Slots: 09:00 - 09:40 slot 1 09:45 - 10:25 slot 2 10:30 - 11:00 break 11:00 - 11:40 slot 3 12:00 - 13:00 lunch break 13:00 - 13:40 slot 4 13:45 - 14:25 slot 5 14:30 - 15:00 break 15:00 - 15:40 slot 6 15:45 - 16:25 slot 7 16:25 - 17:00 Overflow time / small group discussion / short presentations We will track proposed presentations on the WineConf Wiki: https://wiki.winehq.org/WineConf2019 Likely we will have open time at the conference which we will propose presentations and fill at the time. We have never had a problem finding things we all want to talk about. thanks! -aric

3 4

[PATCH 1/2] user32/edit: In EM_POSFROMCHAR return correct position for empty lines
by Fabian Maurer July 4, 2019

July 4, 2019

Fix with permission from ROS Jira Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47305 Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> --- dlls/user32/edit.c | 2 +- dlls/user32/tests/edit.c | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/dlls/user32/edit.c b/dlls/user32/edit.c index 3c5331f9dc..6c758c3911 100644 --- a/dlls/user32/edit.c +++ b/dlls/user32/edit.c @@ -1102,7 +1102,7 @@ static LRESULT EDIT_EM_PosFromChar(EDITSTATE *es, INT index, BOOL after_wrap) x -= es->x_offset; } else - x = es->x_offset; + x = (lw > 0 ? es->x_offset : -es->x_offset); if (es->style & ES_RIGHT) x = w - (lw - x); diff --git a/dlls/user32/tests/edit.c b/dlls/user32/tests/edit.c index d0374c02a3..31f20fbc12 100644 --- a/dlls/user32/tests/edit.c +++ b/dlls/user32/tests/edit.c @@ -1142,6 +1142,9 @@ static void test_edit_control_4(void) int lo, hi, mid; int ret; int i; + HDC dc; + SIZE size; + RECT rect; trace("EDIT: Test EM_CHARFROMPOS and EM_POSFROMCHAR\n"); hwEdit = create_editcontrol(ES_AUTOHSCROLL | ES_AUTOVSCROLL, 0); @@ -1251,6 +1254,22 @@ static void test_edit_control_4(void) ret = SendMessageA(hwEdit, EM_POSFROMCHAR, 2, 0); ok(-1 == ret, "expected -1 got %d\n", ret); DestroyWindow(hwEdit); + + /* Test newline when the edit control is scrolled to the right */ + + hwEdit = create_editcontrol(ES_MULTILINE | ES_AUTOHSCROLL | ES_AUTOVSCROLL, 0); + SendMessageA(hwEdit, WM_SETTEXT, 0, (LPARAM)"wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww\r\n\r\n"); + SendMessageA(hwEdit, EM_SETSEL, 40, 40); + + dc = GetDC(hwEdit); + GetClientRect(hwEdit, &rect); + GetTextExtentPoint32A(dc, "w", 1, &size); + ReleaseDC(hwEdit, dc); + lo = (short)LOWORD(SendMessageA(hwEdit, EM_POSFROMCHAR, 42, 0)); + ret = (short)LOWORD(SendMessageA(hwEdit, EM_POSFROMCHAR, 40, 0)); + ret = size.cx * (-40) + ret; + ok(ret == lo, "expected %d got %d\n", ret, lo); + DestroyWindow(hwEdit); } /* Test if creating edit control without ES_AUTOHSCROLL and ES_AUTOVSCROLL -- 2.21.0

3 5

[PATCH 4/4] ddraw/tests: Add test for checking available depth format.
by Jactry Zeng June 16, 2019

June 16, 2019

Signed-off-by: Jactry Zeng <jzeng(a)codeweavers.com> --- dlls/ddraw/tests/ddraw4.c | 44 +++++++++++++++++++++++++++++++++++++++ dlls/ddraw/tests/ddraw7.c | 44 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 88 insertions(+) diff --git a/dlls/ddraw/tests/ddraw4.c b/dlls/ddraw/tests/ddraw4.c index cb7582c1d4..db70fa2423 100644 --- a/dlls/ddraw/tests/ddraw4.c +++ b/dlls/ddraw/tests/ddraw4.c @@ -16002,6 +16002,49 @@ static void test_clipper_refcount(void) DestroyWindow(window); } +static HRESULT CALLBACK enum_available_fmt(DDPIXELFORMAT *format, void *ctx) +{ + DDPIXELFORMAT *z_fmt = ctx; + + if (U1(*format).dwZBufferBitDepth > U1(*z_fmt).dwZBufferBitDepth) + *z_fmt = *format; + + ok(U3(*format).dwZBitMask != 0xffffffff, "Got unexpected depth format: %#x.\n", U3(*format).dwZBitMask); + + return DDENUMRET_OK; +} + +static void test_available_fmt(void) +{ + DDPIXELFORMAT z_fmt; + IDirectDraw4 *ddraw; + IDirect3D3 *d3d3; + HWND window; + HRESULT hr; + + ddraw = create_ddraw(); + ok(!!ddraw, "Failed to create a ddraw object.\n"); + + window = create_window(); + hr = IDirectDraw4_SetCooperativeLevel(ddraw, window, DDSCL_NORMAL); + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); + + hr = IDirectDraw4_QueryInterface(ddraw, &IID_IDirect3D3, (void **)&d3d3); + IDirectDraw4_Release(ddraw); + if (FAILED(hr)) + { + skip("D3D interface is not available, skipping test.\n"); + return; + } + + memset(&z_fmt, 0, sizeof(z_fmt)); + hr = IDirect3D3_EnumZBufferFormats(d3d3, &IID_IDirect3DHALDevice, enum_available_fmt, &z_fmt); + if (FAILED(hr) || !z_fmt.dwSize) + skip("No depth buffer formats available, skipping test.\n"); + + IDirect3D3_Release(d3d3); +} + START_TEST(ddraw4) { DDDEVICEIDENTIFIER identifier; @@ -16134,4 +16177,5 @@ START_TEST(ddraw4) test_gdi_surface(); test_alphatest(); test_clipper_refcount(); + test_available_fmt(); } diff --git a/dlls/ddraw/tests/ddraw7.c b/dlls/ddraw/tests/ddraw7.c index 5f066a6257..83c6671c54 100644 --- a/dlls/ddraw/tests/ddraw7.c +++ b/dlls/ddraw/tests/ddraw7.c @@ -15893,6 +15893,49 @@ static void test_begin_end_state_block(void) DestroyWindow(window); } +static HRESULT CALLBACK enum_available_fmt(DDPIXELFORMAT *format, void *ctx) +{ + DDPIXELFORMAT *z_fmt = ctx; + + if (U1(*format).dwZBufferBitDepth > U1(*z_fmt).dwZBufferBitDepth) + *z_fmt = *format; + + ok(U3(*format).dwZBitMask != 0xffffffff, "Got unexpected depth format: %#x.\n", U3(*format).dwZBitMask); + + return DDENUMRET_OK; +} + +static void test_available_fmt(void) +{ + DDPIXELFORMAT z_fmt; + IDirectDraw7 *ddraw; + IDirect3D7 *d3d7; + HWND window; + HRESULT hr; + + ddraw = create_ddraw(); + ok(!!ddraw, "Failed to create a ddraw object.\n"); + + window = create_window(); + hr = IDirectDraw7_SetCooperativeLevel(ddraw, window, DDSCL_NORMAL); + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); + + hr = IDirectDraw7_QueryInterface(ddraw, &IID_IDirect3D7, (void **)&d3d7); + IDirectDraw7_Release(ddraw); + if (FAILED(hr)) + { + skip("D3D interface is not available, skipping test.\n"); + return; + } + + memset(&z_fmt, 0, sizeof(z_fmt)); + hr = IDirect3D7_EnumZBufferFormats(d3d7, &IID_IDirect3DHALDevice, enum_available_fmt, &z_fmt); + if (FAILED(hr) || !z_fmt.dwSize) + skip("No depth buffer formats available, skipping test.\n"); + + IDirect3D7_Release(d3d7); +} + START_TEST(ddraw7) { DDDEVICEIDENTIFIER2 identifier; @@ -16038,4 +16081,5 @@ START_TEST(ddraw7) test_alphatest(); test_clipper_refcount(); test_begin_end_state_block(); + test_available_fmt(); } -- 2.20.1

4 4

[PATCH 1/4] wined3d: Drop support for WINED3DFMT_D32_UNORM.
by Jactry Zeng June 13, 2019

June 13, 2019

Based on idea from Matteo. Signed-off-by: Jactry Zeng <jzeng(a)codeweavers.com> --- dlls/wined3d/utils.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c index a83d444fba..e9eaf311ad 100644 --- a/dlls/wined3d/utils.c +++ b/dlls/wined3d/utils.c @@ -1777,14 +1777,6 @@ static const struct wined3d_format_texture_info format_texture_info[] = GL_DEPTH_COMPONENT, GL_UNSIGNED_SHORT, 0, WINED3DFMT_FLAG_TEXTURE | WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_SHADOW, ARB_DEPTH_TEXTURE, NULL}, - {WINED3DFMT_D32_UNORM, GL_DEPTH_COMPONENT, GL_DEPTH_COMPONENT, 0, - GL_DEPTH_COMPONENT, GL_UNSIGNED_INT, 0, - WINED3DFMT_FLAG_DEPTH, - WINED3D_GL_EXT_NONE, NULL}, - {WINED3DFMT_D32_UNORM, GL_DEPTH_COMPONENT32_ARB, GL_DEPTH_COMPONENT32_ARB, 0, - GL_DEPTH_COMPONENT, GL_UNSIGNED_INT, 0, - WINED3DFMT_FLAG_TEXTURE | WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_SHADOW, - ARB_DEPTH_TEXTURE, NULL}, {WINED3DFMT_S1_UINT_D15_UNORM, GL_DEPTH_COMPONENT16, GL_DEPTH_COMPONENT16, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_SHORT, 0, WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_SHADOW, -- 2.20.1

3 3

[PATCH v4 1/5] server: Added support for tracking registered device notifications
by Micah N Gorrell June 12, 2019

June 12, 2019

Signed-off-by: Micah N Gorrell <mgorrell(a)codeweavers.com> --- server/protocol.def | 23 +++++++++ server/user.h | 3 +- server/window.c | 112 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 137 insertions(+), 1 deletion(-) diff --git a/server/protocol.def b/server/protocol.def index e450388c17..1645d09d5f 100644 --- a/server/protocol.def +++ b/server/protocol.def @@ -3692,6 +3692,29 @@ struct handle_info @END +/* Register a handle for device notifications */ +(a)REQ(register_device_notification) + user_handle_t recipient; /* handle to a window or service that will receive device events */ +(a)REPLY + user_handle_t handle; /* handle associated with the registration */ +(a)END + + +/* Unregister device notifications for a handle */ +(a)REQ(unregister_device_notification) + user_handle_t notification; /* handle that was previously returned by register_device_notification */ +(a)END + + +/* Return a list of handles that have registered for device notifications */ +(a)REQ(get_device_notifications) +(a)REPLY + int count; /* total count of registered handles */ + VARARG(handles,user_handles); /* registered handles */ +(a)END + + + /* Make the current process a system process */ @REQ(make_process_system) @REPLY diff --git a/server/user.h b/server/user.h index eb1b7ce1e4..282cb63339 100644 --- a/server/user.h +++ b/server/user.h @@ -36,7 +36,8 @@ enum user_object { USER_WINDOW = 1, USER_HOOK, - USER_CLIENT /* arbitrary client handle */ + USER_CLIENT, /* arbitrary client handle */ + USER_DEVNOTIFY }; #define DESKTOP_ATOM ((atom_t)32769) diff --git a/server/window.c b/server/window.c index c9b131cba5..80ac897ea6 100644 --- a/server/window.c +++ b/server/window.c @@ -129,6 +129,19 @@ static struct window *taskman_window; #define WINPTR_TOPMOST ((struct window *)3L) #define WINPTR_NOTOPMOST ((struct window *)4L) +struct device_notification +{ + user_handle_t recipient; /* the window handle to send notifications to */ + user_handle_t handle; /* full handle for this window */ + struct process *process; /* process that owns this notification handle */ + struct list entry; /* entry in global notifications list */ + + /* FIXME: Add support for notification filters */ +}; + +/* global list of handles that have registered for device notifications */ +static struct list device_notifications = LIST_INIT(device_notifications); + /* retrieve a pointer to a window from its handle */ static inline struct window *get_window( user_handle_t handle ) { @@ -2880,3 +2893,102 @@ DECL_HANDLER(set_window_layered_info) } else set_win32_error( ERROR_INVALID_WINDOW_HANDLE ); } + +/* retrieve a pointer to a device_notification from its handle */ +static inline struct device_notification *get_device_notification( user_handle_t handle ) +{ + struct device_notification *ret = get_user_object( handle, USER_DEVNOTIFY ); + if (!ret) set_win32_error( ERROR_INVALID_HANDLE ); + return ret; +} + +/* create a new device notification structure and link it into the global list */ +static struct device_notification *register_device_notification( struct window *recipient ) +{ + struct device_notification *notification; + + if (!recipient) + { + return NULL; + } + + if (!(notification = mem_alloc( sizeof(*notification) ))) goto failed; + if (!(notification->handle = alloc_user_handle( notification, USER_DEVNOTIFY ))) goto failed; + + notification->recipient = recipient->handle; + notification->process = current->process; + /* FIXME: Add support for notification filters */ + + list_add_tail( &device_notifications, &notification->entry ); + + return notification; +failed: + if (notification) + { + if (notification->handle) free_user_handle( notification->handle ); + free( notification ); + } + + return NULL; +} + +static void unregister_device_notification( struct device_notification *notification) +{ + list_remove( &notification->entry ); + free_user_handle( notification->handle ); + memset( notification, 0x55, sizeof(*notification) ); + free( notification ); +} + +static int get_device_notifications( struct user_handle_array *array ) +{ + struct device_notification *notification; + + LIST_FOR_EACH_ENTRY( notification, &device_notifications, struct device_notification, entry ) + { + /* FIXME: Implement notification filtering */ + if (!add_handle_to_array( array, notification->recipient )) return 0; + } + + return 1; +} + +/* register for device notifications */ +DECL_HANDLER(register_device_notification) +{ + struct device_notification *notification = NULL; + struct window *recipient = get_window( req->recipient ); + + reply->handle = 0; + if (!recipient) return; + + if (!(notification = register_device_notification( recipient ))) return; + + reply->handle = notification->handle; +} + +DECL_HANDLER(unregister_device_notification) +{ + struct device_notification *notification = get_device_notification( req->notification ); + if (notification) { + if (notification->process == current->process) unregister_device_notification(notification); + else set_error( STATUS_ACCESS_DENIED ); + } +} + +DECL_HANDLER(get_device_notifications) +{ + struct user_handle_array array; + data_size_t len; + + array.handles = NULL; + array.count = 0; + array.total = 0; + + if (!get_device_notifications( &array )) return; + + reply->count = array.count; + len = min( get_reply_max_size(), array.count * sizeof(user_handle_t) ); + if (len) set_reply_data_ptr( array.handles, len ); + else free( array.handles ); +} -- 2.21.0

3 7

[PATCH v3 1/2] ntdll/directory: Add support for EXT4 case folding per directory
by Gabriel Ivăncescu June 10, 2019

June 10, 2019

This adds support for checking the case-insensitive attribute on ext4 with newer kernels so that Wine can rely on it for performance. It has some conditional processing for perf reasons. Checking for the EXT4_CASEFOLD_FL attribute involves an ioctl, which operates on file descriptors, while all the former checks operated directly on the dir pathname (e.g. statfs). Obviously, it's best to avoid looking up the directory multiple times (also for correctness, so it refers to the same dir). So in the case that we *do* have a file descriptor, then use it everywhere, with e.g. fstatfs. However, to avoid a perf regression or downgrade on systems that don't support the EXT2_IOC_GETFLAGS ioctl (e.g. MacOS, FreeBSD), we continue using statfs and the like directly, this shaves off two syscalls (open/close). But in the case the EXT4_CASEFOLD_FL is not supported on Linux (i.e. on current kernels) or the directory doesn't have it, this will unfortunately involve a bit more syscalls now, because it has to open() and close() the fd, but it shouldn't be too much of a problem. (the fstatfs and fstatat make it less impactful somewhat, so they won't have to lookup the directory again, hopefully mitigating some of it) Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47099 Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- v3: Clean up the code and don't have unused parameters in any case. GET_DIR_CASE_SENSITIVITY_USE_FD is used so it can be as generic as possible for fast tweaking and future expansion on other platforms, if they get something similar. As it is now, on Linux, we always set the EXT4_CASEFOLD_FL flag ourselves. Thus, I can of course remove the .ciopfs old code and keep just the fstatat() call by assuming we always use fd on Linux, if you prefer it that way, to keep the code smaller. I didn't remove it because I didn't want to "hardcode" this assumption, so please let me know if that should be done or not. dlls/ntdll/directory.c | 73 +++++++++++++++++++++++++++++++++++++----- 1 file changed, 65 insertions(+), 8 deletions(-) diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c index bbdbbe9..354c00f 100644 --- a/dlls/ntdll/directory.c +++ b/dlls/ntdll/directory.c @@ -115,6 +115,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(file); /* just in case... */ #undef VFAT_IOCTL_READDIR_BOTH +#undef EXT2_IOC_GETFLAGS +#undef EXT4_CASEFOLD_FL #ifdef linux @@ -130,12 +132,25 @@ typedef struct /* Define the VFAT ioctl to get both short and long file names */ #define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, KERNEL_DIRENT [2] ) +/* Define the ext2 ioctl for handling extra attributes */ +#define EXT2_IOC_GETFLAGS _IOR('f', 1, long) + +/* Case-insensitivity attribute */ +#define EXT4_CASEFOLD_FL 0x40000000 + #ifndef O_DIRECTORY # define O_DIRECTORY 0200000 /* must be directory */ #endif #endif /* linux */ +/* Use a file descriptor for the case-sensitivity check if we have to */ +#if defined(EXT2_IOC_GETFLAGS) && defined(EXT4_CASEFOLD_FL) +#define GET_DIR_CASE_SENSITIVITY_USE_FD 1 +#else +#define GET_DIR_CASE_SENSITIVITY_USE_FD 0 +#endif + #define IS_OPTION_TRUE(ch) ((ch) == 'y' || (ch) == 'Y' || (ch) == 't' || (ch) == 'T' || (ch) == '1') #define IS_SEPARATOR(ch) ((ch) == '\\' || (ch) == '/') @@ -1109,18 +1124,35 @@ static int get_dir_case_sensitivity_attr( const char *dir ) } #endif +/*********************************************************************** + * get_dir_case_sensitivity_ioctl + * + * Checks if the specified directory is case sensitive or not. Uses ioctl(2). + */ +static int get_dir_case_sensitivity_ioctl(int fd) +{ +#if defined(EXT2_IOC_GETFLAGS) && defined(EXT4_CASEFOLD_FL) + int flags; + if (ioctl(fd, EXT2_IOC_GETFLAGS, &flags) != -1 && (flags & EXT4_CASEFOLD_FL)) + return FALSE; +#endif + return -1; +} + /*********************************************************************** * get_dir_case_sensitivity_stat * * Checks if the volume containing the specified directory is case - * sensitive or not. Uses statfs(2) or statvfs(2). + * sensitive or not. Uses (f)statfs(2), (f)statvfs(2), or fstatat(2). */ -static BOOLEAN get_dir_case_sensitivity_stat( const char *dir ) +static BOOLEAN get_dir_case_sensitivity_stat( const char *dir, int fd ) { #if defined(__APPLE__) || defined(__FreeBSD__) || defined(__FreeBSD_kernel__) struct statfs stfs; - if (statfs( dir, &stfs ) == -1) return FALSE; + if (fd != -1 && fstatfs( fd, &stfs ) == -1) return FALSE; + if (fd == -1 && statfs( dir, &stfs ) == -1) return FALSE; + /* Assume these file systems are always case insensitive on Mac OS. * For FreeBSD, only assume CIOPFS is case insensitive (AFAIK, Mac OS * is the only UNIX that supports case-insensitive lookup). @@ -1157,7 +1189,9 @@ static BOOLEAN get_dir_case_sensitivity_stat( const char *dir ) #elif defined(__NetBSD__) struct statvfs stfs; - if (statvfs( dir, &stfs ) == -1) return FALSE; + if (fd != -1 && fstatvfs( fd, &stfs ) == -1) return FALSE; + if (fd == -1 && statvfs( dir, &stfs ) == -1) return FALSE; + /* Only assume CIOPFS is case insensitive. */ if (strcmp( stfs.f_fstypename, "fusefs" ) || strncmp( stfs.f_mntfromname, "ciopfs", 5 )) @@ -1170,7 +1204,9 @@ static BOOLEAN get_dir_case_sensitivity_stat( const char *dir ) char *cifile; /* Only assume CIOPFS is case insensitive. */ - if (statfs( dir, &stfs ) == -1) return FALSE; + if (fd != -1 && fstatfs( fd, &stfs ) == -1) return FALSE; + if (fd == -1 && statfs( dir, &stfs ) == -1) return FALSE; + if (stfs.f_type != 0x65735546 /* FUSE_SUPER_MAGIC */) return TRUE; /* Normally, we'd have to parse the mtab to find out exactly what @@ -1180,6 +1216,13 @@ static BOOLEAN get_dir_case_sensitivity_stat( const char *dir ) * This will break if somebody puts a file named ".ciopfs" in a non- * CIOPFS directory. */ + if (fd != -1) + { + if (fstatat( fd, ".ciopfs", &st, AT_NO_AUTOMOUNT ) == 0) + return FALSE; + return TRUE; + } + cifile = RtlAllocateHeap( GetProcessHeap(), 0, strlen( dir )+sizeof("/.ciopfs") ); if (!cifile) return TRUE; strcpy( cifile, dir ); @@ -1201,16 +1244,30 @@ static BOOLEAN get_dir_case_sensitivity_stat( const char *dir ) * get_dir_case_sensitivity * * Checks if the volume containing the specified directory is case - * sensitive or not. Uses statfs(2) or statvfs(2). + * sensitive or not. Uses multiple methods, depending on platform. */ static BOOLEAN get_dir_case_sensitivity( const char *dir ) { + int case_sensitive, fd = -1; + #if defined(HAVE_GETATTRLIST) && defined(ATTR_VOL_CAPABILITIES) && \ defined(VOL_CAPABILITIES_FORMAT) && defined(VOL_CAP_FMT_CASE_SENSITIVE) - int case_sensitive = get_dir_case_sensitivity_attr( dir ); + case_sensitive = get_dir_case_sensitivity_attr( dir ); if (case_sensitive != -1) return case_sensitive; #endif - return get_dir_case_sensitivity_stat( dir ); + + if (GET_DIR_CASE_SENSITIVITY_USE_FD) + { + if ((fd = open(dir, O_RDONLY | O_NONBLOCK | O_LARGEFILE)) == -1) + return TRUE; + if ((case_sensitive = get_dir_case_sensitivity_ioctl(fd)) != -1) + goto end; + } + case_sensitive = get_dir_case_sensitivity_stat(dir, fd); + +end: + if (fd != -1) close(fd); + return case_sensitive; } -- 2.21.0

4 11

Wine and mingw-w64 cooperation
by Jacek Caban June 6, 2019

June 6, 2019

Hi all, [I'm addressing it to both mingw-w64-public and wine-devel] As most of you know, Wine and mingw-w64 have a lot in common and cooperate to some extend for quite a while. There have been talks about tightening this relationship for years. Recent Wine move to using PE files for its builds led us to revisit those ideas. My feeling so far is that there is an agreement among people I heard from that it's a good direction for both projects to have mingw-w64 under an umbrella of the Wine project. It would be great to move forward with this. Let me discuss a few aspects of the idea. - Infrastructure mingw-w64 currently mostly depends heavily on SourceForge. While I'm thankful to SF for years of free support, it's doesn't feel like an optimal choice those days. Wine has its own infrastructure that mingw-w64 could use right away. Moving things like mailing list, bug tracker, etc. is straightforward to do, except for one thing... how should it be called? Which brings us to the next item. - mingw-w64 name There have been talks about rebranding mingw-w64 for a long time (longer than I am in joined the project). While it's a good name for a branch, an established project that is no longer related to mingw.org could have a better branding. Kai mentioned that ironcrate was considered as some point, but to my knowledge no action was taken at that time. Alexandre offered lately that Wine brand could be used for mingw-w64 as well. I personally like the idea. Wine is already well recognised brand and brings roughly right associations. So... how about WineSDK? - Source code sharing Technically, we could share much more code than we currently do. Duplicating efforts is quite suboptimal for everyone. Right now mingw-w64 imports a number of platform headers and widl tool from Wine via wine-import.sh script. Wine has a few headers imported from mingw-w64 as well. It works to some extend, but the fact is that we still duplicate more than we share. I'm not yet sure how to fix that entirely, but I'd like us to have a workflow that would limit the duplication. - Testing Wine has a TestBot and a number of test cases, which is a great tool for developers to make sure their patches are right. mingw-w64 does not have such thing and mostly depends on developers doing their own testing and regression reports after the patch is committed. We could integrate mingw-w64 testing with Wine TestBot to make sure that we don't break things (well, at least limit that possibility). I believe that it would nicely accelerate mingw-w64 development workflow as well as ensure that mingw-w64+Wine don't regress. - WineConf The annual Wine conference is a nice chance to meet other contributors in person: https://wiki.winehq.org/WineConf It would be great mingw-w64 developers there as well. Any ideas, comments and thoughts on this topics are welcomed. Thanks, Jacek

9 18