September 2022 - Wine-Devel

WineConf - starting next week!

by Jeremy White

Hi folks, We are excited to welcome you in person to the 2022 Wine Conference, held in conjunction with the X.org developers conference (XDC) and the FOSS XR conference. The XDC conference will start on Tuesday morning, October 4th. The program is here: https://indico.freedesktop.org/event/2/timetable/#all.detailed The official events start at 8:30 am, but we will have coffee and pastries available from 7:30 on Tuesday and 8 on Wednesday and Thursday. WineConf proper will start on Wednesday morning, October 5th, with Alexandre's keynote. We expect everyone attending to be vaccinated and to be respectful of people that are trying to avoid catching COVID. Masks are mandatory, except when presenting or eating. The plan is to gather at Brit's Pub, both Monday and Tuesday in the late afternoon to welcome arrivals. We’ll try to have a table with some sort of a sign, and folks can connect, have a drink, and then perhaps group up to explore alternate food. Note that if the weather is nice, we may be up on the roof, so explore far to find us. We will be on the Minneapolis campus of St. Thomas, which is a mildly confusing campus. We have given instructions and a picture to guide you here: https://indico.freedesktop.org/event/2/page/10-attending-xdc-wineconf-foss-… We are working on the remote experience, and expect to have streaming of all events available. The above page will have those details just as soon as they are finalized. We have a page of instructions for folks that will be presenting: https://indico.freedesktop.org/event/2/page/18-speaker-instructions We are also excited to announce the happy hour taking place on Wednesday, from 6:00 pm until 8:00 pm. The hope is that all three projects can mingle and socialize and enjoy the return of in person meetings. We will again use a Matrix chat room just for the conference. Matrix has a variety of apps, and Element, the default one is easy to configure on many devices, including mobile phones. The link to that channel is here: https://matrix.to/#/#xdc-wineconf-fossxr-2022:matrix.org We find the chat channel a good place to learn what restaurants and bars are chosen, and just a good way to track the social aspects of the conference. We look forward to seeing you next week! Cheers, Jeremy

Sept. 29, 2022

Re: Winelib portability on USB booted system

by Stefan Dösinger

