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

[Bug 50352] New: Maximum sockets per process is set very low
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=50352 Bug ID: 50352 Summary: Maximum sockets per process is set very low Product: Wine Version: 5.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)winehq.org Reporter: skreech(a)skree.ch Distribution: --- Created attachment 68942 --> https://bugs.winehq.org/attachment.cgi?id=68942 TWGS warning at startup Within wine-5.22/dlls/ws2_32/socket.c, the maximum number of sockets per process is set and used like so: > #define WS_MAX_SOCKETS_PER_PROCESS 128 /* reasonable guess */ and: > lpWSAData->iMaxSockets = WS_MAX_SOCKETS_PER_PROCESS; This became relevant when I ran the TradeWars 2002 game server (TWGS) under a maximum license allowing 100 simultaneous players. On startup, it logs a message warning that the OS's number of sockets per process is limited to 128, therefore no more than 63 players will be able to connect. This makes sense, since two sockets are required per player connection, and one SysOp connection is reserved. Changing WS_MAX_SOCKETS_PER_PROCESS to 1024 and recompiling WINE results in TWGS not experiencing this limit and not giving the warning. Also, I tested TWGS under ReactOS and did not experience limit nor warning. Peeking into their socket.c, I notice that their limit is set to 32767, or 0, depending: https://github.com/reactos/reactos/search?q=iMaxSockets It seems likely that WS_MAX_SOCKETS_PER_PROCESS should be set to 32767 here if any value is being set, given that the underlying OS should be the one imposing its own limits or lack of limit. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 50370] New: Gothic 1 doesn't start correctly when screen resolution of the game matches display resolution
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=50370 Bug ID: 50370 Summary: Gothic 1 doesn't start correctly when screen resolution of the game matches display resolution Product: Wine Version: 5.13 Hardware: x86-64 URL: https://www.fileplanet.com/archive/p-5260/Gothic-Demo- English OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: f90d607c67768f19e36d9d74b498594252faa3fd Distribution: --- I'm starting Gothic 1 v1.08k using in-game resolution 1440x900 which matches my native display resolution. The game does start up because I can hear the sound of the intro movie, but no visible window is created (the screen is black). This used to work up until commit f90d607c67768f19e36d9d74b498594252faa3fd ddraw: Use the WINED3D_SWAPCHAIN_NO_WINDOW_CHANGES flag. Reverting that commit on top of 6.0-rc3 fixes the problem for me. To reproduce the problem in the demo: 1. Before starting the game modify GOTHIC.INI located in the Program Files/Piranha Bytes/Gothic 1 Demo/system directory. Look for the section [Video] and change in-game screen resolution there so that it matches your display resolution: zVidResFullscreenX= zVidResFullscreenY= You also need to set 32-bit color depth (the problem doesn't occur with 16-bit): zVidResFullscreenBPP=32 2. run gothic.exe setupg1demo-en.exe md5sum: 2932bcb79118abadca0d394a7a86c096 wine-6.0-rc3 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 730/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 455.46.04 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 51900] New: regression: REAPER scrollbars flash between themed and non-themed
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=51900 Bug ID: 51900 Summary: regression: REAPER scrollbars flash between themed and non-themed Product: Wine Version: 6.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: uxtheme Assignee: wine-bugs(a)winehq.org Reporter: s_chriscollins(a)hotmail.com Distribution: --- Created attachment 70847 --> https://bugs.winehq.org/attachment.cgi?id=70847 video showing the bug Starting with Wine 6.13, scrollbars in REAPER will flash between themed and non-themed graphics when the mouse cursor passes over or interacts with them. The attached video shows the behavior in Wine 6.12 (correct) followed by Wine 6.13 (glitchy). A regression test pinpoints the following commit as the culprit: ------------------------------------------------------------------- commit 883878e550d263fd9caedd4ba5ee8c142407c010 Author: Zhiyi Zhang <zzhang(a)codeweavers.com> Date: Tue Jul 20 21:12:15 2021 +0800 uxtheme: Support scroll bar state tracking in non-client areas. Signed-off-by: Zhiyi Zhang <zzhang(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> dlls/user32/controls.h | 3 +++ dlls/user32/defwnd.c | 11 +++++++++++ dlls/user32/nonclient.c | 33 +++++++++++++++++++++++++++++++++ dlls/user32/scroll.c | 37 ++++++++++++++++++++++++++++++++++--- 4 files changed, 81 insertions(+), 3 deletions(-) ------------------------------------------------------------------- This bug is still present in master as of today (10/18/21) and can be reproduced in a VirtualBox VM. REAPER can be downloaded for free from: http://reaper.fm/ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 51163] New: WinOffice Pro 5.3 stops after splashscreen
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=51163 Bug ID: 51163 Summary: WinOffice Pro 5.3 stops after splashscreen Product: Wine Version: 6.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: maiktapwagner(a)aol.com Distribution: --- Created attachment 70031 --> https://bugs.winehq.org/attachment.cgi?id=70031 Console Output (wine 6.8) Hello everyone, I came across a forum question where somebody asked how to get the German accounting application WinOffice Pro 5.3 to run. There is a 60 day trial version available and I noticed that the application requires mdac27 and jet40 in a 32-Bit prefix to perform a successful installation. Starting the application works until the splashscreen but then the application terminates. Console output is attached. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 52426] New: BCryptSignHash mishandles empty arguments
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=52426 Bug ID: 52426 Summary: BCryptSignHash mishandles empty arguments Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: bcrypt Assignee: wine-bugs(a)winehq.org Reporter: janisozaur+wine(a)gmail.com Distribution: --- Created attachment 71684 --> https://bugs.winehq.org/attachment.cgi?id=71684 BCrypt test program BCryptSignHash should provide count of bytes required for signature when provided with NULL value for pbOutput, but mishandles this parameter. Sample application is provided -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 52446] New: Normal dlls with native subsystem id are no longer processed when importing system dlls with uppercase names
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=52446 Bug ID: 52446 Summary: Normal dlls with native subsystem id are no longer processed when importing system dlls with uppercase names Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, this is a regression found during testing of bug 50433 ("'MsiBreak' custom action debugging aid should use custom action's name from 'CustomAction' table (currently uses 'Target' field)"). --- snip --- $ WINEDEBUG=+seh,+relay,+ntdll,+loaddll,+server wine msiexec -i AcroPro.msi >>log.txt 2>&1 ... 0104:trace:msi:ACTION_CustomAction Handling custom action L"CreatePortMonitor" (c41 L"AdobeIsf" L"SetupPortMonitor") ... 0248:Ret PE DLL (proc=0236618A,module=02360000 L"msi40ea.tmp",reason=PROCESS_ATTACH,res=00000000) retval=1 ... 0248:Ret kernelbase.LoadLibraryW() retval=02360000 ret=7bc3acd4 0248:Ret KERNEL32.LoadLibraryW() retval=02360000 ret=100225a8 ... 0104:trace:msi:wait_thread_handle waiting for L"CreatePortMonitor" ... 0248:Call KERNEL32.LoadLibraryW(00474ef0 L"C:\\windows\\system32\\AdobePDF.dll") ret=025d7344 0248:Call kernelbase.LoadLibraryW(00474ef0 L"C:\\windows\\system32\\AdobePDF.dll") ret=7bc3acd4 ... 0248: get_mapping_info( handle=00f0, access=0000000c ) 0248: get_mapping_info() = 0 { size=0000a000, flags=01800000, shared_file=0000, total=152, image={base=50400000,stack_size=00100000,stack_commit=00001000,entry_point=00004438,map_size=0000a000,zerobits=00000000,subsystem=00000001,subsystem_minor=0000,subsystem_major=0004,osversion_major=0004,osversion_minor=0000,image_charact=210e,dll_charact=0000,machine=014c,contains_code=1,image_flags=00,loader_flags=00000000,header_size=00000400,file_size=00005600,checksum=0000e958}, name=L"\\??\\C:\\windows\\syswow64\\AdobePDF.dll" } ... 0248:trace:loaddll:build_module Loaded L"C:\\windows\\syswow64\\MSVCR71.dll" at 02600000: builtin 0248: close_handle( handle=00f4 ) 0248: close_handle() = 0 0248:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\AdobePDF.dll" at 50400000: native 0248: close_handle( handle=00f0 ) 0248: close_handle() = 0 0248:Call PE DLL (proc=02666D60,module=02600000 L"MSVCR71.dll",reason=PROCESS_ATTACH,res=00000000) ... 0248:Ret PE DLL (proc=02666D60,module=02600000 L"MSVCR71.dll",reason=PROCESS_ATTACH,res=00000000) retval=1 0248:Ret ntdll.LdrLoadDll() retval=00000000 ret=7b01b8e3 ... 0248:Ret kernelbase.LoadLibraryW() retval=50400000 ret=7bc3acd4 0248:Ret KERNEL32.LoadLibraryW() retval=50400000 ret=025d7344 0248:Call KERNEL32.GetProcAddress(50400000,025db5ef "InitializePrintMonitor2") ret=025d73bf ... 0248:Ret KERNEL32.GetProcAddress() retval=00000000 ret=025d73bf 0248:Call KERNEL32.GetProcAddress(50400000,025db607 "InitializePrintMonitorUI") ret=025d73cf ... 0248:Ret KERNEL32.GetProcAddress() retval=00000000 ret=025d73cf 0248:Call KERNEL32.GetProcAddress(50400000,025da1ac "InitializePrintMonitor") ret=025d73de ... 0248:Ret KERNEL32.GetProcAddress() retval=50404423 ret=025d73de 0248:Call KERNEL32.GetProcAddress(50400000,025db620 "InitializeMonitorEx") ret=025d73ee ... 0248:Ret KERNEL32.GetProcAddress() retval=00000000 ret=025d73ee 0248:Call KERNEL32.GetProcAddress(50400000,025db634 "InitializeMonitor") ret=025d73fe ... 0248:Ret KERNEL32.GetProcAddress() retval=00000000 ret=025d73fe --- snip --- Note, dll notifications were not called for 'AdobePDF.dll'. At this point spooler calls 'InitializePrintMonitor' export. --- snip --- ... 0248:Call advapi32.RegCreateKeyW(80000002,00472da8 L"System\\CurrentControlSet\\Control\\Print\\Monitors\\Adobe PDF Port",504060b8) ret=50404368 ... 0248:Ret advapi32.RegCreateKeyW() retval=00000000 ret=50404368 0248:Call ntdll.RtlEnterCriticalSection(504060e0) ret=504020b7 0248: create_semaphore( access=001f0003, initial=00000000, max=00000001, objattr={} ) 0248: create_semaphore() = 0 { handle=00f0 } 0248: select( flags=2, cookie=0235ebe4, timeout=+4.9999870, size=8, prev_apc=0000, result={}, data={WAIT_ALL,handles={00f0}}, contexts={} ) 0248: select() = PENDING { call={APC_NONE}, apc_handle=0000, signaled=0, contexts={} } 0248: *wakeup* signaled=TIMEOUT 0248:err:sync:RtlpWaitForCriticalSection section 504060E0 "?" wait timed out in thread 0248, blocked by 0000, retrying (60 sec) 0248: select( flags=2, cookie=0235ebe4, timeout=+59.9999082, size=8, prev_apc=0000, result={}, data={WAIT_ALL,handles={00f0}}, contexts={} ) 0248: select() = PENDING { call={APC_NONE}, apc_handle=0000, signaled=0, contexts={} } 0248: *killed* exit_code=0 ... 0220:Ret PE DLL (proc=006B1900,module=00630000 L"ucrtbase.dll",reason=THREAD_DETACH,res=00000000) retval=1 0220: *killed* exit_code=0 0248: *wakeup* signaled=TIMEOUT 0248:err:sync:RtlpWaitForCriticalSection section 504060E0 "?" wait timed out in thread 0248, blocked by 0000, retrying (60 sec) 0248: select( flags=2, cookie=0235ebe4, timeout=+59.9999082, size=8, prev_apc=0000, result={}, data={WAIT_ALL,handles={00f0}}, contexts={} ) 0248: select() = PENDING { call={APC_NONE}, apc_handle=0000, signaled=0, contexts={} } 0104: *wakeup* signaled=1 --- snip --- Due to loader not calling loader notifications for 'AdobePDF.dll', the critical section 0x504060e0 was not initialized, leading to infinite hang. The problem was introduced by commit https://source.winehq.org/git/wine.git/commitdiff/250c113169217933b1fffa802… ("ntdll: Factor out is_import_dll_system() function."), part of Wine 6.21 release. The refactoring inadvertently changed the case sensitivity for comparision of imported dlls against the system dlls from case-insensive ('wcsicmp') to case-sensive ('strcmp'). This breaks the detection for dlls which are marked as 'native subsystem' but are in fact regular dlls if they import dlls with upper/camel case. Dump of 'AdobePDF.dll' headers: --- snip --- ... ->File Header Machine: 0x014C (I386) NumberOfSections: 0x0005 TimeDateStamp: 0x41BEBC76 (GMT: Tue Dec 14 10:12:06 2004) PointerToSymbolTable: 0x00000000 NumberOfSymbols: 0x00000000 SizeOfOptionalHeader: 0x00E0 Characteristics: 0x210E (EXECUTABLE_IMAGE) (LINE_NUMS_STRIPPED) (LOCAL_SYMS_STRIPPED) (32BIT_MACHINE) (DLL) ->Optional Header Magic: 0x010B (HDR32_MAGIC) MajorLinkerVersion: 0x07 MinorLinkerVersion: 0x0A -> 7.10 SizeOfCode: 0x00004200 SizeOfInitializedData: 0x00001000 SizeOfUninitializedData: 0x00000000 AddressOfEntryPoint: 0x00004438 BaseOfCode: 0x00001000 BaseOfData: 0x00006000 ImageBase: 0x50400000 SectionAlignment: 0x00001000 FileAlignment: 0x00000200 MajorOperatingSystemVersion: 0x0004 MinorOperatingSystemVersion: 0x0000 -> 4.00 MajorImageVersion: 0x0004 MinorImageVersion: 0x0000 -> 4.00 MajorSubsystemVersion: 0x0004 MinorSubsystemVersion: 0x0000 -> 4.00 Win32VersionValue: 0x00000000 SizeOfImage: 0x0000951A SizeOfHeaders: 0x00000400 CheckSum: 0x0000E958 Subsystem: 0x0001 (NATIVE) DllCharacteristics: 0x0000 SizeOfStackReserve: 0x00100000 SizeOfStackCommit: 0x00001000 SizeOfHeapReserve: 0x00100000 SizeOfHeapCommit: 0x00001000 LoaderFlags: 0x00000000 NumberOfRvaAndSizes: 0x00000010 ---- snip --- -> native subsystem Dump of 'AdobePDF.dll' import table, showing the dll names are uppercase: --- snip --- 1. ImageImportDescriptor: OriginalFirstThunk: 0x00004864 TimeDateStamp: 0x00000000 (GMT: Thu Jan 01 00:00:00 1970) ForwarderChain: 0x00000000 Name: 0x00004948 ("SPOOLSS.DLL") FirstThunk: 0x0000117C Ordinal/Hint API name ------------ --------------------------------------- 0x003A "ImpersonatePrinterClient" ... 0x0032 "GetJobW" 2. ImageImportDescriptor: OriginalFirstThunk: 0x000047FC TimeDateStamp: 0x00000000 (GMT: Thu Jan 01 00:00:00 1970) ForwarderChain: 0x00000000 Name: 0x00004A76 ("MSVCR71.dll") FirstThunk: 0x00001114 Ordinal/Hint API name ------------ --------------------------------------- 0x00F1 "_except_handler3" ... 0x0189 "_mbschr" 3. ImageImportDescriptor: OriginalFirstThunk: 0x0000473C TimeDateStamp: 0x00000000 (GMT: Thu Jan 01 00:00:00 1970) ForwarderChain: 0x00000000 Name: 0x00004DAA ("KERNEL32.dll") FirstThunk: 0x00001054 Ordinal/Hint API name ------------ --------------------------------------- 0x01C0 "GetSystemTimeAsFileTime" ... 0x0394 "WriteFile" 4. ImageImportDescriptor: OriginalFirstThunk: 0x00004884 TimeDateStamp: 0x00000000 (GMT: Thu Jan 01 00:00:00 1970) ForwarderChain: 0x00000000 Name: 0x00004EFE ("USER32.dll") FirstThunk: 0x0000119C Ordinal/Hint API name ------------ --------------------------------------- 0x0202 "PostMessageW" ... 0x01DE "MessageBoxA" 5. ImageImportDescriptor: OriginalFirstThunk: 0x000046E8 TimeDateStamp: 0x00000000 (GMT: Thu Jan 01 00:00:00 1970) ForwarderChain: 0x00000000 Name: 0x0000507A ("ADVAPI32.dll") FirstThunk: 0x00001000 Ordinal/Hint API name ------------ --------------------------------------- 0x01D8 "RegEnumKeyW" ... 0x01C9 "RegCloseKey" --- snip --- Stable download link via Internet Archive: https://web.archive.org/web/20061114115407/http://ardownload.adobe.com/pub/… https://www.virustotal.com/gui/file/d9270dc2abfb3c0e216af188343dbd0058c6025… $ sha1sum AcTR7EFG.exe 4f1ff389ea71f21d624083d65bbe5a74e4760079 AcTR7EFG.exe $ du -sh AcTR7EFG.exe 116M AcTR7EFG.exe $ wine --version wine-7.0-119-gc09a5da1575 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 51619] New: advapi32:registry fails in Wine because a German timezone name translation is too long
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=51619 Bug ID: 51619 Summary: advapi32:registry fails in Wine because a German timezone name translation is too long Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: advapi32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- advapi32:registry fails in the timezone tests in a German locale: registry.c:4339: Test failed: L"Aus Central W. Standard Time": expected L"West-Zentralaustralische Normalzeit", got L"Aus Central W. Standard Time" registry.c:4357: Test failed: L"Aus Central W. Standard Time": expected L"West-Zentralaustralische Sommerzeit", got L"Aus Central W. Daylight Time" https://test.winehq.org/data/patterns.html#advapi32:registry The reason is that the test compares the localized obtained through the registry with the one obtained through EnumDynamicTimeZoneInformation(). But the latter translation must fit into a 32 character buffer: WCHAR StandardName[32]. However Wine's German translation is too long (36 character including the trailing '\0'), causing EnumDynamicTimeZoneInformation() to return the untranslated string instead. Potential fixes --------------- 1. Only compare the values if they fit in the {Daylight,Standard}Name buffer. - That means Windows applications will not get a translated timezone name which is bad. - This prevents detecting further issues. - It's unclear if returning an untranslated string is the right thing for EnumDynamicTimeZoneInformation() to do: I did not find a case (at least in German where a translation did not fit). 2. Modify EnumDynamicTimeZoneInformation() to return a truncated translation instead of an untranslated string. - Windows applications will get a not quite correct timezone name. - Also we would need evidence that this matches the Windows behavior. 3. Modify the German translation. - This side-steps the issue and may be the best solution. - But I doubt one can find a shorter translation that fits, short of using ellipses which is not great. Detecting / Preventing recurrences ---------------------------------- 1. It would be nice to be able to include a translator warning about this issue. I'm not sure how to do so in dlls/tzres/tzres.rc. 2. The current tests are insufficient to detect further issues - To detect every issue they would have to be run in every locale. - Or going forward, whenever a PO file is modified they would need to be run in that locale. - Maybe issues could be detected by calling RegLoadMUIStringW() for every timezone and locale combination. However it does not take an LCID which makes this complicated. 3. Write a script checking the PO files. - This seems like the simplest option to detect issues. - When to run it? Manually? Automatically from the makefiles? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 52163] New: postgresql-9.3 installer expects scrrun:filesys_GetTempName to return filename with TMP suffix
by WineHQ Bugzilla 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=52163 Bug ID: 52163 Summary: postgresql-9.3 installer expects scrrun:filesys_GetTempName to return filename with TMP suffix Product: Wine Version: 6.23 Hardware: x86-64 URL: https://web.archive.org/web/20211009084355if_/https:// get.enterprisedb.com/postgresql/postgresql-9.3.25-1-wi ndows-x64.exe OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: scrrun Assignee: wine-bugs(a)winehq.org Reporter: sloper42(a)yahoo.com Distribution: --- This is followup from https://bugs.winehq.org/show_bug.cgi?id=51971 Test with postgresql-9.3 installer from [1]. It runs a script during installation similar to https://github.com/three-plus-three/tpt_env_amd64/blob/master/postgresql/in… that reports non-critical error to main install, script itself terminates. This part strBatchFile = Replace(objFso.GetTempName, ".tmp", ".bat") is not working, because GetTempName returns "rad12345.tx". File is not renamed to *.bat and cannot be started by objShell.Run later. [1] https://www.enterprisedb.com/postgresql-tutorial-resources-training?cid=340 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 45916] New: x64dbg does not open executables, nothing happens
by wine-bugs＠winehq.org 08 Nov '22

08 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=45916 Bug ID: 45916 Summary: x64dbg does not open executables, nothing happens Product: Wine Version: 3.16 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: jimbo1qaz(a)gmail.com Distribution: --- When I File/Open or drag a .exe file into x32dbg (x64dbg 32-bit), the exe does not load onto the graphs, and Ctrl+G doesn't work. I think the EXE is not loaded by the debugger at all. Fixed by ~/bin/winetricks vcrun2013 . Wine 3.16 on Debian on Virtualbox. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 11

[Bug 25257] New: Enabling Virtual desktop by default cannot be turned off for specific applications
by wine-bugs＠winehq.org 08 Nov '22

08 Nov '22

http://bugs.winehq.org/show_bug.cgi?id=25257 Summary: Enabling Virtual desktop by default cannot be turned off for specific applications Product: Wine Version: 1.3.7 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: zzarko(a)gmail.com My system is Ubuntu 10.10 and Wine is installed from Ubuntu Wine team's PPA. Steps to reproduce the problem: 1. Select Default settings in Configure Wine/Applications tab and check Graphics/Enable virtual desktop 2. Add an application (in my case, Subtitle Workshop) to Applications tab and uncheck the same option for this application 3. Start the application -> application is started in virtual desktop, despite the different setting for that application -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 7