Hacker News new | past | comments | ask | show | jobs | submit login

Ah, so DOS did this too! I was aware that Windows NT similarly has a few “.COM” command-line utilities that are actually Portable Executables (the successor to the successor to the MZ format), for compatibility's sake.



I find it actually somewhat hard to believe that DOS ever cared about the extension of filename passed to EXEC because the same syscall is also used (with AL != 0) for overlays and can also be used as generic MZ loader, in both these cases such files typically did not have EXE extension.

In DOS 5.0+ (at least, never tried it on earlier) and probably every version of Windows DOS's EXEC and Windows' CreateProcess()/LoadLibrary() does not care about the filename and just uses loader implementation appropriate for whatever was detected from the header.

ShellExecute() (and it's DOS "equivalent" EXEC(%COMSPEC%, "/C foo")) does care about the extension. In DOS there is hardcoded list of extensions that are executable (BAT, COM, EXE, in this order, with BAT being handled by the command.com itself. There is no way to directly execute image with different extension from the command line), while in Windows what happens depends on contents of HKCR.

One notable feature of how this is handled by DOS is that when you have both foo.exe and foo.com then foo.com takes precedence (IIRC this has something to do with the fact that traditional Windows entrypoint was called WIN.COM although it always was MZ binary).


If I remember correctly, the order was COM, EXE, BAT.

On NT platforms today, this is actually user-configurable via the PATHEXT environment variable - and that definitely has them in that order.

I wonder why that was the case. I remember reading some explanation about how it was about backwards compatibility, but that doesn't make much sense, since the first release of DOS 1.0 already had all three. Strictly speaking, COM as a format predates DOS (it's originally from CP/M), while EXE and BAT are more recent additions, COM files compiled for CP/M cannot run on DOS for other reasons, so there's still no compat issue there.


Having an order of precedence provides predictable behaviour and, perhaps more importantly, is simpler to implement than forcing disambiguation.

But probably it's just that they added the checks in that order and put no further thought into it.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: