rloew

SSDs should be 512 Bytes on the SATA connector end as they work on DOS->XP. Now if 3TB->18TB SSDs will be 512e that would make them useful. Since SSDs do not have a defined Sector Size they would be 512 Byte Drives not 512e. The "e" means it is emulated. Get it and see if it works. I'm not interested in MACs. If you want me to run tests, send me one. I can't find any references to this limit. How did you calculate this? INT 13 ID 0x9F is reserved leaving 0x80-0x9E. Anything that is accessed through the INT 13 Interface and is not treated as a Floppy Drive ID 0 or 1. Copied the wrong link. Here is the correct 4KB Native SATA model. Seagate 2TB 3.5 HDD V.5 (4Kn) 3.5" SATA Model ST2000NM0105 https://www.amazon.com/Seagate-2TB-SATA-Model-ST2000NM0105/dp/B01G3S8SGA Two more higher capacity 4KB Native SATA drive models. ST4000NM0085 https://www.ebay.com/itm/Seagate-4TB-Ent-3-5-4Kn-SATA-MPN-ST4000NM0085/152658137978?epid=1679560179&hash=item238b22537a:g:ASsAAOSw66pZjGh3 ST6000NM0125 https://www.amazon.com/Seagate-ST6000NM0125-Enterprise-7200RPM-256MB/dp/B01E1XS3W8 Interesting. A bit pricey and not a brand that I would trust though. You might want to stock up.

In reference to The Starman link, either Jump format is acceptable. All of the integrity checkers I have seen check for E8 xx 90 or E9 xx xx.

I haven't so far needed to use any alignment tools and WD or other companies no longer offer them on their website. They probably figured out how to do it internally on newer drives. I read some earlier documents there used to be a jumper to set these boundaries for XP and now these drives are jumperless. I don't know if jumpers could be extended to 64K. I'm sure proper manipulation of the NTFS Partition can be done to align on 64K Boundaries. I can already do this with FAT32. Located a 2TB 4KB Native drive. I guess they are pushing these out. Seagate HDD ST2000NM0115 2TB SAS 12Gb/s Enterprise 7200 $148 https://www.amazon.com/Seagate-ST2000NM0115-Enterprise-7200RPM-128MB/dp/B01E1XRKIQ That is a SAS Drive. It uses SCSI protocol. The AF Format was designed for efficiency. They still have 512 Byte Sectors at the interface. SSDs do not have a defined Sector Size except for erase. That's what I'm hoping for the near future. If 64KB physical sector drives with 512e means higher capacity by squeezing more data on the platters and maintaining compatibility I'll take it. I'm not sure about the near future. The improvement over 4K is a lot less than the switch from 512B to 4KB. What about the ECC overhead? That should add some extra data usage. I think 64KB with one ECC segment than 512 Bytes with 128 ECC segments would show some noticeable impact. Transferring TBs of data there might be a noticeable ECC overhead savings of 9-10% like the 512 Bytes to 4KB difference. No. The ECC is at the Physical level. In either case there would be only one ECC per 64KB. You don't add ECC to the 512 Byte Sectors at the Interface unless you are emulating a "READ LONG" Command. You still need the extra Address Translation adapter or else XP 32-Bit couldn't see more than the 2.2TB. A regular SATA to USB adapter wouldn't work. Yes. But your response is unrelated to what I said. That's nice but booting to a large capacity drive and not being able to do everything like in Windows XP or accessing USB 3.0 speed drives makes DOS->ME too limited. It's a shame the XP source code hasn't leaked yet as it probably could blow away W10 with the right programmers. Live with it. I think you could build a better SATA to SATA hardware address translating adapter given your evaluation of this eBay product. All hardware based that supports DOS -> Windows 10 transparent to the user avoiding unnecessary patches to each OS. The eBay example is just demonstrating the competition which isn't much at the moment. It might be possible to add translation to that Card because it probably has an EPROM. But you will end up with an ISA to PATA Card which is not very helpful. SATA Controllers use dedicated hardware with built-in firmware so they cannot be changed. The BIOS may be updateable but that would not help with Windows. It's most likely one of the newer models and not XP compatible. They usually come as GPT and NTFS preformatted if you check. What brand and model is this you purchased? It isn't particularly new. I bought them years ago. I'm not sure if they were pre-formatted. I don't remember what model. We are still using NTFS v3.1 since XP. 1PB is still 4 times the current Windows 256TB limit. Strike a deal with MS if they decide to keep with NTFS and hold off from ReFS and offer this patch as NTFS v3.2. Have you checked if the 256TB NTFS limit applies to MAC OS and Linux? They won't. I don't have a MAC. I haven't experimented much with Linux. It was up earlier probably not a hot seller so it was taken down. Ableconn PEX10-SAT 10 Port SATA 6G PCI Express Host Adapter Card - AHCI 6 Gbps https://www.ebay.com/itm/Ableconn-PEX10-SAT-10-Port-SATA-6G-PCI-Express-Host-Adapter-Card-AHCI-6-Gbps/371982006638?hash=item569bdaf96e:g:asUAAOSwFqNZQbWB Get it and see if it works. 31 total. This is the limit of INT 13 Drive Numbers. If the BIOS supports it, DOS supports it. So should Windows.

