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

7 hours ago, 98SE said:

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.

 

No, that is not what I said.

The "normal" way of booting XP is having a booting chain that through MBR and PBR code loads NTLDR (that then accesses BOOT.INI).

Grub4dos can chainload NTLDR directly.

Once loaded, NTLDR continues doing what it is designed to do (i.e. load BOOT.INI)

I doubt that the BOOT.INI example you posted is actually working, because if the C;\ corresponds to Windows 98, then its PBR is the one loading IO.SYS, and you have no way to load NTLDR (without using some other third party tool to load it.

So once in grub4dos you can decide to run command lines:

find --set-root /ntldr

chainloader /ntldr

boot

or have a menu.lst with an appropriate entry, like:


title find and load NTLDR of Windows NT/2K/XP\n find and load NTLDR of Windows NT/2K/XP
fallback +1
find --set-root --ignore-floppies --ignore-cd /ntldr
map () (hd0)
map (hd0) ()
map --rehook
find --set-root --ignore-floppies --ignore-cd /ntldr
chainloader /ntldr
savedefault --wait=2

You may want to review:

1) http://www.winimage.com/bootpart.htm

2) http://diddy.boot-land.net/grub4dos/Grub4dos.htm

Then it will be fun to see if you will be able to find a decent (recent) version of grub4dos.

7 hours ago, 98SE said:

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. 

Well, you have a lot of homework to do to get in sync with the last 10 years of developments.

It is OBVIOUS that some modifications are needed in order to have the HAL detect the USB bus and load and start the relevant drivers, if you consider that a switch between real mode and protected mode happens when a NT system is loading.

There is no need to modify the NTDETECT.COM in most cases (in some cases is needed), only a few registry keys  need to be modified, though - and it only depends on specific hardware - a number of "helper" drivers might be needed.

In any case, while you should be aware of ALL the different methods available (and possibly also get familiar with them) nowadays I would go for a RAW image (or Fixed VHD) using either Firadisk or Winvblock, like (circa 2010):

http://reboot.pro/topic/13731-full-universal-xpvhd-run-from-usb-finally-work-for-me-maybe-for-you-too/

and/or (circa 2013):

http://reboot.pro/topic/18657-vhd-xp-compact-make-mini-xp/

jaclaz

Share this post


Link to post
Share on other sites

12 hours ago, 98SE said:

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

Well that link isn't wrong, it just isn't being specific.

https://technet.microsoft.com/en-us/library/hh824898.aspx

Share this post


Link to post
Share on other sites
5 minutes ago, Tripredacus said:

Well that link isn't wrong, it just isn't being specific.

https://technet.microsoft.com/en-us/library/hh824898.aspx

If you want a "wrong" one (just in case), here it is:

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

Quote

GPT Format

Starting with Microsoft Windows 2000, the operating system uses the GPT format for the following types of disks:

bold/italic is mine.

I believe there is a difference between Vista and Vista SP1 however :unsure::

Vista can access GPT disks but cannot be installed to them.

Vista SP1 allows installing to them (on EFI, thus hardware bitwidth locked), .

https://technet.microsoft.com/en-us/library/cc749132(v=ws.10).aspx

Written in plain English, this more or less translates to "we added bootmgr.efi to Vista" :dubbio:

jaclaz

  • Like 1

Share this post


Link to post
Share on other sites

 


 

Quote

 

I doubt that the BOOT.INI example you posted is actually working, because if the C;\ corresponds to Windows 98, then its PBR is the one loading IO.SYS, and you have no way to load NTLDR (without using some other third party tool to load it.

 

Yes the Boot.Ini does work.  It's been that way since the dinosaur years. ;)

Tripredacus Era but not quite Jurassic Period.

What happens is it depends on what you want to do.  You can have 98SE, ME, 2K, and XP all reside on the same partition if that's what you were uncertain about.

Was this what caused you to switch to Grub because you thought Windows couldn't do this?

But in this case you can have C: store the Boot Loader for 98-XP and the OS can be installed to the same partition or to another one.  98-XP don't have to be installed onto the same partition as the boot loader which is why I keep to this method (Although 9X/ME does prefer C:).  A simple USB Floppy / Drive can get me back in and restore the boot loader off an image if it were to be corrupt.

 

The only issue would be for Vista+ could not be included on the same partition as 98 as they require NTFS so this actually won't work unless someone has found a way to install Vista or Windows 7 onto FAT32 directly which is something that made me steer away from installing those OSs aside from the enormous bloat compared to XP.

 

9 hours ago, jaclaz said:

No, that is not what I said.

The "normal" way of booting XP is having a booting chain that through MBR and PBR code loads NTLDR (that then accesses BOOT.INI).

Grub4dos can chainload NTLDR directly.

Once loaded, NTLDR continues doing what it is designed to do (i.e. load BOOT.INI)

So once in grub4dos you can decide to run command lines:


find --set-root /ntldr

chainloader /ntldr

boot

or have a menu.lst with an appropriate entry, like:


title find and load NTLDR of Windows NT/2K/XP\n find and load NTLDR of Windows NT/2K/XP
fallback +1
find --set-root --ignore-floppies --ignore-cd /ntldr
map () (hd0)
map (hd0) ()
map --rehook
find --set-root --ignore-floppies --ignore-cd /ntldr
chainloader /ntldr
savedefault --wait=2

You may want to review:

1) http://www.winimage.com/bootpart.htm

