Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Cixert

2 TiB limit size in MBR hard drives

Recommended Posts

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.

Share this post


Link to post
Share on other sites

WHICH folder?

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

Check device manager.

Devices By Connection view.

jaclaz

Share this post


Link to post
Share on other sites

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.

IQoS5Wkl.jpg
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.

Share this post


Link to post
Share on other sites

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 by Tripredacus

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 :w00t: 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 :unsure::

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

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

 

jaclaz

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 :unsure:

 

jaclaz

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...