2 TiB limit size in MBR hard drives

[jaclaz]

3 hours ago, 98SE said:

You haven't tested the GPT Loader so there is no actual confirmation you tested reading and writing to FAT32 and NTFS under those conditions.  I'm not disputing FAT32 and NTFS don't work on GPT since I've tested 16TB on Vista before so I know it works.  It's seeing whether the GPT Loader can handle this under XP 32-bit that got me curious.  It's only meaningless to you since you are okay with believing something works without testing it.  I prefer to go the extra mile to confirm.  Just as we have predicted the 9th planet but until actual physical photographic proof of it most won't be fully satisfied.

The reason the 500GB MBR to GPT transformation was suggested for testing is that capacity would still work under both conditions.

If you don' t have the means or interest yet to test it don't worry about it.

The GPT Loader (even if I didn't ever test it) is a Commercial product that has been used successfully by a number of people without particular issues, there is no need to test it.

These people did use it to read and write (obviously) on hard disks.

No problem there.

The whole point that you seemingly insist on ignoring (or fail to understand) is that the filesystems are accessed (and read and written) by filesystem drivers.

These on NT based Windows are represented commonly by FASTFAT.SYS and NTFS.SYS.

They hook on an object that in NT based windows is a "volume".

Whatever creates the volume (the "standard" partmgr.sys in case of a partitioned MBR device, or the gpt_loader.sys in the case of a partitioned GPT device) doesn't make ANY difference in the way the volume is accessed, again a number of devices use not the partmgr.sys and directly expose a "volume".

So there is no doubt whatever about the working of these filesystem drivers with the GPT loader.

As well, everyone has been able of creating partitions smaller than 2.2 Tb AND residing within the 2.2 Tb limit and accessing the resulting volumes through FASTFAT.SYS and/or NTFS.SYS.

The question is whether in the general way these drivers (and these drivers in the specific XP 32-bit version) are used, they may suffer from a 32-bit limit of some kind when the volume crosses (or is entirely beyond) the 2.2 Tb limit.

In theory they shouldn't, particularly the NTFS.SYS, as all indexing fields in a NTFS filesystem are 64 bit (since day one) BUT LONG BEFORE THAT because volume/filesystem access uses "relative" addressing (from the start of the volume). 

Since it is NOT possible to make partitions larger than 2^32-1 sectors with the MBR scheme, the proposed scheme is to make two partitions (the first just a little smaller than 2^32-1 sectors) and the second as big as the rest of the disk (limited obviously anyway to 2.2 TB, so only useful for 3 Tb or 4 Tb disks).

The experiment carried on by Tripredacus (with Windows 7) confirmed that the dual partition MBR scheme works just fine (or if you prefer Microsoft lied when they imposed the GPT to access more than 2.2 Tb disks) and the NTFS.SYS from Windows 7 is confirmed to behave correctly (which is not a surprise, since in 7 there is also GPT support and thus, indirectly, support for volumes crossing or beyond the 2.2Tb "border").

When (if) someone will be able to replicate that experiment on Windows XP 32 bit, then we will have certainty that also the XP version of the NTFS,SYS driver is fine with volumes crossing the 2.2Tb border, but - as a matter of fact - the issues, if any, will more likely come from other files/tools.

Whether FASTFAT.SYS may have issues with such a cross-border volume it is meaningless, as noone (in his/her right mind) will ever make a partition (at least 1 Tb on a 3 Tb disk or 2 Tb on a 4 Tb disk).  

Hope that now the matter is more clear.

jaclaz

[rloew]

3 hours ago, 98SE said:

This is what I suspected.

What about a smaller Extended MBR based off of the Partition 1 up to 2.18TB, Partition 2 extended from 2.19TB to 4.39TB?

Would this type of 4.39TB Extended MBR drive work without updating DOS or 9X files on another system?

Could 4.39TB read access work on an unmodified DOS/9X and would the only issue be write access is where data corruption would occur?

 

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.

[98SE]

9 hours ago, jaclaz said:

The GPT Loader (even if I didn't ever test it) is a Commercial product that has been used successfully by a number of people without particular issues, there is no need to test it.

These people did use it to read and write (obviously) on hard disks.

No problem there.

The whole point that you seemingly insist on ignoring (or fail to understand) is that the filesystems are accessed (and read and written) by filesystem drivers.

These on NT based Windows are represented commonly by FASTFAT.SYS and NTFS.SYS.

They hook on an object that in NT based windows is a "volume".

Whatever creates the volume (the "standard" partmgr.sys in case of a partitioned MBR device, or the gpt_loader.sys in the case of a partitioned GPT device) doesn't make ANY difference in the way the volume is accessed, again a number of devices use not the partmgr.sys and directly expose a "volume".

So there is no doubt whatever about the working of these filesystem drivers with the GPT loader.

As well, everyone has been able of creating partitions smaller than 2.2 Tb AND residing within the 2.2 Tb limit and accessing the resulting volumes through FASTFAT.SYS and/or NTFS.SYS.

The question is whether in the general way these drivers (and these drivers in the specific XP 32-bit version) are used, they may suffer from a 32-bit limit of some kind when the volume crosses (or is entirely beyond) the 2.2 Tb limit.

In theory they shouldn't, particularly the NTFS.SYS, as all indexing fields in a NTFS filesystem are 64 bit (since day one) BUT LONG BEFORE THAT because volume/filesystem access uses "relative" addressing (from the start of the volume). 

Since it is NOT possible to make partitions larger than 2^32-1 sectors with the MBR scheme, the proposed scheme is to make two partitions (the first just a little smaller than 2^32-1 sectors) and the second as big as the rest of the disk (limited obviously anyway to 2.2 TB, so only useful for 3 Tb or 4 Tb disks).

Whether FASTFAT.SYS may have issues with such a cross-border volume it is meaningless, as noone (in his/her right mind) will ever make a partition (at least 1 Tb on a 3 Tb disk or 2 Tb on a 4 Tb disk).  

Hope that now the matter is more clear.

jaclaz

There might be a bunch of older reviews but I'm more interested in recent testing of the Paragon GPT Loader with 8TB hard drives and larger.  A lot of the < 6TB drives still came as MBR if found in an enclosure.  I find the probability quite low if people had a 3TB hard drive they would use this program to get that extra 800GB of data.  It would be more than likely they would sacrifice the 800GB and convert GPT to MBR for internal usage as a 2.2TB MBR drive.

Now if there are some 8TB GPT drive users using this internally that would be a relevant review if you found such to refer.

The use of an extended MBR from 2.2 to 4.4TB would be more useful on 4TB and 5TB drives.

The 4TB would be better divided into two half capacity of 2.0TB partitions.  On the 5TB the 2.2 Part1 and 2.2-4.4 Part2 with a loss of 600GB would be allowable and acceptable for most people.

6TB and larger hard drives would be wasted with this method.

The idea of splitting a 4TB-5TB would create two drive letter consumptions if both partitions are being accessed in XP.

This is the reason why an 8TB MBR is a better option via external USB method and still a better choice even up to 17.6TB or 18TB if it exists.

20TB and larger (64TB is where I would consider using GPT entirely) if it cannot be fully utilized in the same manner with MBR is when GPT will be a necessity and if GPT Loader only works internally up to the 256TB Windows limit where it will shine for XP.  But I feel by the time 64TB-256TB drives are out most people would have moved onto to Windows 7 64-Bit so GPT Loader would become irrelevant except for some niche XP 32-bit users.
 

Quote

 

The experiment carried on by Tripredacus (with Windows 7) confirmed that the dual partition MBR scheme works just fine (or if you prefer Microsoft lied when they imposed the GPT to access more than 2.2 Tb disks) and the NTFS.SYS from Windows 7 is confirmed to behave correctly (which is not a surprise, since in 7 there is also GPT support and thus, indirectly, support for volumes crossing or beyond the 2.2Tb "border").

When (if) someone will be able to replicate that experiment on Windows XP 32 bit, then we will have certainty that also the XP version of the NTFS,SYS driver is fine with volumes crossing the 2.2Tb border, but - as a matter of fact - the issues, if any, will more likely come from other files/tools.

 

In your experiment were you still capped at 4.4TB max or do you see the possibility of multiple 2.2TB partitions as long as the partition information was properly stored within the first 2.2TB.  For example if you had somehow had a 12TB drive to test could 5 (2.2TB) Partitions be spanned?

As for XP when there was originally a 128GB limit.  You could try and break it artificially on an OLDER 28-Bit (not 48-Bit) LBA system and by not installing SP1 to do your tests.

Would it be possible to split 500GB to see if 4 120GB partitions were accessible in XP with No SP?

 

For a 2TB MBR hard disk with NTFS you can choose 512 Bytes Allocation Unit Size.  But on the other end you can choose 64KB Allocation Unit Size.  That's a 1/128 fold difference in allocation units which has less overhead.

http://graveyard-buffet.blogspot.com/2011/02/sector-size-vs-cluster-size.html

https://blogs.technet.microsoft.com/askcore/2010/02/18/understanding-the-2-tb-limit-in-windows-storage/

https://support.microsoft.com/en-us/help/140365/default-cluster-size-for-ntfs--fat--and-exfat

 

I think hard drive manufacturers should have considered larger sectors.  512 Bytes to 4KB was not enough and 64KB sectors would have brought a higher capacity threshold for MBR with an adapter even up to the 256TB Windows limit.

 

 

7 hours ago, rloew said:

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.

MBR's fate seems sealed for Windows.   Did your EMBR also work with external USB drives?

Looking forward perhaps developing DOS,9X,ME,NT3.5/4.0,2K,XP GPT support for both internal drives and external USB drives might be a better solution to maintain compatibility.  It could be a popular bridge for old OS hold outs from upgrading.

Edited October 16, 2017 by 98SE

[jaclaz]

1 hour ago, 98SE said:

In your experiment were you still capped at 4.4TB max or do you see the possibility of multiple 2.2TB partitions as long as the partition information was properly stored within the first 2.2TB.  For example if you had somehow had a 12TB drive to test could 5 (2.2TB) Partitions be spanned?

As for XP when there was originally a 128GB limit.  You could try and break it artificially on an OLDER 28-Bit (not 48-Bit) LBA system and by not installing SP1 to do your tests.

Would it be possible to split 500GB to see if 4 120GB partitions were accessible in XP with No SP?

An LBA entry in the MBR (or in a EMBR) is made of two fields, each 32 bit in size:

1) "Start Address" or "Sectors Before" i.e. how many sectors are BEFORE the beginning of the partition described in the entry
2) "Size" or "Sectors in partition". i.e. how many sectors (starting from the address in the field above) are contained in the partition.

