July 2026 - Wine-Bugs - list.winehq.org

[Bug 59451] New: Open Rails component - Track Viewer drop-down menus works but are rendered black
by WineHQ Bugzilla July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=59451 Bug ID: 59451 Summary: Open Rails component - Track Viewer drop-down menus works but are rendered black Product: Wine Version: 11.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: deim(a)seznam.cz Distribution: --- Created attachment 80437 --> http://bugs.winehq.org/attachment.cgi?id=80437 All dropdowns have correct size but are rendered black Winetricks -> dxvk, dotnet48, corefonts Everything in this game works well but drop-down menus are drawn black -- 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 59959] New: Minor correction to wiki content
by WineHQ Bugzilla July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=59959 Bug ID: 59959 Summary: Minor correction to wiki content Product: WineHQ Gitlab Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: gitlab-unknown Assignee: wine-bugs(a)list.winehq.org Reporter: matt.m.seng(a)gmail.com Distribution: --- Sorry if this isn't the right place to report; it was very unclear how one might contribute discourse regarding the wiki content. I just wanted to share that there is an omission in the code posted in the following page/section: https://gitlab.winehq.org/wine/wine/-/wikis/FAQ#how-do-i-associate-a-native… The existing code block: ------------------------------------------------ [HKEY_CLASSES_ROOT\.pdf] @="PDFfile" "Content Type"="application/pdf" [HKEY_CLASSES_ROOT\PDFfile\Shell\Open\command] @="winebrowser \"%1\"" ------------------------------------------------ ... is not valid content for a properly-formatted .reg file, in the context of this documentation at least. A header defining the registry editor version is needed in order for the subsquently-documented commands to work. The following code block corrects this: ------------------------------------------------ Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\.pdf] @="PDFfile" "Content Type"="application/pdf" [HKEY_CLASSES_ROOT\PDFfile\Shell\Open\command] @="winebrowser \"%1\"" ------------------------------------------------ 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 2