They are all probably AF Drives making them untranslated 512e. I damaged the case on the Seagate I disassembled also. It had a detachable base with the adapter in it allowing me to switch from USB to eSATA. The base could be used by itself with a bare drive or another drive of the same series. It automatically switched from 4K translation to no translation depending upon the size of the attached drive. The SATA connector of the internal drive was behind a slot that was too narrow to let a standard SATA connector fit. Otherwise I would not have had to disassemble it to experiment with a direct connection without buying their eSATA base.

Whatever makes it easier to create it in 9X/ME and fully robust. Since 64-Bit RAM is normally unused, you can create the RAMDisks in DOS and just leave them until needed. I'm not sure what you mean by robust. They have proven stable under all of the circumstances I know of. Customers love the fluff. Guilty. How much extra would you be willing to pay for fluff. How much extra would all of your friends and coworkers be willing to pay for fluff. You kind of missed what I was asking. Regarding Intel USB 2.0, in 98SE Real DOS (not inside 98SE OS) could you find a way to bridge USB device detection using the 9X/ME core system files? So as long as the user owned a 98SE CD to get the core and system files and used your DOS/USB interface program it could then in 98SE Real DOS basically detect any USB devices (USB Keyboard, USB Mouse, USB audio device, USB gaming controller, USB network device) or whatever USB device that used 9X/ME native USB drivers without requiring an additional manufacture driver to work). A lot of these USB devices simply are plug and play in 9X/ME. If you could make 98SE Real DOS run as normal but with added 9X/ME USB detection that allowed any USB devices connected to the USB 2.0 ports like a USB sound device could then be plugged in and on a hardware level any Real DOS based game could directly access this USB sound device for audio output. Adding a USB game controller would automatically work as if it were a legacy PC joystick. Is this within your programming expertise? It sounds like you want to make Windows 98SE Drivers run without Windows 98SE. That would require containerizing the entire WDM Interface. Then it would be necessary to interface between the Windows Audio and Networking Interfaces and those used by DOS Audio and Networking. Keyboard and Mouse are already handled by SMI Emulation. Game Controllers can be handled fairly simply. Send me a six figure retainer and I will work on it. For a Boot Partition, it is OK. For data, not even close. Perhaps by disabling AutoPlay it wouldn't tamper with the drive at all. Not entirely sure. Only a DOS clone would seem the safest. DOS is safest and fastest. I normally use DOS. I was giving it some thought. It might not happen soon but given 64KB Physical sector drive size wouldn't actually be needed yet but if a pure 64KB Physical sector drive through the drive controller appeared as 64KB sectors and a proper OS support patch was done this would really benefit high transfer rates for large HD file sizes. I already said 64KB Logical Sectors will NOT improve transfer rates, only that 64KB AUS might. Not so. The Adapter converts 4KB to 512B. The Drive converts then 512B back to 4KB which then accesses the appropriate Sectors. The MBR barrier is extended only by having larger Logical Sectors at the OS interface. The Physical Sector size of the Hard Drive, or the Logical Sector Size between the USB Adapter and the SATA Port on the Hard Drive are irrelevant. The Logical Sector size at the SATA or USB Controller is also irrelevant if using a DDO or emulator. Only EMBR or GPT can break the MBR barrier. The OS has to understand the Sector size presented to it's FileSystem. Unmodified DOS and Windowx 9x is limited to 512B, XP and above appear to be limited to 4K. My modified DOS supports up to 32K and my modified Windows 9x supports up to 4K. These determine the MBR limits, nothing else. All this nonsense about adapter boards and 64K will not increase the capacity of any OS beyond which has already been achieved. No one is going to rewrite the FileSystems just to support 64K when it is far easier to support EMBR or GPT. Maybe when Windows 14 comes out, they might add it, but don't count on ever getting an upgrade for Windows 12 or earlier.