Hi, Wine itself doesn't care how you boot. I am running a pile of games on systems booted from NFS. It is possible that there is a difference between the two systems. Are they using the same distro, and same version of the distro? Three things to check: 1) Stupidity check, is the file xerase.exe.so actually there and not e.g. a dead symlink? What if you cd into the directory and run it from there? 2) Does winecfg work? If it doesn't, something's flawed with the Wine installation 3) use the +module debug channel (WINEDEBUG=module wine ...). It will be spammy. Search for xerase.exe and see if it reports any library load issues in xerase or its dependencies. Good luck, Stefan > Am 28.09.2022 um 22:44 schrieb Brent Burkholder <bburk(a)extremeprotocol.com>: > > Update: decided to delete the extra links in dosdevices… no change > > If I don’t use sudo (which the program actually needs, so this is just for a data point) then instead I get > wine: failed to start L”C:\\XERASxlnx\\xerase.exe.so” > > > > From: Brent Burkholder > Sent: Wednesday, September 28, 2022 3:33 PM > To: wine-devel(a)winehq.org > Subject: Winelib portability on USB booted system > > > We had originally tried a software port using winelib 5, and it was just a no-go in functionality. Wine 7 is working a LOT better for what we’re doing (Windows GUI with ability to do low level Linux hooks), so thank you all for all of the hard work! > > > Unfortunately, even though the software is running great on our development machine, when I try to run it on another system (configured USB boot, should have the same version of wine, etc) it doesn’t run at all with pretty much no feedback. Can anyone help me understand why, or what I need to be looking for? > > Both systems are starting with the same script (I’ve done a lot of variations, directly launching myself, and it doesn’t seem to matter.) > > #!/bin/bash > sudo env “PATH=/opt/wine-devel/bin:$PATH” /opt/wine-devel/bin/wine xerase.exe.so > > > The compiling system starts right up. The USB boot system that I’m trying to run it on gives me > > 0078:fixme:wineusb:add_unix_device Interface 1 has 2 alternate settings; using the first one. > Wine: failed to start L”F:\\home\\test\.wine\\drive_c\\XERASxlnx\\xerase.exe.so” > Application could not be started, or no application associated with the specified file. > ShellExecuteEx failed: File not found. > > If I do the command directly instead of through a script I get exactly the same thing. > > If I cut out the env path stuff (1), or keep the path but call just wine (2), or just call wine (bashrc has the path now) same results > • sudo /opt/wine-devel/bin/wine xerase.exe.so > • sudo env “PATH=/opt/wine-devel/bin:$PATH” wine xerase.exe.so > • sudo wine xerase.exe.so > • sudo wine /home/test/.wine/drive_c/XERASxlnx/xerase.exe.so > > 0078:fixme:wineusb:add_unix_device Interface 1 has 2 alternate settings; using the first one. > Wine: failed to start L”F:\\home\\test\.wine\\drive_c\\XERASxlnx\\xerase.exe.so” > Application could not be started, or no application associated with the specified file. > ShellExecuteEx failed: File not found. > > > So… observations… > • Not sure where F: is coming from? C: I might understand (though frankly, I’d just as soon the program realize we’re using the unix file structure, not any virtualized windows stuff for what we’re doing) > > > When I look at .wine/dosdevices on both systems… > > Build/working system: > z: -> / > c: -> ../drive_c > <com devices> > . > .. > > Not working USB booted system: > z: -> / > c: -> ../drive_c > d:: -> /dev/sda1 > g:: -> /dev/sda > f:: -> /dev/sd5 > e:: -> /dev/sda2 > <com devices> > d: -> /boot/efi > f: -> / > . > .. > > Any suggestions in changes to compilation or environmental variables to get wine to start running it? > > I guess I could delete d::, g::, f::, e::, d:, and f: and see if that makes a difference but figured I’d ask the question first > > > > > > Brent Burkholder > Extreme Protocol Solutions > bburk(a)extremeprotocol.com

Sept. 29, 2022

wine-7.0.1-rc1 Available

by Michael Stefaniuc