[Bug 59961] New: dwrite.dll (builtin) does not apply bold weight for CSS font-weight in CEF/Chromium-based application (Evernote), works correctly with native dwrite.dll
by WineHQ Bugzilla July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=59961 Bug ID: 59961 Summary: dwrite.dll (builtin) does not apply bold weight for CSS font-weight in CEF/Chromium-based application (Evernote), works correctly with native dwrite.dll Product: Wine Version: 11.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dwrite Assignee: wine-bugs(a)list.winehq.org Reporter: markus.kern1(a)gmx.at Distribution: --- Created attachment 81344 --> http://bugs.winehq.org/attachment.cgi?id=81344 with override -- Bug Report Created by Claude --- Version: wine-11.12 OS: Fedora 44, Linux (Wine devel branch) Description When running a CEF/Chromium-based Windows application under Wine, text styled with CSS font-weight: bold (or HTML tags) renders in the regular weight instead of bold. This occurs with a TrueType font family installed as separate static weight files (Regular, Bold, etc.), each registered individually under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts (e.g. "<Family> Bold (TrueType)"="<family>-bold.ttf"). Classic GDI-based rendering (tested with Notepad, same font family, same installed files) correctly displays bold text. This isolates the issue to Wine's builtin dwrite.dll font weight/family grouping rather than to font installation, registry setup, or the application itself. Steps to reproduce Install a TrueType font family with separate static weight files (Regular + Bold at minimum) into C:\windows\Fonts, with matching registry entries under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts. Run a CEF/Chromium-based Windows application that renders HTML/CSS text referencing that font family and applies font-weight: bold (or ) to part of the text. Observe that the bold text renders visually identical to the regular weight. For comparison: open Notepad and manually apply Bold formatting to text using the same installed font family — bold renders correctly there. welcher bug passt am besten zu meinem fehlerbild? Durchforstete Fehlerliste und identifizierte nächstbeste Übereinstimmung Von der Liste passt am besten: Bug 32965 – "arialbd.ttf not found (Text applied to textures in Kerbal Space Program are not visible)" (Component: fonts) Warum das die beste Übereinstimmung ist Das ist der einzige Eintrag in der Liste, der sich explizit auf die Bold-Variante einer Font-Datei bezieht (arialbd.ttf = Arial Bold) – exakt das Muster, das du hattest: Regular-Schnitt wird gefunden und korrekt gerendert, der Bold-Schnitt wird von Wine nicht aufgelöst/gefunden, obwohl die Datei vorhanden ist. Einschränkung, die du kennen solltest Er liegt unter Komponente fonts, nicht dwrite – das ist wahrscheinlich ein älterer, GDI-naher Bug (Kerbal Space Program nutzt vermutlich kein DirectWrite), während dein Fall ja klar über die dwrite-Schicht lief. Die Symptomatik (Bold-Datei wird nicht gefunden/genutzt) ist aber sehr ähnlich, auch wenn der zugrunde liegende Code-Pfad ein anderer sein könnte. Von den echten dwrite-Bugs in der Liste (54028, 53739, 59252, 59488/89, 48447, 51150, 51367, 56717, 59218, 59487, 50627, 53311) behandelt keiner explizit Weight-/Bold-Gruppierung – die meisten drehen sich um Font-Fallback, fehlenden Text, Performance oder Abstürze bei anderen Programmen. Dein spezifisches Problem (Familie wird erkannt, aber Bold-Weight-Zuordnung schlägt fehl) scheint als eigenständiger Bug noch nicht sauber erfasst zu sein. Praktischer Vorschlag Falls du das dokumentieren willst, wäre ein neuer Bugreport unter Komponente dwrite vermutlich der sauberere Weg, statt 32965 zu kommentieren (der ja ein anderes Programm und wahrscheinlich einen anderen Code-Pfad betrifft). Du hättest mit deinem Fall (Evernote/CEF, Inter-Variable-Font-Familie, Bold wird bei Wine-dwrite.dll ignoriert, mit nativer dwrite.dll behoben) einen sehr klaren, reproduzierbaren Report – das ist genau die Art von Beitrag, die den Wine-Entwicklern hilft, weil du schon den Vergleich Wine-dwrite vs. Native-dwrite als Beweis lieferst. Willst du, dass ich dir einen strukturierten Bugreport-Entwurf dafür erstelle? ist eigentlich inter zwingend notwendig? Evaluierte Notwendigkeit von Inter-Schriftart nach Behebung des Rendering-Problems Nein – "Inter" ist nur der erste Kandidat in der CSS-Fallback-Kette, kein Hard-Requirement: font-family: Inter, system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen-Sans, Ubuntu, Cantarell, Helvetica Neue, sans-serif Der Browser/CEF-Renderer geht die Liste von links nach rechts durch und nimmt den ersten Font, den er tatsächlich findet. Fehlt "Inter" komplett, fällt er automatisch auf den nächsten verfügbaren zurück – z.B. "Segoe UI" (die ist ja über deine kopierten Windows-Fonts vermutlich ohnehin vorhanden) oder letztlich das generische sans-serif. Der entscheidende Punkt jetzt, nach deinem Fix Da die eigentliche Ursache (Wines dwrite.dll gruppiert Bold-Varianten nicht korrekt) jetzt durch die native dwrite.dll systemweit behoben ist, betrifft das nicht nur Inter, sondern jede Font-Familie in deinem Prefix. Das heißt: Selbst wenn du "Inter" komplett entfernst und der Browser auf "Segoe UI" oder sogar nur generisches sans-serif zurückfällt, würde Bold jetzt korrekt dargestellt werden – weil die native DirectWrite-Engine die Weight-Gruppierung für alle installierten Fonts sauber übernimmt, nicht nur für Inter. Praktisch heißt das für dich Du musst Inter nicht behalten, wenn du Speicherplatz sparen oder den Prefix aufräumen willst Die optische Übereinstimmung mit dem "echten" Evernote-Look (Windows/Mac-Client) ist aber nur mit Inter gegeben – ohne Inter sieht der Text etwas anders aus (Segoe UI hat andere Proportionen/Zeichenformen) Falls dir das Erscheinungsbild egal ist und nur "Bold funktioniert" zählt, kannst du die Inter-Dateien und den Registry-Import jederzeit wieder entfernen, ohne dass das Bold-Problem zurückkommt – der Fix sitzt ja jetzt auf Ebene der DirectWrite-Engine, nicht auf Ebene der einzelnen Font Falls du die Inter-Fonts drinlässt, hast du also im Grunde nur den optisch "originalgetreueren" Look zusätzlich zur ohnehin behobenen Bold-Funktionalität. ok - erstelle mir infos für einen bugreport bei wine Orchestrierte strukturierten Bug-Report mit technischen Details und bilingualer Formatierung Hier ein strukturierter Report-Entwurf, den du bei WineHQ Bugzilla (Component: dwrite) einreichen kannst. Bug-Reports dort sind auf Englisch üblich, daher hab ich den Report-Inhalt direkt auf Englisch formuliert – du musst nur noch die Platzhalter (Wine-Version etc.) ergänzen. Component: dwrite Summary: dwrite.dll (builtin) does not apply bold weight for CSS font-weight in CEF/Chromium-based application (Evernote), works correctly with native dwrite.dll Version: [bitte wine --version einfügen] OS: Fedora 44, Linux (Wine devel branch) Description When running a CEF/Chromium-based Windows application (Evernote 11.23.2) under Wine, text styled with font-weight: bold (or tags) is rendered in the regular weight instead of bold — but only for certain font families. The issue is reproducible with the "Inter" font family (all 18 static weight variants, Thin through Black, plus italics, installed as separate HKLM\...\CurrentVersion\Fonts registry entries pointing to individual .ttf files per weight, e.g. "Inter Bold (TrueType)"="Inter-Bold.ttf"). Classic GDI-based rendering (tested with Notepad) correctly displays bold text using the exact same installed fonts. This isolates the issue to Wine's dwrite.dll (builtin) font weight/family grouping, rather than to font installation or GDI itself. Steps to reproduce Install Inter font family (all static weights) into C:\windows\Fonts, with matching registry entries under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts. Run a CEF/Chromium-based Windows application that renders HTML/CSS text with font-family: Inter, ... and applies font-weight: bold (or ) to some of that text. Observe that bold text renders visually identical to regular-weight text. For comparison: open Notepad (or another classic GDI app) and manually apply Bold formatting to text in the same font family — bold renders correctly. Expected result Bold text should render with the corresponding bold font face, matching GDI-based rendering behavior. Actual result Bold text renders in the regular weight; no visual distinction between normal and bold text. Workaround confirmed Overriding dwrite to use the native Windows DLL fixes the issue completely: wine reg add "HKCU\Software\Wine\DllOverrides" /v "dwrite" /t REG_SZ /d "native,builtin" /f With dwrite.dll copied from a genuine Windows installation into system32, bold rendering works correctly for the same font/application/registry setup — confirming the regression is isolated to Wine's builtin dwrite.dll implementation, not to font installation, registry setup, or the application itself. Additional notes Fully disabling dwrite (DllOverride: disabled) causes the application to fail to start entirely — the application has a hard dependency on dwrite.dll being present in some form (native or builtin), it cannot fall back to GDI-only rendering. This may be related to font family/weight grouping logic in Wine's dwrite implementation (similar in nature to historic issues like bug 584769 in other DirectWrite implementations, where GDI-style vs. DirectWrite-style family grouping — based on name table / weight-width-slope family name — differ). Zwei Dinge, die du vor dem Einreichen noch ergänzen solltest: wine --version – exakte Versionsnummer Falls du magst, ein Vorher/Nachher-Screenshot (Bold mit builtin dwrite vs. mit nativer dwrite.dll) – das ist bei Font-Rendering-Bugs fast immer hilfreicher als reine Textbeschreibung und wird von Wine-Maintainern gerne gesehen Soll ich dir noch eine minimale Testanwendung/HTML-Datei vorbereiten, die das Problem ganz ohne Evernote reproduziert (nur reines HTML mit font-family: Inter + font-weight: bold in einem CEF-Testkontext)? Das würde den Report für die Wine-Entwickler noch einfacher nachvollziehbar machen, da er nicht an eine proprietäre App gebunden ist. beim bugreport - lass das mit inter weg und mache in auf english neu Generalized bug report, removing font-specific details Hier die überarbeitete Version – generisch gehalten, ohne Bezug zu Inter, auf Englisch: Component: dwrite Summary: dwrite.dll (builtin) does not apply bold font weight in CEF/Chromium-based application; native dwrite.dll works correctly Version: [insert wine --version output here] OS: Fedora 44, Linux (Wine devel branch) Description When running a CEF/Chromium-based Windows application under Wine, text styled with CSS font-weight: bold (or HTML tags) renders in the regular weight instead of bold. This occurs with a TrueType font family installed as separate static weight files (Regular, Bold, etc.), each registered individually under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts (e.g. "<Family> Bold (TrueType)"="<family>-bold.ttf"). Classic GDI-based rendering (tested with Notepad, same font family, same installed files) correctly displays bold text. This isolates the issue to Wine's builtin dwrite.dll font weight/family grouping rather than to font installation, registry setup, or the application itself. Steps to reproduce #1 Install a TrueType font family with separate static weight files (Regular + Bold at minimum) into C:\windows\Fonts, with matching registry entries under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts. #2 Run a CEF/Chromium-based Windows application that renders HTML/CSS text referencing that font family and applies font-weight: bold (or ) to part of the text. #3 Observe that the bold text renders visually identical to the regular weight. #4 For comparison: open Notepad and manually apply Bold formatting to text using the same installed font family — bold renders correctly there. Expected result Bold text should render using the corresponding bold font face, matching the behavior seen with GDI-based rendering. Actual result Bold text renders in the regular weight; there is no visual distinction between normal and bold text within the CEF/Chromium-based application. Workaround confirmed Overriding dwrite to use the native Windows DLL fixes the issue completely: wine reg add "HKCU\Software\Wine\DllOverrides" /v "dwrite" /t REG_SZ /d "native,builtin" /f With a genuine dwrite.dll copied from a real Windows installation into system32, bold rendering works correctly for the identical font/application/registry setup — confirming the regression is isolated to Wine's builtin dwrite.dll implementation. Additional notes Fully disabling dwrite (DllOverride: disabled) causes the application to fail to start entirely — it has a hard dependency on dwrite.dll being present in some form (native or builtin) and cannot fall back to GDI-only rendering. This may be related to font family/weight grouping logic in Wine's dwrite implementation — potentially similar in nature to historic family-grouping issues seen in other DirectWrite implementations, where GDI-style grouping (by name table ID 1) and DirectWrite-style grouping (by weight-width-slope family name) can diverge for fonts installed as separate per-weight files. -- 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 59952] New: Support an environment variable disable for user mode dispatch!
by WineHQ Bugzilla July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=59952 Bug ID: 59952 Summary: Support an environment variable disable for user mode dispatch! Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: timothylottes(a)protonmail.com Distribution: --- The old way to work around problems in Wine on Linux was to do direct Linux system calls from inside the WIN32 application using inline assembly. However now with user mode dispatch, those SYSCALL instructions get trapped. This makes it impossible to implement in-app workarounds for Wine bugs. The request here is an environment variable that can be set before execution of "wine" that would disable use of userr-mode-dispatch, so that it restores ability to do Linux system calls instead. -- 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 27313] New: Requiem: Avenging Angel - Loading a savegame freezes the keyboard.
by wine-bugs＠winehq.org July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=27313 Summary: Requiem: Avenging Angel - Loading a savegame freezes the keyboard. Product: Wine Version: 1.3.21 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: cyclops(a)fastwebnet.it Sometimes, when you load a previous savegame, keyboard is freezed and the game must be rebooted to make it run well again. Also, health goes to 1, armour goes to 0 and essence goes to 666 (strange, uh?). If you need a log, please ask me. -- 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 9

