Inside MSDOS-1.0

http://www.patersontech.com/Dos/Byte/InsideDos.htm
Inside DOS,


Some points on DOS operating system { MSDOS 1.0 }, when I did not even exist on this earth. Facinating.

Design Issues

a) Efficiency --> Well every operating system needs to be efficient, given those times this one had be better. Notably, give maximum consideration to user space, so that _user_ gets to use resources not _system_.

b) Speed --> Coded completly in assembly. Though not primarily because of speed.
c) Compatibilty with CP/M --> Provide compatibilty with CP/M so that software compiled for CP/M could effectively run without modfication on MS-DOS.


Bit on organization.


High memory for transient component of DOS. Could be overlayed by application if need be.
User memory.
Command Resident //Could have been replaced by any other command prompt, did not know this one.
MSDOS.sys
IO.sys
IVT.



File Structure

FAT file system

Sector 0 --> MBR
Sector 1-6 --> FAT
Sector 8-13 --> Copy of FAT
Sector 14-30 --> Directory Structure // Each sector 128 bytes, Each directory entry 32 bytes
// 17 * 128 / 32 = 68 Directory enteries in total
// No it could not be resized.
Sector 31-2001 --> User space.

Most importantly file structre was NOT hierarchical. Only "root" directory. No sub directories.

Maximum file size = 65535 bytes. No not 65536. Pretty efficient overall.


Only _one_ sector buffer. i.e. we only had one single buffer for whole of the file system and that was for just one sector.

Queries to file system had to specify for reading any file. So if we are looking for byte streams like we have now, each record was effectively of size 1.

a) Record size, the size of the record.
b) And the record number.

So if an application wanted to read 2nd record, with each record of 90 bytes. Request would be generated for reading 128-90 from sector 0, and then 90 - ( 128 - 90 ) from next sector.


Some questions:

Though the article says that there was only one single sector buffer, it also says that the IO system was able to "look ahead" in FAT to know if we are to read consecutive, blocks. But if it could do so, then it should be able to put them in some sort of buffer otherwise there is just no use of _looking_ahead_

At one time he gives an indication that the number of sectors for FAT(7) is pretty much fixed, but then again in his example regarding internal fragmmentaion, he conisders FAT to be as long as 24 sectors.

Even looking back just 68 files looks quite pathetic.