Hello, I have pushed wine-7.0.1-rc1 (217323fff7da7f318a30348b4665ace55d04c50b) to https://github.com/mstefani/wine-stable/tree/stable https://people.redhat.com/mstefani/wine/stable/ And created the draft merge request https://gitlab.winehq.org/wine/wine/-/merge_requests/955 Bugs and most other fixes are from the 7.1 to 7.8 era. Previous x.0.1 releases would include only stuff from x.1 to x.4 or x.5 devel versions to fill the "budget" of about 100 cherry picks. Also this is lowest amount of bugs fixed since 1.8.1. The "use long" commits were a major nuisance so I might have missed bugs due to the long patch dependency chains. If your favorite bug is missing please let me know. The rest of the commits picked are small and found by keywords in the commit message. The longer commit messages help here. There are a bunch of "newer" (> 7.8) commits and those are mostly there to fix the currently "broken in 7.0 too" tests. The usual plan is to wait for feedback for 7-10 days before the real 7.0.1 is released. There will be definitely a -rc2 as I need to cherry pick or backport some of the gitlab related commits. What's new in this release: - Various bug fixes - Translation updates ---------------------------------------------------------------- Bugs fixed in 7.0.1 (total 31): 12732 Nota Bene crashes on install 44202 undname.c fails to parse symbols with rvalue-reference semantics '&&' 45916 x64dbg fails to load debuggee, needs ThreadScheduler_ScheduleTask 50352 Maximum sockets per process is set very low 50370 Gothic 1 doesn't start correctly when screen resolution of the game matches display resolution 50433 'MsiBreak' custom action debugging aid should use custom action's name from 'CustomAction' table (currently uses 'Target' field) 50869 Killing Wine process in Wine 6.5 doesn't terminate the application because of the new use of start.exe 51163 WinOffice Pro 5.3 stops after splashscreen, needs WMI class SoftwareLicensingProduct 51619 advapi32:registry fails in Wine because French & German timezone name translations are too long 51900 regression: REAPER scrollbars flash between themed and non-themed 52163 postgresql-9.3 installer expects scrrun:filesys_GetTempName to return filename with TMP suffix 52298 Opening PPT with Freeoffice Presentations crashes on unimplemented function ole32.dll.OleConvertIStorageToOLESTREAMEx 52426 BCryptSignHash mishandles empty arguments 52434 Light Blue theme has rendering errors in tree views 52436 In Light Blue theme, checkable toggle buttons (BS_AUTOCHECKBOX) look unchecked when hovered 52446 Normal dlls with native subsystem id are no longer processed when importing system dlls with uppercase names 52476 QuickLOAD (VB5 app) input value is changed by factor 10 52494 shell32 progman_dde tests crash if run immediately after prefix creation 52510 alt:V mod for Grand Theft Auto V fails due to missing concrt140._Byte_reverse_table(a)details@Concurrency@@3QBEB 52562 advapi32:registry fails in Wine because some French timezone name translations are too long 52581 Internet MIDI crashes with Light Blue theme enabled 52583 ApiSetView does not display export ordinals correctly 52616 SteelSeries GG installer crashes on unimplemented function setupapi.dll.SetupQueryInfVersionInformationW 52618 32-bit EXEs do not launch from build dir on macOS 10.14 in WOW64 52626 MahjongSoul needs unimplemented function combase.dll.RoSetErrorReportingFlags 52667 DTS Master Audio Suite can't select save file location when wine's "Light" theme is used 52679 Anno 1602 / 1602 A.D. graphics too dark / black 52704 FreeHand 9 demo: invalid handle exception (0xc0000008) when attaching uxtheme.dll 52787 Invalid function prototype for "RegisterUserApiHook" when compiling for C++ 52953 GuiPy crashes on unimplemented function xmllite.dll.CreateXmlReaderInputWithEncodingCodePage 53430 urlmon:url fails due to unexpected redirection ---------------------------------------------------------------- Changes since 7.0: Alex Henrie (14): explorer: Only try to destroy the IShellWindows object if it exists. tzres: Inform translators of 31-character limit. po: Update Catalan translation. msi: Fix memory leak in get_fusion_filename (Coverity). winhttp: Fix memory leak on error path in WinHttpCrackUrl (Coverity). adsldp: Fix memory leak on error path in search_ExecuteSearch (Coverity). conhost: Fix memory leak on error path in create_screen_buffer (cppcheck). dbghelp: Fix memory leak on error path in dwarf2_read_range (cppcheck). ws2_32: Fix memory leak on error path in get_local_ips (cppcheck). ws2_32: Fix memory leaks on error paths in unix_gethostby* (scan-build). sane: Fix memory leak in create_item (Coverity). winspool: Fix memory leaks on error path in DeviceCapabilitiesA (Coverity). shell32: Fix sizeof argument in DoPaste (Coverity). mciwave: Fix bad free in MCI_SendCommandAsync (Coverity). Alexandre Julliard (9): user.exe: Make sure that the thunk selector doesn't get freed. makefiles: Disable printf format warnings for non-PE msvcrt modules. README: Mention Gitlab. kernel32/tests: Fix affinity test when there are too many CPUs. ntdll/tests: Fix affinity test when there are too many CPUs. secur32/tests: Update for new WineHQ certificate. urlmon/tests: Run tests against the gitlab server to avoid redirects. webservices/tests: Mark tests that fail on 64-bit as todo. wininet/tests: Update WineHQ certificate. Alistair Leslie-Hughes (1): msado15: Return valid object in Recordset::Clone. Andrey Gusev (1): d3d11: Implement the ID3DUserDefinedAnnotation interface. Aurimas Fišeras (1): po: Update Lithuanian translation. Bastien Orivel (1): ws2_32: Fix setsockopt(TCP_NODELAY) when optlen is less than 4. Ben Shefte (1): ntdll: Use case insensitive comparison in is_import_dll_system(). Bhavesh Davda (1): wined3d: Add GPU information for NVIDIA Ampere A10 and AMD Radeon Pro V620 GPUs. Brandon Moore (1): msadpm: Stop decoding instead of crashing for invalid adpcm data. Brendan Shanks (1): makefiles: On macOS, use @rpath instead of @loader_path when building Unix libs. David Kahurani (1): oleaut32: Do not skip the first decimal digit in VarParseNumFromStr(). Dmitry Timoshkov (2): ieframe: Clear a being invalidated history entry. ieframe: Initialize new history log entry. Eric Pouech (3): start: Wrap child inside a job so it gets killed when start.exe terminates. include/msvcrt: Redefine towlower* & towupper* with wint_t types. msacm32: Use extended structure definition for driver configuration. Fabian Maurer (4): printui: Use LocalFree for memory allocated by LocalAlloc (Coverity). mfplay: Prevent usage of uninitialized pointer in error case (Coverity). mfplat: Prevent use after free (Coverity). shell32: Prevent user after free in error case (Coverity). Floris Renaud (1): po: Update Dutch Translation. François Gouget (8): po: Fix the French translation of 'code page'. po: Fix backslash duplication in a French translation. po: Remove a space before a linefeed in the French translation. po: Remove spaces before linefeeds in the Spanish translation. po: Remove a space before a linefeed in the Chinese translation. po: Fix an accelerator shortcut in the Norwegian Bokmål translation. inetmib1: Avoid overflows in IPv4 address comparisons. inetmib1: Fix the IPv4 address network order for comparisons. Gabriel Ivăncescu (3): ddraw: Use WINED3D_SWAPCHAIN_NO_WINDOW_CHANGES only if window is not in foreground. jscript: Handle NULL return pointers in all constructors. mshtml: Fix leak on failure in return_nsstr. Gerald Pfeifer (1): iphlpapi: Zero-init prefix_len to avoid a compiler warning. Gijs Vermeulen (1): setupapi: Add SetupQueryInfVersionInformationA/W stub. Giovanni Mascellani (3): winegstreamer: Do not block forever if EOS races with command queue. mfplat: Avoid a race condition when releasing a tracked sample. mfmediaengine: Fix a memory leak. Hans Leidekker (1): msi: Use custom action name for MsiBreak handling. Henri Verbeet (2): d3d11/tests: Add some tests for ID3DUserDefinedAnnotation. wined3d: Add GPU information for NVIDIA Tesla T4. Kevin Puetz (1): winegcc: --out-implib needs to propagate -m32/-m64 to winebuild. Lauri Kenttä (2): po: Update Finnish translation. readme: Update Finnish translation. Louis Lenders (2): wbemprox: Add some properties of SoftwareLicensingProduct class. ole32: Add stub for OleConvertIStorageToOLESTREAMEx. Martin Storsjö (1): ntdll: Zero-initialize the syscall_frame used for starting threads on ARM/ARM64. Matteo Bruni (1): combase: Add RoSetErrorReportingFlags() stub. Michael Stefaniuc (1): tools: Get the ANNOUNCE bug list from the stable-notes git notes. Mohamad Al-Jaf (1): hid: Implement HidD_GetPhysicalDescriptor. Nikolay Sivov (4): comctl32/listview: Initialize subitem text buffer before drawing each subitem. uxtheme: Fix double free on registry key handle. xmllite/reader: Implement CreateXmlReaderInputWithEncodingCodePage(). evr/sample: Avoid a race condition when releasing a tracked sample. Paul Gofman (1): concrt140: Add ?_Byte_reverse_table(a)details@Concurrency@@3QBEB data export. Piotr Caban (2): ucrtbase: Add support for r-value demangling in unDName. msvcr100: Improve ThreadScheduler_ScheduleTask_loc stub. Piotr Kleski (1): bcrypt: Return BCryptSignHash len when only output is NULL. Robert Wilhelm (2): scrrun: Add test for GetTempName. scrrun: Generate temp name with tmp suffix. Rémi Bernon (1): mf: Handle MESourceSeeked and MEStreamSeeked state change events. Santino Mazza (2): ncrypt/tests: Test key import of an rsa key. ncrypt: Make NCryptOpenStorageProvider return a valid stub pointer. Saulius Krasuckas (1): ntdll: Check __WINE_PE_BUILD instead of compiler macros. Zebediah Figura (12): ws2_32/tests: Add tests for WSAStartup(). ws2_32: Always fill the WSADATA structure in WSAStartup(). ws2_32: Cap the negotiated winsock version to 1.1 or 2.2. ws2_32: Return 32767 or 0 in the iMaxSockets field. ws2_32: Return 65467 or 0 in the iMaxUdpDg field. ws2_32: Return WSAEFAULT instead of WSAEINVAL from WSAStartup() if "data" is NULL. configure: Fix the check for CAPI support. d3dx9: Don't mark annotation variables as dirty. winegstreamer: Release stream_cs on error in stream_thread(). setupapi: Avoid leaking subKey in SETUPDI_AddDeviceInterfaces(). server: Allocate enough space for the backslash in dup_nt_name() (Valgrind). tiff: Explictly link to zlib. Zhiyi Zhang (12): user32/tests: Test painting standard scroll bars in hovered state. user32: Draw standard scroll bars in hovered state only when they were previously painted by DefWinProc(). comctl32/button: Use pressed state when a pushlike checkbox or radio button is checked and hovered. comctl32/treeview: Do not draw client edge without WS_EX_CLIENTEDGE. light.msstyles: Do not use transparent treeview parts. uxtheme/tests: Add IsThemePartDefined() tests. uxtheme: Search parts of any state in IsThemePartDefined(). light.msstyles: Add Menu stub class. user32/tests: Test NUMCOLORS for display DCs. win32u: Return -1 for NUMCOLORS with 8-bit display DCs. include: Avoid a C++ keyword for RegisterUserApiHook(). light.msstyles: Use stretch sizing type for scroll bar arrow button background. -- Michael Stefaniuc mstefani(a)winehq.org