I wasn't aware that they did not have conventional Internal drives in them. I only opened one Seagate drive and it had a standard drive inside. The internet is full of how-tos for removing the drive from the case.

That was my point in having 64KB drive physical sector sizes and using 64KB AUS or Cluster Sizes on the OS side. That only helps if the Clusters are aligned on 64K boundaries. They don't which is why if they are already imposing 4KB native drives which is not XP compatible then no reason to not just jump to 64KB native drives and skip these interim jumps from 8KB-64KB. They would be able to come up with OS patches today if agreed between MS and drive manufacturers as the new standard. No one is imposing 4KB Native Drives. I have never seen one. Only SCSI supports them. All AF Drives are 512e. USB Enclosure Manufacturers decided to make 4K translating adapters as a stopgap for XP users. Microsoft had no part in that. Microsoft as already completely abandoned XP so they are not going to add new support. Forget about 64KB Native or 64KB Translated. Only 64K Physical 512e Drives are reasonable. Faster write rates for multiple HD video stream recording or anything bandwidth intensive. No. It is just as fast to request 128 512B Sectors as it is to request 1 64KB Sector. The Drive is going to translate it into 1 64KB read operation either way. Current Controllers transfer the data as one monolithic block anyway so there is no loss there either. That's why they would release a new USB enclosure with the proper translator for XP compatibility using the 512 Bytes Sectors just as they had done previously but updated for 64KB physical sectors. Physical Sectors are transparent to USB as well as SATA. The Drive can translate to 512e faster than the USB adapter, so there is no penalty to 512e. The adapter does the magic. Now if they made a SATA to SATA 32-Bit address translation adapter then you wouldn't be confined to external USB connections only. My BOOTMAN3 DDO does the job with Internal Drives. How do you think I booted DOS with a 128TiB C: Partition. That is correct. I haven't hook it up internally yet since I'm not sure if XP would try to write to it and cause corruption. I might have to do another bare internal drive test on the 3TB to get a true MBR for you. I don't want your MBR. It is not going to tell me anything. The E-Bay sellers are just selling unbranded Cards under this own name. Zero technical knowledge required. PATA Controllers are far simpler than SATA. The one in the E-Bay picture is a very basic design using a microcontroller. Nowadays they just slap an existing IDE Controller chip and some glue logic on a card. The Chip is manufactured in a foundry. I said, I had a 4TB USB Hard Drive that did not Translate. I never Partitioned it so it is neither MBR nor GPT. I'm not sure if I had tested it with XP. No idea. Ask MS directly the reasoning. All those documents have claimed this 256TB Limit. I think it has to do with the NTFS limitation but somehow exFAT suffers the same limit. https://support.microsoft.com/en-us/help/140365/default-cluster-size-for-ntfs--fat--and-exfat This one is more descriptive: Support for large volumes. NTFS can support volumes as large as 256 terabytes. Supported volume sizes are affected by the cluster size and the number of clusters. With (232 - 1) clusters (the maximum number of clusters that NTFS supports), the following volume and file sizes are supported. https://technet.microsoft.com/en-us/library/dn466522(v=ws.11).aspx Apparently NTFS has a 32-Bit Math limit at the Cluster Level. I would have to look at the ExFAT Spec. The compatibility tables are not correct. FAT32 is supported on all of the OSes listed up to 2TiB even if Microsoft refuses to let you create them I have pushed the Cluster Size limit in Windows XP FAT32 to 256KB using 256 Byte Sectors. If I could do the same with NTFS, it might be possible to increase the limit to 1PiB. Easy swapping of drives between machines running 24/7. Can't hook up these special USB address translation adapter drives to SATA ports directly. These are needed for MBR and XP 32-Bit without a XP 32-Bit GPT Loader for external USB drives. I use tray-less racks. This allow me to swap Drives easily. I do have to reboot though. The USB limit is 128 per Root Controller. The listing is gone. It is obviously an AHCI Controller. You can have 32 Direct Ports. Each Port can be expanded with a FIS Multiplier. It might work with XP if you add an AHCI Driver. The newest UNIATA appears to have AHCI Built-in. You don't "chain" them. You put them in separate PCI/PCI-E Slots. I think the BIOS limits you to 31 Hard Disks. Windows 9x has some minor issues above 8. Unless they are UEFI only, they must support DOS or they could not load any OS. Pick your poison.

