VOGONS

Common searches


First post, by SirNickity

User metadata
Rank Oldbie
Rank
Oldbie

I have a functional knowledge of how disk interfaces worked in the DOS days. But, for the most part, when I was going through this stuff as a teenager, the hardware and software was all developing at around the same pace so that things worked together without a lot of fuss. I mean, there was some fuss, because it was PC architecture and MS-DOS after all, but for example when the 500MB barrier really became an issue when buying new hard disks, the BIOS guys and DOS had already been working on a solution for a while. You didn't really have to think about it much anymore, there's a good chance the hardware you had would work with the hardware you just got, as long as those pieces were of a similar vintage.

So, going back today, when any period combination of hardware and software is possible, I've had to learn some lessons that I didn't the first time around. I never retrofitted my first PC with a 2GB drive, and I wasn't lugging forward an 80MB Caviar with DOS 5 when I built my 6x86. This knowledge gap became evident when I hit a major milestone with a coding project I had kicking around idly for a couple years -- a complete FAT library in C.

The library reads the MBR, parses partition tables, converts between CHS and LBA, reads FAT (12,16,32 -- with LFN support), and finally can write the critical layout stuff as well - the boot sector, BIOS Parameter Block (DOS 2.0, 3.0, 3.2, 3.3, 3.31, 4.0, and 7.0 styles), the FAT tables, root directory, directory entries, etc. There were a few challenges -- one of which was LFN Unicode support, for which I had to throw together a very rudimentary Unicode support library (I wanted this to be fully self-contained for use on microcontroller-based systems, for e.g.), but probably the trickiest bit was how to code a procedure that, when creating a new volume, would intelligently decide whether to use FAT12, 16, or 32; and what cluster size to use; and handling any number of things automatically along with any number specified by the user. I'll get in to those later, if there are any gearheads like me that find those discussions interesting.

For now, the point of this post is to give myself a place to document all the quirks I ran into when using my own library to create an MBR, initialize a new file system on the primary partition, and then try to install Windows 95 on it. As it turns out, MS-DOS (even 7.0) is extremely picky about the layout. While Linux -- even ScanDisk -- will gladly give a pass to most things that are valid FAT, DOS is a cranky beast.

OK -- Episode One: "Setup could not create files on your startup drive."

Reply 1 of 7, by SirNickity

User metadata
Rank Oldbie
Rank
Oldbie

Well, I thought I had some concrete detail to add to this, but I'm not so sure now.

First run was to create a 2.1GB FAT16 LBA file system for Win95 retail. That revealed some bugs and other issues, and I hit a red herring I thought was with half-hearted support for LBA. It seemed Win95A was not willing to use a partition without CHS parameters -- but it turns out, the problem might have been something else: My code neglected to write the FS type field (which is a text string that says "FAT16" or "FAT32", padded with spaces. The MS docs say this string is not to be used to determine FAT type, and isn't used by Microsoft code, but that's a lie. I think Windows Setup was trying to use it to verify compatibility, and it seems at least sys.com refuses to transfer system files to a volume without that string set appropriately. When the field is null, you get something like "Cannot transfer system to _ file system". The '_' there is an extra space, which looked at first like a typo, but then seemed to be important. Sure enough, I think it was concatenating the (empty) FS type string there. When I fixed that bug, sys.com was happy.

The other issue I'm having is on a 5.1GB disk with a FAT32 (LBA) partition, prepared for Win95 OSR2.1. I cannot get ScanDisk to accept my image. It keeps thinking the FAT tables are a different size than what I'm creating, and complains that the two copies are "not the same" -- presumably because it's reading both copies as one copy, and then comparing it to the empty data region. I have not been able to figure this one out. AFAICT, my code is working perfectly -- I even forced it to use the same cluster size as format.com, and then extracted an image of the disk as created by format.com, and aside from other text fields and the boot code, it looks identical to me.

It could be that another "should be benign" difference -- the OEM name string, which is "MSWIN4.1" with format.com, and "fat.c " with my code -- is breaking detection? Or it might really not like that I created a second primary partition with FAT16 (which works fine). Linux's fsck.fat seems to think my image is A-OK. Norton Utilities' DiskEdit can show you a comparison of what's on disk vs. what DOS has detected, but they are sometimes SO far off that I'm not sure where NU is getting the information, but it is clearly wrong. (Sometimes it reports the 2nd partition, sometimes it's obviously reporting what's on the boot floppy I used, and other times it's just completely wacko data.)

So that's where I'm at.

Once I pass muster, I'm going to try tweaking settings and running various DOS and Windows utilities against them to see what breaks. I feel like there's no comprehensive information as to what you can and cannot get away with, and typical errors (like "missing operating system") are really misleading, or at least uninformative.

Reply 2 of 7, by SirNickity

User metadata
Rank Oldbie
Rank
Oldbie

So...

liar1.png
Filename
liar1.png
File size
62.55 KiB
Views
495 views
File license
Public domain
code.png
Filename
code.png
File size
159.21 KiB
Views
495 views
File license
Public domain
IMG_6274.JPG
Filename
IMG_6274.JPG
File size
47.21 KiB
Views
495 views
File license
Public domain
liar2.jpg
Filename
liar2.jpg
File size
41.01 KiB
Views
495 views
File license
Public domain

Reply 3 of 7, by Cobra42898

User metadata
Rank Member
Rank
Member

i thought there was only supposed to be one primary dos partition, especially with dos and probably at least some win9x OSes?
i thought that multiple primary partitions was more an NT/XP thing?

Searching for Epson Actiontower 3000 486 PC.

Reply 4 of 7, by Cobra42898

User metadata
Rank Member
Rank
Member

https://retrocomputing.stackexchange.com/ques … ions-to-be-used

This seems to indicate multiple primary partitions began with msdos 5.0 ?
Perhaps I'm a bit behind thr (retro) times ?

Searching for Epson Actiontower 3000 486 PC.

Reply 5 of 7, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

Primary partitions refers to the ones listed in the MBR (usually sector 0), which has space for four entries.
You may be thinking of the Active partition, which is meant to be a flag on one of them indicating which one is meant to be used for booting.

Reply 6 of 7, by SirNickity

User metadata
Rank Oldbie
Rank
Oldbie

DOS FDISK has very strange rules for primary partitions. It will allow you to create one and only one primary FAT partition. All other FAT partitions must be in an extended partition table. You cannot create an extended table until you have made one primary partition.

That said, you can create multiple primary partitions via other tools and DOS will use them fine. I have not tested this extensively, but it’s at least true of DOS 7.

I am writing a CLI-based FDISK tool now, just as an exercise. The code is 98% handling command line options and doing something sensible with them. Heheh. When it’s finished, I will use it to create different partition tables and see what various versions of DOS and Windows can cope with. It would be good info to have, I think. Then I will do the same for FAT file systems.

I suspect, for most people, it’s just easier to use the tools that come with the version of the OS you want to use, but it’s still an interesting experiment to me, and I’ll have a nice functional library to use on ARM projects later on. 😀

Reply 7 of 7, by appiah4

User metadata
Rank l33t++
Rank
l33t++

FAT always allowed for up to 4 primary partitions or 3 primary partitions + 1 extended partition - it was just DOS fdisk that artificially did not allow for this.

Retronautics: A digital gallery of my retro computers, hardware and projects.