[Bug 59237] New: EGS game (NSFW) not displaying properly (vertical offset when windowed, blank screen when full screen)
by WineHQ Bugzilla July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=59237 Bug ID: 59237 Summary: EGS game (NSFW) not displaying properly (vertical offset when windowed, blank screen when full screen) Product: Wine Version: 11.0-rc5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: tbterry0(a)yahoo.com Distribution: --- The EGS game (adult game) is not working properly with recent Wine versions (including 11.0rc5: it however works fine with Wine 10.2 or older). That game is available here: https://mega.nz/folder/EC1AnajC#Woaxul8_aI91GViGiop7xw When used in windowed mode, the display is shifted downwards in the window and a white strip appears at the top. When used in full screen mode, the whole screen becomes blank (white). -- 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 3

[Bug 59767] New: loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations
by WineHQ Bugzilla July 5, 2026

July 5, 2026

http://bugs.winehq.org/show_bug.cgi?id=59767 Bug ID: 59767 Summary: loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations Product: Wine Version: 11.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: loader Assignee: wine-bugs(a)list.winehq.org Reporter: arraybolt3(a)gmail.com Distribution: --- This is kind of a weird bug as it doesn't have anything to do with Windows applications in particular, but rather with how Wine registers itself with the system. loader/wine.desktop registers Wine as a MIME handler for a number of different Windows-related executable file formats (EXEs, MSIs, and Batch files. Linux doesn't recognize these files as programs (unless they have their executable bit set and are registered with binfmt-misc of course), so it will attempt to "open" these files with Wine. Wine will then run arbitrary code within these programs with the privileges of whatever program launched Wine. On the surface, this doesn't sound like a problem, but it becomes an issue because sandboxed code under Linux can usually use D-Bus to open files in their default application *outside of the sandbox*. Since the default application to open EXE files in is Wine, anything that can open arbitrary files outside of the sandbox can now escape the sandbox by writing an EXE file somewhere and then "opening" it with Wine. There are two ways I know of to do this: * Some file managers handle the org.freedesktop.FileManager1.ShowFolders method call by opening the "folders" they are told to open with their default application. Of course, there is no guarantee that the "folders" actually are folders; if the sandboxed app passes a file name in this call, those file managers will open the specified files in their default application. If Wine is installed, and one of the "folders" specified is an EXE file, the application can now run arbitrary code outside of the sandbox. (I reported this bug to an affected file manager over 90 days ago.) * xdg-desktop-portal-gtk intentionally allows applications to open arbitrary files outside of a sandbox, via the org.freedesktop.portal.OpenURI.OpenFile D-Bus method. If there are multiple applications that can open the same file type, it will usually open a dialog asking what application to open the file in, but if there is only one handler for a file type on the system, it will immediately open the file with its default handler. Handlers for EXE files other than Wine are relatively rare (lxqt-archiver is one, oddly enough), so there is a very good chance that a sandboxed app can just write an EXE file to the disk, then open it with xdg-desktop-portal-gtk and have code execution outside the sandbox. (I reported this privately to the Flatpak developers over 90 days ago.) Arguably, neither of these issues are security vulnerabilities in xdg-desktop-portal or file managers. The `xdg-mime` manpage warns: Security Note: Never set a handler that will blindly execute code or commands from the file being handled. Such behavior will sooner than later lead to unintended code execution i.e. through a curious user trying to inspect a freshly downloaded file but running it by accident. Keeping opening and executing separate actions helps with people protecting themselves from malware, the default handler is an opener, not a runner. Therefore I believe this is an issue with Wine. -- 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 24

