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

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

Share this post


Link to post
Share on other sites

13 hours ago, jaclaz said:

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.

Yes the Fixed bit is just one issue. But USB sticks cannot boot into XP just 98SE.  Now a SSD (with XP previously installed and working) connected to a USB adapter still can't boot into XP in this manner so you have to connect directly to the SATA controller.  I'll have to do a few more tests to confirm.  I think it requires some sort of patching to the OS to boot XP off a SATA to USB adapter.  Just from memory I believe it either resets the computer after attempting to load into XP or it shows a BSOD error.

 

Quote

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.

I hope you were making a joke here? :unsure:

If you weren't Wow you really haven't been keeping up with hard drive technology over the years.

I'll refresh your memory on the USA side in case in Italy things differed.

Starting with 40GB to 500GB USB powered external hard drives were common to be FAT32 for instant usage.  Yes a 500GB FAT32 drive came standard out of the box ready to go.  HD videos had not yet required NTFS since most SD videos were about 1GB per hour.  Once HD videos started happening in 2007 hitting 4GB files were common place for anything over 30 mins in length.  For awhile I was struggling with 1TB hard drives which Seagate also released in FAT32.  So as a result I began manually stopping recording at near half hour increments because once you crossed over the 4GB file size it would not record any more to the file and in some cases could corrupt the video file entirely.  This was the SD vs HD headache and the battle between FAT32 vs NTFS adoption.

Here's a link that someone commented that also confirms 1TB came as FAT32.

https://www.techsupportalert.com/freeware-forum/general-computer-support/11174-external-hard-drive-fat-or-ntfs-format.html

 

Then came the 1.5TB hard drives but I held out as long as possible for 2.0TB hard drives and BOTH these drives shifted to NTFS by default but this also caused problems for MAC users so they even sold specific MAC versions in FAT32 for cross platform compatibility.

You also have to remember DVDs could be ripped and they came in 1GB VOB file chunks max even though most were around 8GB max in capacity for the entire disc.  They were intentionally split in this manner because FAT32 was the norm then.

I think it took awhile before I finally before I became a full NTFS adopter.  Most 1.5TB and larger drives had already standardized NTFS out of the box and again HD recordings ran over 4GB in file sizes for anything over 30 minutes in length and the HD transition had solidified.

 

Quote

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.

Well to trust something one must overwrite the entire 2nd > 2.2TB partition region 100% full and inspect if any corruption occurred in Partition 1 Region below 2.2TB.  I would actually do to 4 tests just for thoroughness.

FAT32 Part1 (2.2), FAT32 Part2 (>2.2 to 4.4)

NTFS Part1 (2.2), NTFS Part2 (>2.2 to 4.4)

FAT32 Part1 (2.2), NTFS Part2 (>2.2 to 4.4)

NTFS Part1 (2.2), FAT32 Part2 (>2.2 to 4.4)

Although even if the Math looks good I still go the extra mile to test integrity and for any chance of corruption not accounted.

How it handles FAT32 files > 4GB file size limit if left recording non stop will the final write byte when stopped cause a strange corruption of either Partition.  Doing the same filling up to the last byte on each partition.

There are probably more tests I could think of or repeatedly copying video files onto both partitions 10 cycles to look for anyone sign of data corruption before completely trusting it for serious storage.

 

Now I did ask if there was a way to seamlessly combine the two partitions to act as one but it sounds like this isn't possible and two partitions and two drive letters must be exhausted and 4.4TB is the maximum capacity possible for EMBR without using special drivers.

 

Lastly did you document what program or tools and simplified the process so it can be repeated and tested by others with ease?  Probably both a 98SE DOS command line program method and a XP method of repeating the process for further integrity testing.

Quote

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. 

https://en.wikipedia.org/wiki/GUID_Partition_Table#Windows:_64-bit_versions

64-Bit OS that had GPT support

Windows XP Professional x64 Edition 2005-04-25

Windows Server 2003 x64 Edition 2005-04-25