2) http://diddy.boot-land.net/grub4dos/Grub4dos.htm

Then it will be fun to see if you will be able to find a decent (recent) version of grub4dos.

Well, you have a lot of homework to do to get in sync with the last 10 years of developments.

It is OBVIOUS that some modifications are needed in order to have the HAL detect the USB bus and load and start the relevant drivers, if you consider that a switch between real mode and protected mode happens when a NT system is loading.

There is no need to modify the NTDETECT.COM in most cases (in some cases is needed), only a few registry keys  need to be modified, though - and it only depends on specific hardware - a number of "helper" drivers might be needed.

In any case, while you should be aware of ALL the different methods available (and possibly also get familiar with them) nowadays I would go for a RAW image (or Fixed VHD) using either Firadisk or Winvblock, like (circa 2010):

http://reboot.pro/topic/13731-full-universal-xpvhd-run-from-usb-finally-work-for-me-maybe-for-you-too/

and/or (circa 2013):

http://reboot.pro/topic/18657-vhd-xp-compact-make-mini-xp/

jaclaz

I'll dig more into those links once I've exhausted all possible legacy Dinosaur methods.

 

But to outline what I'm trying to accomplish.

 

Stage 1:

98SE DOS boot to the command line.

At the 98SE DOS command line use Grub to launch Windows XP directly (This can be off a partition of the drive so no change and just booting XP like normal)  Basically another way to access the Windows Boot Menu.  If this works I will move onto Stage 2.

 

Stage 2:

Now I had planned to find a way to image the XP partition to a file and then use a DOS Based Ramdrive to store that XP image to boot off.

Now if loading XP off the DOS Ramdrive will this work or will any DOS based Ramdrive just get purged as soon as it's trying to load into XP?

I'm not entirely sure if that's possible under 98SE DOS which is why someone like maybe you would know or have some thoughts if this has, has not, or can't be done?

 

Stage 3:

This is refining the XP image to include access to a Ramdrive above the 3.2GB memory region and later trimming down any unnecessary OS files if 2GB is too large an XP image to boot off a DOS Ramdrive.

 

Share this post


Link to post
Share on other sites

Oh, I see :), you have then a "normal" install of XP after a single DOS/Windows 9x/Me install.

That will re-write the bootsector of the active partition, overwriting the bootsector invoking IO.SYS (or Winboot.sys) with a bootsector invoking NTLDR, then will add to the BOOT.INI an entry pointing to a copy of the previous bootsector, called bootsect.dos.

NTLDR has "embedded" this filename, so the C:\ reference is enough, because it actually resolves to C:\bootsect.dos

http://thestarman.pcministry.com/asm/mbr/bootini.htm

So, yes it works, but only as long as you have a bootsect.dos file in the root of the active primary partition.

Yes, it is very dinosaurish, but as long as it floats your boat it is fine :thumbup, using bootpart since the good ol' NT days, I always used a folder to store the bootsector, forgot what the default was :blushing:.

In any case the traditional (and right) way is to have a (small) primary partition for the boot files (FAT16 if using DOS 6.22, FAT32 otherwise) and then separate partitions for each windows, this is advised since day one by Gilles Vollant, the Author of Bootpart (which at the time, circa 1994/95, was more or less the only way to customize/fix a dual/triple boot system),

Hey, wait, this separation between "boot" and "system" (which the good MS guys have reversed):

http://www.multibooters.co.uk/system.html

 is the same thing that modern OS's use with UEFI. :w00t::ph34r:

As a side note:

1) Vista can be installed to FAT32 just fine (Dietmar at the time posted a way).

2) Windows 7 cannot (actually it can, but it will have a few limitations) JFYI:

http://reboot.pro/topic/19643-winsxs-hardlinked-files/

And now, for no apparent reason, as long as you are on FAT32, you can go here:

http://www.multiboot.ru/files.htm

and find about dostoxp.com and dostowin.com (still grub4dos' grub.exe is a much more flexible solution)

jaclaz

 

P.S.: about stage 2 it won't work, of course (HAL kicking in, switching to protected mode) anything DOS is "lost", and that is exactly the reason why drivers like Firadisk and Winvblock (that can "hook" parameters passed by grub4dos) were developed. 

Edited by jaclaz

Share this post


Link to post
Share on other sites

 

Quote

 

As a side note:

1) Vista can be installed to FAT32 just fine (Dietmar at the time posted a way).

 