[Bug 59129] New: Parallel Port Tester fails to detect the parallel port's base I/O address
by WineHQ Bugzilla July 5, 2026

July 5, 2026

http://bugs.winehq.org/show_bug.cgi?id=59129 Bug ID: 59129 Summary: Parallel Port Tester fails to detect the parallel port's base I/O address Product: Wine Version: 11.0-rc1 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: wmi&wbemprox Assignee: wine-bugs(a)list.winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Steps to reproduce: 1. Use a computer with a motherboard-attached or PCI-attached parallel port. USB-attached parallel ports do not have base I/O addresses and Parallel Port Tester ignores them. 2. Ensure that /dev/lp0 exists and works outside of Wine, for example by connecting the parallel port to a printer or to an LED tester, running `echo hello > /dev/lp0`, and seeing the word printed on the printer or seeing different LEDs light up on the tester. 3. (Optional) Figure out what the base address of the parallel port is by looking at DEVNAME in /sys/class/printer/lp0/device/ppdev/parport0/uevent, then reading the first number in /proc/sys/dev/parport/<DEVNAME>/base-addr. You will need to convert the value to hexadecimal and prepend "0x" if you want to manually enter it into Parallel Port Tester. 4. Run `wine ParallelPortTesterSetup-1.0.0.2.exe` 5. Run `wine 'C:\Program Files (x86)\Parallel Port Tester\ParallelPortTester.exe'` 6. Click the drop-down labeled "Port" in the lower-right corner of the window. When my desktop computer is booted into Windows and I click the drop-down in Parallel Port Tester, it offers "LPT3 (0xEFF8)" as an option. When the same computer is booted into Linux and I run Parallel Port Tester on Wine, the drop-down is empty. However, if I run it on Wine with https://gitlab.com/alexhenrie/ioperm and enter the parallel port's base address manually, the program correctly displays the states of the parallel port's pins and can manipulate them. That means that the main part of the program works, it's just failing to automatically detect the port. The author helpfully wrote up an explanation of what the program does to find parallel ports and their base addresses: https://www.downtowndougbrown.com/2014/11/detecting-parallel-ports-and-thei… $ sha256sum ParallelPortTesterSetup-1.0.0.2.exe 9e9b399dd92ac48433af2061eb8491d1d68a6134eaeab2efcdcd36361e723d09 -- 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 3