Windows Server 2003 x64 Itanium Edition 2005-04-25 - First one with GPT boot support

Windows Vista 64-Bit 2006-07-22 - First one with GPT boot support

 

32-Bit OS that had GPT support

Windows Server 2003 32-Bit SP1, 2005-03-30

Windows Vista 32-Bit SP0 2006-07-22

Windows 8 32-Bit 2012-08-01 - First one with GPT boot support

 

If you examine the dates Windows 2K3 32-Bit needed SP1 for GPT support, but XP Pro 64-Bit and 2K3 64-Bit both had GPT support built in from the start.  Now it would be worth looking at the Vista 64-Bit edition since it supported both GPT and boot capability as the standard and any previous version of GPT support could be different in some fashion or not finalized.

Windows 8 32-Bit also had this this support reverse engineering this code might be more adaptable to Windows XP 32-Bit.

 

Quote

 

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

jaclaz

 

The normal Windows method calls the XP Boot Loader Menu which can then select XP, 2K, or Older OS like ME or 98SE.

I'm referring to booting into 98SE Real DOS.  At the command line (in 98SE Real DOS) could you boot into XP or call up the NTLDR or XP Boot Loader Menu without rebooting the computer first and not using Grub4DOS?

 

Share this post


Link to post
Share on other sites
4 hours ago, rloew said:

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.

I would probably recommend you don't combine the products.  I'd rather have clean code keeping to GPT legacy OS support only.  Any possible EMBR could pose some compatibility or corruption issue unforseen and add to the cost or time.  GPT is considered the new standard and it would better to keep it simple.  Now you could offer it as a FREE separate package included with the GPT driver purchase that the user could choose to install on their own if they chose.  Now if you are clever enough to find better ways to implement or expand the GPT standard beyond the 256TB Windows barrier safely I'd recommend you sell or license this to MS so they could add it into their next OS or service pack.  The earlier the better the adoption can happen as 256TB could be around the next decade.

Yes I understand you could add your special "EMBR" but most would probably refrain from using it if they intended the data to be distributed and accessed easily by others without your driver.  But a global free (read) driver only for your EMBR would be useful for adoption purposes if you wish to retain as much income for the licensed EMBR write access.

Think of when PKZIP was first released.  It was the PKUNZIP program that was free so they could decompress the files without needing a license.  This is what benefited its adoption.  Had PKZIP been stringent and didn't offer PKUNZIP freely I think the amount of users and adoption of it for BBSs would have been low and wouldn't have spreaded to the internet ubiquitously.  As you can see even XP came with a ZIP decompressor built so it made opening zip files and accepting ZIP even on Windows a non issue.  I guess a similar program could be Adobe Acrobat since AA Reader is offered freely.

Quote

A "Read Only" Version would actually be more complicated that Read/Write.

I understand this may be enough to dissuade you from doing a stand alone "Read Only" which is why a GPT read/write driver for XP and older OS on internal and external drives is the only forward compatible useful solution and probably the only guaranteed licensed product I could think would be as far as income.  The Paragon driver so far is only internal and limited to XP and not any older OSs so if they are unable or unwilling of doing it someone else with the capability could close in on this niche.  I have no idea how many people still use XP 32-bit all the way back to 98SE DOS in this world but that would be the potential customer pool.  Perhaps analyzing your own customer database could give you an idea if its worth pursuing.

 

Quote

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

Also I'm in agreement here as I forgot to address this since I have used 2TB FAT32 USB external drives it does not in any way effect the read/write speed compared to a 1TB or 500GB.  Now the initial USB plugging in of the drive could take slightly longer before it's fully detected (depending how full it is) and the drive letters are recognized if you have multiple partitions.  If the FAT32 was corrupted or you disconnected during a write transfer then you might trigger the CHKDSK at reboot issue and like all drives with larger and larger capacities it takes longer to finish the CHKDSK scanning the disk and it can't be helped.  Often times hitting the key (within the 10 second countdown) to bypass the CHKDSK at start and manually scanning the drive once inside the OS is faster as you aren't waiting around and can still multitask and do other things while it's scanning.