2) Windows 7 cannot (actually it can, but it will have a few limitations) JFYI:

http://reboot.pro/topic/19643-winsxs-hardlinked-files/

And now, for no apparent reason, as long as you are on FAT32, you can go here:

http://www.multiboot.ru/files.htm

and find about dostoxp.com and dostowin.com (still grub4dos' grub.exe is a much more flexible solution)

W7 64-bit would be the logical one to install to FAT32 at this point if this is easily done preinstallation.  However there might be some better alternatives that exist which I am looking at in next comment below that allow FAT32 installation while still being quite modern enough for GPT.

 

10 hours ago, jaclaz said:

If you want a "wrong" one (just in case), here it is:

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

bold/italic is mine.

I believe there is a difference between Vista and Vista SP1 however :unsure::

Vista can access GPT disks but cannot be installed to them.

Vista SP1 allows installing to them (on EFI, thus hardware bitwidth locked), .

https://technet.microsoft.com/en-us/library/cc749132(v=ws.10).aspx

Written in plain English, this more or less translates to "we added bootmgr.efi to Vista" :dubbio:

jaclaz

Hmmm, but aside from all this Vista talk wouldn't W8 32-bit be the best choice to reverse engineer GPT and GPT boot capability for XP 32-bit?

GPT storage is the only real need here.  A bootable GPT drive would be icing but I'm not sure if it would be compatible with 98SE to boot.

 

Going forward a better choice might be to use the last 32-bit GPT capable (not GPT boot capable) OS and sticking to MBR for booting.

As for the last OSs with GPT support that can be installed onto FAT32 would this be XP Professional 64-Bit and Windows 2003 Server 32/64-Bit before NTFS became mandatory?

 

5 hours ago, jaclaz said:

Oh, I see :), you have then a "normal" install of XP after a DOS/Windows 9x/Me install.

That will re-write the bootsector of the active partition, overwriting the bootsector invoking IO.SYS (or Winboot.sys) with a bootsector invoking NTLDR, then will add to the BOOT.INI an entry pointing to a copy of the previous bootsector, called bootsect.dos.

NTLDR has "embedded" this filename, so the C:\ reference is enough, because it actually resolves to C:\bootsect.dos

http://thestarman.pcministry.com/asm/mbr/bootini.htm

So, yes it works, but only as long as you have a bootsect.dos file in the root of the active primary partition.

Yes, it is very dinosaurish, but as long as it floats your boat it is fine :thumbup, using bootpart since the good ol' NT days, I always used a folder to store the bootsector, forgot what the default was :blushing:.I

P.S.: about stage 2 it won't work, of course (HAL kicking in, switching to protected mode) anything DOS is "lost", and that is exactly the reason why drivers like Firadisk and Winvblock (that can "hook" parameters passed by grub4dos) were developed. 

Yup it's the dinosaur method but also the reason why it's possible to retain the DOS->Windows 10 boot loader in a very tiny partition of space.  I think it was around 22MB total but I realize now a majority of the space taken are for foreign language files which can be trimmed down in DOS.  The smallest usable of course was the DOS->XP boot loader which won't fit on a floppy and of course DOS is always the tiniest to image.  You can do this dinosaur Windows boot menu to include Vista/W7 which has their own, and then W8.X/W10 I believe share another version but I have been able to revert Windows 10 to show up on the Vista/W7 older Boot Menu so it may be possible to ignore the ugly Windows 10 GUI Boot Menu which adds to the boot time.

 

Ahh so a DOS Ramdisk to store the XP image is no go. ;(

Now it sounds like I'm left with trying some of your other ideas "Firadisk / Winvblock" if DOS Ramdrives can't persist so booting an XP image off of it won't work.

So If I'm using my XP partition stored on the hard drive what's the next step in imaging that partition to something that can be then loaded into the Ramdisk you had in mind?  Are these normal files that can be stored on FAT32 without issue?

 

Quote

In any case the traditional (and right) way is to have a (small) primary partition for the boot files (FAT16 if using DOS 6.22, FAT32 otherwise) and then separate partitions for each windows, this is advised since day one by Gilles Vollant, the Author of Bootpart (which at the time, circa 1994/95, was more or less the only way to customize/fix a dual/triple boot system),

Yes this is the dinosaur way, ;).  What method did you think I've been using this entire time? :)

C: (22MB) or smaller DOS-> W10 stored Windows boot loader essential files / Optional 9X/ME on the same partition or on D:

D:  9X,ME,NT 3.X/4

E: 2K

F: XP / 2003

You can have 2K and XP coexist on the same partition as well just for fun.  Just assign a different Windows folder name.