So at the very most you can have is:

1) One entry where the "Start Address"+"Size"<2^32-1 (this can be also multiple partitions as long as the sum of the last "Start Address"+"Size" remains within the 2^32-1 limit.

 2) Given that the #1 is actually <2^32-1 ONLY a single primary partition with a maximum extent of 2^32-1 sectors.

If you prefer, you can have one (and only one) partition crossing the 2^32-1 "border".

Since you need some "hidden sectors" before the first partition (at the very minimum 1, the MBR), the most you can have theoretically is:

Entry #1 -> "Start Address" = 1 and "Size"= (2^32-1-1)=4,294,967,294 these will be in hex respectively 0x00000001 and 0xFFFFFFFE and 0x00000001+0xFFFFFFFE=0xFFFFFFFF=4,294,967,295, i.e. (2^32-1)

Entry #2 -> "Start Address" =(2^32-1)=4,294,967,295 "and "Size"=4,294,967,295 these will be both in hex 0xFFFFFFFF

In practice you need to align the partitions using more "hidden sectors" which are typically 63 (traditional value, aligned to disk geometry)  or 2048 (new value since Vista, aligned to 4Kb, actually more than advised, strongly suggested on 512e disks) so you can have at the most:

Entry #1 -> "Start Address" = 2048 and "Size"= (2^32-1-2048-7)=4,294,965,240 (i.e. a number divisible by 8), these will be in hex respectively 0x00000800 and 0xFFFFF7F8 and 0x00000800+0xFFFFF7F8=0xFFFFFFF8=4,294,967,288 (<4,294,967,295)

