Date: Wed, 5 Feb 1997 02:10:22 +0100 (MET) From: "Manuel J. Petit de Gabriel" To: OpenDOS List Subject: RE: [opendos] OpenDOS + Win95 w/FAT32? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-opendos AT mail DOT tacoma DOT net Precedence: bulk On Tue, 4 Feb 1997, Jonathan Tarbox - SSG wrote: > Actually, you are still wrong but looking in the right direction, the > superblock of the partition (say it was Ext2) would have the code to > supply read-only support for it's FS, and the IFS line enabled the full > read-write support for that and other IFS drives The superblock of the partition will only have the working parameters for that filesystem. You can NEVER put there the code you want to put: you cannot tweak an already predefined File System Format. > This may all sound reasonable, but I'm clueless on the actually > programming of it.. But it should be able to work, since MS-DOS uses the > same concept to the computer can see the system files on a FAT partition > and Linux does the same with it's EXT2 partitions.. MS-DOS (or OpenDos) is able to read/write FAT because the FAT filesystem is built into the kernel... from the "superblock" it only gets the filesystem parameters Linux is able to read/write EXT2 because the EXT2 filesystem is built into the kernel... from the "superblock" it only gets the filesystem parameters. LILO is able to read EXT2 (and load Linux kernel from it) because the EXT2 filesystem is built into LILO... from the "superblock" it only gets the filesystem parameters. etc, etc, etc To do what you want EXT2, HPFS... should be built into the system (at least a "tiny" version to read them) So your DOS "kernel" either: i) will be big ii) you have a way to taylor it iii) you have different kernels with different level of support options (ii) and (iii) could be a real mess. Have you ever studied the way a machine is booted? It's quite tricky, Since the boot sector has room for little info/code. For M$-DOS is something like: i) boot block loads IO.SYS (it's in a fixed place so it's only a matter of reading a few consecutive places) ii) IOSYS is composed by a module called SysInit and a collection of drivers. SysInit has little understanding of FAT filesystem and loads MSDOS.SYS. SysInit is discarded afterwards. iii) MSDOS.SYS has full FAT implmentation and starts parsing CONFIG.SYS iv) etc OpenDos is quite similar, just replace names and you will have a good picture. For SunOS (for instance) it's a bit trickier (I'm using SunOS as example because I know it better than Linux): i) the boot sector has a list of sectors which conforms /boot (a booter which is in the root directory) ii) /boot has BSD filesystem built into it so it can read /vmunix iii) /vmunix it's a full kernel with a full implementation of BSD filesystem iv) etc For Linux it's similar but replace /boot by LILO Now tell me, how do you want OpenDos to be able to have read support for both HPF and EXT2 without having a huge IBMBIO and IBMDOS? One idea could be to have another stage in the boot process. Instead of reading directly IBMBIO, the boot sector (or maybe LILO) could search for a sector list. Perhaps sector 2 of track 0 (track 0 is typically unused except for the first sector which contains MBR and partition table) could hold sector list for partition 1, sector 3 for partition2 ... If such sector list is found the boot sector will load the refered sectors and start executing. The sectors in this list will be the sectors used by a file in the filesystem of that partition. That file (lets call it IFSBOOT) will contain a tiny implementation of the filesystem to load IBMBIO. IBMBIO will use the services of IFSBOOT to load IBMDOS. IBMDOS will use it also to load CONFIG.SYS and/or a suitable IFS for that filesystem. IFSBOOT is discarded from memory. The rest of IFS are read from disk. This model requires: i) modify IBMBIO & IBMDOS to use the IFSBOOT module, should be not hard... don't know ii) modify LILO to use the sector if found. Seems easy. iii) and IFSBOOT for each filesystem. If you are going to make a full implementation of the filesystem as IFS this should be a minor problem iv) a tool for each filesystem which will write the sector list of the corresponding IFSBOOT in the apropiate place This way you could have an OpenDos which will be ablee to run in HPFS only mode, EXT2 mode... Posible problems: i) the place suggested for the sector list is typically used by virus... you'd better have an emergency bootdisk with all required IFS in it ii) if anyone replaces the IFSBOOT file and doesn't run the apropiate tool to build up the new sector list... you'd better have an emergency bootdisk with all required IFS in it [ have anyone tried the following in a SunOS system: cp /boot /boot- mv /boot- /boot the same effect. Pretty annoying. After doing the above you MUST run a program named installboot to build up the sector list or the machine will not boot again ] iii) Same as above if the filesystem has a defrag tool iv) Others... yet to be discovered Comments??? manuel, PD: my own opinion is that for hackers like most of us the model is good. For the general public... may be a bit overcomplex, why the hell should my father (a lawyer) or my sister (also a lawyer) want to have an EXT2 partition (maybe he/she could want HPFS if he installs OS/2 also)