rloew

Yes. I'm not sure why this would happen as I was in DOS and the INT 13 Interface should hide the type of drive. How does using Head 81 more fully utilize the Hard Drive? BIOSes typically only report an integral number of Cylinders when reporting the Drive size.

Version 2.37 only seemed to recognize 8GB and was totally confused with most of my Partitions. Version 2.44 did not work for me. It created a MBR but none of the Partitions I created were placed in the MBR. Version 2.40 insisted on starting Partitions on Head 81. This is totally incompatable with CHS Logical Partitions. You can always reset the Partition Type from '0F' to '05'. It doesn't do any checks. The default behavior is OK. Also, could you please elaborate on the above quote, please? Logical Partitions starting above 8GB are not accessible within a Type '05' Partition.

I agree, but it may apply only to people also using Windows NT who need to use non-standard Type '05' Partitions. No, as I don't use NT. The problems of LBA partitions being addressed as CHS and phantom enumeration occurred for me with W9X (98SE, to be precise). Windows NT users are the only ones that NEED to use Non-Standard Type '05' Partitions. Apparently a lot of people HAVE Non-Standard Type '05' Partitions. Apparently some Partitioning tools are creating them. Some Versions of Ranish Partition Manager do this, as noted by Dencorso above. I downloaded and ran Ranish Partition Manager Version 2.4.0, but it created Type '0F' Partitions by default.

I am still trying to determine the effect of the +3A01 Patch. It is supposed to fix the doubling of the Partition Start Sector. I setup the suggested Type '0C' Partition within a Type '05' Partition. The +3A01 Patch alone does not correct the problem. The +206C Patch corrects the problem, with or without, the +3A01 Patch. So far I haven't seen a reason for the +3A01 Patch as the +206C Patch seems sufficient for the intended purpose. @Phellum: Is there any configuration that requires the +3A01 Patch?

There are additional issues with using LBA Partitions within Type '05' Partitions but they are also bypassed by the +206C Patch.

I don't have a Windows NT setup to test. You obviously have some reverse-engineering experience. I can ptobably give you some suggestions on what to look for. I added Type '0F' support to DOS 6.2 years ago. The problem with your Patch is that it breaks CHS compatability. With a CHS only BIOS, you cannot access any Extended Partitions whatsoever. With a LBA supported BIOS, Type '05' Partitions are not needed, except to support unpatched Windows NT. If you can find the doubling bug or any other using a CHS Partition in a Type '05' Wrapper and/or a Partition in a Type '0F' Wrapper, I would be very interested. I do think it is a NT issue. I didn't assign 'blame' for it. I didn't blame Microsoft for not putting 48-Bit LBA support into Windows 98, only the stupid way they handled it. I don't know if Type '0F' Partitions existed when NT was developed, but I am sure it was before the last service pack. I was not criticizing his work, just pointing out some issues. I agree, but it may apply only to people also using Windows NT who need to use non-standard Type '05' Partitions. Possibly, although writing is more likely to fail before damage occurs. Formatting or using SCANDISK is another story. I set it up and tested it before I posted. No. It ignores any LBA Partitions. It may even abort scanning, although I have not comfirmed this. Then the Patch would only be of value to users of unmodified Windows NT as others have no need for Type '05' Partitions. No. There is an unrelated bug in IO.SYS that he didn't Patch. I have not evaluated the impact of the third Patch (+3A01).

My hard drive contained an extended partition (type 05) that was about 30GB. This partition contained CHS accessible volumes before cylinder 1023 and others (NTFS and FAT32) from cylinder 1024 onwards. There was a FAT32 volume before cylinder 1023 and I would get a phantom drive in Win98 if I set this volume's type to 0C. A simple test to show the problem is to create an extended partition (type 05) on a drive and add a type 0C (FAT32 LBA) volume. IO.SYS will double the start key whereas the 32-bit disk code in Win98 gets it right. I realise that type 05 partitions shouldn't exceed cylinder 1023 but I had to use 05 not 0F for NT4 compatibility. Also, all LBA keys must be correct. I didn't see this as a problem because NT always uses LBA keys and my partitioning program ensured they were correct. But, this might cause problems in setups that rely/use CHS only. The recent comment that an LBA extended partition should contain only LBA volumes might explain why IO.SYS works the way it does. Cheers, Steven Saunderson Microsoft considers LBA the preferred access mode. Since a type '0F' Partition requires use of LBA, it is safe to assume that any Logical Partition contained within it can be accessed by LBA, regardless if LBA is specified. FDISK makes this assumption, so your Patch at +2072 breaks this. JDS removed this part of your Patch. Without the +2072 Patch, your Patch at +206C now causes all Logical Partitions to be set for LBA access. This would be a problem in any machine that does not support LBA. Without the +206C Patch, the value of using a Type '05' Partition with LBA Logical Partitions is severely diminshed. Besides needing your +3A01 Patch, you will be unable to define Partitions that start above 8GB. Type '05' Partitions were meant to be CHS only and there may ber even more issues. Basically what you have done is make a workaround for a problem that is basically a Windows NT problem not a DOS problem. Windows 98 has different code so it handles these nonstandard partitions differently, so you get the duplicate mounts. I think you would get much better results if you fix the problem in Windows NT instead. Since it can handle LBA, the modification should be relatively simple. The problem I found does not require CHS Partitions or non-standard Partitions, only the presence of NON-DOS Partitions, such as NTFS.