Edited by 98SE

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
2 hours ago, rloew said:

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.

 

I would just not combine the products (EMBR and GPT Loader).  I understand if you combined both then you wouldn't need a separate patch.  I just think it's highly unlikely the EMBR is going to be that popular a product and adding it as a separate Freebie purchase with the GPT Loader so the user could choose to install it or not would be preferable.  Personally I don't see myself using an EMBR unless it could be used without modifying any OS which is what the JT EMBR was trying to do and I wouldn't want it combined with my GPT Loader program but want to install it separately if I needed it.  I understand your hesitance in releasing a "read" only EMBR driver due to reverse engineering and cracking of it might be possible and you want to protect your work but I still doubt it would be something people needed or wanted badly enough to pirate.  Perhaps if you had come out with this 20 years ago and got it put into 98SE this could have become a new standard today.  That time is long gone.

The GPT Loader for legacy OSs is something I see that could have potential monetary value.  MBR is pretty much dead imo except through USB which will cap around 17.6TB or 18.0TB drives.  Either you learn how to reverse engineer those 4K adapters and sell them as SATA to SATA 4KB-64KB to 512 Byte adapters so any SATA drive can use them and internally or if you can crack that 256TB GPT Windows barrier safely I would get that licensed to MS to gain better adoption.  It's still early enough GPT isn't fully adopted by all and still in its infancy.  You would still have rights for Linux and MAC OS distribution and if Windows adopts your GPT method you will milk more clients.  This is where I see you could make money for your business.

 

https://en.wikipedia.org/wiki/Logical_block_addressing

LBA48 shows a limit of

128PB=128,000TB (about 16,000 times the common 8TB drive)

256TB Max for Windows which is about 1 / 500th.

 

Compared to history the 5MB MFM hard drive to 8TB SATA today took about 16 years to increase 1,600,000 the capacity.

Finding a way to patch the 256TB GPT barrier to reach 128PB would be the new holy grail in capacity for GPT.  You figure this puzzle out and license it to MS and it gets adopted and it will be used beyond your lifetime most likely.

I'm not sure if 128PB will be as large as we think it is today when we start hitting that limit.  Maybe by then they would have started using LBA64.

 

Edited by 98SE

Share this post


Link to post
Share on other sites

@rloew can you impliment lba48 on xp for free?

Share this post


Link to post
Share on other sites
7 hours ago, 98SE said:

Yes the Fixed bit is just one issue. But USB sticks cannot boot into XP just 98SE.

Again (last time) anyone else (but you) have been capable of booting Windows XP from "normal" USB sticks since the original work by Dietmar came out, in 2006.

You simply cannot negate more than ten years of evidence and of all the world experience, and insist of spreading this kind of misinformation.

Here is where it all started via Wayback Machine (911CD is dead):

https://web.archive.org/web/20160523171220/http://www.911cd.net/forums//index.php?showtopic=14181

 

There are however several different ways, later developed.

 

7 hours ago, 98SE said:

The normal Windows method calls the XP Boot Loader Menu which can then select XP, 2K, or Older OS like ME or 98SE.

I'm referring to booting into 98SE Real DOS.  At the command line (in 98SE Real DOS) could you boot into XP or call up the NTLDR or XP Boot Loader Menu without rebooting the computer first and not using Grub4DOS?

 

You cannot invent your own limitations (if a suited tool is grub4dos' grub.exe, why would you not use it?),

Why you keep asking questions on  things you evidently haven't studied or tested and have not experience with BUT refuse to accept the answers?

It is tiring. :(

The "normal" method of booting a XP is:

BIOS->MBR->PBR of active partition invoking NTLDR->NTLDR->Choices in BOOT.INI->XP (if you chose the XP entry in BOOT.INI)

The "normal" method of booting a DOS/9x is:
 BIOS->MBR->PBR of active partition invoking IO.SYS->IO.SYS (aka DOS)

The "normal" method of booting a DOS/9x  when in dual boot with XP is:

BIOS->MBR->PBR of active partition invoking NTLDR->NTLDR->Choices in BOOT.INI->DOS/9x (if you chose the DOS/9x entry in BOOT.INI which actually chainloads a copy of the PBR invoking IO.SYS)

What you can do is:

1) Boot to 98SE DOS.

2) Run GRUB.EXE.