G: Whatever floats your boat 2K3-W10 partition.  Although due to the large bloat of these Operating Systems I probably would store Vista->W10 on a 2nd hard drive (much larger capacity up to 2TB) into 64GB partitions.

 

Quote

 

Hey, wait, this separation between "boot" and "system" (which the good MS guys have reversed):

http://www.multibooters.co.uk/system.html

 is the same thing that modern OS's use with UEFI.

 

Have they?  Well up to Windows 10 my technique is still working to separate them and yes the Boot Loader portion stays on the Boot Partition.  The OS portion can reside separate from it with the dinosaur method.

In that link they show Vista (only) installed which is on the Entire single partition.  So in this case the Boot Loader and OS are combined on the same partition.  This is the worst method commonly found on prebuilt systems for system recovery.

 

To give you an idea how useful this is for system recovery if a very basic XP system was designed.

 

C: 98SE DOS Boot Partition

D: 98SE DOS Boot Partition Clone

 

E: XP1

F: XP1 Clone

 

If you only have access to a partition cloner but not an imager this method would work to recover either a corrupt Boot Loader or the OS itself is corrupt.

If C: Boot Partition got corrupted somehow which can happen but your XP OS Partition is fine, then Recloning D: to C: you are back on track.  You will need a USB Floppy, Flash, or optical drive depending if the Partition Cloning program is small enough to fit with 98SE DOS.  The DOS based ones are the best and most compact.

 

If the OS is Corrupt which you means you are still able to get to the Windows OS Boot Menu just fine then you just reclone F: over E: and you're back.

 

It's better to use a partition to file imager instead so you don't waste partitions or drive letters but both options save your butt without too much technical knowledge.

 

Technical jargon confusion:
 

Quote

 

You say Tomato

Microsoft calls the partition with the boot files the System partition, and the partition with the operating system the Boot partition. Everyone else refers to them exactly the other way round. The boot files on the boot partition. The operating system on the system partition.

 

In my MS Dinosaur Method,

Only the Primary Partition C: is the only one I call a "Boot Partition" where the necessary Boot Loader and Front end Boot Menu are located.  Once you select the OS any other files it loads on that Operating System Partition I don't call "Boot Files" but technically the Front end Boot Menu is just redirecting to their respective OS Boot Files but I don't make that distinction.  Probably DOS is the only that you can call a pure Boot Partition/Boot Loader combined but I think using the BOOTSECT.DOS it could possibly be placed on another partition.  It's not something I tampered with yet.

The other partitions where each OS system files is installed on their own individual partition I would call those "System Partitions" if the understanding is it means "Operating System" Partitions.

Had this way of MultiBooting DOS/Windows not been possible I think I would be using something like Grub. ;)

 

 

Edited by 98SE

Share this post


Link to post
Share on other sites
Quote

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?

Quote

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.

The EMBR and GPT Structures are completely independent. You can even avoid having a Hybrid MBR by using my Multi-Boot Profile MBR.

A GPT Loader is not necessary, as DOS and Windows 9x would be setup to use the EMBR and other OSes would use the GPT. Each partition would appear in both.

Quote

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.

I already sell my EMBR as part of my TeraByte Plus Package so there is no water to test. The Package provides multiple solutions. 4K Support for translated USB Hard Drives up to 16TiB as well
as untranslated Internal and USB Hard Drives over 2TiB. Without my TeraByte Plus Package you cannot Boot or use 4K USB Drives with DOS or Windows 9x. My RFDISK Multi-Boot Partitioner
has an option to reserve space for a GPT structure so you can build it with a GPT Partitioner.

Quote

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.

I support DOS and Windows 98SE. GPT can be used to access Partitions above 2TiB on other OSes. My EMBR is compatible with standard MBR for Partitions below 2TiB.
At present, mainly 2K and XP users are the ones out in the cold.

Quote

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

A GPT Loader is a separate product I could consider writing. It would still require a MBR Partition for Booting DOS.

Quote

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.

Why would I create a product for a new OS that would not be usable for over a decade and use a standard that had not even been written yet.

Partition tools have nothing to do with FileSystem limitations.

I have no problem exceeding 256TiB.

Quote

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 you have a couple of billion dollars to invest in a foundry, let me know.

Quote

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

That would cause a lot of compatibility issues. 4K is OK because Windows caches 4K blocks internally.

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.

Quote

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?

No. There is no Driver. It is Patched into IO.SYS itself. The Sector remapper, if needed, is in a DDO.

Quote

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

Quote

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

Yes. The same increase applies to the 48-Bit LBA Limit as well. 

Quote

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

Quote

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?

No. The pre-boot information is already lost. The Patch does fit inside IO.SYS. I have not released it. I haven't determined a market for it.

Quote

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?

Don't count on LBA-64 any time soon. It would not improve compatibility with 32-Bit OSes. It would break all current OSes.

Edited by rloew

Share this post


Link to post
Share on other sites

