mrau wrote:

why would i give you a link? i gave you the info;
provocation will not work, read the conversation again;

Hahaha! Awww ... did some of the 6th graders give you a hard time again at school today? Why would you give me a link? Because that's what any intelligent person would do, which, as I correctly assumed, you clearly are not. But don't worry, this "adult mentality" will all make sense when you get a little older -- it's perfectly normal not being able to think like that when you're only 10 ...

Scali wrote:

Yup, when the EXE starts, it just jumps to the entrypoint address that is set to the MZ header. In this case you set it to 0000: […]
Show full quote

Yup, when the EXE starts, it just jumps to the entrypoint address that is set to the MZ header.
In this case you set it to 0000:0000.
Does that work on a real DOS machine? I don't think so.
So unless you verified it to work on real hardware/real DOS, then I don't see what DOSBox would be doing wrong.

I guess the point here is that perhaps DOSBox should fail gracefully instead of completely crashing.

Strange thread is strange.

Maybe try looking for issues in actual DOS game executables instead of messing around with contrived boundary cases.

Please try to keep the conversation civil, or the thread will be locked.

Edit: FWIW, MS-DOS 5 and 6 tend to crash when executing a bodiless (header only) executable file such as the one suggested in the initial post. The actual behavior is arbitrary, depending on the contents of memory, which is typically decided by what was executed before the malformed executable, and this is also the case with DOSBox's internal DOS emulation.

ripsaw8080 wrote:

Strange thread is strange. […]
Show full quote

Strange thread is strange.

Maybe try looking for issues in actual DOS game executables instead of messing around with contrived boundary cases.

Please try to keep the conversation civil, or the thread will be locked.

Edit: FWIW, MS-DOS 5 and 6 tend to crash when executing a bodiless (header only) executable file such as the one suggested in the initial post. The actual behavior is arbitrary, depending on the contents of memory, which is typically decided by what was executed before the malformed executable, and this is also the case with DOSBox's internal DOS emulation.

Thank you very, very much for taking the time to try it out on real DOS systems and sharing your results, ripsaw! That's all I needed to know 😀 +1

Noctumus wrote:

I'm listening ... what is it I don't get? If you can provide a link to the DOS API that specifically states that an EXE must contain some code after the header, that's all I need to know.

Well, to be an executable, wouldn't it have to have something to be executed? For that rather obvious reason, it probably was not specified.

If you want fun with minimal programs, read up on the history of IBM's IEFBR14.

Sincerely,

Gene Wirchenko

Reading this thread feels a lot like Zen. Is an executable with no code still an executable? Is a picture with dimensions 0 by 0 pixels still a picture? Is a wave file with zero sound samples still a wave file?

Hint: it doesn't really matter 😀

Fact: If a specifically-crafted EXE file can crash DosBox, that might hint at an exploitable issue to escape the DOS "sandbox" (yes, I know, nowhere is it stated that DosBox is in any way a secure sandbox, but still, such issues should be fixed when noticed)

It can cause a crash within the emulation, although often it will just execute the code of last program executed. DOSBox itself does not crash -- well, as always, it can depend on how badly the emulated execution path jumps the rails.