3) Chainload NTLDR.

4) Choose an entry in BOOT.INI

5) If you chose the XP entry, you boot into XP.

6) NO reboot was performed.

jaclaz

Share this post


Link to post
Share on other sites
12 hours ago, 98SE said:

64-Bit OS that had GPT support

Windows Vista 64-Bit 2006-07-22 - First one with GPT boot support

 

This was added in SP1, not RTM.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@rloew are you sure partmgr in server 2003 is responsible for 2tb up support? 

Share this post


Link to post
Share on other sites
4 minutes ago, Dibya said:

@rloew are you sure partmgr in server 2003 is responsible for 2tb up support? 

I don't know, but it is one of a few files that cannot be substituted into XP.

Share this post


Link to post
Share on other sites
22 minutes ago, rloew said:

I don't know, but it is one of a few files that cannot be substituted into XP.

Any chance to have list of such files?

Share this post


Link to post
Share on other sites

I didn't keep a list.

I remember PARTMGR.SYS, DMIO.SYS, and FTDISK.SYS

Share this post


Link to post
Share on other sites
16 hours ago, Dibya said:

@rloew are you sure partmgr in server 2003 is responsible for 2tb up support? 

Dibya take a look at W8 32-bit for GPT boot support.

19 hours ago, Tripredacus said:

This was added in SP1, not RTM.

Thanks for clearing that as the wiki could be updated with this information.  I usually use only SP2 but don't use GPT to boot in any of my systems but the W8 32-bit would be the one to reverse engineer in making XP 32-bit GPT boot compatible.

 

Although Microsoft themselves seem to state otherwise not mentioning the SP:

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

 

Quote

 

Can Windows 7, Windows Vista, and Windows Server 2008 read, write, and boot from GPT disks?

Yes, all versions can use GPT partitioned disks for data.

Booting is only supported for 64-bit editions on UEFI-based systems.

 

 

 

16 hours ago, rloew said:

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?

This is what I also thought shouldn't be done and by preventing this EMBR/GPT Loader then there is no chance of infecting the user with this hybrid EMBR/GPT scheme.  Leave the GPT structure intact and don't contaminate it with the EMBR structure which is why if you really wanted to release the EMBR make it a separate package so the user can decide.

Unless you found a way to hide the EMBR structure where it doesn't affect the GPT structure but I think haven't the choice to use a pure GPT Loader vs a Hybrid or EMBR should be left to the customer.

I wasn't self contradicting as I personally don't think you should market it or sell EMBR and in fact I think it should be put away.  But since you had spent "X number of hours" and constantly kept bringing up your EMBR I felt you didn't want to abandon it and it would be unkind to not package it for free to test the waters as you never know I could be wrong but I'm as hardcore about legacy OSs as anyone else you'd find.  If you are selling the GPT Loader and including the EMBR package for free then if you somehow gain some fans of it as a side effect then that's a win for you.  You don't have to include it if you don't want to as it was just a suggestion as I really don't think a proprietary EMBR will be adopted today so you could just sell this EMBR as a stand alone driver and compare the sales results over time.

You had stated you needed to create a EMBR driver for the OS the user was using to access the data and if someone didn't buy a license they would not be able to read/write to this drive and your fears of even making a read only driver could be pirated so there was a significant personal investment.  The other issue is are you offering this EMBR license each possible OS (DOS, 3.X, NT, 9X/ME, 2K, XP, Vista, W7, W8.X, W10) version for that user?  If a Windows 10+ is released in the distant feature will you then again create this new OS driver for free to grandfathered licensed EMBR users?  This creates more work for you to keep supporting a proprietary EMBR which probably GPT would crush.  If you're only making say this EMBR driver and licensed to just one OS for that user I can't imagine anyone using this long term should they hook this drive to Vista or W7 or W10 and can't read the data unless they bought another EMBR license for another OS.