@98SE

As long as an image file is within the 4GB (-1 byte) FAT32 file size limit it can of course reside on a FAT32 volume.

There is no actual need to "reverse engineer" a GPT implementation, the way it works is known, it has official public specifications in the UEFI documentation (consisting in more than 2000 - that is two thousand - pages)  it is writing a replacement (or - as seemingly Paragon did - "parallel" driver) for Partmgr.sys that is the problem.

Scroll down the given page on multibooters, the whole point is that MS call "System" what you (and all the rest of the world) call "boot" and "Boot" what you (and all the rest of the world) would call "system".

 JFYI, those duplicated systems are "copies", not "clones" (as always trying to use same naming conventions).

 

 

jaclaz

 

 

Edited by jaclaz

Share this post


Link to post
Share on other sites

Files larger than 4GiB can be handled on a FAT32 Partition with my large File Emulator on 9x and XP.

Share this post


Link to post
Share on other sites
1 hour ago, rloew said:

Files larger than 4GiB can be handled on a FAT32 Partition with my large File Emulator on 9x and XP.

Not in this case, I believe.

The context is to use a Raw or a VHD disk image to boot a XP (or other NT system), to do this you rely on grub4dos to do the initial mapping and chainloading and to specific (Winvblock or Firadisk) drivers, or - in the case of "native" VHD booting (windows 7 and probably later) on MS original bootloader. (and those will surely throw a fit when attempting to access the file).

Additionally the base idea is to do some kind of ramdisk booting (which implies copying the image to Ram) and that takes time, so, as always, the smaller the image, the faster will be the booting.

In any case, booting a larger than 4 Gb image is "pure folly" :w00t::ph34r:, personally I find already find senselessly bloated some of the images the tools by wimb create (at around 1.2-2.0 Gb), and for a "decent" XP system you can usually stay within the 512 Mb size (which BTW would also allow MS ramdisk booting). 

jaclaz  

Edited by jaclaz

Share this post


Link to post
Share on other sites

 

Quote

Why would I create a product for a new OS that would not be usable for over a decade and use a standard that had not even been written yet.

Maybe I misunderstood the reason why you developed your EMBR.  How many users worldwide do you believe are currently using your EMBR?  When '95 was released did you already have full grasp of your EMBR or could have licensed it to MS back in the day where it might have been adopted sooner?  I believe if your EMBR stood a real chance of full adoption and Windows at the time was dominating the market then I would have gone that route and got your EMBR approved by the 2000 days it would have become the de facto standard.  Some kind of lifetime royalty fee like 1 cent per OS license sold using your EMBR you could have lived forever off those dividends.

 

17 hours ago, rloew said:

The EMBR and GPT Structures are completely independent. You can even avoid having a Hybrid MBR by using my Multi-Boot Profile MBR.

A GPT Loader is not necessary, as DOS and Windows 9x would be setup to use the EMBR and other OSes would use the GPT. Each partition would appear in both.

I already sell my EMBR as part of my TeraByte Plus Package so there is no water to test. The Package provides multiple solutions. 4K Support for translated USB Hard Drives up to 16TiB as well
as untranslated Internal and USB Hard Drives over 2TiB. Without my TeraByte Plus Package you cannot Boot or use 4K USB Drives with DOS or Windows 9x. My RFDISK Multi-Boot Partitioner
has an option to reserve space for a GPT structure so you can build it with a GPT Partitioner.
 

I have no problem exceeding 256TiB.

Have you inquired if MS be interested on a NTFS that supports > 256TB for Windows?  Or can you create your own file system superior to that with the security features intact?

 

Quote

Don't count on LBA-64 any time soon. It would not improve compatibility with 32-Bit OSes. It would break all current OSes.

Can you elaborate how LBA64 would break all current OS support?  What is the reason LBA-48 hasn't caused problems for 32/64 Bit Operating Systems but the jump to LBA-64 would?
 

Quote

 

I support DOS and Windows 98SE. GPT can be used to access Partitions above 2TiB on other OSes. My EMBR is compatible with standard MBR for Partitions below 2TiB.
At present, mainly 2K and XP users are the ones out in the cold.

A GPT Loader is a separate product I could consider writing. It would still require a MBR Partition for Booting DOS.

Partition tools have nothing to do with FileSystem limitations.

 

No plans on GPT booting on my end and probably not in the foreseeable future.

Are you working on a NT 3/4, 2K, or XP GPT Loader yet?

If so how long before you could up with one that supports both internal and external USB drives?  I really think such a tool would be useful to a lot of people now and in the future.  I can't see anyone really using DOS and 9X/ME with GPT drives as most software that would really take advantage of large files are not found on these older OS.  Blu-rays would be one example of 50GB files playable on XP and a GPT external USB drive would be quite a bridge to larger capacities.  I don't think Blu-rays are playable on DOS, 9X/ME since no software was ever created for those OSs.

