Read GPT hard disk on Windows XP

[Andalu]

@Dave-H 

I don't remember exactly where I got it from, @roytam1 is probably right

or maybe it is a simple renaming?

 

Edit: I just downloaded the version you uploaded some days ago and it is identical (same SHA-1) to the gptmount.sys I used in my test.

 

 

[off-topic]:

@roytam1

I take this opportunity to thank you for the wonderful work with Basilisk

 

 

Edited April 16 by Andalu

[user57]

Cixert creator of thread this has mentioned other methods it always came in to use bigger sectors, it it was mentioned again by Milkinis

some say that already worked for them

it is a similiar discussion:

https://msfn.org/board/topic/176480-2-tib-limit-size-in-mbr-hard-drives/#comments

user-mode wise it dont seems a problem to me since it use that overlapped structure

it contain 2 times 32 bits (64 bits) offsets -> those get translated to a physical address on a harddrive (i think recently somewhere i pointed that out somewhere passing to 64 bit via a structure)

https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-overlapped

that harddrive example makes a good example why and how 32 bit where passed, we know why there already where HDD discs with more then 4 GB - so actually we have a passed method because harddrive reached that areas a lot ealier then the RAM

 

to be honest it dont look hard either since the function already can do that - sure i might not know about the windows driver for now ... but that raise the question why the driver cant do that

 

it looks simple to me up to the point i know about it

it just has to convert that 64 bit address given in the overlapped structure to a physical offset on the disc

if they are 512  / 4096 /whatever "cluster-sector" size

thats easy too , that just means you have more data that you actually can use with the 64 bit offset

 

to make an example if the sector size was 1 you might would have have the 4 GB limit with a 32 bit offset, but that simply didnt use the other 32 bits (that are available)

in case the sector was 512 with and now having a 4096 sector that means you have 8 times more space

4 gb (32 bit) * 512 = 2,19 TB

 

GPT is a partion not a disc , a partion is a small file on the disc (in the past it was easy to currupt, you had bad luck if that one got demaged) - thats why you rather dont come to easy to access it

[Cixert]

Years ago I found that Windows Seven was not capable of reading MBR disks larger than 2 TB, while Windows 2000-XP and Linux distributions from 2009 onwards were capable.
I don't remember which Windows Seven version I installed, whether it came with Service Pack 1 or not. I think that this one did not have it and that the problem was solved with Service Pack 1 . Windows 10 reads +2TB MBR hard drives without problems.

Regarding the GPT +2TB disks, I have not experimented with them again, in my last comments I reported problems such as that the 6 TB disk was not read by USB adapters if it was formatted with SATA and it was not read by SATA if it was formatted with USB.

Furthermore, the partitions on the 6 TB GPT hard drive were not read by XP if these were formatted with the Windows 10 disk manager, but these were read by XP if these were defragmented in Windows 10 with third-party tools.
https://msfn.org/board/topic/181911-read-gpt-hard-disk-on-windows-xp/?do=findComment&comment=1251210
And here the culprit that will not dedicate my time to anything else, the different disk defragmentation utilities have so many differences from each other that researching them took me several months. Then I got involved with something else, of course... 
 
The fact is that during this time I have worked with MBR on a 5 TB hard drive so as not to have problems, although it also has a specific post about problems.
Regarding the sector and cluster size, here we have the @jaclaz's final statements 
https://msfn.org/board/topic/184904-problems-with-mbr-hard-disk-5-tb/

So I have not experimented with GPT again and I seem to read that the conclusion you reached is that GPT in XP cannot work with partitions larger than 2 TiB. Is this so? Can you confirm it or is it pending further verification?
What file system do you format the partitions? @Dave-H

Apart from the MBR sector size physical limits, depending on whether the hard drive is 512 bytes or 4096 bytes, there are cluster limits directly related to the FAT32 and exFAT formats.
These tables indicate the cluster limits provided by MiniTool Partition Wizard. Which seem about right for a hard drive with a 4096 bytes sector size on MBR.
I assume that these limits are also applicable to GPT hard drives.

FAT32 PARTITION LIMITS (format with MiniTool Partition Wizard)
Cluster     4 KiB =   0.29 TiB /     300.99 GiB /     308213.76 MiB
Cluster     8 KiB =   0.58 TiB /     600.99 GiB /     615413.76 MiB
Cluster   16 KiB =   1.17 TiB /   1203.99 GiB /   1232885.76 MiB
Cluster   32 KiB =   2.35 TiB /   2407.99 GiB /   2465781.76 MiB
Cluster   64 KiB =   4.70 TiB /   4815.99 GiB /   4931573.76 MiB
Cluster 128 KiB =   9.40 TiB /   9631,99 GiB /   9863157,76 MiB
Cluster 256 KiB = 18.81 TiB / 19263,99 GiB / 19726325,76 MiB

*Just I exceeds only 3.4 GiB the limit for cluster 16 KiB and problems arose.
*Values from cluster 64 kib are not given by MiniTool, these have been calculated by the previous amounts and I have not verified their correct operation.
*You have to take into account the limits punctured by @jaclaz for the maximum partition size of 16 TiB with sectors of 4096 bytes and 2 TiB for 512 bytes sectors.
(real calculation 15,9999999962747097015380859375 TiB & 1,9999999995343387126922607421875 TiB)

exFAT PARTITION LIMITS (format with MiniTool Partition Wizard)
Cluster     4 KiB =   1.00 TiB /   1025.00 GiB /   1049610.24 MiB
Cluster     8 KiB =   2.00 TiB /   2049.00 GiB /   2098176.00 MiB
Cluster   16 KiB =   4.00 TiB /   4097.00 GiB /   4195328.00 MiB
Cluster   32 KiB =   8.00 TiB /   8193.00 GiB /   8390656.00 MiB
Cluster   64 KiB = 16.00 TiB / 16385.00 GiB / 16779264.00 MiB
Cluster 128 KiB = 32.00 TiB / 32769.00 GiB / 33556480.00 MiB
Cluster 256 KiB = 64.00 TiB / 65537.00 GiB / 67110912.00 MiB
...and so on to cluster 32768 KiB (32 MiB) = 8192 TiB

