rloew

I was about to post just this, when I read your post! Way to go! I must add, however, that I don't actually use MDGx's HOSTS files myself, because I find them way too much restrictive. I prefer the one I linked to some posts above, as the basis of my HOSTS file, and have been adding to it more addresses slowly. But for the in-depth explanation, MDGx's page is the best resource on the web, for sure. @wsxedcrfv: one sure way of determining which cookies' URL's are needed for a specific site is to disable the HOSTS file, then use NirSoft's IECookesView to destroy all cookies, then access the desired site and do whatever you want to do there, and then return to IECookesView and jot down what was added. Then comment out those url's in the hosts file, enable it back again, test, and finally uncomment each url alone, to find out which are really needed. With patience you can determine precisely which urls are needed for that site and decide whether to leave them commented-out or not. I'm not sure whether IECookesView works with 9x/ME, because I've been doing this in XP, so this procedure needs to be tested under 9x/ME. Just checking the Cookies generated by a site may not be sufficient to determine what Sites have to be unblocked. Necessary pages may not leave any Cookies. I use a DNS logger to track activity and to adjust my Hosts File.

While Western Digital appears to be heading in the direction of 4KB Logical Sectors to break the 2TiB barrier, it appears that Seagate has decided to break the 32-Bit Sector barrier for their 3TB Hard Drive. This means there will be two different issues for Windows 9x. It looks like I may have to break out my other set of Patches before I get to put my new ones to use.

did your mobo workng on ide? i using h55 using sata(IDE mode) @ \!/ <- & can't using usb 2.0 Using SATA Drives, that don't have Windows 9x compatable RAID Drivers, requires my SATA Patch.

I have solved the last Software barrier to using 4KB Logical Sector Drives. I can now boot from them as well as run DOS and Windows. The only issue left is the BIOS, over which I have no control. If necessary I can create a new BOOTMAN Package to bridge the gap.

Stupid? Absolutely not. I have thought about this and I see no problem. Additionally, this idea is not limited to IO.SYS 8.