I can see that my patch has had an unwanted side-effect. I didn't hit a problem because my extended partitions are all type 05 whether CHS or LBA. I need this type because NT4 doesn't recognise type 0F. I put a dummy partition at cylinder 1023 so systems that use CHS don't see anything after. NT systems always use LBA so they continue down the chain and find subsequent partitions. Win98SE does find FAT32 partitons after cylinder 1023. Thanks for the update to my patch and the interest in it. Cheers, Steven Saunderson Can you tell me under what conditions does the Partition Start Sector become doubled without your Patch? I have observed a bug that causes spurious Partition Start Sector settings, but they are not doubled. I have developed a fix that corrects the problem. I recently ran some tests and found that your Patch did not fix the Bug I identified.

Wow! That was fast! Way to go, RLoew! You do rock! I presume you did it by hand... Please, do consider creating a decompressor tool to automate the process. Besides the default IO.SYS for hard disks and the one that comes in the EBD floppy, three other flavours of the Win ME IO.SYS are known: the one in the bootable floppy image contained in Win ME's CD, and those embedded in discopy.dll, retrievable with DiskExtract, thanks to Nuno Brito (there are two flavors of it, one in the discopy.dll from Win XP and another in the same dll from Vista or 2k3), not to mention those in KB311561... so that an automated solution would be a wonderful tool to have handy. Done. Close, but no cigar. Even though next to each oter, the 'MS' and 'CM' as tested separately for different purposes. The 'MS' appears to be an integrity check. The 'CM' indicates the Compressed Data Header. It also appears at the start of the Decompression Code Header.

I was able to decompress the Windows ME IO.SYS file and combine the data to produce an uncompressed IO.SYS file. It turned out that the entire file is decompressed in one operation. This made it a lot simpler. @Mijzelf: I don't have a Linux system to test my MP3 Player on. Windows ME USB Drivers mount mine as two separate Devices. I was able to mount a FAT Filesystem on a CD-ROM so I already have a way of setting up a 2KB Logical Sector Device.

What do you want to know? It's this device. When you think it can help you to Support the Community, pm me your address, and I will send it to you. (I just connected it, and saw I was mistaken. It has a 2k sectorsize) You may be looking at the USB CDROM component. Many MP3 Players mount as two devices. A Mass Storage Device where your files go and a simulated CDROM with a Setup Program on it.

I have been concentrating on the Windows 98 IO.SYS, mainly the Boot sequence and the resident code. I took a quick look at the ME IO.SYS. It appears to only load the initial 2K block uncompressed. The decompressor should be inside. IO.SYS loads itself in multiple stages so analysis is difficult. I am still looking at the loading sequence for the Windows 98 Version to see if it can be made bootable with larger sectors and/or 64KB or larger Clusters.

How is the partition table organized? The original IBM partitiontable is not usable, is it? Is there another way to define a partition on an internal (boot) harddisk? Why not? I'm under the impression that the default partition table is depends on a 512 byte sectorsize. A standard Partition Table and Boot Sector Data are 512 Bytes, but the size of the Sector is not important. The rest will just be ignored. Wouldn't is be more elegant to increase the sectorsize, instead of splitting the drive? AFAIK the sectorsize doesn't need to be 512 bytes, and since FAT32 creates clusters of at least 4kB, sectors could get this size without any penalty. Three years ago I was not as familiar with the internals of IO.SYS and VFAT.VXD. I was not aware that their code could be adapted without a major rewrite. As it is, several modifications were required to both of them and IOS.VXD as well. This still tops out at 16TiB of course. Subsequently I developed a modified Partition table Format to get past 2TiB, but the caveat above still applies. Unmodified VFAT.VXD and the 32-Bit portion of IOS.VXD can handle up to 2KB Sectors, so it is possible that an 1KB Sector USB Device would work. I would be interested in more details about that MP3 Player. My latest RFDISK Program should be able to Partition it.