I cannot find any detailed information on 2.2TB infinity. If it does not support more than 2TiB using INT 13 Calls from DOS then it isn't what I was thinking of.

I said I got DOS to support 32K Sectors, not that standard DOS did. I put the Sector size Patches in IO.SYS along with the EMBR Patches so my Customers have both. No idea. The TeraByte Plus Package works with any CPU. I do Windows 9x programming as well. The DOS RAMDisks work well enough that making a Windows Version was not a priority. I probably could rewrite my USB Mass Storage Driver to act as a RAMDisk. A GUI Interface is just fluff. USB Sound Cards and Adapters work fine with Windows 98. The Motherboard doesn't matter. The standard Drivers do that. If you are talking about DOS USB Drivers, some exist. A long time ago. Even if you are using a 2TB Drive, the FAT32 Partitions were nowhere near that size with 512 Bytes or 4K AUS. The minimum AUS size for a FAT32 Partition larger than 1TiB is 8K. 64K AUS is considered non-standard. Unmodified DOS won't boot and DEBUG will not save data. Maybe for NTFS, but FAT32 Partitions that size will use 32K AUS. The VIA Driver has a bug, IAA is limited to Intel Controllers. I don't think it does if connect the Drive and grab the data without using Explorer or other Windows Functions. I keep telling you that 64K Logical Sectors will not happen. Your point?

They are the same thing. SCANREG is the name of the program that checks the Registry.

That would be the highest you might go with my Patched DOS. Standard DOS only supports 512 Byte Sectors. If you are using my Patched DOS, you might as well use my EMBR as well. You won't need 16KB Sectors until you exceed 16TiB Per Partition or 384TiB total. My point was that it is not free. I have a Multi-Core API that lets you write Applications that you other Cores. Writing a DOS RAMDisk was much simpler. You will have to bug nVidia about that. Good. There is no USB 3 for Windows 9x. I plan to do some more work in this in the near future. Why would you use 512 Byte Clusters on any FAT32 Partition? The default is 4K for the smallest ones and 32K for large ones. Not surprised. With my EMBR I get full speed AND reduced Drive Count at the same time. I am also not limited to total size of 16TiB. I did say that XP is not my area of expertise. Already done. Try reading the XP Forum. There are other XP USB 3.0 Drivers such as Asmedia. I was the first to break the 137GB barrier on Windows 9x. If you want to live with 120GB Drives, that's up to you. I will stick with my 4TB and 6TB Drives. The distinction is in size. I only bother to save what's on a new Drive when it has some software pre-stored on it, not just an empty Partition. According to you these are the new normal. A Floppy or Super-Floppy has no MBR or Partitions, just a PBR to Boot. When booted they become A:. Size matters. 2.88MB and below is a Floppy. Super means bigger.

64K Physical Sectors would provide some improvement. Not as much as the switch to 4K. I assume you are referring to Cluster Size. This is entirely separate from Logical or Physical Sector Size, or from the Windows Cache Block size. For best performance, the Cluster Size should be at least the Physical Sector Size. Microsoft does not acknowledge support in XP. I think the 4K Support may have been for SCSI, which allows different Sector Size Formats to be used even in a single Drive. Windows 9x has some support up to 2K Sectors built in. I don't remember if it was complete. True, but what is the advantage of having 64K Logical Sectors then? XP would still only be able to access 2TiB with translated 512 Byte Sectors, If it is translated to 512 Bytes, the limit is still 2TiB. The 128KB I referred to earlier is the Cluster Size limit of my Patches. Unless I can find a way of modifying the FAT32 Drivers to work with Cluster addresses rather than Sector Addresses, it won't matter. That Drive is an Internal Drive. The MBR says it is translated to 4K. This means that you are partitioned it using a separate Enclosure or Adapter that is translating. The Western Digital "My Book" External Drive series has 2TB, 4TB, 6TB, and 8TB Models. I could not determine from the Specs if any of them translate. I'm not aware of any. As far as I know, no Motherboard with a Floppy port supports more than 2TiB in it's BIOS. I have no idea why the 256TiB limit. Is it a Partition limit or a Drive limit? Why USB External Drives, why not Internal?

RBBAD is the saved bad registry, if you wanted to undo the Restore. It is not used. It's size suggests that the Registry was seriously corrupted. You may have other damaged files. I would not trust RB000.CAB. RB005.CAB probably is OK if the system was running OK Yesterday Afternoon. If you haven't made any changes in the last few days you could remove it also. To be safe, rename them with a different extension such as RB000.BAK rather than deleting them. You can put one or both back if you need to. Let SCANREG restore the Registry. If SCANREG doesn't run, you can force it to run by renaming or deleting WINDOWS\SYSTEM.DAT. It is hidden and read-only so you will have to unprotect and unhide it.

