Thread: Weird access to an exe compiled with windows.h

Off hand without seeing the code, I would guess, your program is not ending... this is common mistake in beginners windows program. If you don't create a handler to handle WM_DESTROY, more specifically, by calling PostQuitMessage when your app needs to end, it will continue to run even though the window has closed.

Unless you're building an actual Windows-Windows program, it should be compiled as a console program imo.

This is like being surprised you get food from a restaurant from the kitchen. Where the heck else do you expect this to come from?

Except of course that firing up the 8086 emulation environment, loading the .com into it, executing it, finding out that it tries to do something not directly allowed, emulating the operation, collecting the output and returning it to your program takes faaaaaaaaaaaaaaaar longer than calling into the kernel a hundred times - certainly longer than a millisecond.

I think this is a clear case of someone not understanding how this stuff works. This isn't like an NES or SNES where you talk directly to the hardware, and for all intents and purposes, you are the O/S. You're not allowed to do that on Windows unless you're a driver, and even then, you have conditions that you must stick with (ie. conforming to specifications).

Nowadays, your program talks to the O/S and requests resources, be it extra memory, file access, or whatever else. If the O/S doesn't like you, it says no, and that's that. That's how modern operating systems work.