Copy pasting (plus some formatting fixes) this r*ddit post here because I haven’t seen any duplicate in a Fediverse search and I think you all deserve to know about this toxic developer. I know I’ve tried using dgvoodoo under Proton to try and fix an old game in the recent past and couldn’t figure out why it’d crash. Now I know. 💩
https://reddit.com/r/pcgaming/comments/1x7k3l5/wine_for_linux_might_mark_dgvoodoo2_as_wontfix/
https://bugs.winehq.org/show_bug.cgi?id=58731
User Nostalgia_Realm used GPT-6 Astra to decompile dgvoodoo2 to check crashing of the utility on Linux/Wine environments
I used GPT-6 Astra to investigate the supplied dgVoodoo2 binaries. It identified the relevant code and produced a working fix in approximately 17 minutes. I then personally confirmed that Snail Mail’s Tutorial renders and responds correctly with the patched DLL.
The findings point to a Wine-specific code path inside dgVoodoo2 as the cause of this regression. No changes to Wine were needed to remove the reproduced crash.
The relevant code does the following:
- Walks the process’s loaded-module list and locates
NTDLL.DLLusing an encoded name.- Reads its export table directly and searches for names containing
wine_get, such aswine_get_version.- Conceals that substring comparison behind arithmetic and numeric constants, rather than a readable Wine-identification string.
- When Wine is detected, takes a path that skips clearing two graphics-state values. Redirecting execution to the normal clearing path removes the reproduced failure.
This was confirmed in 2.82 and 2.87.5. The corresponding check was absent from the supplied 2.8 D3D8/DDraw binaries. Every intervening release was not individually analysed, so this does not establish the exact release that first introduced it.
The fix is very small once the affected DLLs are unpacked:
- 2.82: change one branch-displacement byte in each affected D3D8/DDraw DLL so that the state-clearing instructions also execute under Wine.
- 2.87.5: change one instruction byte per Wine-export detection routine so it returns “not detected.” There are 23 copies across 22 DLLs, including both copies inside the ARM64X D3D9 DLL. The two D3DImm DLLs lack this check.
With the original DLLs, Snail Mail crashes and a separate DirectDraw test fails during surface creation. With the patches, Snail Mail runs and the DirectDraw test passes drawing, pixel readback, and cleanup. DXVK was still needed for D3D11 translation.
I strongly suspect deliberate interference with Wine compatibility, given the obfuscated Wine detection and the harmful path it selects. Intent cannot be established conclusively from this evidence alone, but the Wine detection itself, and its connection to the reproduced failure is concrete. The earlier comment’s more specific D3D12-pointer explanation was not independently established.
He then continues
About this bug report, I am not a coder. I cannot say with 100% certainty that this is a Wine issue. However, the evidence GPT-6 Astra produced seems to point to malice from Dege. He intentionally sabotaged his app to not run via Wine. I’d say this means we can close this bug report and make it a community effort to introduce an open source alternative that can do the same. I think that’s a much better use of our time and AI compute ;)
Has not happened yet but I believe it would happen in the future
User Nostalgia_Realm also said he might provide patched dgvoodoo2 builds in his website
Dege has a history with being against linux for a long time
And also https://github.com/lutris/dgvoodoo2/issues/5#issuecomment-3520470529
What to be expected, according to open source cancer-like development practices (it’d be nice to bet money on this):
you keep it until your d7vk or whatever is in development, using MY stuff for reverse engineering the api implementation details (instead of an old win xp/7 machine, just to save yourself a lot of work, I mean, years of work), being paid by an ugly capitalist company, and then all the sect members and random clueless idiots will be ranting all over the net that you’re the best
then and only then you will ditch dgVoodoo, the “propietary shit”, independently on what the quality of your crap is like
but, in the meantime, at least anybody can read into how much you’re being loved
TLDR:
-
dgvoodoo dev creates intentional sabotage in software code to not run on linux
-
dev lies and crashes out on Lutris’s github and his website about how sabotaged environments are inferior and because they cannot run newer versions of said software
-
gets caught red-handed after a user decomped his software
Sounds like Microsoft’s attempt in early Windows development to prevent users from using alternative versions of DOS.