Try going into the WINDOWS\SYSBCKUP Folder. There are files named RB000.CAB, RB001.CAB etc. Rename or remove the ones that are dated after you changed things. DO not remove the oldest one. Let the Checker reload the Registry.

You keep missing the point. Large Physical Sectors never were a problem except maybe for performance. Any OS will run, no matter the Physical Sector size. The major incompatibilities I refer to are related to Logical Sector Sizes. Making larger Logical Sector Sizes does not improve performance or Storage capacity. It only bumped the MBR limit. Never OSes support GPT so there is no issue there. 64K Logical Sectors would require major changes to all existing OSes so no one is going to bother. A translation adapter or a DDO for DOS and Windows 9x could handle it but that would defeat any purpose in implementing 64K. You said they stopped using translators in 6TB Drives. I don't have any, so I can't verify. If so, 4K will probably disappear leaving 512e Drives only. I know of no way to support more than 26 Partitions simultaneously in DOS, Windows 9x or any Windows NT without major changes. This why I consider the limit of Windows 9x to be 384TiB, or 416TiB if I can get A: and B: on board. DOS gets a limit of 3PiB or 3.25PiB for the same reasons.

DOS puts it's Sector Buffers in a single Segment. With a 32-Bit Sector plus a few Bytes of overhead, only one Sector will fit. I did a file compare using a program that read the files in small pieces. It would have run for hours, even on fairly small files. When I analyzed it, DOS was reading a Sector to supply a small piece of one File, then reading a Sector to supply a small piece of the second File. It then had to repeat this process on the same two Sectors until all of them had been transferred to the Program, before going on to the next pair of Sectors. Switching to 16K Sectors, allowed 3 Buffers and the Program ran at a reasonable rate. No connection. I have increased the Cluster Size limit to 128KB with 512 Byte Sectors or 8MB with 32K Sectors. I already did it. Tell that to the waitress when she hands you the bill. Then don't blame me for choosing it. Not necessarily. The standard MBR area does not have a granularity limitation so the first 8GB is available as normal. The reserved area is at the top. I am referring to the issues that occur when exceeding 2TiB in general, not your specific case. I thought you cared about Windows 9x. How often do you move TeraBytes of data to or from USB Drives? It takes a long time with Internal Drives, far longer with USB. I can backup my 4TB Internal Drives to another Internal Drive in about 8 hours using a DOS Program I wrote. It would take 24 hours in Windows. I hate to think how long it would take with USB. So far. By your own statements it doesn't sound very profitable. If I could solve the Math issue in XP, it would be far easier to implement my EMBR than a GPT Loader or support. Going higher has not been a headache for my Customers or me. I think Jaclaz summed up the reason why you cannot extrapolate to three of more 2TiB Partitions. You keep asking about going past 4TiB. @jaclaz Extended Partitions are called EBRs not EMBRs. There is a third-party EMBR for a different purpose. Not 4TiB Drives. I was aware of the possibility when I first worked on the 2TiB Problem. Only a two-fold improvement. I went for a 256-fold improvement. More efficient for Drive Letters but less for performance. Presumably Paragon found a solution. I have also seen others that make the Hard Drive look like multiple smaller Hard Drives. I already did this with Windows 9x but chose EMBR as a better solution. There is no reason that >2TiB 2.5" Hard Drives or SSDs won't become available in the future. You just have to wait for the technology to improve. I believe there may have been a warning or they simply dropped Windows 9x from the compatible OS list. A partitionless (super-floppy) Disk is an interesting possibility. It would have to be NTFS to push the limit. Unfortunately, it probably would not work in XP for the same reasons as the 4TiB approach unless USB does not have the Math Problem. I do have a 4TB USB Drive that is not translated, I could test with. Pointless maybe but inexpensive.