[Bug 44920] New: Starcraft II Arcade Crash during load
by wine-bugs＠winehq.org July 5, 2026

July 5, 2026

https://bugs.winehq.org/show_bug.cgi?id=44920 Bug ID: 44920 Summary: Starcraft II Arcade Crash during load Product: Wine Version: 3.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: antonio.e.russo(a)gmail.com Distribution: --- Created attachment 61011 --> https://bugs.winehq.org/attachment.cgi?id=61011 WINEDEBUG=warn+all log of crash (gzipped) Starcraft II is a moving target. After the most recent patch, I was unable to use wine-staging 2.21, which had been working excellently for me. Wine 3.5 has trouble: loading the "Hero Attack 3X" (popular) arcade game, the game crashes. I've attached a "WINEDEBUG=warn+all" log, and can help debug. I checked "use 32-bit version", and I am using a clean prefix. -- 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.

4 26

[Bug 26011] New: BitLocker.exe not working with wine
by wine-bugs＠winehq.org July 5, 2026

July 5, 2026

http://bugs.winehq.org/show_bug.cgi?id=26011 Summary: BitLocker.exe not working with wine Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: paloseco(a)gmail.com Created an attachment (id=33174) --> (http://bugs.winehq.org/attachment.cgi?id=33174) Log of the BitLocker.exe errors when trying to load USB Removable BitLocker.exe is a tool for reading/writing partitions or USB removable media encrypted with the BitLocker application included with Windows 7 Ultimate (similar to TrueCrypt). The pendrives encrypted include the portable application to read/write from windows xp platform. >From winecfg I've created a new drive pointing to the folder where the USB Removable is mounted, but doesn't work due to unimplemented features. -- 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