5 ms·

Retrowin32: Async, DLL loading, tracing execution, and Zig

81 points by goranmoomin 3y ago

amerine 3y ago
I really love how the author shares their thoughts as the flow through the problems in the post. Great read.
dingdingdang 3y ago
Excellent project. One can dream.. somehow Wine never worked for me, just perpetually that little bit off and excessively configurable/hackable! Which I realize is brilliant for many people, just not me, don't have the necessary attention/time-tokens available for yet another it hobby sub!
mysterydip 3y ago
I like the idea of win32 being the next dosbox. Similarly stable but more capable out of the box (higher res, networking, etc)
userbinator 3y ago
What this actually points to is some bug in the emulator; running the program on a native Windows machine is fine. But how can I isolate the bug? Via a disassembler I can see that the initialization code runs a bunch of loops over memory and at some point things go wrong ... but where? Go deep enough into understanding Windows architecture and you'll find that there's a lot of officially-undocumented stuff that various "protections" rely on. PEB/TEB fields, syscall entry points, known fixed addresses, anti-debugging/VM detection, etc. As for that particular scary message, I recognised it as coming from a packer I saw a long time ago --- and a quick search reveals it is PEtite: http://users.freenet.am/~softland/tutorials/Petite.v2.3.MUP.txt http://users.freenet.am/~softland/tutorials/Petite.v2.3.MUP.... Packed software is in general a good way to "stress test" your emulator. Besides the obvious fact of being essentially self-modifying code, they also tend to exercise the more subtle aspects of the OS loader/linker.
- eek2121 3y ago
  Don't forget about the undocumented "bugs" that developers began to rely upon. I was a win16/win32 developer that later implemented the very APIs I used to build stuff in a certain open source project simply because I understood all the bugs/nuances. Quite a few of these bugs Microsoft did NOT fix due to compatibility.
- rice7th 3y ago
  I am no expert but recently I found out that windows syscalls are a complete mistery. They're almost never mentioned in the official docs and with each update they can shift their position. I've found out a reverse engineered version online but they only got the name and the number of parameters. This brings the question how on earth are you supposed to generate code with windows syscalls? Like if I am building a compiler, how the heck am I supposed to know what to put where? Are such syscalls just defined in the winapi and abstracted away? Or each compiler needs to do some black magic fuckery to get core features?
  - atesti 3y ago
    Typically by using ntdll.dll. That is the low level interface of Windows NT.
  - userbinator 3y ago
    The majority of "well-behaved" software doesn't use syscalls directly. Are such syscalls just defined in the winapi and abstracted away? Yes. Unlike Linux, the OS interfaces with the applications via system DLLs (kernel32, user32, gdi32, etc.) As a historical note, the syscall interface on Win9x is completely different from the NT series.
    - rice7th 3y ago
      Thank you for the answer. I was learning assembly and after trying it out on Linux x86_64 I tried on Windows but I got very confused from the lack of syscall docs, so after searching I got to such conclusion. Still, thanks for clearing this out!
- 3y ago
sacnoradhq 3y ago
Oh, DLLs. I vaguely remember thee. :) Once upon a time(tm), I took advantage of the DLL directory search order to crack or change behavior in annoying software. I would compile a proxy DLL to a system DLL that would handle the symbols I was interested in and send all other calls onto the real DLL unmodified. I forgot the mechanism and it probably doesn't work anymore in Windows 11. Edit: Basically: C:\Program Files\Brand\Some App\SYSTEM32.DLL <- mine and this one is loaded ahead of the real system one.
- therein 3y ago
  That is documented behavior that should still be valid to this day.
- userbinator 3y ago
  I believe putting a proxy DLL alongside the main EXE still works. It's the current working directory that's been removed from the search path for security reasons (and IMHO that does make sense.)

81 points by goranmoomin 3y ago

I really love how the author shares their thoughts as the flow through the problems in the post. Great read.

Excellent project. One can dream.. somehow Wine never worked for me, just perpetually that little bit off and excessively configurable/hackable! Which I realize is brilliant for many people, just not me, don't have the necessary attention/time-tokens available for yet another it hobby sub!

mysterydip 3y ago

I like the idea of win32 being the next dosbox. Similarly stable but more capable out of the box (higher res, networking, etc)

userbinator 3y ago

What this actually points to is some bug in the emulator; running the program on a native Windows machine is fine. But how can I isolate the bug? Via a disassembler I can see that the initialization code runs a bunch of loops over memory and at some point things go wrong ... but where? Go deep enough into understanding Windows architecture and you'll find that there's a lot of officially-undocumented stuff that various "protections" rely on. PEB/TEB fields, syscall entry points, known fixed addresses, anti-debugging/VM detection, etc. As for that particular scary message, I recognised it as coming from a packer I saw a long time ago --- and a quick search reveals it is PEtite: http://users.freenet.am/~softland/tutorials/Petite.v2.3.MUP.txt http://users.freenet.am/~softland/tutorials/Petite.v2.3.MUP.... Packed software is in general a good way to "stress test" your emulator. Besides the obvious fact of being essentially self-modifying code, they also tend to exercise the more subtle aspects of the OS loader/linker.

eek2121 3y ago
Don't forget about the undocumented "bugs" that developers began to rely upon. I was a win16/win32 developer that later implemented the very APIs I used to build stuff in a certain open source project simply because I understood all the bugs/nuances. Quite a few of these bugs Microsoft did NOT fix due to compatibility.
rice7th 3y ago
I am no expert but recently I found out that windows syscalls are a complete mistery. They're almost never mentioned in the official docs and with each update they can shift their position. I've found out a reverse engineered version online but they only got the name and the number of parameters. This brings the question how on earth are you supposed to generate code with windows syscalls? Like if I am building a compiler, how the heck am I supposed to know what to put where? Are such syscalls just defined in the winapi and abstracted away? Or each compiler needs to do some black magic fuckery to get core features?
- atesti 3y ago
  Typically by using ntdll.dll. That is the low level interface of Windows NT.
- userbinator 3y ago
  The majority of "well-behaved" software doesn't use syscalls directly. Are such syscalls just defined in the winapi and abstracted away? Yes. Unlike Linux, the OS interfaces with the applications via system DLLs (kernel32, user32, gdi32, etc.) As a historical note, the syscall interface on Win9x is completely different from the NT series.
  - rice7th 3y ago
    Thank you for the answer. I was learning assembly and after trying it out on Linux x86_64 I tried on Windows but I got very confused from the lack of syscall docs, so after searching I got to such conclusion. Still, thanks for clearing this out!
3y ago

sacnoradhq 3y ago

Oh, DLLs. I vaguely remember thee. :) Once upon a time(tm), I took advantage of the DLL directory search order to crack or change behavior in annoying software. I would compile a proxy DLL to a system DLL that would handle the symbols I was interested in and send all other calls onto the real DLL unmodified. I forgot the mechanism and it probably doesn't work anymore in Windows 11. Edit: Basically: C:\Program Files\Brand\Some App\SYSTEM32.DLL <- mine and this one is loaded ahead of the real system one.

therein 3y ago
That is documented behavior that should still be valid to this day.
userbinator 3y ago
I believe putting a proxy DLL alongside the main EXE still works. It's the current working directory that's been removed from the search path for security reasons (and IMHO that does make sense.)