This is why I proposed just sticking to a pure GPT read/write loader for XP 32-bit down to DOS support is the better path forward.  Any newer OS Vista and up would take care of GPT on its own and since it's the the forward compatible path for massive data storage this is a win win scenario for your time invested.  You either gain more legacy OS users over time or new users wanting to use their GPT drives on an older OS now find a reason to buy your GPT loader.  We are looking at pretty limited amount of OSs to support for a GPT Loader (DOS, NT 3.X/4. 9X/ME, 2K/XP 32-bit) where support EMBR you're looking at those plus Vista-W10 and any other possible newer Windows if MS changes their mind and makes W11+.

 

Quote

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.

20 years may have been a unfair time line but most people find a way to get their product into the next OS years before it releases.  Figuring you had been doing this for so long you could have had something good to license even then.  But my point was it's not too late to either redesign something better than NTFS (if that's possible) since it's NTFS that seems to limit itself to 256TB in Windows.  You've been studying and creating your own partition tools you probably have the knowledge to define a better standard or improve NTFS or exFAT to supersede the 256TB limitation.

Quote

 

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.

 

Perhaps if you can disassemble and reverse engineer this yourself you can adapt and make 4KB-64KB -> 512 Byte Translation Bridges.  Hardware beats Software in this case for adapters.  No need for any special XP EMBR driver to use it as long as you have the appropriate Bridge Adapters.  If your EE background is enough so you can self fabricate these boards so they are USB powered SATA adapters you could make some real money on eBay/Amazon.  The best is a SATA to SATA Translation Bridge Adapter that way they could be used "internally" or "externally".

If you're convinced MS won't want to deal with you then this hardware device might be a way to keep legacy MBR last beyond 18.0TB.

If Hard drive manufacturers shift jump to 64KB sector drives we can use 256TB MBR drives in XP using this adapter.

Quote

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.

This is nice information regarding the current limits you achieved.  But I assume you have to patch the DOS in some way to access these drivers and you wrote a special driver for Config Sys or CLI loading?

Quote

GPT supports 8ZiB with 512 Byte Sectors so it is not an issue.

Would this increase GPT limit increase to 64ZB on 4KB sector drives?

 

Quote

I have a slightly modified DOS that preserves the pre-boot environment. It can boot anything from a DOS Prompt.

Can this be modified into a Config Sys driver instead?  What is this program called or is this an experimental program you didn't release?

 

Quote

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

It astounds me they still capped the bits instead of taking full advantage of it.  We'll probably need to skip to LBA64 and not bother hitting the LBA48 limit.

Any reason why MS would do this except to sell newer Windows versions that finally add the full 48-Bits when we start reaching the capacity limits?  Or was this easier to code and maintain compatibility with 32-Bit OSs?

Now if we switched to LBA64 could 32-Bit OSs still take advantage of the same max capacity as the 64-Bit OSs?

 

 

23 hours ago, jaclaz said:

Again (last time) anyone else (but you) have been capable of booting Windows XP from "normal" USB sticks since the original work by Dietmar came out, in 2006.

You simply cannot negate more than ten years of evidence and of all the world experience, and insist of spreading this kind of misinformation.

Here is where it all started via Wayback Machine (911CD is dead):

https://web.archive.org/web/20160523171220/http://www.911cd.net/forums//index.php?showtopic=14181

 

There are however several different ways, later developed.

 

I appreciate your enthusiasm here.  I'm aware there are XP bootable methods via USB.  But I'm talking about without modification it won't work whereas 98SE can boot via USB without doing anything to the files.

I am enthralled by what that that link presents and your own reflection then of the Dietmar procedure.

https://web.archive.org/web/20160523171220/http://www.911cd.net/forums//index.php?showtopic=14181&view=findpost&p=90545

