rloew

I was not referring to combining my EMBR with a GPT Loader. I am talking about having both an EMBR and GPT structure on the same Drive. The 4.4TB MBR approach requires OS modifications for DOS, 9x and XP. Again you wrote a self-contradictory argument. If a Read Only EMBR is not worth Pirating, how is it worth Marketing? It would have been tough to write my EMBR Patches 20 years ago as Windows 98SE did not even exist. Also there no LBA-48 Hard Drives. Many USB Enclosures have 4K Translating Bridges in them. They can be used with 6TB, 8TB etc. Drives. External Drives can be disassembled to retrieve the Bridges as well. 256TB is an artificial limitation, so Microsoft won't be interested in anything I do. My current EMBR supports 512TiB using 512 Byte Sectors. There is nothing stopping me from increasing that number to the full LBA-48 limit. With Sector Mapping, Windows 9x can support 384TiB of Hard Disk space (24 Partitions), DOS can support 3PiB. GPT supports 8ZiB with 512 Byte Sectors so it is not an issue. I have a slightly modified DOS that preserves the pre-boot environment. It can boot anything from a DOS Prompt. @Dibya UNIATA provides low level support. I have not identified the higher level Drivers that limit support. Free? @cc333 Dibya is referring to full 48-Bit Support. XP SP1 added support for LBA-48 but did not add support for the full 48 Bits, only 32 Bits. LBA-48 replaced LBA-28 which only supported 28 Bits (137GB).

If my EMBR is combined with GPT, it can be used with new OSes without any modified Drivers. Unlike PKZIP, my EMBR implementation is done with Patches. Adding Read Access automatically adds Write Access. I would have to add extra Code to disable Write Access. This would easily be found and defeated by Reverse Engineering, especially with all the Free Copies that would be around. Like PKZIP, I can safely provide free Read Only Demos of my RFDISK Program because the Code for Write Functionality is completely absent. This is why I do not provide a Demo of my SATA or nVidia Patches. I have already tried substituting Windows 2003 Files without success. PARTMGR.SYS cannot be substituted. For Data Disks, a GPT Loader TSR would be fairly easy to write for DOS. I already have a manual Loader that can Mount anything that is EMBR compatible. The Partitions would be available in Windows 9x in Compatibility Mode.

@jaclaz I use 1TB and 2TB FAT32 Partitions. They don't run slowly. SCANDISK is very slow but I have a faster Program that can handle the routine issues. As I mentioned, my EMBR can be combined with GPT to provide access via newer OSes. A "Read Only" Version would actually be more complicated that Read/Write. Converting DOS/WIN9x to GPT would still require a License for each Computer with DOS/WIN9x to use the data. DOS is not compatible with UEFI so a special Boot Sector would be needed to load it. All Partitions would have to be aligned to 2K or other predefined power of 2. The 4.4TB MBR approach will work with my TeraByte Plus Package. 8GiB will be lost because the Final Partition must start before the EMBR Reserved Area. I could make a smaller Patch that would just support the 4.4TB MBR approach.

There is no GPT support in 9x, so my EMBR is the only option at present. In 9x, 4K Sector Support also requires Patches. It is also possible to combine my EMBR and GPT in one Hard Drive. My Multi-Boot Profiles are setup to show either the EMBR or the GPT according to the OS. this avoids the problems with Hybrid MBR/GPT combinations that are blocked by some BIOSes and OSes. Using untranslated USB Drives above 2TiB requires READ(16)/WRITE(16) Support which is not in 9x or XP. I had to Patch the Drivers in 9x.

My Patched DOS and Windows 9x will boot from a Native 4K Drive. I had to test with Emulators because my BIOSes did not support Native 4K USB Boot.

All this talk about 4TB, 5TB, 8TB etc. is irrelevant to External USB (Native 4K) Drives as only 32-Bit Math is needed up to 17.6TB (16TiB). The 128GiB Problem never was a Math issue as Jaclaz already pointed out. Larger Clusters will not help. I was able to increase the Maximum Cluster Size to 128KB for 9x and 256KB for XP assuming 512 Byte Sectors. I made DOS support 32KB Sectors, allowing 8MB Clusters and 128TiB Partitions My EMBR reserves the last 8GiB of the first 2TiB of a Hard Drive. Any Partition starting value in this range is converted to a 40-Bit Value with coarser granularity. The Length is used normally. It will work with an USB Drive, but is not relevant unless the Drive is larger than 17.6TB or is not translated to Native 4K. I found one External USB Drive larger than 2TiB that did not translate. Another option is to emulate 4K Sectors using Software allowing 16TiB Internal Drives. I did this with DOS and Windows 9x. If the 32-Bit Math issues can be resolved in XP, then 4TB should be possible. My full EMBR should then be possible also.

No to both. VFAT.VXD and ESDI_506.PDR use 32-Bit Math for both Read and Write. Unlike XP, the File System Driver is responsible for Absolute addressing. The changes are less complex than the ones I use for my Extended MBR, but they are still necessary.

Obviously the Extended MBR is not going to work with unmodified DOS or Windows. Both DOS and Windows require modifications to access above 2TiB. The Partitions can be made visible to all. They can be hidden from DOS to avoid BIOS issues or unmodified Windows or Linux. If the Partition is visible, it could be damaged if put in an unmodified system. I have not found a way to modify Windows XP so far.