Entry #2 -> "Start Address" =4,294,967,288 "and "Size"=4,294,967,295 these will be in hex respectively 0xFFFFFFF8 and 0xFFFFFFFF

There  is simply no more address space to write bigger numbers.

The 128 Gb limit you mention is an altogether different issue.

The LBA data in the MBR has always been 32 bit in size, but the actual hard disk standards (ATA) had only 28 bit resolution (early drivers , i,e, 2k until Service Pack 3 if I remember correctly and XP until SP1 followed the standard) with ATA 6 the resolution was increased to 48 bit (i.e. more than the amount that can be stored in the physical space available in the MBR).

The 48 bit in itself allows accessing 2^48-1=281,474,976,710,655 sectors, i.e., with "normal" 512 bytes sector 128 Pb.

If you prefer, before the ATA transmitted only partially the data available, now it can trasmit more data than what exists.

Now any *normal* OS manufacturer  would have found a way to extend the MBR scheme finding a way to use some otherwise unused 4*2 bytes *anywhere* in the MBR as "high address" (and BTW also a 40 bit extension, needing only one additional byte per entry would have made accessible 512 Tb that would have been more than enough for several years),  but the good MS guys (strongly pushed by the good Intel guys I believe) decided that it was too d@mn simple and went for the stupid GPT scheme (which is the typical exampe of an overcomplicated scheme  designed by a commission).

