2 TiB limit size in MBR hard drives

[Tripredacus]

Ok for this one, I followed the instruction to update the VIA SATA RAID controller device in Device manager and browsed to the folder that only has uataxp.inf in it. It did not change the VIA device but instead put a flagged device into Other devices. I then installed the driver for that, and now under System there is a UATA Virtual Communication Device. That driver is in the root of the Release folder of the driver download. The instructions do not mention having to install this device.

This particular computer does have the IDE controller also, but the only thing connected to it is a DVD drive.

Now having rebooted with this UATA driver installed, it doesn't seem to make any difference. It still shows the inaccessible drive (now E) in My Computer, and the same "healthy" extent sized volume in Disk Management.

[jaclaz]

WHICH folder?

There is a folder \XP\ containing readme_xp.txt, uata_xp.inf, uata_xph.inf in my copy.

Check device manager.

Devices By Connection view.

jaclaz

[Tripredacus]

Yes I had moved the INFs to different folders because it specifically says to use one vs the other depending on the controller. So I moved the H to a different folder so Windows could only pick the INF I wanted.

Quote

10.  enter path to .INF file for new driver

    If this is usual onboard IDE controller, use
        C:\temp\uniata\Release_Dist\uata_xph.inf
    If this is IDE RAID controller or additional PCI IDE controller, use
        C:\temp\uniata\Release_Dist\uata_xp.inf

So since this is a "VIA SATA RAID" controller, I didn't want Windows to try to use the uata_xph.inf so I took it out of the folder.

direct link: http://i.imgur.com/IQoS5Wkl.jpg

FWIW, I did also try to use the xph driver on there, but it added about 6 flagged devices and all of them had the "not enough free resources" message in device properties.

[jaclaz]

I don' t know, but clearly the installation didn't go through correctly, the UNIATA replaces the VIA RAID controiller, it is not a "child" of it.

There is no need to move the .inf, only you need to select the "right" one.

But you can try installing differently.

Try following this (seemingly completely unrelated) and remame the uniata driver:

[redacted]

Or remove the VIA driver, force the install of the plain MS one (I presume it is compatible anyway) and start again from there.

jaclaz

 

 

Edited September 5, 2017 by Tripredacus

[rloew]

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.

[jaclaz]

2 hours ago, rloew said:

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.

Yep, in theory Uniata should allow the same result as Tripredacus demonstrated for Windows 7 32-bit, i.e. that the good MS guys lied to us  in their attempt to push UEFI/GPT.

But maybe there is some additional (intentional or not) roadblock in XP.

It seems like Windows Server 2003 SP1 (both 32 and 64 bit)  have "native" GPT support, so - likely - that would be the first OS to  support this scheme - like 7 - without needing further mods.

The key should be :

http://alter.org.ua/soft/win/uni_ata/

• large drives above 2Tb support (SCSI READ16, WRITE16)

 

jaclaz

[rloew]

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.

[jaclaz]

38 minutes ago, rloew said:

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.

Yes, but there is no need (in the proposed scheme) to use 64 bit math at all.

All values are within the 32 bit limit since, once the volume is addressed, all addresses are relative and the 0 offset is from the PBR.

jaclaz

[rloew]

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.

[jaclaz]

16 hours ago, rloew said:

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.

Maybe the DOS/Windows 9x/Me way to access volumes is different, cannot say.

The Paragon driver (which does support GPT and thus more than 2.2 Tb addresses) is after all two drivers, but the fastfat.sys remains AFAICR the "default one" (and as well the NTFS.SYS, etc.).

If you prefer (AFAIK/AFAICR) there are no original files patched or substituted in that solution, so I would exclude that the partition management and related files need any patch, I still beleive (but I may well be wrong) that all volume access is done using relative addresing only and on the other hand - unlike the FAT32 - the NTFS has 64 bit addresses since day 0, long before XP came out, so I would guess that the 64 bit math, if neeeded,  is already correct. (but of course until some proper experiment confirms of denies it there is no way to know for sure).

jaclaz

 

[rloew]

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.

[jaclaz]

2 hours ago, rloew said:

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.

I have it (for a limited time it was a "free" download), but I have no system with it installed, nor any "spare" large sized disk, so cannot make any real test, but I can provide you with some info.

There are two drivers in the package:

1) hotcore3.sys
2) gpt_loader.sys

At a quick look the two main/meaningful Registry entries are:

    HKLM, "SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}", "UpperFilters", 0x00010008, gpt_loader
    HKLM, "SYSTEM\CurrentControlSet\Control\Class\{71a27cdd-812a-11d0-bec7-08002be2092f}", "UpperFilters", 0x00010008, hotcore3

So gpt_loader "hooks" to "Disk Drive":

https://msdn.microsoft.com/en-us/library/windows/hardware/ff553426(v=vs.85).aspx

Quote

Disk Drives 
Class = DiskDrive
ClassGuid = {4d36e967-e325-11ce-bfc1-08002be10318}

This class includes hard disk drives. See also the HDC and SCSIAdapter classes.

and hotcore3 to "storage volume"

Quote

Storage Volumes 
Class = Volume
ClassGuid = {71a27cdd-812a-11d0-bec7-08002be2092f}

This class includes storage volumes as defined by the system-supplied logical volume manager and class drivers that create device objects to represent storage volumes, such as the system disk class driver.

both are set as "Upper Filters", which should mean that they are "Filter Drivers", and given the GUIDs, they seemingly "hook" over - as you guessed - to the PartMgr.sys ({4d36e967-e325-11ce-bfc1-08002be10318}) but the other one (the {71a27cdd-812a-11d0-bec7-08002be2092f}) seems related  to VolSnap.sys

 

jaclaz

[rloew]

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.

[jaclaz]

4 hours ago, rloew said:

Unfortunately, providing GPT support does not guarantee that the entire Driver stack is 64-Bit compatible.

Well, these drivers provide to "normal" XP BOTH  GPT support AND access to bigger than 2.2 Tb (512 bytes sectored) disk drives, that is the whole point, and, compare with this:

http://download.paragon-software.com/doc/GPTLoader_RG_081111.pdf

at least they allow (of course in GPT style) a "monolithic" partition/volume of 3 Tb.

It may be the case that the "GPT" part of the driver is the only thing 64-bit needed and then NTFS.SYS takes care of the "monolithic" partition/volume (that anyway begins at a normal offset of 63 or 2048 sectors, like any other "first partition"), but if this is the case it would be a really "ugly" workaround.

jaclaz

[rloew]

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