Would the licensing be per user per OS or per user with as many Operating Systems you would develop support?

People who don't own their license but want to access another user's data who does own your GPT license are they unable to access this data without buying their own license?

I thought that background knowledge might be helpful in lifting those file systems limitations especially for NTFS and exFAT.

 

Quote

If you have a couple of billion dollars to invest in a foundry, let me know.

That would cause a lot of compatibility issues. 4K is OK because Windows caches 4K blocks internally.

No. There is no Driver. It is Patched into IO.SYS itself. The Sector remapper, if needed, is in a DDO.

Yes. The same increase applies to the 48-Bit LBA Limit as well. 

No. The pre-boot information is already lost. The Patch does fit inside IO.SYS. I have not released it. I haven't determined a market for it.

I don't think you need a foundry or you could have some factory in China take care of production.  Are you just a software engineer or do both?  If you do hardware you could modify some SATA controllers with a programmable chip and your translation bridge software that might allow updating to include options for 4KB->64KB sector drive support for when those drives appear.  Or what's wrong with duplicating those already existing hard drive adapters but adding your updated features?  With so many people making adapters and this particular one not exactly sold independently in stores (and also discontinued with hard drives) it would only fit as a product with your legacy support based company.
 

 

6 hours ago, jaclaz said:

Not in this case, I believe.

The context is to use a Raw or a VHD disk image to boot a XP (or other NT system), to do this you rely on grub4dos to do the initial mapping and chainloading and to specific (Winvblock or Firadisk) drivers, or - in the case of "native" VHD booting (windows 7 and probably later) on MS original bootloader. (and those will surely throw a fit when attempting to access the file).

Additionally the base idea is to do some kind of ramdisk booting (which implies copying the image to Ram) and that takes time, so, as always, the smaller the image, the faster will be the booting.

In any case, booting a larger than 4 Gb image is "pure folly" :w00t::ph34r:, personally I find already find senselessly bloated some of the images the tools by wimb create (at around 1.2-2.0 Gb), and for a "decent" XP system you can usually stay within the 512 Mb size (which BTW would also allow MS ramdisk booting). 

jaclaz  

Most of my XP SP3 images are in the 1.5GB range I believe for a fresh install.  Windows 2000 SP4 I believe came out around 700-800MB or much lower since it's been awhile so many of these would be good candidates for this bootable OS on Ramdisk test.  I haven't installed NT 3.X/4.0 in ages since the Pentium 1 but amazingly 98SE and NT 4.0 did allow dual booting when I experimented with it.  NT 4.0 at the time did seem rather stable (Pre Windows 2000 experience) compared to 98SE at the time.  It just lacked a lot of software compatibility so it felt barren.  Windows 2000 was a huge step up.  Here's a curious one.  How about an OS/2 Boot off a Ramdisk?

 

On the topic of the 2TB MBR Barrier I happen to have a 3TB USB bridge adapted drive available that I just unleashed out of the shrinkwrapped box and plan on storing some data on it.  But if either you Jaclaz, Tripredacus, Dencorso, RLloew (unless you already own one?) or other MSFN member who doesn't own one and wants me to run some tests that might be useful for someone to adapt this technology from hardware into a software form for Windows 2000 and XP 32-bit I would be willing to postpone storing vital data on the drive for a few days or longer if the experiments prove more interesting.  Perhaps the MSFN community could benefit from this somehow.

 

Some tools I think might be useful if Jaclaz or others might know of way(s) to:

Image the entire partition layout as it came "unused".  Sort of like a snapshot that can be investigated in more detail.

Capture the entire drive's partition layout to clone exactly the actual used bytes without altering the sequence.

A way to extract/rip/disassemble the 4KB -> 512 Byte Translation adapter firmware/code or whatever makes it tick so people can build their own controller board.

Any other ideas that would be useful in cracking this nut and dissecting it so this can be adapted and possibly added to someone's BIOS so all drives could do this without the adapter which means any OS from DOS -> W10+ would see the entire capacity at least for the time being up to the 18TB theoretical MBR Max.

:D:unsure::dubbio::w00t:

Edited by 98SE

Share this post


Link to post
Share on other sites

I designed the EMBR when 3TB Drives first appeared. In 2000 they still were using LBA-28. No one would have cared about my EMBR then.

I'm sure that Microsoft could easily increase the NTFS limit if they decided to. There may be some tradeoffs to going higher.

LBA-64 would be a new protocol, so it would not be supported by any existing OS. LBA-48 was not supported by Windows 9x or NT below 2K SP4 or XP SP1. LBA-48 preceded 64-Bit OSes.
Hard Drives were usable with older OSes because they maintained the LBA-28 protocol as well.