Still, there is nothing preventing adding GPT compatibility to an existing OS such as XP, but a number of drivers (and possibly a number of disk related tools need to be rewritten (from scratch since most are not open source).

Most probably the next candidate would be a port of ReactOS drivers, when and if that OS will have GPT support, and by that time most probably it would make more sense to use directly ReactOS instead of XP.

jaclaz

Edited October 16, 2017 by jaclaz

[Mcinwwl]

I bet nuts against matches that we'll sooner see the release of Hurd kernel than complete ReactOS :>

[rloew]

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.

[jaclaz]

9 hours ago, rloew said:

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).

Exactly!

And this will cover also *any* 512n or 512e in any of the USB enclosures that do the "translation" to 4k internally (which is what most pre-made external USB disks larger than 2 Tb already do).

The only "issue" with the Ntive 4K (internal or external) may be bootability,

Still in times when every decent system has anyway a SSD (thus for now and for a long time much smaller than 2.2 Tb and definitely "512e") and the low cost of (bootable) USB sticks it is not at all IMHO a priority of any kind.

jaclaz

 

[rloew]

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.

[dencorso]

4Kn HDDs seem to be the way to go, in the near futures, when no more 512n HDDs are findable. But either a DDO or some contoller with the right BIOS and a reasonable price will have to be found...

[jaclaz]

Yep, but what I meant was that there is no actual *need* to have them bootable, one thing is having them bootable (as a nice thing to have ) and another one is *needing* it.

In the future and for a loong time, we will have SSD's (normally "512e") as main internal disk, and anyway we can use a USB stick as "boot initiator".

What has to be tested (I haven't) is whether the "mini-DOS-ike" OS inside NTLDR is  compatible with 4K sector disk drives, that could be a show stopper.

And again the solution (if needed) might come from ReactOS, there were a few years ago the usual undocumented or terribly documented or misdocumented reports that the FreeLDR could also boot Server 2003. If there is even a minimum of truth in those, the steps to make it work for XP (and on 4K) should really be minimal.

jaclaz

[dencorso]

The NTLDR, since it's almost monolithic, is probably the single piece of NT-5.x OSes easiest to reverse-analyse and patch. NTDETECT.COM is the next one in complexity. Thenceforward things get thougher, IMO.

[98SE]

On 10/16/2017 at 3:35 PM, jaclaz said:

An LBA entry in the MBR (or in a EMBR) is made of two fields, each 32 bit in size:

1) "Start Address" or "Sectors Before" i.e. how many sectors are BEFORE the beginning of the partition described in the entry
2) "Size" or "Sectors in partition". i.e. how many sectors (starting from the address in the field above) are contained in the partition.