Replacing the NTDETECT.COM would be the least invasive since it can be done at the DOS level.  The Registry portion would have to be done with the live install unless a DOS XP Registry method or automated method can be done (Something in the Jaclaz banks says yes there is?)  I didn't have a chance but I plan to investigate the older to newer methods you outlined that have occurred and time being the limited resource.  I prefer to keep as close as possible to maintaining full backward compatibility using the basic tools available then to create the bootable disk.  So something that was discovered in 2005/2006 would not pertinent to me then since I was not actively interested then in a bootable XP and not really till 2016 did I have thoughts of this being useful for SkyLake and later where it can tap into 64GB of RAM and once the Intel xHCI driver issue can be resolved this would be a useful tool.  I had been using a P4 till around 2011/2012 so the onboard RAM then was limited to 2GB and no way would I have thought of using a underpowered single core CPU for this.  Even a USB bootable 98SE is quite slow and nearly unbearable.  I can't imagine how booting XP off USB on this dinosaur would have been worth the trouble.

 

Quote

 

You cannot invent your own limitations (if a suited tool is grub4dos' grub.exe, why would you not use it?),

Why you keep asking questions on  things you evidently haven't studied or tested and have not experience with BUT refuse to accept the answers?

It is tiring.

The "normal" method of booting a XP is:

BIOS->MBR->PBR of active partition invoking NTLDR->NTLDR->Choices in BOOT.INI->XP (if you chose the XP entry in BOOT.INI)

The "normal" method of booting a DOS/9x is:
 BIOS->MBR->PBR of active partition invoking IO.SYS->IO.SYS (aka DOS)

The "normal" method of booting a DOS/9x  when in dual boot with XP is:

BIOS->MBR->PBR of active partition invoking NTLDR->NTLDR->Choices in BOOT.INI->DOS/9x (if you chose the DOS/9x entry in BOOT.INI which actually chainloads a copy of the PBR invoking IO.SYS)

 

Being a purist I think anything away from DOS / Windows or tampers with the MBR or partition structure you already knew I will not cross at this point.  So if your method can be done using Grub4DOS tools while still in 98SE DOS I will definitely adapt them if it gets to the same goal.  If you can invoke booting to XP from the 98SE DOS command line environment directly that would prove useful for my experiment.

 

Now whether one can create a DOS based RAMDISK that is still persistent and store an XP partition image onto that as the boot source is something maybe you've already tested?

But this method I'm experimenting with would allow using the extra memory for a XP Ramdisk above the 3.2GB region as well creating an XP that runs off a Pure DOS Ramdisk.

Quote

What you can do is:

1) Boot to 98SE DOS.

2) Run GRUB.EXE.

3) Chainload NTLDR.

4) Choose an entry in BOOT.INI

5) If you chose the XP entry, you boot into XP.

6) NO reboot was performed. :w00t:---:w00t:---:w00t:

 

Thanks for this simplistic outline.  So I use GRUB.EXE to call up and boot directly to the XP partition while within the 98SE DOS command line?  If this is correct this is what I wanted.  No modification of the MBR has taken place and it replaces needing the 2K/XP Bootloader menu to boot XP.

 

As an example one of the more basic 98/2K/XP

BOOT.INI

[Boot Loader]
timeout=2
default=multi(0)disk(0)rdisk(0)partition(3)\WINDOWS

[Operating Systems]
multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="Microsoft Windows XP Professional" /NOEXECUTE=OPTIN /FASTDETECT /PAE /3GB

multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Professional" /FASTDETECT /PAE /3GB


C:\="Microsoft Windows 98 Second Edition on C:"

 

Show me what you do with Grub.exe to get the equivalent setup going in 98SE DOS.  What is done in #3 Chainload NTLDR?

Now if you're saying GRUB.EXE just reads the BOOT.INI file directly and just redisplays the same Windows boot menu that would actually be a bonus and work perfectly.

 

Edited by 98SE

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