Playing with DOS stub for fun...and more fun

“The Portable Executable (PE) format is a file format for executables, object code, DLLs and others used in 32-bit and 64-bit versions of Windows operating systems.”

“The format has retained limited legacy support to bridge the gap between DOS-based and NT systems. For example, PE/COFF headers still include a DOS executable program, which is by default a DOS stub that displays a message like "This program cannot be run in DOS mode" (or similar), though it can be a full-fledged DOS version of the program (a later notable case being the Windows 98 SE installer).”

It’s this thing here….

Ah…the DOS stub, the little message you see when trying to run Windows programs under DOS. Wait what? Who runs anything under DOS these days?

If you are not a retro gamer or not playing a lot of CTFs you probably don’t need to use DOS that often. But if you do use DOS, ever wanted to make this message a bit more custom?

Let’s try to put something else there. We can manually modify the bytes and get something working but if we want to made this really unique this way might be too difficult as we would be modifying non-string bytes or pushing bytes out of their place. We need to find a better approach. And there is one. Visual Studio’s linker has an option to specify a DOS Stub. We can provide a path to a program that will be put in the resulting file.

Let’s see if that works. We create a simple C++ program and in the settings we specify /STUB option providing a link to a 16-bit executable and hit build. Where to get a 16-bit program? You can write one yourself of course. I happen to have a collection of programs from the 90s so I’ll use that.

But this stub is not cool enough. I’ve recently posted a Twitter message that I was working on an new DOS stub that use fire and scroll effects to print the message. So let’s see if we can make it happen. The fire & scroll program itself works under DOS but if we use it as a /STUB something breaks. It does not work at all or displays some artifacts.

Some simpler graphics effects works so there must be something different between them and of of course I immediately spotted the difference. The fire effect uses 64kB buffer for a double buffering. If I made it smaller it might work. The problem with this buffer is that’s not dynamic so maybe there’s some limitations that we are hitting. We need to get rid of this buffer.

Another way would be to hold only parts of the screen that needs to used for calculating new flames or to use some EMS DOS trickery to allocate - this time dynamically - the bufor needed for the double buffering that we are doing here.

Let’s see if we can get rid of this double buffering at it will work.

Maybe if we remove a bit more.
And more.
And with that change let’s compile…

And now we need to compile our host program with the new DOS stub.
Interestingly the binary with our big stub weights less. Hmm…
Executing under Windows still gives us the regular message but under DOS - viola. Our new customized + fire + scroll effect that print ‘This program cannot be run in DOS mode’. Enjoy.

I hope it was fun and educational video. Maybe next time we will try to put Wolf3d clone as a DOS stub?

[toerktumlare]

for future videos i would recommend actually explaining what you are doing, like now it was "we remove som stuff" and then silence, no explanation of what was removed and why. I would have preferred more explanation.