So at the very most you can have is:

1) One entry where the "Start Address"+"Size"<2^32-1 (this can be also multiple partitions as long as the sum of the last "Start Address"+"Size" remains within the 2^32-1 limit.

 2) Given that the #1 is actually <2^32-1 ONLY a single primary partition with a maximum extent of 2^32-1 sectors.

If you prefer, you can have one (and only one) partition crossing the 2^32-1 "border".

Since you need some "hidden sectors" before the first partition (at the very minimum 1, the MBR), the most you can have theoretically is:

Entry #1 -> "Start Address" = 1 and "Size"= (2^32-1-1)=4,294,967,294 these will be in hex respectively 0x00000001 and 0xFFFFFFFE and 0x00000001+0xFFFFFFFE=0xFFFFFFFF=4,294,967,295, i.e. (2^32-1)

Entry #2 -> "Start Address" =(2^32-1)=4,294,967,295 "and "Size"=4,294,967,295 these will be both in hex 0xFFFFFFFF

In practice you need to align the partitions using more "hidden sectors" which are typically 63 (traditional value, aligned to disk geometry)  or 2048 (new value since Vista, aligned to 4Kb, actually more than advised, strongly suggested on 512e disks) so you can have at the most:

Entry #1 -> "Start Address" = 2048 and "Size"= (2^32-1-2048-7)=4,294,965,240 (i.e. a number divisible by 8), these will be in hex respectively 0x00000800 and 0xFFFFF7F8 and 0x00000800+0xFFFFF7F8=0xFFFFFFF8=4,294,967,288 (<4,294,967,295)

Entry #2 -> "Start Address" =4,294,967,288 "and "Size"=4,294,967,295 these will be in hex respectively 0xFFFFFFF8 and 0xFFFFFFFF

There  is simply no more address space to write bigger numbers.

The 128 Gb limit you mention is an altogether different issue.

The LBA data in the MBR has always been 32 bit in size, but the actual hard disk standards (ATA) had only 28 bit resolution (early drivers , i,e, 2k until Service Pack 3 if I remember correctly and XP until SP1 followed the standard) with ATA 6 the resolution was increased to 48 bit (i.e. more than the amount that can be stored in the physical space available in the MBR).

The 48 bit in itself allows accessing 2^48-1=281,474,976,710,655 sectors, i.e., with "normal" 512 bytes sector 128 Pb.

If you prefer, before the ATA transmitted only partially the data available, now it can trasmit more data than what exists.

Now any *normal* OS manufacturer  would have found a way to extend the MBR scheme finding a way to use some otherwise unused 4*2 bytes *anywhere* in the MBR as "high address" (and BTW also a 40 bit extension, needing only one additional byte per entry would have made accessible 512 Tb that would have been more than enough for several years),  but the good MS guys (strongly pushed by the good Intel guys I believe) decided that it was too d@mn simple and went for the stupid GPT scheme (which is the typical exampe of an overcomplicated scheme  designed by a commission).

jaclaz

