when DOS is not DOS

[Octocontrabass]

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.

You can also replace the BIOS with ntoskrnl.exe or vmlinux, and you will have full USB flash drive FAT32 access with long file name support only a "BIOS" call away.

[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.

You can also replace the BIOS with ntoskrnl.exe or vmlinux, and you will have full USB flash drive FAT32 access with long file name support only a "BIOS" call away.

Seems like a lot of work for such a little gain.

[Octocontrabass]

Seems like a lot of work for such a little gain.

So is writing an OS.

[iansjack]

I think we have reached the conclusion that you can replace MS-DOS with another operating system. On that bombshell....

[Antti]

Code: Select all

  ______________________           ______________________
 |                      |         |                      |
 |  "Standard BIOS PC"  |         |    "Non-BIOS PC"     |
 |______________________|         |______________________|
                        |         |
  ______________________|         |______________________
 |                      |         |                      |
 |  "Standard IO.SYS"   |         |    "OEM's IO.SYS"    |
 |______________________|         |______________________|
                        |____ ____|
                             |
                   __________|___________
                  |                      |
                  |  "IO.SYS Interface"  |
                  |__________ ___________|
                             |
                   __________|___________
                  |                      |
                  |     "MSDOS.SYS"      |
                  |__________ ___________|
                             |
                   __________|___________
                  |                      |
                  |    "command.com"     |
                  |______________________|

The basic idea was not bad if there really were plenty of OEM's IO.SYS implementations widely in use. However, it seems that the non-BIOS branch is almost non-existing.

Instead of the limited sector based drive access they would have full USB flash drive FAT32 file access with long file name support

There is a huge OSDev-ethical controversy. In this context, I am not sure how a project like this is interesting. As a DOS-programming experiment, why not.

[Kevin]

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.

Okay, so the whole point is about terminology?

If you do this, I think we all agree that you're running on a DOS kernel, and you're technically just a DOS application. You would probably have to leave file system, memory and possibly to a certain degree also task management to the DOS kernel if you don't want to break it.

What makes your question interesting is that DOS applications have full access to everything, so they can do very OS-like things. So there is some point at which the user perception is that your application really provides more OS-like functionality than your (DOS) kernel does. We know that the perception changed from "just a graphical shell" to "an OS" with the change from Windows 3.1 to 95, even though both have a DOS running underneath. At this point, Windows already didn't use the DOS file system drivers any more, but bypassed them and used its own drivers.

So perhaps this gives an idea on when the combination of a DOS kernel with some additional software starts being perceived as a separate OS.

[iansjack]

The basic idea was not bad if there really were plenty of OEM's IO.SYS implementations widely in use. However, it seems that the non-BIOS branch is almost non-existing.

There is (or was) a third branch to your diagram - "Non-standard BIOS PC".

In the early days, before the 5150 became the de facto standard, there were a number of manufacturers producing PCs that were essentially clones of the IBM offering but had slightly different BIOS routines. Examples that spring to mind are Apricot, Sirius, and early Compaqs. Each of these required their own version of MS-DOS to interface between their BIOS routines and the DOS API. But each of these machines - like just about every computer - had some sort of ROM-based I/O routines. It is certainly true that some of the earliest hobby computers did not contain such ROMs and had to be bootstrapped by entering the initial code via toggle switches, and this was very common with the very earliest computers; this, I think, is irrelevant to the present discussion.

Your right-hand branch ("Non-BIOS PC") is, I believe, an empty branch. And, in the context of MS-DOS - which is implied by the fact that this discussion is predicated upon io.sys and msdos.sys - the idea of "Before there was a ROM BIOS" is just nonsense. As fas as MS-DOS is concerned there has always been a ROM BIOS. MS-DOS was designed for the 5150, and the 5150 had such a BIOS; there is no "before" in this context.

It is, of course, easy to denigrate experience and rely upon half-understood information from web sites.

[embryo2]

I think we have reached the conclusion that you can replace MS-DOS with another operating system.

It was an artistic impression of a historic scene. Pure logical approach was not considered (as it seems to me).

[mikegonta]

... in the context of MS-DOS - which is implied by the fact that this discussion is predicated upon io.sys and msdos.sys - the idea of
"Before there was a ROM BIOS" is just nonsense. As fas as MS-DOS is concerned there has always been a ROM BIOS. MS-DOS was
designed for the 5150, and the 5150 had such a BIOS; there is no "before" in this context.

Here you can follow a link to download the original source code for MS-DOS v1.1. The file io.asm assembles to the disk based io.sys.
In this early MS-DOS version; which we know from history was adapted from 86-DOS (and says so in the file) by the original author
Tim Paterson (who is mentioned in the header comment of msdos.asm; there are absolutely no BIOS calls - all input/output is
accomplished through port I/O.

It is, of course, easy to denigrate experience and rely upon half-understood information from web sites.

Sheesh.

[rdos]

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.

You can also replace the BIOS with ntoskrnl.exe or vmlinux, and you will have full USB flash drive FAT32 access with long file name support only a "BIOS" call away.

Yes, or with your own DOS emulators. I once had this, but since I no longer maintain them, they probably aren't functional anymore. If I get a lot of time some day I might try to update them and check some old DOS apps.

[Kazinsal]

Here you can follow a link to download the original source code for MS-DOS v1.1. The file io.asm assembles to the disk based io.sys.
In this early MS-DOS version; which we know from history was adapted from 86-DOS (and says so in the file) by the original author
Tim Paterson (who is mentioned in the header comment of msdos.asm; there are absolutely no BIOS calls - all input/output is
accomplished through port I/O.

Read closer yourself -- that particular io.sys is an io.sys providing glue for Seattle Computer Products CPU support cards and disk controllers, not generic IBM PCs, thus the lack of BIOS calls.

If you're using the DOS kernel as a basis for your operating system, you are both using DOS as your operating system kernel (making your OS some weird hybrid of a DOS clone and MS-DOS itself) and are likely violating a few nice license agreements about unauthorized redistribution of Microsoft code.

And it's just a weird idea on top of everything. An interesting project for a bored rainy day, sure -- what exactly *can* you do with DOS? But as a real project? It'd be more worth your time to write a real operating system

[mikegonta]

Here you can follow a link to download the original source code for MS-DOS v1.1. The file io.asm assembles to the disk based io.sys.
In this early MS-DOS version; which we know from history was adapted from 86-DOS (and says so in the file) by the original author
Tim Paterson (who is mentioned in the header comment of msdos.asm; there are absolutely no BIOS calls - all input/output is
accomplished through port I/O.

Read closer yourself -- that particular io.sys is an io.sys providing glue for Seattle Computer Products CPU support cards and disk
controllers, not generic IBM PCs, thus the lack of BIOS calls.

My lead in was that originally io.sys was the BIOS, it was others who started the IBM PC thing (which, by the way, IBM never shipped an
io.sys - their licensed version was called ibmbio.sys. Also, if you read closer, you might discover that Microsoft purchased 86DOS from
Seattle CP and hired Tim Paterson to shape it into MS-DOS version 1.0 of which this is the source code for (other OEM vendors had their
own BIOS-less versions).

If you're using the DOS kernel as a basis for your operating system, you are both using DOS as your operating system kernel (making your
OS some weird hybrid of a DOS clone and MS-DOS itself) ...

Thanks for the input - that's the subject of this discussion - when is DOS not DOS. The "DOS BIOS" is not DOS because on a classic PC
(Compatibility Support Module enabled UEFI) it is only a BIOS wrapper. The DOS file system functions (while part of the DOS kernel)
of and by themselves can not be considered a DOS Operating System.

... and are likely violating a few nice license agreements about unauthorized redistribution of Microsoft code.

That hair has been split many times - io.sys was freely distributable on all bootable floppy disks formatted back in the day, yadda yadda.

And it's just a weird idea on top of everything. An interesting project for a bored rainy day, sure -- what exactly *can* you do with DOS?

That "flame" is not worth the match head it's printed on.

But as a real project? It'd be more worth your time to write a real operating system

Show us yours and we'll talk.

[Antti]

The DOS file system functions (while part of the DOS kernel) of and by themselves can not be considered a DOS Operating System.

Technically it might be possible to turn this into a valid statement but you will have difficulties in convincing people. Those file system functions are not just providing mechanism but significant policy is involved. And that policy is very DOS.

Show us yours and we'll talk.

A little bit rude comment. However, I kind of agree with you. In the hobby OSDev scene, there seems to be very few "production quality" operating systems available. All the common IO.SYS implementations are production quality although someone could probably list a truckload of flaws. If you built your OS based on that, assuming that your code is high quality too, you could have an operating system that can be valid in production use.

Still, there is a huge OSDev-ethical controversy.

[iansjack]

... and are likely violating a few nice license agreements about unauthorized redistribution of Microsoft code.

That hair has been split many times - io.sys was freely distributable on all bootable floppy disks formatted back in the day, yadda yadda.

From the relevant Microsoft Licence agreement:

You may not distribute or publish the software or Derivative Works.

[mikegonta]

Show us yours and we'll talk.

A little bit rude comment.

And I apologize for that, but it was meant to be tongue in cheek (I'm not a big user of the funny face). It's sort of like when someone
makes an informal (not requested) business proposal and the response is "OK, we'll talk" (a sort of brush off), or "my people will contact
your people". I should have said "Show us yours and we'll have lunch"