*Values from cluster 32 KiB are not given by MiniTool, these have been calculated by the previous amounts and I have not verified their correct operation.

 

Edited April 24 by Cixert

[user57]

and the firmware translate this correctly ? 

it would make sence the the harddrives firmware actually know this and translates these to physical places on the real harddrive

 

if the partition can filled with how you want to have the clusters, what is even the problem ?

[Dave-H]

11 hours ago, roytam1 said:

I think it is from https://dl.bloba.dev/Operating Systems/Windows/Windows XP/Windows XP Professional SP3 x86 - Integral Edition 2022.6.16/Extras/Paragon GPT Loader v8.0.1.2/

Ah thanks. That's an older version of the Paragon driver than the one I have.
IIRC it was buggy, and the version 10 driver is much better.

[roytam1]

... from my testing. Paragon's GPT Loader can only work well with standard ATA driver(pciide.sys/atapi.sys). Any driver using SCSIPORT.SYS doesn't work well.

[Dave-H]

11 hours ago, Andalu said:

@Dave-H 

I don't remember exactly where I got it from, @roytam1 is probably right

or maybe it is a simple renaming?

 

Edit: I just downloaded the version you uploaded some days ago and it is identical (same SHA-1) to the gptmount.sys I used in my test.

Ah, so it looks like it was just re-named for some reason then.

[Dave-H]

10 hours ago, Cixert said:

So I have not experimented with GPT again and I seem to read that the conclusion you reached is that GPT in XP cannot work with partitions larger than 2 TiB. Is this so? Can you confirm it or is it pending further verification?
What file system do you format the partitions? @Dave-H

 

@Cixert

I didn't format the 3TB disk I was using, it was pre-formatted with NTFS and I just used it as it was.
Maybe that was a mistake, and I should have tried formatting it in XP, using Partition Magic if XP couldn't do it itself, with it connected in the hardware configuration I was trying to use.

All I know is that it had severe filesystem corruption on it as soon as I started using it, which became very obvious when switching between XP and Windows 10.
This happened whether it was connected directly to the motherboard or via an add-in Asmedia SATA card, and whether I was using the Paragon GPT driver or the driver files from Windows 2003 which @Andalu kindly supplied for me.

It looked fine until anything was written to it using XP, and it had nowhere near to 2TB of data on it.

[Dave-H]

2 hours ago, roytam1 said:

... from my testing. Paragon's GPT Loader can only work well with standard ATA driver(pciide.sys/atapi.sys). Any driver using SCSIPORT.SYS doesn't work well.

My motherboard BIOS allows both legacy and AHCI modes.
I use legacy mode as Windows 98 won't boot otherwise.

[Outbreaker]

8 hours ago, Dave-H said:

Ah thanks. That's an older version of the Paragon driver than the one I have.
IIRC it was buggy, and the version 10 driver is much better.

v8 was a very od one. The new one that was added is v11.0.0.175

https://www.mediafire.com/file/gj2i59pdix1o180/Windows_XP_-_Integral_Edition_-_Paragon_GPT_Loader_v11.0.0.175.zip/file

Edited April 16 by Outbreaker

[Dave-H]

Thanks, good to know that there is a later version that's still compatible with XP.
I don't think I'll bother to update what I've got though.
There's no evidence to suggest that the Paragon driver was the cause of the issues I was having.

 

[Andalu]

On 4/16/2024 at 1:28 PM, roytam1 said:

... from my testing. Paragon's GPT Loader can only work well with standard ATA driver(pciide.sys/atapi.sys). Any driver using SCSIPORT.SYS doesn't work well.

When you write that any driver that uses SCSIPORT.SYS does not work well are you referring to some limitation that the latter has?

Maybe the one of 2,199,023,255,552 bytes with disks that have a sector size of 512 bytes?

[roytam1]

1 minute ago, Andalu said:

When you write that any driver that uses SCSIPORT.SYS does not work well are you referring to some limitation that the latter has?

Maybe the one of 2,199,023,255,552 bytes with disks that have a sector size of 512 bytes?

yeah thats the case I encountered.

with IDE/ATAPI driver, it works.

[Andalu]

2 minutes ago, roytam1 said:

yeah thats the case I encountered.

with IDE/ATAPI driver, it works.

Thanks for the confirmation.

Unfortunately, even with drivers that do not depend on scsiport.sys you cannot get recognition of GPT disks even if you have the GPT Loader installed in a system configured in AHCI mode.

The only sata/ahci driver that allows recognition of GPT disks on intel systems even without GPT Loader is the asmedia asahci32.sys. But it, too, is based on scsiport.sys which is thus the reason for the problem of corrupted files I encountered on disks with sector size of 512 bytes when the limit of 2,199,023,255,552 bytes was exceeded.

[roytam1]

18 minutes ago, Andalu said:

Thanks for the confirmation.

Unfortunately, even with drivers that do not depend on scsiport.sys you cannot get recognition of GPT disks even if you have the GPT Loader installed in a system configured in AHCI mode.

The only sata/ahci driver that allows recognition of GPT disks on intel systems even without GPT Loader is the asmedia asahci32.sys. But it, too, is based on scsiport.sys which is thus the reason for the problem of corrupted files I encountered on disks with sector size of 512 bytes when the limit of 2,199,023,255,552 bytes was exceeded.

I do wonder if STORAHCI.SYS for XP can work or not, if such thing exists.