I'm not working on a GPT Loader at present. I was never even thinking about a GPT Loader for NT or XP. An EMBR + GPT Hard Drive covers nearly all bases.
DOS and Windows 9x users need their own Licenses to Read or Write these Drives, but they can always use newer OSes to access any Data they need.

Large File Support I already have for 9x. I could watch a ripped Blu-Ray Movie if I wanted to on 9x. Actual Blu-Ray Movies Disks use encrypted UDF FileSystems so they need special Software.
I have also added Large File Support to XP for FAT32 Partitions for compatibility.

If you want a 4K Adapter, you can always buy an Enclosure. I think the standalone adapters may work also. 64K isn't going to happen soon, it would cause a lot of problems.

My Sector Mapper can simulate 4K Sectors. This allows me to access the Data on a given 16TiB MBR Disk whether in a Translating USB Enclosure, a non-Translating USB Enclosure or Internally.

I already have 4TB USB Drives and have saved the preinstalled data on them, so I don't need you to test anything.

Share this post


Link to post
Share on other sites

Sorry, but i miss the point of, what is the practical purpose of this tread?

1. The XP supports over 2 Tb volumes very well. I have an XP installation patched to support software Raid 5 and a volume of three 2 Tb HDDs, so about 4 Tb volume. It works like a charm, no problem.

2. There is a way to utilise over 2 Tb drives under XP - the Paragon GPT loader (and some other proprietary solutions from HDD manufacturers). The only thing that may be better here, if someone release a free GPT driver for XP.

3. There is no practically need in booting XP from an over 2 Tb drive. You always can add a bootable SSD drive to any system, including laptops. One of the main benefits of XP is that it isn't as bloated as 7 or 10, so a very small (and cheap) SSD will be enough to install it.

I see no benefit in developing EMBR if it can't be a widely supported technical standard.

Share this post


Link to post
Share on other sites

@Yellow Horror

#1 Sure it does support larger than 2 Tb volumes, only it cannot access them on a single hard disk, simply the MBR scheme doesn't allow that.

#2 Sure there is the GPT loader, but the point (at least mine) was that there is no need to have GPT to access up to nearly 4.4 Tb on a single hard disk, divided in at least two volumes, this approach has been tested and it works on Windows 7 32 bit successfully. Actually there is no need whatever to have any hard disk (internal) larger than 2 Tb on a machine that runs XP, and thanks to the sector size translation present in most external USB enclosures, translated to 4 Kb disks work just fine (for backup, offline storage, etc.).

#3 Sure there isn't any need of that, as a matter of fact that is another of my points, the good MS guys made up all these complications with GPT exactly in a time when noone in his/her right mind would not use a SSD as boot (and thus a smaller than 2.2 Tb device).

Still, sometimes one does things just for the fun of it :), and to learn new, strange things.

 

@98SE