So in your EMBR tests you concluded 4.4TB would be the highest maximum capacity possible as spanning only one partition allowed before the 2.2TB limit?  Would this JTEMBR scheme have any corruption issues if both partitions created were FAT32 and accessed under 98SE DOS for reading or writing (Example: writing data in FAT32 Partition 2 (Above the 2.2TB) region.  Would data corruption occur on Partition 1?

Was there a way to seamlessly bridge the two partitions to be identified one entire partition?

Any impact on data corruption when reading/writing on FAT32 or NTFS in the 2nd partition region exceeding the 2.2TB barrier with XP SP1 or other compliant > 128GB OS support.
 

Quote

 

Still, there is nothing preventing adding GPT compatibility to an existing OS such as XP, but a number of drivers (and possibly a number of disk related tools need to be rewritten (from scratch since most are not open source).

Most probably the next candidate would be a port of ReactOS drivers, when and if that OS will have GPT support, and by that time most probably it would make more sense to use directly ReactOS instead of XP.

 

Hence GPT support for internal and external drives would be the best path forward for older Operating Systems with only native MBR support.

I think the death of XP will be related to the SATA controller.  If compatibility is broken that will be the death of XP on most builds.  For example if a switch to entirely new storage controller with no SATA backward compatibility.  However a work around would be internal PCIe SATA cards.

ReactOS will only succeed in replacing XP 32-bit if it has full XP 32-bit compatibility including DX9, Window 7 64-Bit compatibility including DX 10-11.1 support and if possible DX 12.0.  Otherwise it will be relegated to being another Linux flavor with GPT support if Windows compatibility is just for non graphics/non gaming and only office related software.  XP Pro 64-Bit would already do the same thing and have DX10 support.

 

On 10/16/2017 at 9:59 PM, rloew said:

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.

This software would be the best alternative but you'd have to write the drivers to be loaded for DOS, 9X,ME,NT,2K,XP if the goal was permanent usage.  Currently my hardware version should work on these older OS without needing these drivers but I haven't tested to see how 8TB via USB is detected except on XP.

I have doubts of needing to bring in your EMBR because if that were chosen and brought to another system it would not be able to read it.  GPT support read/write support seems to be best path forward for XP and older Operating Systems down to 98SE DOS.

 

11 hours ago, jaclaz said:

Exactly!

And this will cover also *any* 512n or 512e in any of the USB enclosures that do the "translation" to 4k internally (which is what most pre-made external USB disks larger than 2 Tb already do).

The only "issue" with the Ntive 4K (internal or external) may be bootability,

Still in times when every decent system has anyway a SSD (thus for now and for a long time much smaller than 2.2 Tb and definitely "512e") and the low cost of (bootable) USB sticks it is not at all IMHO a priority of any kind.

jaclaz

 

Well to be more precise even 2TB up to 5TB had these special USB SATA bridge adapters.  I'm not sure why the 2TB model had it as it could have been used internally.  Perhaps the drive was 4K and not usable in XP directly.  All 6TB models are guaranteed to be GPT without the bridge adapter as they dropped these.

I agree with the "bootability" issue.  I see large drives 2.2TB+ to be data drives not requiring it to be a bootable drive.  Though the preference would be for bootable SSDs for a primary drive and not a USB stick if used in conjunction with a large GPT drive.

 

9 hours ago, jaclaz said:

Yep, but what I meant was that there is no actual *need* to have them bootable, one thing is having them bootable (as a nice thing to have ) and another one is *needing* it.

In the future and for a loong time, we will have SSD's (normally "512e") as main internal disk, and anyway we can use a USB stick as "boot initiator".

What has to be tested (I haven't) is whether the "mini-DOS-ike" OS inside NTLDR is  compatible with 4K sector disk drives, that could be a show stopper.

And again the solution (if needed) might come from ReactOS, there were a few years ago the usual undocumented or terribly documented or misdocumented reports that the FreeLDR could also boot Server 2003. If there is even a minimum of truth in those, the steps to make it work for XP (and on 4K) should really be minimal.

jaclaz

Exactly.  But so far USB sticks natively (without some modifications) cannot be used to boot into XP 32-bit.  98SE seems to be the exception which could mean any DOS based are fine booting into the OS on these.  NT 3.X/4.X and 2000 may have the same issue as XP.

 

10 hours ago, dencorso said:

4Kn HDDs seem to be the way to go, in the near futures, when no more 512n HDDs are findable. But either a DDO or some contoller with the right BIOS and a reasonable price will have to be found...

512n HDDs will exist for a long time as long as laptop hard drives will be 2TB and less capacity.  Then replaced by SSD but you can find alternatives which will keep to this.  Such a DDO or controller might come around on eBay.  If I were to send the USB SATA translation bridge adapter to one of these sellers for them to reverse engineer and replicate we could see these adapted for laptop USB powered hard drives for over 2.2TB.  Currently these adapters are only for 3.5" drives and require an external power source making it not ideal.  But we all know China probably made this adapters and could leak them out on their own.  Later when 8KB and larger sector drives become available (hoping for 64KB sector drives) then you will see 256TB MBR partitions possible in Windows XP.

 

8 hours ago, dencorso said:

The NTLDR, since it's almost monolithic, is probably the single piece of NT-5.x OSes easiest to reverse-analyse and patch. NTDETECT.COM is the next one in complexity. Thenceforward things get thougher, IMO.

It would seem this might easier to analyze it then the one in 2001: A Space Odyssey.

After booting into 98SE DOS at the command line could you boot into XP from the command line or call up the NTLDR without rebooting?

Edited October 17, 2017 by 98SE

[rloew]

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.

[jaclaz]

13 hours ago, 98SE said:

Exactly.  But so far USB sticks natively (without some modifications) cannot be used to boot into XP 32-bit.

Sure , we only do that since 2006 (and no, USB sticks are not modified, modified ones (having the "Fixed" bit set) have an advantage but it is not at all a requirement.

 

13 hours ago, 98SE said:

Any impact on data corruption when reading/writing on FAT32 or NTFS in the 2nd partition region exceeding the 2.2TB barrier with XP SP1 or other compliant > 128GB OS support.

I will try to write this again, this time slowly, noone in his/her right mind would even think of making a FAT32 volume bigger than - say - 128 or maybe 256 Gb in size when/where NTFS is supported, it simply makes no sense whatever (and much smaller filesystems are actually advised) since you can have only one volume past (actually crossing) the 2.2 Tb border and at the most 2.2 Tb in size, the scheme may only be good for 3 Tb and 4 Tb disks, thus the second partition will be either around 800 Gb or 1800 Gb, sizes simply NOT suited for FAT32, It would be - provided that it works - very likely slow as molasses.

And no, no foreseeable issue with NTFS, as I have written maybe 10 times already, and that you insist on ignoring, but unless the setup is actually tested there is NO way whatsoever to know if anything in *something else* (apart the NTFS filesystem per se) might create issues.

Tripredacus managed to test the setup on Windows 7 32 bit succcessfully so we know that the whole related driver stack is OK with 7 (which is normal, since Windows 7 32 bit already supports GPT and as such volumes beyond or crossing  the 2.2 Tb limit), but it is entirely possible that the XP implementation of the corresponding drivers has some limit, but it is improbable, because there is no difference in "where" the volume is, once the volume/filesystem driver are hooked, it is more likely that something in PartMgr.sys (besides the actual bus driver) may create problems.

Since the Server 2003 does have (in Service Pack 1 if I remember correctly) GPT support, it goes without saying that its driver stack supports - just like Windows 7 - those addresses, so it may be needed to do - if possible - some file transplant from 2003, though - if I recall correctly - the architecture for storage in Server 2003 is partially different from XP. 

 

13 hours ago, 98SE said:

 

After booting into 98SE DOS at the command line could you boot into XP from the command line or call up the NTLDR without rebooting?

Sure, via grub.exe of grub4dos, as an example.

jaclaz

 

[98SE]

On 10/17/2017 at 3:40 PM, rloew said:

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.

From my perspective it only makes sense to maintain the standard MBR profile but add GPT support to older OSs that I previously mentioned prior XP 32-bit to DOS.  But it's really a suggestion.  I can't see anyone really wanting to use an EMBR if it involves needing to patch their OS in some manner and can't be read on other computers without the drivers required installed.  And let's assume they purchased your EMBR license would this be restricted to the user only?  Unless you are offering a free version of the read access only (not write) driver for all to download otherwise the data would be inaccessible except to the license users.

Now adding GPT access (read/write) has forward compatibility built in so anyone using DOS to XP 32-bit could then read/write to GPT drives and if they were to bring their drive to another person's computer who had XP Pro 64-Bit, Vista or higher OS they would be able to read the GPT drive without needing a new driver.  That was the entire point I was hoping was made clear.

Nothing against your own EMBR but compatibility and accessibility are tied together and adoption as well.  Even if a DOS 256TB technique was created and offered free to all it's still hard to gauge how many people would use it.  Despite my resistance to GPT I now find it is the only sustainable compatibility path forward.

That's why if 4.4TB JTEMBR worked and could be used on any OS then that would be something people could adopt as it would not require any kind of OS patching since the patching is on the drive itself.

 

Edited October 19, 2017 by 98SE