The 24 Partitions don't have to be on one drive either. My current prototype DDO is limited to 512TiB, so I would need six drives with four Partitions each to support 3PiB.

I found the Buffer limitation that limited DOS to 16KB Sectors, My Patched IO.SYS now supports 32KB Logical Sector Devices. This brings the largest FAT32 Partition to 128TiB, largest FAT16 to 512GiB and largest FAT12 to 32GiB. With 24 Partitions, DOS can manage 3PiB, while Windows 9X can manage 384TiB.

I have corrected my Profile so it points to my Website redirector. I haven't created Demos, so they are both listed in my Prerelease and Beta Section. I provide free updates on all Products.

Which of the Win98-compatible partition-related software Partition Magic v8.01 Build 1274, Paragon Partition Manager v9.0.4156, Partition Table Doctor v3.5, Acronis Disk Director v10 build 2089 or Ghost v11.0.2 can handle 4kb sector size? System Commander can't according to their docu. I doubt that any of them can handle 4KB Logical Sector Drives. I upgraded my RFDISK and RFORMAT to support up to 16KB Logical Sectors. Fortunately 4KB Logical Sector Drives are not likely to appear for some time. The so called "Advanced Format" Drives from Western Digital use a 4KB Physical Sector internally but are still 512 Byte Logical Sector Drives. These drives can be used with any software, but will not perform optimally if not aligned properly. Western Digital's Align Utility, or using the jumper on the Drive, only facilitate alignment. They only work for XP and above. To use "Advanced Format" Drives with Windows 98 you can use any Partitioner, but will need a customized Formatter. I plan to add an alignment option to my RFORMAT Program to facilitate alignment. I know this is a 98 forum. But, your comment "They only work for XP and above." begs the question... how about 2K? Just wondering, as it is one of my oses, that I intend to keep and use for those instances I need Windows. Maybe, I should start laying up some drives if 2K will have issues. Thanks in advance. I don't use 2K so I have no idea. Western Digital does not list 2K in it's compatability list. As I said, the current Drives only have Sector alignment issues, so a suitable formatter will work. I have already upgraded my RFORMAT Program to properly align Partitions for use with Windows 9X. It may work for 2K as well. 4KB Logical Sector Drivers are not yet available. They will probably break most OSes as well as most BIOSes. So I doubt they will be coming soon.

Which of the Win98-compatible partition-related software Partition Magic v8.01 Build 1274, Paragon Partition Manager v9.0.4156, Partition Table Doctor v3.5, Acronis Disk Director v10 build 2089 or Ghost v11.0.2 can handle 4kb sector size? System Commander can't according to their docu. I doubt that any of them can handle 4KB Logical Sector Drives. I upgraded my RFDISK and RFORMAT to support up to 16KB Logical Sectors. Fortunately 4KB Logical Sector Drives are not likely to appear for some time. The so called "Advanced Format" Drives from Western Digital use a 4KB Physical Sector internally but are still 512 Byte Logical Sector Drives. These drives can be used with any software, but will not perform optimally if not aligned properly. Western Digital's Align Utility, or using the jumper on the Drive, only facilitate alignment. They only work for XP and above. To use "Advanced Format" Drives with Windows 98 you can use any Partitioner, but will need a customized Formatter. I plan to add an alignment option to my RFORMAT Program to facilitate alignment.

With a few modifcations Windows 9X can handle 4KB Sector Hard Drives. This allows Partitions up to 16TiB. DOS can handle 16KB Sectors and up to 64TiB Partitions.

Windows 9x IDE driver (esdi_506.pdr) is limited to 137 gb. Windows 9x does not use esdi_506.pdr on sata drives when the motherboard is not performing SATA->IDE translation. In that mode, win-9x will either use an installed SATA driver (if available) or will resort to DOS-compatibility mode (int 13h function calls). Both of which do not require patching to be win-9x compatible. True, but then it is not using it's own Driver. If you mean that win-9x will attempt to use esdi_506.pdr to access a SATA drive that is not being remapped as an IDE drive by the system bios, I have never seen that situation happen. I did say "some circumstances". This means IDE Mode. IDE Mode is not a translation or remapping. It is one of the protocols supported by the SATA Controller.

