Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
when is DOS not DOS
78 views
Skip to first unread message
Mike Gonta
Jun 14, 2015, 6:40:07 AM6/14/15
to
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 (at that
time IBM 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 "command.com"
and create a bootable DOS USB flash drive with the latest
version of io.sys (freely downloadable on the net).
https://rumorscity.com/2013/12/04/how-to-create-a-dos-bootable-usb-drive/
io.sys will load and initialize and then load and run your own
OS - 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 OS directly it
must be a DOS "MZ" exe file even though it's 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]
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$'
[/code]
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 and rename it "logo.sys" and put it in the root
directory.
Mike Gonta
look and see - many look but few see
http://mikegonta.com
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 (at that
time IBM 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 "command.com"
and create a bootable DOS USB flash drive with the latest
version of io.sys (freely downloadable on the net).
https://rumorscity.com/2013/12/04/how-to-create-a-dos-bootable-usb-drive/
io.sys will load and initialize and then load and run your own
OS - 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 OS directly it
must be a DOS "MZ" exe file even though it's 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]
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$'
[/code]
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 and rename it "logo.sys" and put it in the root
directory.
Mike Gonta
look and see - many look but few see
http://mikegonta.com
Mike Gonta
Jun 15, 2015, 10:41:48 AM6/15/15
to
"Mike Gonta" wrote:
> 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 (at that
> time IBM 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.
Some lively discussion here:
> 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 (at that
> time IBM 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.
http://forum.osdev.org/viewtopic.php?f=1&t=29383
James Harris
Jun 15, 2015, 11:34:28 AM6/15/15
to
This is very interesting, Mike. While it seems to be some well researched info I don't have much to add, or even to criticise. It seems complete as it is. But am copying comp.os.msdos.programmer. Folks there may also be interested.
"Mike Gonta" <mike...@gmail.com> wrote in message news:mljlm3$8nt$1...@speranza.aioe.org...
Maybe there are versions of a free DOS which could be used similarly.
I am also not sure which INT services would be handled by io.sys and which by command.com? Is it as simple as saying that *none* of the INT 0x20 and 0x21 services are handled by command.com? That would make sense. Perhaps it just runs command interpretation and some internal commands and finds and runs external commands.
All good info. Thanks for posting.
James
"Mike Gonta" <mike...@gmail.com> wrote in message news:mljlm3$8nt$1...@speranza.aioe.org...
> 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 (at that
> time IBM 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 "command.com"
> and create a bootable DOS USB flash drive with the latest
> version of io.sys (freely downloadable on the net).
> https://rumorscity.com/2013/12/04/how-to-create-a-dos-bootable-usb-drive/
> io.sys will load and initialize and then load and run your own
> OS - giving you full access to the MS-DOS "BIOS" without
> actually running DOS.
That sounds as though an OS developer could run that io.sys (in a protected environment) and thus run DOS apps in a window. But I suspect there would be legal issues in doing so.
> 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 (at that
> time IBM 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 "command.com"
> and create a bootable DOS USB flash drive with the latest
> version of io.sys (freely downloadable on the net).
> https://rumorscity.com/2013/12/04/how-to-create-a-dos-bootable-usb-drive/
> io.sys will load and initialize and then load and run your own
> OS - giving you full access to the MS-DOS "BIOS" without
> actually running DOS.
Maybe there are versions of a free DOS which could be used similarly.
I am also not sure which INT services would be handled by io.sys and which by command.com? Is it as simple as saying that *none* of the INT 0x20 and 0x21 services are handled by command.com? That would make sense. Perhaps it just runs command interpretation and some internal commands and finds and runs external commands.
James
Mike Gonta
Jun 15, 2015, 12:22:38 PM6/15/15
to
"James Harris" wrote:
> This is very interesting, Mike. While it seems to be some well
> researched info I don't have much to add, or even to criticise.
> It seems complete as it is. But am copying
> comp.os.msdos.programmer. Folks there may also be interested.
>
Probably not. Not much interest on Dos Ain't Dead:
> This is very interesting, Mike. While it seems to be some well
> researched info I don't have much to add, or even to criticise.
> It seems complete as it is. But am copying
> comp.os.msdos.programmer. Folks there may also be interested.
>
http://www.bttr-software.de/forum/forum_entry.php?id=14273
>"Mike Gonta" wrote in message news:mljlm3$8nt$1...@speranza.aioe.org...
>> 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 (at that
>> time IBM 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 "command.com"
>> and create a bootable DOS USB flash drive with the latest
>> version of io.sys (freely downloadable on the net).
>> https://rumorscity.com/2013/12/04/how-to-create-a-dos-bootable-usb-drive/
>> io.sys will load and initialize and then load and run your own
>> OS - giving you full access to the MS-DOS "BIOS" without
>> actually running DOS.
>
> That sounds as though an OS developer could run that io.sys (in a
> protected environment) and thus run DOS apps in a window. But I
> suspect there would be legal issues in doing so.
That's my plan for SudoBIOS. But it won't run DOS apps because DOS
>> 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 (at that
>> time IBM 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 "command.com"
>> and create a bootable DOS USB flash drive with the latest
>> version of io.sys (freely downloadable on the net).
>> https://rumorscity.com/2013/12/04/how-to-create-a-dos-bootable-usb-drive/
>> io.sys will load and initialize and then load and run your own
>> OS - giving you full access to the MS-DOS "BIOS" without
>> actually running DOS.
>
> That sounds as though an OS developer could run that io.sys (in a
> protected environment) and thus run DOS apps in a window. But I
> suspect there would be legal issues in doing so.
won't be running. I only intend to provide transparent access to the
"DOS BIOS" and the DOS file system functions as sort of an advanced
BIOS replacement for a simple OS (one that for example would be
using BIOS calls now). It's perfectly legal to download the io.sys file,
replace command.com with your own OS and make a bootable DOS flash drive.
> Maybe there are versions of a free DOS which could be used similarly.
> I am also not sure which INT services would be handled by io.sys and
> which by command.com? Is it as simple as saying that *none* of the
> INT 0x20 and 0x21 services are handled by command.com?
real DOS version that came with Windows98, includes the functionality
of msdos.sys. Int 0x20 and the critical error handler ints would need
to be replaced (and they are simple enough) to accommodate the OS
since DOS is not actually running.
James Harris
Jun 16, 2015, 4:52:06 AM6/16/15
to
"Mike Gonta" <mike...@gmail.com> wrote in message news:mlmu49$6ge$1...@speranza.aioe.org...
...
>>> Simply rename your own real mode operating system "command.com"
>>> and create a bootable DOS USB flash drive with the latest
>>> version of io.sys (freely downloadable on the net).
>>> https://rumorscity.com/2013/12/04/how-to-create-a-dos-bootable-usb-drive/
>>> io.sys will load and initialize and then load and run your own
>>> OS - giving you full access to the MS-DOS "BIOS" without
>>> actually running DOS.
>>
>> That sounds as though an OS developer could run that io.sys (in a
>> protected environment) and thus run DOS apps in a window. But I
>> suspect there would be legal issues in doing so.
...
> It's perfectly legal to download the io.sys file,
> replace command.com with your own OS and make a bootable DOS flash drive.
How do you know it's legal? If Microsoft wrote the code presumably they protect their rights by copyrighting it.
>> Maybe there are versions of a free DOS which could be used similarly.
>
> Of course, but since the file can be used as is, why not use the original.
Defence in court: someone on the internet said it would be ok. ;-)
>> I am also not sure which INT services would be handled by io.sys and
>> which by command.com? Is it as simple as saying that *none* of the
>> INT 0x20 and 0x21 services are handled by command.com?
>
> All int 0x21 functions are installed by io.sys, which in the latest
> real DOS version that came with Windows98, includes the functionality
> of msdos.sys. Int 0x20 and the critical error handler ints would need
> to be replaced (and they are simple enough) to accommodate the OS
> since DOS is not actually running.
Versions of MS-DOS seems to have used interrupt vectors from 0x20 to 0x2f. Are you saying that only 0x21 services are provided by io.sys? Or are you saying that all 0x20 to 0x2f services are provided by io.sys but that we would have to override ones like 0x20?
James
...
>>> Simply rename your own real mode operating system "command.com"
>>> and create a bootable DOS USB flash drive with the latest
>>> version of io.sys (freely downloadable on the net).
>>> https://rumorscity.com/2013/12/04/how-to-create-a-dos-bootable-usb-drive/
>>> io.sys will load and initialize and then load and run your own
>>> OS - giving you full access to the MS-DOS "BIOS" without
>>> actually running DOS.
>>
>> That sounds as though an OS developer could run that io.sys (in a
>> protected environment) and thus run DOS apps in a window. But I
>> suspect there would be legal issues in doing so.
> It's perfectly legal to download the io.sys file,
> replace command.com with your own OS and make a bootable DOS flash drive.
>> Maybe there are versions of a free DOS which could be used similarly.
>
> Of course, but since the file can be used as is, why not use the original.
>> I am also not sure which INT services would be handled by io.sys and
>> which by command.com? Is it as simple as saying that *none* of the
>> INT 0x20 and 0x21 services are handled by command.com?
>
> All int 0x21 functions are installed by io.sys, which in the latest
> real DOS version that came with Windows98, includes the functionality
> of msdos.sys. Int 0x20 and the critical error handler ints would need
> to be replaced (and they are simple enough) to accommodate the OS
> since DOS is not actually running.
James
Rod Pemberton
Jun 16, 2015, 5:18:12 AM6/16/15
to
On Mon, 15 Jun 2015 12:22:33 -0400, Mike Gonta <mike...@gmail.com> wrote:
> "James Harris" wrote:
>> [...]
> It's perfectly legal to download the io.sys file,
Why is that? Isn't that M$ (C) code?
>> Maybe there are versions of a free DOS which could be used similarly.
>
> Of course, but since the file can be used as is, why not use the
> original.
I don't recall other DOSes merging the two. Aren't they still
separated for FreeDOS and OpenDOS?
>> I am also not sure which INT services would be handled by io.sys and
>> which by command.com? Is it as simple as saying that *none* of the
>> INT 0x20 and 0x21 services are handled by command.com?
>
> All int 0x21 functions are installed by io.sys, which in the latest
> real DOS version that came with Windows98, includes the functionality
> of msdos.sys. Int 0x20 and the critical error handler ints would need
> to be replaced (and they are simple enough) to accommodate the OS
> since DOS is not actually running.
Do you have a more in-depth source of information on this stuff?
I.e., what constituted the "low level file system" interface and
the "BIOS interface".
Rod Pemberton
--
It's time to put an end to gun violence!
Use a hammer ...
> "James Harris" wrote:
>> [...]
>
> I only intend to provide transparent access to the "DOS BIOS"
> and the DOS file system functions as sort of an advanced BIOS
> replacement for a simple OS (one that for example would be
> using BIOS calls now).
What is the advantage of "DOS BIOS" interface over normal BIOS?
> I only intend to provide transparent access to the "DOS BIOS"
> and the DOS file system functions as sort of an advanced BIOS
> replacement for a simple OS (one that for example would be
> using BIOS calls now).
> It's perfectly legal to download the io.sys file,
>> Maybe there are versions of a free DOS which could be used similarly.
>
> Of course, but since the file can be used as is, why not use the
> original.
separated for FreeDOS and OpenDOS?
>> I am also not sure which INT services would be handled by io.sys and
>> which by command.com? Is it as simple as saying that *none* of the
>> INT 0x20 and 0x21 services are handled by command.com?
>
> All int 0x21 functions are installed by io.sys, which in the latest
> real DOS version that came with Windows98, includes the functionality
> of msdos.sys. Int 0x20 and the critical error handler ints would need
> to be replaced (and they are simple enough) to accommodate the OS
> since DOS is not actually running.
I.e., what constituted the "low level file system" interface and
the "BIOS interface".
Rod Pemberton
--
It's time to put an end to gun violence!
Use a hammer ...
Rod Pemberton
Jun 16, 2015, 5:37:32 AM6/16/15
to
On Mon, 15 Jun 2015 10:41:44 -0400, Mike Gonta <mike...@gmail.com> wrote:
> Some lively discussion here:
>
> http://forum.osdev.org/viewtopic.php?f=1&t=29383
>
"My whole point (before the big guns came out) was that
> Some lively discussion here:
>
> http://forum.osdev.org/viewtopic.php?f=1&t=29383
>
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."
So, the new set up would be:
BIOS --> IO.SYS "BIOS" --> SudoBIOS --> app
16-bit RM --> 16-bit RM --> 32-bit PM --> 32-bit PM
Rod Pemberton
Jun 16, 2015, 5:43:47 AM6/16/15
to
On Sun, 14 Jun 2015 06:40:03 -0400, Mike Gonta <mike...@gmail.com> wrote:
> 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 (at that
> time IBM 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.
>
So, DOS is a BIOS API and a filesystem. And, by far the
> 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 (at that
> time IBM 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.
>
most useful DOS enhancement, IMO, is XMS plus DPMI which
is a memory allocator and a 32-bit PM interface . So, now
for the philosphical question. Does that mean we get to
simplify the definition of an OS to this:
1) trivial hardware functions
2) lousy filesystem
3) bad memory allocator
4) better processor mode
Mike Gonta
Jun 16, 2015, 5:48:54 AM6/16/15
to
"Rod Pemberton" wrote:
16-bit RM --> 16-bit RM --> 32-bit PM --> 32-bit PM --> 32 bit PM
Exactly, (with the mouse.com and doslfn.com TSR's shoehorned
in there as well for good measure.
> "Mike Gonta" wrote:
>
>> Some lively discussion here:
>>
>> http://forum.osdev.org/viewtopic.php?f=1&t=29383
>>
>
> "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."
>
> So, the new set up would be:
>
> BIOS --> IO.SYS "BIOS" --> SudoBIOS --> app
>
> 16-bit RM --> 16-bit RM --> 32-bit PM --> 32-bit PM
BIOS --> IO.SYS "BIOS" --> SudoBIOS --> 32 bit PM OS --> app
>
>> Some lively discussion here:
>>
>> http://forum.osdev.org/viewtopic.php?f=1&t=29383
>>
>
> "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."
>
> So, the new set up would be:
>
> BIOS --> IO.SYS "BIOS" --> SudoBIOS --> app
>
> 16-bit RM --> 16-bit RM --> 32-bit PM --> 32-bit PM
16-bit RM --> 16-bit RM --> 32-bit PM --> 32-bit PM --> 32 bit PM
Exactly, (with the mouse.com and doslfn.com TSR's shoehorned
in there as well for good measure.
Mike Gonta
Jun 17, 2015, 8:02:38 AM6/17/15
to
"Rod Pemberton" wrote:
consists of 3 parts, io.sys, which today is basically
wrapper functions for classic BIOS functions; msdos.sys -
the DOS kernel - (the functionality of which is included in
the latest real DOS version of io.sys which came with
Windows98) and includes amongst the DOS operating system
kernel functions the file system functions; command.com the
user interface. command.com (or a similar replacement)
requires msdos.sys which requires io.sys which by itself is
totally useless. The DOS file system functions of and by
themselves could not be considered an operating system.
My point is that for a simple system (standalone utility,
game, hobby OS) that is typically using the BIOS function
drivers it could just as easily use the "DOS BIOS", which
includes the input/output and basic file functions, without
being considered a DOS application/appliance/operating
system. The DOS functions for loading/executing programs and
memory allocation etc. are the actual DOS operating system
kernel. It's this OS functionality that would be implemented
in the OS and not the DOS kernel functions being used.
The ones being used are only drivers and BIOS wrappers.
So, to simplify the definition of an OS, we have:
1) Production quality BIOS hardware functions (everthing thing
else no matter how modern, well coded and bug free is only
a hack.
2) The best file system known to man. Historically, back in the
day it was DOS, today new improved file systems exit, you
get to chose what you can implement.
3) The best memory allocator is the simplest (and much better
than alzheimer's.
4) Even with the latest and greatest processor we still have our
beloved '386 (real and protected modes).
PS. the discusion here is lively
http://forum.osdev.org/viewtopic.php?f=1&t=29383
> "Mike Gonta" wrote:
>
>> 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 (at that
>> time IBM 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.
>>
>
> So, DOS is a BIOS API and a filesystem. And, by far the
> most useful DOS enhancement, IMO, is XMS plus DPMI which
> is a memory allocator and a 32-bit PM interface . So, now
> for the philosphical question. Does that mean we get to
> simplify the definition of an OS to this:
>
> 1) trivial hardware functions
> 2) lousy filesystem
> 3) bad memory allocator
> 4) better processor mode
It's generally accepted that a basic DOS operating system
>
>> 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 (at that
>> time IBM 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.
>>
>
> So, DOS is a BIOS API and a filesystem. And, by far the
> most useful DOS enhancement, IMO, is XMS plus DPMI which
> is a memory allocator and a 32-bit PM interface . So, now
> for the philosphical question. Does that mean we get to
> simplify the definition of an OS to this:
>
> 1) trivial hardware functions
> 2) lousy filesystem
> 3) bad memory allocator
> 4) better processor mode
consists of 3 parts, io.sys, which today is basically
wrapper functions for classic BIOS functions; msdos.sys -
the DOS kernel - (the functionality of which is included in
the latest real DOS version of io.sys which came with
Windows98) and includes amongst the DOS operating system
kernel functions the file system functions; command.com the
user interface. command.com (or a similar replacement)
requires msdos.sys which requires io.sys which by itself is
totally useless. The DOS file system functions of and by
themselves could not be considered an operating system.
My point is that for a simple system (standalone utility,
game, hobby OS) that is typically using the BIOS function
drivers it could just as easily use the "DOS BIOS", which
includes the input/output and basic file functions, without
being considered a DOS application/appliance/operating
system. The DOS functions for loading/executing programs and
memory allocation etc. are the actual DOS operating system
kernel. It's this OS functionality that would be implemented
in the OS and not the DOS kernel functions being used.
The ones being used are only drivers and BIOS wrappers.
So, to simplify the definition of an OS, we have:
1) Production quality BIOS hardware functions (everthing thing
else no matter how modern, well coded and bug free is only
a hack.
2) The best file system known to man. Historically, back in the
day it was DOS, today new improved file systems exit, you
get to chose what you can implement.
3) The best memory allocator is the simplest (and much better
than alzheimer's.
4) Even with the latest and greatest processor we still have our
beloved '386 (real and protected modes).
PS. the discusion here is lively
http://forum.osdev.org/viewtopic.php?f=1&t=29383
Rod Pemberton
Nov 4, 2015, 5:26:29 AM11/4/15
to
On Tue, 03 Nov 2015 22:39:12 -0500, Antony Gordon <cuzi...@gmail.com> wrote:
> Technically, this is a flawed argument, at least based on the
> understanding I'm getting from it.
>
> IBM PCs and their compatibles boot from a set of ROM based routines
> burned in a chip that test memory and determine hardware characteristics.
> In 286 and later model computers, the BIOS reads the information from
> where CMOS stores it and configures the system accordingly.
>
> IO.SYS or IBMBIO.COM provide the basic I/O routines for DOS device
> drivers, i.e., CON (also known as STDIN, STDOUT), STDERR, AUX, LPTx,
> COMx, and the all too familiar bit bucket, known as NUL.
>
> During the DOS 1.0 until DOS 2.x days, there were software compatible
> PCs that had different hardware, such as the Tandy 2000 (with 720K 5.25"
> floppy drives), some Wang PC computers that doubled as word processors,
> because the only requirement to run DOS was an x86 compatible processor
> (the original IBM used the 8086, some others used the 8088 or the 80186),
> there was enough differences in the hardware that IO.SYS was used as the
> "glue" to hold these systems together. Any application that used pure
> DOS system calls to access the hardware would work, while software written
> to bypass DOS and directly access the hardware expecting IBM results would
> usually fail on the non-standard hardware.
>
> Prior to Windows 95, MSDOS.SYS contained the actual kernel of the OS,
> which was responsible for the various interrupts we know and love,
> like INT 21h, INT 2Fh, etc, etc.
>
> COMMAND.COM is just a shell that can easily be replaced with any
> application (from at least DOS 2.0 forward) as CONFIG.SYS is
> processed ahead of loading the command interpreter and the SHELL=
> line in CONFIG.SYS will cause another application to be the default
> shell.
>
> For DOS 1.0 - 6.22 you need IO.SYS and MS-DOS.SYS to get the DOS
> kernel. Windows 9x still requires both files, even though MS-DOS.SYS
> is roughly a 1.4K text file (because some programs look for MSDOS.SYS)
> if they detect an "MS-DOS" environment and will not work if the file
> isn't present and has a certain minimum size.
>
(On Usenet, your reply goes on the bottom. On Usenet, you
need to wrap your lines at 72 characters, preferably less.
Fixed. No, you didn't post to a Google Groups forum, but
posted to an unmoderated Usenet group.)
I take it, the "flaw" to which you're referring too is
that MSDOS.SYS is needed for MS-DOS 6.22 and earlier
since IO.SYS is not a "combined" IO.SYS and MSDOS.SYS
like for the later versions of MS-DOS which came with
MS Windows 95, 98, ME.
From the conversion, I took it that Mike is probably
only concerned with MS-DOS' which have support for
_both_ USB and FAT32.
Those would be MS-DOS 8.00 for WinME, 7.10 for Win95C
Win98, WinSE, and only 7.10 for Win98B v4.03.1212.
7.10 for Win98B v4.00.1111 didn't have USB support.
7.00 for Win95A didn't have FAT32 or USB. So, I'd
suspect he was primarily targetting IO.SYS of 7.10
for Win98 and WinSE to be used for USB and FAT32
code. This, of course, would leave FreeDOS and
OpenDOS/DR-DOS out of the mix.
As the open source BIOS for BOCHS (rombios.c) and
the Coreboot projects (formerly LinuxBIOS) prove,
much of the ROM BIOS is hardware independent. So,
it's technically feasible that Mike could implement
much of the BIOS in his extender. I.e., he could
probably eliminate dependence on the BIOS except
for disk reads and writes.
You're probably not familiar with Mike's projects
such as SudoBIOS or aeBIOS. Basically, they're 32-bit
PM BIOS extenders, similar to the old DOS extenders but
for the BIOS, plus anything else that excites him.
I was waiting to see if he ported a DOS to 16-bit or
wrote a 32-bit DOS to work on top of aeBIOS. Now, he's
moved on to SudoBIOS. I'm not sure of the differences
between the two projects. He was last working on USB
and other bootable images that used his code.
Mike is probably not on c.o.m.p., so a.o.d added back.
Mike posts sporadically, so we might not see a response
for a year ... The portion of the conversation between
Mike and myself on SudoBIOS is really a continuation of
prior conversations over a some years that we've had on
other OS like projects of his such as aeBIOS.
Rod Pemberton
--
When El Chapo is the most beloved man in Mexico and Trump is the most hated,
it shows that Mexico is truly fouled up.
> understanding I'm getting from it.
>
> IBM PCs and their compatibles boot from a set of ROM based routines
> burned in a chip that test memory and determine hardware characteristics.
> In 286 and later model computers, the BIOS reads the information from
> where CMOS stores it and configures the system accordingly.
>
> IO.SYS or IBMBIO.COM provide the basic I/O routines for DOS device
> drivers, i.e., CON (also known as STDIN, STDOUT), STDERR, AUX, LPTx,
> COMx, and the all too familiar bit bucket, known as NUL.
>
> During the DOS 1.0 until DOS 2.x days, there were software compatible
> PCs that had different hardware, such as the Tandy 2000 (with 720K 5.25"
> floppy drives), some Wang PC computers that doubled as word processors,
> because the only requirement to run DOS was an x86 compatible processor
> (the original IBM used the 8086, some others used the 8088 or the 80186),
> there was enough differences in the hardware that IO.SYS was used as the
> "glue" to hold these systems together. Any application that used pure
> DOS system calls to access the hardware would work, while software written
> to bypass DOS and directly access the hardware expecting IBM results would
> usually fail on the non-standard hardware.
>
> Prior to Windows 95, MSDOS.SYS contained the actual kernel of the OS,
> which was responsible for the various interrupts we know and love,
> like INT 21h, INT 2Fh, etc, etc.
>
> COMMAND.COM is just a shell that can easily be replaced with any
> application (from at least DOS 2.0 forward) as CONFIG.SYS is
> processed ahead of loading the command interpreter and the SHELL=
> line in CONFIG.SYS will cause another application to be the default
> shell.
>
> For DOS 1.0 - 6.22 you need IO.SYS and MS-DOS.SYS to get the DOS
> kernel. Windows 9x still requires both files, even though MS-DOS.SYS
> is roughly a 1.4K text file (because some programs look for MSDOS.SYS)
> if they detect an "MS-DOS" environment and will not work if the file
> isn't present and has a certain minimum size.
>
(On Usenet, your reply goes on the bottom. On Usenet, you
need to wrap your lines at 72 characters, preferably less.
Fixed. No, you didn't post to a Google Groups forum, but
posted to an unmoderated Usenet group.)
I take it, the "flaw" to which you're referring too is
that MSDOS.SYS is needed for MS-DOS 6.22 and earlier
since IO.SYS is not a "combined" IO.SYS and MSDOS.SYS
like for the later versions of MS-DOS which came with
MS Windows 95, 98, ME.
From the conversion, I took it that Mike is probably
only concerned with MS-DOS' which have support for
_both_ USB and FAT32.
Those would be MS-DOS 8.00 for WinME, 7.10 for Win95C
Win98, WinSE, and only 7.10 for Win98B v4.03.1212.
7.10 for Win98B v4.00.1111 didn't have USB support.
7.00 for Win95A didn't have FAT32 or USB. So, I'd
suspect he was primarily targetting IO.SYS of 7.10
for Win98 and WinSE to be used for USB and FAT32
code. This, of course, would leave FreeDOS and
OpenDOS/DR-DOS out of the mix.
As the open source BIOS for BOCHS (rombios.c) and
the Coreboot projects (formerly LinuxBIOS) prove,
much of the ROM BIOS is hardware independent. So,
it's technically feasible that Mike could implement
much of the BIOS in his extender. I.e., he could
probably eliminate dependence on the BIOS except
for disk reads and writes.
You're probably not familiar with Mike's projects
such as SudoBIOS or aeBIOS. Basically, they're 32-bit
PM BIOS extenders, similar to the old DOS extenders but
for the BIOS, plus anything else that excites him.
I was waiting to see if he ported a DOS to 16-bit or
wrote a 32-bit DOS to work on top of aeBIOS. Now, he's
moved on to SudoBIOS. I'm not sure of the differences
between the two projects. He was last working on USB
and other bootable images that used his code.
Mike is probably not on c.o.m.p., so a.o.d added back.
Mike posts sporadically, so we might not see a response
for a year ... The portion of the conversation between
Mike and myself on SudoBIOS is really a continuation of
prior conversations over a some years that we've had on
other OS like projects of his such as aeBIOS.
Rod Pemberton
--
When El Chapo is the most beloved man in Mexico and Trump is the most hated,
it shows that Mexico is truly fouled up.
0 new messages