I have not yet seen a 4K Native SATA Drive. The 6TB Drives I have use 512B logical Sectors. Most, not all, USB Enclosures use 4K Logical Sectors for Drives larger than 2TiB. I created an Extended MBR Format that supports 512TIB (512B Sectors) or 4PiB (4K Sectors) that works with Windows 9x. I may be able to adapt it to XP if a full 64-Bit Path can be created through the Driver Stack.

That still leaves Lower Drivers such as DISK.SYS, PCIIDE.SYS and ATAPI.SYS.

For now I can send you a copy with the Optical Drive code disabled so you may be able to use a DOS AHCI CDROM Driver. The current version supports Drives between 10GB and 144PB. Specify the number of AHCI Ports per controller, usually 4 or 6. The price is $21.00 US.

I could sell you one but I cannot guarantee when I will solve the Optical Drive problem.

I don't have it.

It is possible that GPT_LOADER.SYS replaces PARTMGR.SYS and the lower Drivers with a Monolithic Driver.

VOLSNAP is the layer above PARTMGR.SYS. It seemed a bit removed from the level where Partitions are enumerated in the Device Tree. It also does not call the Partition Table management functions. Unfortunately, providing GPT support does not guarantee that the entire Driver stack is 64-Bit compatible. The other solutions I have seen, emulate multiple 2TiB Drives. Only the lowest level Driver would use 64-Bit Math.

One step away from the Abyss. I have a working Hard Disk AHCI Driver. Unfortunately, I do not have the Optical Drive Code working yet.

I don't have the Paragon Driver, so I don't know what two files are affected, but that would suggest that FASTFAT and NTFS only see the relative address. DISK.SYS manages the Partition Table so I assume it is replaced to support GPT. It and PARTMGR.SYS are the most likely Drivers to be the Filters that compute the Absolute Address.

The 64-Bit Math is required when the PBR relative Address is combined with the Partition Offset to create the absolute Address. In Windows 9x, this is done by VFAT.VXD so I was able to implement 64-Bit Math. I already had upgraded ESDI_506.PDR. IOS apparently always supported 64-Bit Math. I was unable to locate the necessary code in FASTFAT.SYS. I do not know if the code is there or if it is somewhere else such as the Partition Manager. I tried UNIATA with an Overlapping FAT32 Partition. It still doesn't work.

In addition to the problem I saw, the FileSystem or Partition Drivers may not do the 64-Bit Math needed. In Windows 9x, I had to patch the FileSystem as well as the Disk Driver to support 64-Bit Math.

At a minimum, XP will require UNIATA, or equivalent, as the standard ATAPI.SYS Driver only writes 32 Bits of the Sector Number to the Hardware. This gave me access through the ASPI Interface but not through the PHYSICALDRIVE Interface.

In order to swap drives, GRUB4DOS needs to hook INT 13. If it hides Partitions, or makes any other changes, by modifying the image of the MBR provided rather than changing the actual MBR, Windows will get confused. I am working on an AHCI Driver, so I have dissected the existing Code. IOS scans the Hard Drives using INT 13 and creates a Checksum for each one. The Standard Disk Driver scans the Hard Drives using Direct I/O, creates Checksums for each one, then compares them to the list from IOS. The ones that match are mapped. Unmatched Drives are added as new Drives. If GRUB4DOS changed the Checksum for a MBR Image, it won't match the Checksum from a MBR read by Direct I/O. This appears to be happening in your case. The Drive didn't match so IOS put it's unmatched Drive and Partitions into compatibility Mode. The same Drive was treated as new and it's Partitions were added as your Ghosts. I noticed that it appears you are using Virtual PC 2007 Drivers. These may be incompatible with your usage of GRUB4DOS. If possible try the same setup on a different VM.

I could separate the Windows only Partition support from the rest of the Terabyte Patches to make a less expensive product, but I never saw any reason to do so. The main reason I designed these Partitions is to handle Partitions above the 2TiB limit. A lot of BIOSes do not support them. The only other case I know of is a BIOS that cannot handle more than 137GB, 8GB or one of the other old limitations.

When a Protected Mode Storage Driver is loaded, Windows scans every Device found. If it matches an existing DOS detected Device it is mapped. If not, all Partitions on it are added. DOS detected Partitions that are not mapped remain in "Compatibility Mode". GRUB4DOS is hiding Partitions from DOS but is not hiding them from Windows. This leads to the "Ghost" Partitions. Other than altering the Partition IDs to hide them, I do not know how to hide Partitions from Windows. My RFDISK Multi-Boot Profile setup alters the MBRs dynamically to provide Windows compatibility. I have intentionally implemented Windows only "Ghost" Partitions in my Terabyte Plus Package to insure that Partitions not supported by the BIOS or DOS are correctly handled.

The Kernel sets the limit. No FileSystem, including Network FileSystems, can exceed 4GiB -2 Bytes. I posted a free fix for the 2GiB limitation. I have a Patch (FILE64) that emulates Files larger than 4GiB. It can be used with any FileSystem including Network FileSystems. This allows 32-Bit Software to manipulate Files larger than 4GiB.

Math was only one consideration. I also wanted to have at least one modern Intel system to test my Products on rather than relying on others to test for me. I already completed the Math run on the SLI Krait. Scaling it up further would require a dual Socket Opteron Motherboard with 4 times the performance of the Threadripper. This would cost thousands of dollars in electricity to run, so I have no plans to do so. I'm not sure if GPUs are amenable to this type of Math problem.