You can't make a blanket statement like that. That statement is only true (without qualifications) if the drive is an ATA-PATA (aka IDE) drive. If the drive is SATA, then because win-98 did not come with SATA drivers, then windows 98 does not typically have size limitations using the SATA drivers that come with the SATA controller or SATA-equipped motherboard. Again, that only applies if the drive is PATA / IDE. If the drive is SATA, then no special modified drivers are required. Windows 9X, using it's own Drivers, IS limited to 137GB. Patching the Driver, or adding third party software can extend the limit. With additional Patching, the Windows 9X Driver can also handle SATA. The 320GB Drive cdoublejj is using comes in PATA and SATA versions. He does not say which kind it is. If it is PATA, and he is not using a third party driver, my warning still applies. Under some circumstances, Windows will attempt to install SATA Drives with the standard driver.

The limit for Hard Disk size is 2TiB unless you are using a controller that has a poorly designed BIOS and/or Driver. A Patched ESDI_506.PDR driver will handle the full 2TiB. The Maximum Partition Size, in Windows 9X, is 1TiB due to a bug in the FileSystem Driver. I have written a Patch that allows 2TiB Partitions to be used. DOS can handle 2TiB Partitions.

Older BIOSes have a limit of 137GB (128GiB) total Drive Size. If your BIOS reports that the drive is 137GB during boot, you will need a newer BIOS or a DDO to provide the needed support. Windows 98 is limited to 137GB as well. A Patched Driver is needed to support larger Hard Drives. You may or may not see problems at first, but as you fill up your Hard Drive with data, you will eventually encounter corruption and lost data. It is not safe to use your 320GB Hard Drive unless all FAT16 and FAT32 Partitions are entirely within the first 137GB of your Hard Drive, and your last (Non-FAT) Partition starts below 137GB.

Please tell me more about the current capabilities of your SATA patch. I see it has evolved since I originally bought my copy of it (which, unfortunately, I still didn't test, since I've got to postpone finishing the assemblage of my ECS GeForce 6100M-M2 board based machine, due to various more pressing matters). The Patch itself has not changed since you bought it. It just has been tested in more situations. I have been doing some testing with LoneCrusader and his FIX95CPU Package. My test system is SATA based so I had to run in compatability mode up until a couple of days ago. Windows 95 Device Detection and installation are not the same as Windows 98+, so it took longer than expected. A somewhat different approach is needed. When I can come up with a suitable procedure that is at least a little bit user friendly, I will release an update.

Although not always, I do prefer doing things the "non-Microsoft" way in many instances, so you're not really alone in this forum. For instance, I set up my dual-boot machine by installing XP after 98SE, and not the other way around (which is recommended by MS). Moreover, I use GRUB4DOS, initiated from real DOS to switch between the systems, which, BTW, are in the 1st primary partitions of separate HDDs, one booting directly to XP if set as the 1st boot device in BIOS, and the other booting to 98SE or GRUB4DOS (selected via CONFIG.SYS) if set as the 1st boot device in BIOS (which is my default). When GRUB4DOS is selected in this latter partition, it first switches hd0 with hd1 and, then, chainloads the boot sector of the XP partition, from which XP boots normally. This has the advantage that no file from 98SE is present or needed in the XP partition, and vice-versa. This is definitely one "non-Microsoft" way, and works very well. Moreover, the system which has booted is always in C: and the dormant one is in D:. All the other drive letters are the same, regardless of which OS has booted, because I set the drive letters of all other partitions or devices in XP to be the same as the one DOS/98SE assigns, using the static letter assignment facility that XP offers to do it (so this part is done in the MS way). All partitions are FAT-32, and are accessible from both OSes. And even if one of the HDDs suddenly dies, the other will still boot. I also use a non-Microsoft way. My RFDISK Partitioning program can set up a multiboot profile system that switches between any partition using the Control Key and one keystroke during boot. The selected Partition becomes the C: Drive and it's boot sector is executed. Other partitions can be visible or not according to the settings configured. I recently enabled a Partition to be a Primary Partition in one profile while a Logical Partition in another. I have also used Densorso's method of switching Boot Drives in the BIOS and have a letter reassigner to adjust the Drive letter sequence.