My point about my Patches was that I already knew what could and what could not be done using Internal and USB 4K Drives five years ago. I could have anticipated what you did in 2012 or earlier. Next time, try reading my entire paragraph before replying. The efficiency improvement you referred to is due to larger Internal (Physical) Sectors, not larger Logical Sectors. As long as reads and writes are properly aligned, the Logical Sector size does not affect performance. If aligned, Windows 9x runs at the same speed on 512 Byte and 4K Sector Drives. Reverse DDOs would be needed to support 64K Logical Drives with DOS and Windows 9x. Even more complicated solutions would be needed for NT OSes. A 64K Physical Sector Drive is perfectly OK but most OSes won't align their I/O properly. Drive letters are managed as single bytes and the tables are hard coded, so forget it. Using Volume names or Mountpoints is another option, as these are remapped. But direct named ordinal access is not. Neither of these approaches increases the maximum usable Disk Drive space as you still have a maximum of 24 Partitions. Banking Drive Letters in DOS may be possible provided that no Pointers or Open Files are present on the Letters being switched.

Partitionless (Floppy-like) USB Drives are not limited in size differently than any other Partition. I called my approach "Extended MBR". You are the first person to call it EMBR. It is fully compatible with standard MBR for Partitions below 2TiB-8GiB. If combined with a matching GPT, the Partitions can be used by anybody with a GPT compatible system without Patches as I have many times. Despite your desires, I am not an XP Programmer. I know far less about XP than I do about 9x, so stop pestering me about writing XP Patches. So far I have only one XP targeted Product. Your 8TB demonstration doesn't prove anything. 3TB, 8TB, or 16TB all face the same issues. The 2TiB limit still stands for Internal and non-4K USB Drives in older OSes. Anyone could slap that 16TB SSD into an Enclosure and hook it up to XP. I already have an Adapter that runs off USB Power. USB Power is not enough for 3.5" Hard Drives, only 2.5" Hard Drives. My tests show that UNIATA is necessary, but not sufficient, to support the 4TB MBR approach in XP. I created a Partition that crossed the 2TiB limit. Windows XP just wrapped back to 0 when I tried to access Sector 0x100000000 at it's relative address in the Partition. If you are still suggesting to try more than 2 Partitions to get past 4TiB, then you clearly do not understand how MBRs work. @bphlpt Thanks for the nice summary. My statements about GPT are in response to 98SE, I am not pushing GPT.

As Jaclaz already said in other words, old news. I had all of my Patches working 5 years ago. The problem with booting 4K USB is lack of BIOS support. I don't think any of my Computers recognize a 4K USB Device. Forget about 64K Sectors. It is far easier to support GPT than Sectors larger than 4K. 4K is just a stopgap measure to deal with MBRs. There is no penalty for having small Logical Sectors. Only large Physical Sectors provide an improvement.

The Drive would work but you would not have access above the respective limits. There are more XP users so that is a given. That is why I was looking into extending the EMBR to XP. You are missing something. I was referring to EMBR + GPT Drives. GPT capable OSes would use the GPT. DOS and Windows 9x users would need my EMBR Patches. The EMBR License is per machine. Any combination of supported OSes are allowed. Currently only DOS and Windows 9x support it. I never said that there was a player. I said special software would be needed. The existing FileSystem is not used. Yes. My point was that I can do that with a Video that is longer than 4GiB. No idea. I used a standard 1080 Monitor. The Patch is an User Mode Overlay. If you look at the Drive under an unpatched OS, you will see multiple files of less than 4GiB. You can corrupt the files by writing to them directly but you won't corrupt the Partition. You could use splitting and merging programs to access the data if necessary. Internally Windows 9x uses 4K blocks so adding 4K support was practical. 64K would not work. DOS cannot handle 64K Sectors. It can support 32K Sectors but the performance is very poor. I would think similar issues would be present in other OSes. I seriously doubt that 64K Logical Sector Drives will be mainstream for a very long time. 64K Physical Sectors maybe. Pushing the MBR limit in this manner would not be worth it. No free lunch. I have Patched BIOSes to support LBA-48, but that is a one-off approach. Every BIOS Version would have to be analyzed and Patched individually. It would still not make DOS or Windows 9x Patch free. Without a specific convention like I use with another aspect of my EMBR, the BIOS would not know what Sector Size to Emulate. NT OSes don't use the BIOS except for the earliest part of Booting so it would not see any BIOS translator and would still try to use 512 Byte Sectors. They behave the same. As long as the Sector Mapper is used properly, you won't get corruption. Not that I know of. How do you expect me to describe something I haven't anticipated? First, read the terms of my License agreement. Second, familiarize yourself on the subject of Cosmic Ray upsets.

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.

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

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 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. 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. 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. Don't count on LBA-64 any time soon. It would not improve compatibility with 32-Bit OSes. It would break all current OSes.

I didn't keep a list. I remember PARTMGR.SYS, DMIO.SYS, and FTDISK.SYS

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