Very likely your USB 3 Tb disk is "controller translated" to 4Kb sectors, so it will simply work (but it won't be bootable), which is exactly what this thread has been started with.

The point of the experiment, since there is no doubt that 4Kb sectors (native or translated) work just fine and then such disks can be as as large as 17.6 Tb, is to have an INTERNAL SATA disk, 512e or 512n be accessible in XP as 2 partitions, the first smaller than 2.2 Tb, the second the rest of the disk.

That (and nothing else) is the experiment *needed*, that Tripredacus performed (and succeeded with Windows 7 32 bit, but that - for some reasons - couldn't be replicated on XP).

jaclaz

 

P.S.: @RLoew, completely OT :w00t: , but JFYI, PC-MOS/386 was recently released as Open Source:

https://github.com/roelandjansen/pcmos386v501

 

 

 

 

Edited by jaclaz

Share this post


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

I designed the EMBR when 3TB Drives first appeared. In 2000 they still were using LBA-28. No one would have cared about my EMBR then.

I'm sure that Microsoft could easily increase the NTFS limit if they decided to. There may be some tradeoffs to going higher.

LBA-64 would be a new protocol, so it would not be supported by any existing OS. LBA-48 was not supported by Windows 9x or NT below 2K SP4 or XP SP1. LBA-48 preceded 64-Bit OSes.
Hard Drives were usable with older OSes because they maintained the LBA-28 protocol as well.

Yes I was thinking something different when you stated that.  LBA64 will be supported by an existing OS if MS or a 3rd party chose to make a patch like yourself.  But shouldn't LBA64 still work fine with all OSs except they would operate at LBA-48 (with existing patches) or at LBA-28 unpatched?

 

Quote

I'm not working on a GPT Loader at present. I was never even thinking about a GPT Loader for NT or XP. An EMBR + GPT Hard Drive covers nearly all bases.

In my opinion this is the future and the GPT Loader to include 2K / XP 32-bit would see more users than DOS/9X/ME combined.  The brunt of the users will probably using the GPT Loader for external USB drives and occasionally internally for faster transfer rates.

Quote

DOS and Windows 9x users need their own Licenses to Read or Write these Drives, but they can always use newer OSes to access any Data they need.

Are you talking about the EMBR drives here?  This was where the concern was if someone used your EMBR on some large drive and went somewhere where the destination system was a standard unlicensed non EMBR system how could they access that data?  Even any GPT capable OS and higher shouldn't understand your EMBR scheme even though they are newer than XP unless I'm missing something here?

Is your EMBR scheme somehow compatible and readable/writeable by GPT capable OSs?  Don't you have to patch each OS that the user intends to read / write the data on the EMBR drive?  If someone bought your EMBR user license and they were originally using 95, and they recently bought a W10 installed machine could they read the EMBR drive and if not are you offering all OSs DOS->W10 EMBR drivers (freely to an original EMBR licensed user) and does that user have to buy an EMBR license for each single Operating System they plan on using.

 

Bottom line: Does their EMBR license cover all Operating Systems DOS->W10 (that you've patched) for that one EMBR license purchase?

 

Quote

Large File Support I already have for 9x. I could watch a ripped Blu-Ray Movie if I wanted to on 9x. Actual Blu-Ray Movies Disks use encrypted UDF FileSystems so they need special Software.

Well maybe you can state what Blu-ray compatible software player you are using on 9X because the only ones that were made were only for XP and later.  Are you reading the original Blu-ray movie disc inside your Blu-ray optical drive?  And what about HDCP and AACS?

The only way I can think of that could play any Blu-ray only as a video file if it were decrypted first and using a standard video player that could read the format.  But have you found a way to add HDCP or get an HDMI video card to work in 9X/ME?  If so what video card as far as I know none existed that had 9X/ME drivers.

 

Quote

I have also added Large File Support to XP for FAT32 Partitions for compatibility.

Can you elaborate on this XP Large File Support for FAT32?  I recall you patched your FAT32 to allow over 4GB file sizes but does every OS the user intends to use need to use your patch first in order to "read" the drive (not write) to it.  When moving such a FAT32 partition that has over 4GB file sizes can Vista or later read these FAT32 over 4GB file sizes or does do you have to patch the Vista or later OS understand it?  For example will Vista read only the first 4GB-1 byte portion of the file and just stop there?  What happens when you write to a FAT32 partition that you've allowed > 4GB file sizes?  Does it corrupt the partition because Vista doesn't understand it or can Vista write larger than 4GB file sizes on your specialized FAT32 partition without needing a special driver patch from you?

Quote

If you want a 4K Adapter, you can always buy an Enclosure. I think the standalone adapters may work also. 64K isn't going to happen soon, it would cause a lot of problems.

What kind of problems are you referring to for 64KB adapters?  Let's assume WD, Seagate, Hitachi have released 64KB sector drives and abandoned all 4KB sector drives today and we now have 64KB -> 512 Byte adapters.  Explain why these wouldn't work with XP 32-bit or later OS with the MBR scheme.  If all the OS sees everything as 512 Bytes I don't see why this would cause any issue with any OS the same with the 4KB -> 512 Byte adapters are already doing with 4KB sector drives.
 

Quote

My Sector Mapper can simulate 4K Sectors. This allows me to access the Data on a given 16TiB MBR Disk whether in a Translating USB Enclosure, a non-Translating USB Enclosure or Internally.

Now this might be useful but you still have to prepatch every OS before an existing (4KB->512 Byte) USB drive's data could be read directly connected to the SATA controller.

Quote

I already have 4TB USB Drives and have saved the preinstalled data on them, so I don't need you to test anything.

If you already own several 4TB USB drives that use the (4KB->512 Byte) adapter do you know enough about BIOS modding to add this code directly to detect the drive so that any SATA controllers can natively interact with them (making them OS patch free)?

 

When studying how the original (4K->512 Byte) adapter vs the scheme you came up with did you find any differences in the way they interacted with the drive and your SectorMapper.  If you've been writing tons of data using this adapter and the user would then try your SectorMapper to read/write to the SATA drive directly not using the 4KB->512 Byte adapter will there be any chance of corruption or misalignment?

The only way I can see using a software version of this adapter if it operates exactly the same in code as the hardware.  Otherwise you'd have to use your own SectorMapper from the beginning on an empty drive.  And what happens if you filled the 17.6TB of information using your SectorMapper then decided to connect this externally using the 4KB-512 Byte adaptor via USB.  Any chance that using the 4KB->512 Byte adapter would be slightly different interpreting your SectorMapper written data and possibly corrupt the data on it when writing on this drive?

Bottom line:  Would flip flopping using your SectorMapping to write the data and then repurposing it back to the USB enclosure with the 4KB->512 Byte continuously on a constant daily basis have any deleterious effect you haven't anticipated?

Would you go as far as trusting it enough that if your own family's life were on the line that there's no chance a single bit of data would be corrupted?

 

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