13

The PC DOS kernel is stored in files named IBMBIO.COM and IBMDOS.COM. Although they have the COM extension like executable files, neither of these files could actually be run from the command line, and attempting to do so would crash the system. To prevent such crashes, the kernel files were given ‘hidden’ and ‘system’ attributes (apparently specifically invented for the purpose), so that the command interpreter would not try to execute them. (In some versions of DR-DOS, this was instead solved by simply making the files print version information and exit when launched from the command line.)

Given that those files are not regular executables, why were they given the COM extension in the first place? Why go to the trouble of inventing ‘hidden’ and ‘system’ attributes? Why not instead give them the SYS extension, like MS-DOS, (ealier versions of) DR DOS and even 86-DOS did?

Improve this question
9
  • 2
    Unless the person who named the files shows up here, I don't see how we can get a definitive answer. People often name files inappropriately. On the other hand, I'd guess that the OS boot files were named before the OS got the ability to run commands, since that particular OS egg needs to come before its chicken.
    – dave
    Commented May 3, 2020 at 16:20
  • 2
    Maybe, but I’m willing to accept speculative answers, of which two kinds seem the most probable: that despite these complications the name served some purpose or that it was a haphazardly chosen default of some toolchain that stuck for the sake of compatibility. Evidence for either should be possible to find in public information.
    – user3840170
    Commented May 3, 2020 at 16:43
  • 2
    If I remember correctly, MS-DOC gave the files the SYS extension whereas IBM DOS gave them the COM extension.
    – No'am Newman
    Commented May 4, 2020 at 5:47
  • 3
    Arguably, for early versions of PC/MS-DOS at least, .COM is a more accurate extension than .SYS: IBMBIO.COM and IBMDOS.COM are memory images, loaded as-is by the boot sector (their contents are moved around by SYSINIT during boot, but that’s nothing a .COM file couldn’t do either). .SYS implies a device-driver-like structure, which IBMBIO.COM/IO.SYS don’t have. Execution starts at the beginning of IBMBIO.COM/IO.SYS, just like a .COM file, except that there is no PSP before the image.
    – Stephen Kitt
    Commented May 4, 2020 at 14:01
  • 2
    PC-DOS 1.0 didn’t support installable drivers, not until 2.0 I believe. Therefore nothing used the .SYS extension yet; I don’t even thing that CONFIG.SYS existed either back then. So there was no reason to use .SYS (or any other extension). Hiding the file and calling it .COM seems pretty reasonable.
    – Euro Micelli
    Commented May 4, 2020 at 15:07

1 Answer 1

Reset to default
9

Given that those files are not regular executables, why were they given the COM extension in the first place?

They are executable files. They are loadable binary images. In so far they are exactly like COM files, except, when loaded, they are not loaded at offset 0100h, after a prepared PSP, and started with CS:IP as segment:0100h, but segment:0000h. Programming/assembling sources works exactly like with a COM program, except were a 'regular' COM file source starts with an ORG 0100h directrive, BIOS and DOS code is assembled with ORG 0000h instead (*1).

[Insert:] Thanks to a hint by Stephen Kitt pointing out the avaibility of the original sources, it looks as if 86-DOS really used this, as the source starts like this (line 109):

ORG  0
PUT  100H

So while the address base 0000h, the assembler output is moved to 0100h. This means the resulting file may have included some 256 bytes infront. But then again, there must have been some kind of merger utility, as with PC-DOS 1.0 IBMBIO and IBMDOS were not loaded as files, but as one continuous blob of 10 Kib from sector 8 onward.

86-DOS did not care about files at all. The directory was only checkt to see if the entries were there, not to use any of the meta information. It wasn't until PC-DOS 2.0 that the file system really got observed.

So for all development and testing purpose they could be as well assembled as COM files as well. While it doesn't matter for the very first version, as soon as a basic system is bootable, further development and debugging can be done in situ, using the (preloaded) OS environment and debugger. All that is necessary to do so is changing the ORG statement to 0100h before compiling.

Why not give them the SYS extension, like MS-DOS and (earlier versions of) DR DOS did?

Sure, it would have been possible - and would as well have made a lot of sense. Then again, it's always easy to see something as obvious in hindsight. Also, we all know how impossible unsensible users are - who would have thought about them unhiding these files and trying to execute? There is no sane reason to do so.