Yes. But Partition Size is also a factor. If the partition start location is set such that the file system clusters (as long as they're multiples of 4 KB in size) will be 4KB-aligned on the disk, then unless there's some other non-file-structured system data that gets frequently written I would think that where the partition ended wouldn't matter (i.e., if it ended at some odd boundary the file system simply would leave the final few sectors that were insufficient to create another cluster unused - just as it has always done). I don't understand HOW anything could be broken as long as one used standard (pre-Vista) partitioning utilities to create the partitions: the entire point of this exercise would be to create bog-standard partitions using standard 'cylinder' boundaries carefully chosen to make virtually all disk access activity by legacy file systems 4KB-aligned (as long as those file systems used clusters that were multiples of 4 KB in size). Even if one made a mistake in such choice the worst that should happen in the presence of 512-byte sector emulation is that small-write performance would suffer - at least as long as one refrained from using Vista/Win7 Disk Management to muck around with the partition structure without first telling it to use old-style partition alignment (a Registry modification which Microsoft appears to support). Am I still missing something? The Data area is after the FAT tables, so the size of the FAT Tables can affect the alignment. This is why the Partition size is important. Aligning some standard Partitions require a legal but non-standard modification to the Format. If your Computer uses 240 Head mapping, it may be impossible to avoid this issue regardless of Partitioning, if you use standard settings.

Actually DOS 7 and Windows 9x can support 4KB Sector Drices WITHOUT 512 Byre Emulation with the proper modifications. I was attempting to ascertain whether merely positioning partition start locations strategically on 4 KB sector drives that DO support 512-byte-sector emulation would be sufficient to allow several legacy operating systems of interest installed within those partitions without any modification (or special formatting) to suffer no significant performance degradation (e.g., to avoid almost all read/modify/write sequences caused by the larger sector size) - at least as long as those systems used file clusters that were multiples of 4 KB. As long as those systems do maintain consistent offsets to the first file cluster (and then manage free space such that clusters are tightly packed) I couldn't see any reason why this wouldn't work, but it's always nice to have such suppositions confirmed. Yes. But Partition Size is also a factor. The trick is knowing how to do it and not breaking something else in the process. My tools have been updated to handle this issue for Windows 9x.

I tried to reduce decompressed and restored real-mode functionality IO.SYS by intuitively cut from 0001EF60 to end, because too many functions in IO.SYS version 8.0 extracted from diskcopy.dll disabled by Microsoft. It work for me. Reduced IO.SYS version 8.0 Size 126 816 Original IO.SYS version 8.0 Size 116 736 Assuming your truncated IO.SYS works properly, you could create a smaller Compressed Version by combining the Loader/Decompressor, the first 3 compressed Blocks, and the Decompression Code Block into a new IO.SYS file. Be aware that my Decompressor will not apply any Patches, that may have been added, if they are done after Decompression. This includes the Partition Bug fixes by Phelum and myself.

Actually DOS 7 and Windows 9x can support 4KB Sector Drices WITHOUT 512 Byre Emulation with the proper modifications. I just secceeded in Booting Windows 98SE from a simulated 4KB Logical Sector Hard Drive. I have noted your concern and updated my Formatter to minimize the need to change the Standard Offset. It may still be necessary to move the Partition to use the Standard Offset, but now it will only need to move one Cylinder.

How to remove uncompressed blocks from compressed IO.SYS(start-end offset)? First you would have to come up with a small set of patches, to the uncompressed code, that renders an entire 48K Block of data unnecessary, and adjust pointers so that the block can be removed. Then you could remove the correspnding compressed block and add the Patches to the code following the decompressor.

I haven't done any extensive testing, but I found that the Windows 98SE NTKERN.VXD did work with 98FE, and in fact, was necessary to porting Windows ME USB Drivers to 98FE.

The first 2KB Block of IO.SYS loads the rest into memory, decompresees it, then jumps to it. My decompressor loads IO.SYS into memory, sets up a suitable stack frame and register settings, then calls the decompression subroutine. It then writes out a modified header and the decompressed data from memory. I have found similar code in WININIT.EXE and SCANDISK.EXE, so it is definitely reused code.

Small Patches to Windows ME IO.SYS can be done to the compressed Version by adding the Patch Code after the Decompression has taken place. Phelum did this with his Windows ME Version of his Partition Offset bug Patch. It should also be possible to shrink the compressed IO.SYS file if one or more of the 48K (uncompressed) blocks can be removed.

DOS 7 is not limited to 500GB. I have used it up to 2Tb without problems. With larger sectors, I have created a 64TiB Partition. The main limitation is FDISK, which cannot handle more than 512GiB. Some older SATA BIOSes topped out at 512Gib, but then the Computer would not even boot if the limit was exceeded.

Even PIO transfers will not work properly unless you specifically check for Sector size. In PIO mode this is not hard, but the BIOS must be coded for it.

Creating an ExFat driver is doable although a rather substantial task. It is when you go beyond the API limits, such as files larger than 4GB, that things get really hard. Tracking down all of the code that uses File Position information and/or the internal File Tables, and Patching them is a lot of work and requiring skills few people have. This is also why the Windows Resource issue is so hard to solve.

Hmm, I suppose the low level BIOS routines would be accessing the HD controller in the old AT-compatible way, i.e. request a number of /sectors/ not /bytes/. But I haven't got 1024 byte per sector disks yet, so I could've held my mouth shut :~{ --- May I assume your reply was backed on actual trials you made ? W/ best regards, -- Ninho Requests to Hard Drives are always based in Sectors. The Data transfer is in Bytes, Words or DWords. The BIOS would have to know the Sector Length to compute the number of transfer requests to perform or to tell the DMA controller to perform. The earliest versions of the protocol allowed specifying a Sector size, but I don't think it was ever used. The LBA protocol completely breaks this protocol. Sector size information was not added to the standard until very recently so only the newest BIOSes could possibly use it. Only by reading a Sector and monitoring the Data Ready Flag could an older BIOS determine the size of a Sector. Since there are no ATA Hard Drives, that I know about, to test with, I could not run trials. As even the latest BIOSes I have seen, do not support the full 48-Bit LBA, but only 32 Bits, I doubt they would have Large Sector support.

This is plainly false. A standard AT BIOS will read one (1) sector from disk to a fixed place in memory, then jump to execute code from the start of that buffer provided the required signature, hex AA 55 is present at offset 510 (1fe hex). It doesn't matter if the sector length isn't 512, provided it is /larger/ (if it were smaller than 512, /then/ you'd have a problem because the boot sector signature wouldn't be found after reading the sector and so, BIOS would think there was a read error and the boot process wouldn't go on. Reading the MBR would not be the issue. Unless the BIOS recognizes larger sector Hard Drives, it would only read 256 Words (512 Bytes) from the sector. This would leave the request incomplete with the drive waiting to return the rest of the sector. The drive would not be ready for the next request. Even if the BIOS managed to continue to boot by repeatedly resetting the drive between reads, it would fail as soon as the loader expected a larger sector.

Sorry for the delayed response. If you need to test different sector sizes for real (not using a DDO) I recommend using a SCSI HDD. SCSI HDDs support low level formatting with different sector sizes. You just need an old HDD (most 9 GB HDDs support this feature), an old SCSI adapter and Bart's SCSI Tool. Run Bart's SCSI Tool and set a different sector size in drive geometry page, then low-level-format the drive. It takes 30min - 1h depending on drive speed and size. There is no progress indicator. I am aware that SCSI Drives can be set for different Sector Sizes. The DDO is more than adequate for testing DOS. I had to add extra Patches to ESDI_506.PDR to simulate in 32-Bit mode but SCSI would not help since I could not use ESDI_506.PDR with it. I was able to use a real 2KB Sector FileSystem by putting a FAT FileSystem on a CD.

The free Generic USB Driver I distribute does the same thing as NUSB (not the USB2.0 portion) but in a smaller package. If you are using NUSB you probably do not need my package. I have been using my Package along with the USB2.0 drivers from NUSB.

The Big HDD Fix is not required with large USB Drives as the ESDI_506.PDR Driver is not used. If you put a large Hard Drive in an old USB Enclosure, you may be limited to 137GB, but no fix will help as the problem would be in the Enclosure's controller. If the Drive is larger than 1TiB, you will need to split it into more than one Partition, as there is a bug in Windows 9x that affects Partitions larger than 1TiB. To use larger Partitions, you will need a Patch that I have written.

Windows 9X has a bug that affects Partitions larger than 1TiB. In some cases accessing Directories located more than 1TiB above the start of the Partition will cause lockup. I have written a Patch for this.

I have published Version 1.0 of my Decompressor on my Website. It is in the Software Catalog under the Prerelease and Beta Section.

I examined this Patch. It only properly supports 4GB when Seeking from the beginning of a File. This may be sufficient for Copying, but it does not properly support Seeking from Current Position, or from End of File. I have a Patch that corrects all modes.

Yes, but not an exact multiple of #cyls * 255 * 63... and this results in just 80 heads on the last cylinder, for all HDDs I've ever seen. I confirmed your statement on the Drive I used. I have seen at least one BIOS that always truncates the size to a Cylinder Boundary. I tried another Hard Drive. Ranish then decided it liked Head 47 Sector 30. To be CHS compatable, all of the Type '05' Partitions in the Chain must start on a Cylinder Boundary. The Logical Partition typically starts one track later. I don't think this is a requirement. The Partition need not end on any particular boundary, so having all Partitions on Cylinder Boundaries will not waste space, if the last one takes the partial Cylinder. The first one MUST end on a Cylinder Boundary, otherwise the BIOS may miscompute the Geometry of the Drive. Using Ranish, I got my BIOS to think there were only 240 Heads per Cylinder. Phelum's Patch will not bypass Geometry discrpancies on CHS Primary Partitions. I tried to install Windows NT 4 on my Test Computer. It crashed during loading. I looked at some of the files for Partition checking. So far I found only one piece of code. It did recognize Type '0F' Partitions but did not recognize '0B', '0C', or '0E'.