doomsday.exe does not work with Wine, doomsday-crink.exe crashes

[Arctic-Circle-System]

I'm not sure how to describe this behavior, so I have instead attached a screenshot of doomsday.exe and a copy of the backtrace for doomsday-crink.exe.

backtrace.txt

[TheComputerGuy96]

And while at the topic of Wine, here's my own Wine observations:

• The 268 byte executable fails to load by default because Wine doesn't correctly handle NULL ImageBase (the executable is loaded at 0x20000 but the entry point code doesn't add that base before loading because the dynamic relocation image flag isn't set and the it jumps to the wrong address, causing a segfault); I was able to make it load by setting a higher image base

• The 268 byte executable can be as small as 152 bytes on 64-bit Wine (going lower than that causes a segfault in libc or a bad EXE format error); here are the changes I needed to make: 268b_wine.diff

And as for how big it can get, I was able to enlarge it up to 0x7FBE0000 (2143158272) bytes without LAA enabled (any byte higher and I get an allocation error)

• The Crinkler Doomsday executable somehow calls IsProcessorFeaturePresent() with the NtDeviceIoControlFile() input buffer and shortly segfaults after that (maybe there's a stack overflow/corruption?)

• There's a bug report for that color code issue: https://bugs.winehq.org/show_bug.cgi?id=52850 (maybe the Unix-side shell would work better? Update: Using the Unix-side shell is worse because the only thing that gets printed is a question mark)

[InkboxSoftware]

The above console is outputting the entire ANSI string, without parsing it at all. That means that the terminal is either not compatible with ANSI string formatting, or it hasn't been turned on yet. The program calls a kernel function to ensure that Window's new "Virtual Terminal" features are enabled, which allows ANSI strings to control console formatting, but it seems like Wine may not support those functions.