Retrowin32: Async, DLL loading, tracing execution, and Zig | Hacker News Reader

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

neugierig.org

81 pointsgoranmoomin13 comments

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....

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.

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.

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?

Typically by using ntdll.dll. That is the low level interface of Windows NT.

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.

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!

Wow, thanks so much for this link!

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!

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

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.

That is documented behavior that should still be valid to this day.

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.)

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

Reply on news.ycombinator.com