Sept. 28, 2022

RE: Winelib portability on USB booted system

by Brent Burkholder

Update: decided to delete the extra links in dosdevices... no change If I don't use sudo (which the program actually needs, so this is just for a data point) then instead I get wine: failed to start L"C:\\XERASxlnx\\xerase.exe.so" From: Brent Burkholder Sent: Wednesday, September 28, 2022 3:33 PM To: wine-devel(a)winehq.org Subject: Winelib portability on USB booted system We had originally tried a software port using winelib 5, and it was just a no-go in functionality. Wine 7 is working a LOT better for what we're doing (Windows GUI with ability to do low level Linux hooks), so thank you all for all of the hard work! Unfortunately, even though the software is running great on our development machine, when I try to run it on another system (configured USB boot, should have the same version of wine, etc) it doesn't run at all with pretty much no feedback. Can anyone help me understand why, or what I need to be looking for? Both systems are starting with the same script (I've done a lot of variations, directly launching myself, and it doesn't seem to matter.) #!/bin/bash sudo env "PATH=/opt/wine-devel/bin:$PATH" /opt/wine-devel/bin/wine xerase.exe.so The compiling system starts right up. The USB boot system that I'm trying to run it on gives me 0078:fixme:wineusb:add_unix_device Interface 1 has 2 alternate settings; using the first one. Wine: failed to start L"F:\\home\\test\.wine\\drive_c\\XERASxlnx\\xerase.exe.so" Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: File not found. If I do the command directly instead of through a script I get exactly the same thing. If I cut out the env path stuff (1), or keep the path but call just wine (2), or just call wine (bashrc has the path now) same results 1. sudo /opt/wine-devel/bin/wine xerase.exe.so 2. sudo env "PATH=/opt/wine-devel/bin:$PATH" wine xerase.exe.so 3. sudo wine xerase.exe.so 4. sudo wine /home/test/.wine/drive_c/XERASxlnx/xerase.exe.so 0078:fixme:wineusb:add_unix_device Interface 1 has 2 alternate settings; using the first one. Wine: failed to start L"F:\\home\\test\.wine\\drive_c\\XERASxlnx\\xerase.exe.so" Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: File not found. So... observations... 1. Not sure where F: is coming from? C: I might understand (though frankly, I'd just as soon the program realize we're using the unix file structure, not any virtualized windows stuff for what we're doing) When I look at .wine/dosdevices on both systems... Build/working system: z: -> / c: -> ../drive_c <com devices> . .. Not working USB booted system: z: -> / c: -> ../drive_c d:: -> /dev/sda1 g:: -> /dev/sda f:: -> /dev/sd5 e:: -> /dev/sda2 <com devices> d: -> /boot/efi f: -> / . .. Any suggestions in changes to compilation or environmental variables to get wine to start running it? I guess I could delete d::, g::, f::, e::, d:, and f: and see if that makes a difference but figured I'd ask the question first Brent Burkholder Extreme Protocol Solutions bburk(a)extremeprotocol.com<mailto:bburk(a)extremeprotocol.com>

Sept. 28, 2022

Winelib portability on USB booted system

by Brent Burkholder

We had originally tried a software port using winelib 5, and it was just a no-go in functionality. Wine 7 is working a LOT better for what we're doing (Windows GUI with ability to do low level Linux hooks), so thank you all for all of the hard work! Unfortunately, even though the software is running great on our development machine, when I try to run it on another system (configured USB boot, should have the same version of wine, etc) it doesn't run at all with pretty much no feedback. Can anyone help me understand why, or what I need to be looking for? Both systems are starting with the same script (I've done a lot of variations, directly launching myself, and it doesn't seem to matter.) #!/bin/bash sudo env "PATH=/opt/wine-devel/bin:$PATH" /opt/wine-devel/bin/wine xerase.exe.so The compiling system starts right up. The USB boot system that I'm trying to run it on gives me 0078:fixme:wineusb:add_unix_device Interface 1 has 2 alternate settings; using the first one. Wine: failed to start L"F:\\home\\test\.wine\\drive_c\\XERASxlnx\\xerase.exe.so" Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: File not found. If I do the command directly instead of through a script I get exactly the same thing. If I cut out the env path stuff (1), or keep the path but call just wine (2), or just call wine (bashrc has the path now) same results 1. sudo /opt/wine-devel/bin/wine xerase.exe.so 2. sudo env "PATH=/opt/wine-devel/bin:$PATH" wine xerase.exe.so 3. sudo wine xerase.exe.so 4. sudo wine /home/test/.wine/drive_c/XERASxlnx/xerase.exe.so 0078:fixme:wineusb:add_unix_device Interface 1 has 2 alternate settings; using the first one. Wine: failed to start L"F:\\home\\test\.wine\\drive_c\\XERASxlnx\\xerase.exe.so" Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: File not found. So... observations... 1. Not sure where F: is coming from? C: I might understand (though frankly, I'd just as soon the program realize we're using the unix file structure, not any virtualized windows stuff for what we're doing) When I look at .wine/dosdevices on both systems... Build/working system: z: -> / c: -> ../drive_c <com devices> . .. Not working USB booted system: z: -> / c: -> ../drive_c d:: -> /dev/sda1 g:: -> /dev/sda f:: -> /dev/sd5 e:: -> /dev/sda2 <com devices> d: -> /boot/efi f: -> / . .. Any suggestions in changes to compilation or environmental variables to get wine to start running it? I guess I could delete d::, g::, f::, e::, d:, and f: and see if that makes a difference but figured I'd ask the question first Brent Burkholder Extreme Protocol Solutions bburk(a)extremeprotocol.com<mailto:bburk(a)extremeprotocol.com>

Sept. 28, 2022

Re: [PATCH 2/2] strmbase: Reset the renderer's state event when flushing.

by Gabriel Ivăncescu

On 16/11/2020 23:07, Zebediah Figura (she/her) wrote: > On 11/3/20 6:43 AM, Gabriel Ivăncescu wrote: >> On 02/11/2020 20:11, Zebediah Figura wrote: >>> This patch isn't wrong per se, but it's less pretty than it could be, >>> and exposes some of the still-present problems with renderer locking. >>> Sorry, I'll need more than a little time to review this. >>> >> >> Understood. Only thing is that I won't be able to send a new version of >> the media detector patches until then, though, because it depends on it. >> (that is why I haven't) >> > > For the sake of transparency, the basic problem is that this patch > treats "filter->sink.flushing" as protected by "csRenderLock", when in > fact it's not. The lock taken in sink_begin_flush() *does* prevent the > race you describe, but it does so in a very non-obvious way. I'm > currently working on restructuring some things so that "flushing" is > protected by a lock which we can safely take from the streaming thread, > but it may take a while (and may not make it in by code freeze). > Hi Zeb, Sorry if this is already done, but I was going through some of my stuff, it seems I still need this patch to have those tests work (and subsequently the other things in qedit). I've no idea how hard this would be to restructure properly, so maybe it's already in progress or done in some way, but if not it's probably just a reminder. Or if there's a better way now to fix it then please let me know.

Sept. 26, 2022

Wine staging 7.18 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 7.18 (514 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * ws2_32: Return a valid value for WSAIoctl SIO_IDEAL_SEND_BACKLOG_QUERY. * dwrite: Test IDWriteTextFormat with nonexistent font. * dwrite: Use MapCharacters for non-visual characters. * dwrite: Use MapCharacters for dummy line metrics. Added: * None Updated: * server-unix_name * ntdll-Junction_Points Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Sept. 23, 2022

Re: What macOS SDK is being tested against on gitlab?

by Dean Greer

Hi Alexandre, > At this point I don't think we care about testing i386 builds for macOS. We should soon have a way of building the 32-bit PE dlls as part of the 64-bit build, which should be the default going forward. Was this implementation confirmed to also work on legacy macOS versions that still natively support 32Bit? More of a concern is recent macOS SDKs are marking functions as depreciated, when those get swapped out with the newer version (usually just renamed), if the old name isn’t mapped building against older SDKs will be broken. Keeping wine(64) buildable against MacOSX10.13.SDK would be the minimum for comparability's sake, still being able to build against MacOSX10.11 (or MacOSX10.10.SDK final revision) would be more ideal at least being buildable against 10.13 would be required to still support the 32Bit wine loader. On Fri, Sep 23, 2022 at 10:43 AM Alexandre Julliard <julliard(a)winehq.org> wrote: > Dean Greer <gcenx83(a)gmail.com> writes: > > > Hi Alexandre, > > > >> Yes, it's a dedicated Mac Mini that we have setup for that purpose, > > currently running macOS 12.5.1. I installed a number of Homebrew > > packages that are necessary for building Wine. If there are specific > > queries you'd like me to run on that box I'd be happy to. > > > > The minimum packages would be; > > > > # build deps > > brew install bison \ > > pkg-config \ > > mingw-w64 > > > > # runtime deps > > brew install freetype \ > > gphoto2 \ > > gst-plugins-base \ > > krb5 \ > > mingw-w64 \ > > molten-vk \ > > sdl2 > > > > # casks > > brew install --cask xquartz > > > > PATH would need to be appended with $(brew --prefix krb5)/bin > > > > A copy of MacOSX10.13.sdk from Xcode9.3 (or later version of Xcode9) > placed into /Library/Developer/CommandLineTools/SDKs/ then the testbot > could also test compiling i386 wine. > > > > configure/make wine64 then set the following before running configure > for i386; > > export > SDKROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk" > > export > PKG_CONFIG_LIBDIR="/opt/X11/lib/pkgconfig:/opt/X11/share/pkgconfig" > > > > That would at least cover the basics for an i386 build without needing a > legacy macOS runner > > At this point I don't think we care about testing i386 builds for > macOS. We should soon have a way of building the 32-bit PE dlls as part > of the 64-bit build, which should be the default going forward. > > -- > Alexandre Julliard > julliard(a)winehq.org >

Sept. 23, 2022

Re: What macOS SDK is being tested against on gitlab?

by Alexandre Julliard

Dean Greer <gcenx83(a)gmail.com> writes: > Hi Alexandre, > >> Yes, it's a dedicated Mac Mini that we have setup for that purpose, > currently running macOS 12.5.1. I installed a number of Homebrew > packages that are necessary for building Wine. If there are specific > queries you'd like me to run on that box I'd be happy to. > > The minimum packages would be; > > # build deps > brew install bison \ > pkg-config \ > mingw-w64 > > # runtime deps > brew install freetype \ > gphoto2 \ > gst-plugins-base \ > krb5 \ > mingw-w64 \ > molten-vk \ > sdl2 > > # casks > brew install --cask xquartz > > PATH would need to be appended with $(brew --prefix krb5)/bin > > A copy of MacOSX10.13.sdk from Xcode9.3 (or later version of Xcode9) placed into /Library/Developer/CommandLineTools/SDKs/ then the testbot could also test compiling i386 wine. > > configure/make wine64 then set the following before running configure for i386; > export SDKROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk" > export PKG_CONFIG_LIBDIR="/opt/X11/lib/pkgconfig:/opt/X11/share/pkgconfig" > > That would at least cover the basics for an i386 build without needing a legacy macOS runner At this point I don't think we care about testing i386 builds for macOS. We should soon have a way of building the 32-bit PE dlls as part of the 64-bit build, which should be the default going forward. -- Alexandre Julliard julliard(a)winehq.org

Sept. 23, 2022

Re: What macOS SDK is being tested against on gitlab?

by Dean Greer

Forgotten one additional export for the i386 side Unless this is set to 10.14 or lower there ends up being weird linker issues for the i386 binaries (this includes CX 32on64 sources) export MACOSX_DEPLOYMENT_TARGET="10.9" On Fri, Sep 23, 2022 at 10:04 AM Dean Greer <gcenx83(a)gmail.com> wrote: > Hi Alexandre, > > > Yes, it's a dedicated Mac Mini that we have setup for that purpose, > currently running macOS 12.5.1. I installed a number of Homebrew > packages that are necessary for building Wine. If there are specific > queries you'd like me to run on that box I'd be happy to. > > The minimum packages would be; > > # build deps > brew install bison \ > pkg-config \ > mingw-w64 > > # runtime deps > brew install freetype \ > gphoto2 \ > gst-plugins-base \ > krb5 \ > mingw-w64 \ > molten-vk \ > sdl2 > > # casks > brew install --cask xquartz > > PATH would need to be appended with $(brew --prefix krb5)/bin > > A copy of MacOSX10.13.sdk from Xcode9.3 (or later version of Xcode9) > placed into /Library/Developer/CommandLineTools/SDKs/ then the testbot > could also test compiling i386 wine. > > configure/make wine64 then set the following before running configure for > i386; > export SDKROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk" > export PKG_CONFIG_LIBDIR="/opt/X11/lib/pkgconfig:/opt/X11/share/pkgconfig" > > That would at least cover the basics for an i386 build without needing a > legacy macOS runner > > > I've not included libusb as that causes wine(64)-preloader to take over > usb devices according to user feedback > > On Fri, Sep 23, 2022 at 8:03 AM Alexandre Julliard <julliard(a)winehq.org> > wrote: > >> Dean Greer <gcenx83(a)gmail.com> writes: >> >> > Hi Alexandre, >> > >> > Good to know, is that a self hosted CI? As it would be nice to have a >> better idea of what’s been installed. >> >> Yes, it's a dedicated Mac Mini that we have setup for that purpose, >> currently running macOS 12.5.1. I installed a number of Homebrew >> packages that are necessary for building Wine. If there are specific >> queries you'd like me to run on that box I'd be happy to. >> >> -- >> Alexandre Julliard >> julliard(a)winehq.org >> >

Sept. 23, 2022