News for hackers. Stuff that matters.
Re:PC DOS 1.0, but Not Quite by Shorel on Friday May 26, 2017 @11:25PM (#14428771)
One reason is that .COM programs were copied to memory as they were, in a single segment, and therefore could access a max of 64 kilobytes of RAM, and they itself could be max 64 kb. They are a tiny memory dump of the program.

.EXE programs have loaders that handled the segmented memory and could access much more, up to the 1MB of memory space. That loader of course made .EXE programs larger than .COM.

Re:PC DOS 1.0, but Not Quite by WalterBright on Saturday May 27, 2017 @02:18AM (#14429133)
> could access a max of 64 kilobytes of RAM

This is incorrect. A COM program had to fit its code and static data into 64K, but it could access as much RAM as existed on the machine.

A related misconception is that the segment registers in COM programs had to have all the same value. This is incorrect as well, as the program once loaded could reset them to any value.

Re:PC DOS 1.0, but Not Quite by nils-m-holm on Saturday May 27, 2017 @02:59AM (#14429215)
Indeed! First thing the executables generated by my early DOS compilers did was to set up the es: and ds: segments in order to get more space.

Eventually I overcame laziness though, and started to study the EXE file format, which, AFAIR, does not have a "loader", (as Shorel suggested) but just a header describing the layout of the file. I think EXE files tend to be larger, just because they can be larger.

Re:PC DOS 1.0, but Not Quite by int_19h on Saturday May 27, 2017 @09:24PM (#14432701)
MZ (DOS .exe) requires a loader - smarter than just "copy this whole thing into memory and jump to start", anyway - because it has a relocation table. But, of course, the loader is not part of the executable itself, so it doesn't contribute to its size. I suspect that the reference was to the relocation tables themselves.
Re:PC DOS 1.0, but Not Quite by int_19h on Saturday May 27, 2017 @08:56PM (#14432641)
> and they itself could be max 64 kb

Minus 256 bytes at the beginning for the Program Segment Prefix (hence why every .com assembly listing usually starts with ORG 100h).