Well, I guess the MS-DOS team had to learn this lesson and it took about a year:

  • August 1980: SCP ships 86-DOS 0.1
  • September 1980: Microsoft licences 86-DOS for 'some' customer
  • April 1981: SCP finishes and ships 86-DOS 1.0 using the .COM type
  • August 1981: MS delivers 86-DOS 1.14 as PC-DOS 1.0 to IBM, both using .COM file types for IBMBIO and IBMDOS (*2)
  • May 1982: (MS/86)-DOS 1.24 is released by IBM as PC-DOS 1.1, both still with .COM types
  • June 1982: Microsoft released MS-DOS 1.25. The first version to be used with (mostly) PC compatible machines (*3), as well the first version where the .SYS file type was used.

IBM never followed that switch, and some manufacturers of compatible systems seem to have continued with a .COM type (IOSYS.COM and MSDOS.COM in case of Compaq)

In the end, it's as with many 'why' questions, as Another_Dave already mentions:

"Unless the person who named the files shows up here, I don't see how we can get a definitive answer."

*1 - Today many would not care and make it the same, but back then, saving 256 bytes of RAM was a big thing. After all, the first 86-DOS could boot in as little as 12 KiB, leaving space for user code in systems with as little as 16 KiB of RAM. Something the PC no longer supported, as here the BIOS loads the Boot sector to 07C00h (that's 1 Ki below 32 Ki). Thus 32 KiB was the minimum system for DOS.

*2 - BTW, the whole wigwag is a bit more complex, as IBMBIO contains two parts:

  • the machine depended BIOS interface and
  • the machine independent SYSINT code, controlling the boot process.

In case of an IBM PC, the machine dependent BIOS interface is rather small and mostly a collection of device drivers, as it uses the ROM-BIOS. For non IBM machines it contained the whole BIOS.

*3 - I still got somewhere an original shrinkwrapped DOS 1.25 for Columbia Data Products' MPC.

Improve this answer
9
  • 1
    We even have the source code to see how the binary was constructed (but not the assembler command, or details of any subsequent processing).
    – Stephen Kitt
    Commented May 5, 2020 at 5:59
  • 1
    "they are exactly like COM files, except, when loaded, they are not loaded at offset 0100h, after a prepared PSP, and started with CS:IP as segment:0100h, but segment:0000h" The execution environment for each a normal .COM executable, the BIO file, and the DOS file, is completely different, not only in the origin offset. For instance, the (late) MS-/PC-DOS load protocols always load the BIO file's first 1536 or 2048 bytes to linear 00700h, and pass a first cluster, and a BPB pointed to by ss:bp. For .COM (or .EXE) files there's no BPB, but the entire executable image is loaded.
    – ecm
    Commented May 6, 2020 at 22:10
  • 1
    @Raffzahn: I did specify that I was talking about later MS-DOS versions' protocols. Even so, 70h:0 or 60h:0 are both incompatible to application mode. The point is that you cannot just do this: "as soon as a basic system is bootable, further development and debugging can be done in situ, using the (preloaded) OS environment and debugger", because of the different load protocol of a kernel versus an application. Other than the specifics I already mentioned, the kernel also expects to have control over the entire base memory as given by int 12h.
    – ecm
    Commented May 7, 2020 at 5:37
  • 1
    @ecm IO hands over a size of 1 in DX to DOS initialisation, which in turn lets DOS scan all memory, after it's own memory, for being writable. Your insistence about 'cannot do' sounds like you never tried to get new software running on a new system with nothing than the target itself and some older (Z80 in this case) system for cross compilation. In 1979 the luxury of a highly developed toolchain and emulators was non existent. ICE and Logic Analyzers are out of range for most. Long story short, if you want to explain how something started, looking at the end of development isn't helpful.
    – Raffzahn
    Commented May 7, 2020 at 10:11
  • 1
    @Raffzahn: Fair about this being applicable to the initial versions of the files, if it is, but it seemed as if you referred to IBMBIO.COM / IBMDOS.COM generally, across their entire history: "They are executable files. They are loadable binary images. In so far they are [...]" -- So you could more precisely refer to the fact that, even if it was sensible for 86-DOS 1.x, it isn't any more for the later versions. It is news to me that the kernel parts could be loaded anywhere, and only used memory starting from that point. A debugger'd still have to insure it was located below that though.
    – ecm
    Commented May 7, 2020 at 11:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .