when DOS is not DOS

[mikegonta]

In the beginning, int 0x21 was two MS-DOS system files - io.sys and msdos.sys. Originally io.sys was an OEM
customizable BIOS similar to the earlier CPM's BDOS. When IBM introduced the "PC" io.sys was and is an
interface to the classic PC BIOS. msdos.sys is the low level file system interface. In the latest actual DOS version
(the one that came with Windows98) io.sys contains the functionality of msdos.sys (msdos.sys is actually a text
file for configuration). io.sys is a high level BIOS and while it is the essence of DOS - it's not actually DOS, nor is
it an operating system - that's the providence of command.com.

Simply rename your own real mode operating system (standalone, game, etc) "command.com" and create a
bootable DOS USB flash drive with the latest version of io.sys (freely downloadable on the net). io.sys will load
and initialize and then load and run your own real mode code - giving you full access to the MS-DOS "BIOS"
without actually running DOS.

You've always been able to replace command.com with your own version, however the user will see a screen asking
for the name and location of the replacement (even if it is named command.com and is located in the root directory.
To get around this and have io.sys load and run your own code directly it must be a DOS "MZ" exe file even though
it is named command.com and the first byte of the code must be 0x7A which is is checked by io.sys.

0x7A is the "jp" opcode.

Code: Select all

; FASM
use16
format mz
  jp .1 ; first byte must be 0x7A
.1:

; io.sys displays a Windows98 splash screen in graphics mode
  mov ax, 3
  int 0x10 ; change to text mode
  
  push cs
  pop ds
  mov ah, 9
  mov dx, hello
  int 0x21
  jmp $
hello: db 'hello IOsys world$'

In this version of io.sys - io.sys does not have to be the first file in the root directory, msdos.sys is not required
(not even an empty file) and long file names are supported. Another cool thing is that you can have io.sys display
your own splash screen instead of the Windows98. Simply create a 320X400 256 color bmp, rename it "logo.sys"
and put it in the root directory.

[Combuster]

io.sys (the kernel) and command.com (the UI) form the operating system as a whole. In its history there have been many cases where command.com had been moved, replaced, or otherwise not started in favour of a different UI, or just the word processor as the only application that people were meant to use at that point.

Yet, even if you remove command.com, you can still run all the other DOS applications natively, so from their perspective it's still DOS, and as long as io.sys remains mostly functional it's always DOS, DOS with something, or something on top of DOS, even if we cease calling it that.

[mikegonta]

io.sys (the kernel) and command.com (the UI) form the operating system as a whole. In its history there have been many cases
where command.com had been moved, replaced, or otherwise not started in favour of a different UI, or just the word processor
as the only application that people were meant to use at that point.

Yet, even if you remove command.com, you can still run all the other DOS applications natively, so from their perspective it's still
DOS, and as long as io.sys remains mostly functional it's always DOS, DOS with something, or something on top of DOS, even if we
cease calling it that.

Exactly.
And that's why we call it DOS. Before DOS there were standalone programs that utilized the BIOS drivers, but the BIOS is not
an operating system. Drivers alone do not an operating system make. Without command.com or a replacement what would happen
when a TSR or even a regular program terminated? io.sys would be looking for command.com which wouldn't be there - what kind
of OS is that?

DOS ran on top of the BIOS, but DOS is not called a BIOS program.

[Octocontrabass]

io.sys will load
and initialize and then load and run your own real mode code - giving you full access to the MS-DOS "BIOS"
without actually running DOS.

Would you say replacing smss.exe gives you full access to the Windows NT "BIOS" without actually running Windows?

Would you say replacing /sbin/init gives you full access to the Linux "BIOS" without actually running Linux?

[Antti]

Here is a small subset of INT 21h services:

Code: Select all

AH      Description

39h     Create subdirectory
3Ah     Remove subdirectory
3Bh     Change current directory
3Ch     Create or truncate file
3Dh     Open file
3Eh     Close file
3Fh     Read file or device
41h     Delete file
42h     Move file pointer
43h     Get or set file attributes
44h     I/O control for devices
47h     Get current directory
4Bh     Execute program
4Eh     Find first file
4Fh     Find next file
56h     Rename file

I would call it a Disk Operating System if you have these services available. The fact that the most DOS implementations happen to run on top of the BIOS is just an implementation drawback. I thought that my OS will have a small subset of INT 21h services implemented even in long mode (16-bit code). It is my bootstrap strategy because I have my helper tools for creating the OS. I could bootstrap from my own OS, MS-DOS, DR-DOS, DOSBox, etc.

Having those services available is to provide a standard interface for application programs. Like an OS would do?

[TightCoderEx]

Maybe the only thing to fall back on in form of a definition is history. As an example, Seattle Computers in 1979 tried to market their computer kit, but failed as it did not have an operating system. Hence, QDOS was born. Vector Computers at the same time had a Z80 based S100 system called "Vector MZ", running the Micropolis OS. CP/M 80 & 86 came about in the same time period as did MSDOS & PCDOS.

Before the advent of flexible media, there was the ability to poke hex code into memory, get something to run using the "OS" in firmware, but it wasn't till the UI layer on top of BIOS came into being that these basically hunks of integrated circuits became useful. If one was to ask most people, when is the last time you run a machine with DOS, some would respond, I've only heard my grandfather/mother talk about that, but most would say long, long time ago. Technically though, most computer still rely on the operating system on disk, albeit, solid state will probably supersede that in the near future.

I've always considered the operating system only that software that actually interacts with the devices on the motherboard. Then, successively layers are added upon that such as file systems, UI and GUI, but these have colloquially become known as DOS as you actually at one point needed to put a disk into a drive to get any results.

[Combuster]

Without command.com or a replacement what would happen when a TSR or even a regular program terminated? io.sys would be looking for command.com which wouldn't be there - what kind of OS is that?

That question is equivalent to "How many bugs do I need to purposefully introduce before I'm allowed to stop calling it by its name"

[mikegonta]

My primary observation here (base on my current research) is that originally io.sys was the BIOS.

Before there was a ROM BIOS each OEM vendor provided a customized BIOS for that particular machine. There was CPM's BDOS
and MS-DOS' io.sys. Later on with the introduction of the ROM BIOS io.sys was a wrapper for these BIOS functions. Later on, the
functionality of these "BIOS" functions was improved with features such as redirection. The Disk Operating System's msdos.sys
drivers ran on top of this "BIOS".

Without the required User Interface - command.com - the end user could not Operate the Disk or run a program (it's
command.com that reads and processes autoexec.bat). Even though only that program was running while the program was
running, the user had the impression that DOS was running because there was command.com when the program ended (or they
could break out with CTRL-BREAK).

[iansjack]

I believe that you are incorrect. The BIOS in PCs was always based in ROM. How do you suppose the computer could have loaded io.sys in the first place without a BIOS containing routines to control the floppy drives? The original 5150 came with extremely comprehensive documentation which included a full listing of the (ROM based) BIOS. As I'm sure you know, the 5150 could be operated and programmed in BASIC without having to load anything from a disk. Again, this rather mitigates against the idea that the BIOS was contained in a disk-stored file.

[mikegonta]

I believe that you are incorrect. The BIOS in PCs was always based in ROM. How do you suppose the computer could have loaded io.sys in the first place without a BIOS containing routines to control the floppy drives? The original 5150 came with extremely comprehensive documentation which included a full listing of the (ROM based) BIOS. As I'm sure you know, the 5150 could be operated and programmed in BASIC without having to load anything from a disk. Again, this rather mitigates against the idea that the BIOS was contained in a disk-stored file.

Apparently, there was computer life before the IBM PC. You had better read up on your history

The OAK reflected the structure of MS-DOS, with the “BIOS” (IO.SYS or IBMBIO.COM) on the lowest level, the “DOS” (MSDOS.SYS
or IBMDOS.COM) in the center, and the shell (typically COMMAND.COM) running on top.

The OAK contained the full source code to IO.SYS, since that was the part of DOS closest to the hardware and most likely to
require adapting to the OEM’s platform.

[iansjack]

I am in the fortunate position of not having to read up on my history - I have lived it. I am, of course, aware of computers before the IBM PC (I used many of them at the time). However, you did specifically refer to MS-DOS and I'm sure I don't need to tell that that was designed for the IBM PC, not one of those earlier computers (almost all of which also had a basic input/output system stored in ROM).

Rather than referring me to other sites (interesting that you chose the OS2 museum to instruct me on DOS ) why not answer my question? Without basic input/output routines to control the disk drives how does a computer load its "BIOS" from disk? Those routines can be entered manually via front-panel switches - a rather tedious process - but more commonly they are built in to the computer in a ROM; this is what we call the BIOS. It really hasn't changed that much, in concept, over the years.

The routines that you refer to in io.sys are a higher level; I believe these are the DOS interrupt routines accessed via int 21, as opposed to the BIOS interrupt routines which are handled by the ROM. Nothing special about MS-DOS there; almost all operating systems provide input/outpust services that are built upon the BIOS or are completely independent from it. But we still need that original code, in some form, to bootstrap the computer.

PS - you need to do a little more research on the place of BDOS in CP/M and it's relationship to the BIOS (no - it is not the BIOS!). Have you ever actually used CP/M?

PPS - now I see where you are going wrong. You are confusing DOS BIOS, a part of MS-DOS, with the ROM BIOS (which most people just call the BIOS) that is built into almost every PC (let's not get into a discussion of whether UEFI is a form of BIOS or not). There was never a time - as far as MS-DOS is concerned, when computers didn't have the latter. It is an essential component in getting the computer to function. The former, you can take it or leave it; BASIC on the 5150 didn't need it; OS/2 didn't need it; NT didn't need it; newer versions of Windows didn't need it - but they all needed the ROM BIOS.

[mikegonta]

I am in the fortunate position of not having to read up on my history - I have lived it. I am, of course, aware of computers before
the IBM PC (I used many of them at the time). However, you did specifically refer to MS-DOS

I also referred to CPM, but more specifically the reference was to latest version of MS-DOS's io.sys (and similar disk based "BIOS"
system files, such as the original io.sys and others)

.and I'm sure I don't need to tell that that was designed for the IBM PC, not one of those earlier computers (almost all of which also
had a basic input/output system stored in ROM).

Rather than referring me to other sites (interesting that you chose the OS2 museum to instruct me on DOS

There is very good DOS instruction there, including the fact that Microsoft provided the source code to OEMs for the purpose of
customizing their non PC hardware.
[Funny Face deleted]

why not answer my question? Without basic input/output routines to control the disk drives how does a computer load its "BIOS" from disk?

OK, I should have said IBM PC ROM BIOS [Funny Face inserted]

PS - you need to do a little more research on the place of BDOS in CP/M and it's relationship to the BIOS (no - it is not the BIOS!). Have you
ever actually used CP/M?

This been there, done that is getting a bit tedious. Take a look as some early CP/M source code:

Code: Select all

 /* C P / M   B A S I C   I / O    S Y S T E M    (B I O S)

                    COPYRIGHT (C) GARY A. KILDALL
                             JUNE, 1975

                                                          */

That and other early CP/M BDOS source code have no BIOS calls and all input/output hardware access is is done by reading and writing
i/o ports. Those early machines only had a ROM monitor which could only load the boot sector. The boot sector would then load a
couple of tracks which contained the BDOS.

PPS - now I see where you are going wrong. You are confusing DOS BIOS, a part of MS-DOS, with the ROM BIOS (which most people
just call the BIOS) that is built into almost every PC

Actually, the confusing part is trying to reply while you keep PPSing.

io.sys is a high level BIOS and while it is the essence of DOS - it's not actually DOS, nor is
it an operating system - that's the providence of command.com.

[iansjack]

Command.com is as much the operating system as bash is.

A little learning....

[mikegonta]

Command.com is as much the operating system as bash is.

io.sys is a high level BIOS and while it is the essence of DOS - it's not actually DOS, nor is
it an operating system - that's the providence of command.com.

providence:
... provident or prudent management of resources; ...

I didn't imply that command.com was the operating system, only that io.sys by itself was not an OS.

A little learning....

Someone has to get off of their high horse.

(And us retired folks have much too much free time on their hands).

[mikegonta]

My whole point (before the big guns came out) was that someone could use io.sys to replace the BIOS functions that their real mode
OS was currently using without losing their OS status to DOS. Instead of the limited sector based drive access they would have full
USB flash drive FAT32 file access with long file name support and only a "BIOS" call away.

PS. Sounds like a future SudoBIOS transparent 32 bit protected mode feature.