98SE

Did you try testing your SkyLake system again using the new AHCI driver to see if the stuttering you complained about is still happening?

To summarize since it's been a long day. RLoew brought up his EMBR since it is his product so he has the right to advertise it here as long as no moderators have an issue and it is not prohibited on MSFN. Since he brought up EMBR several times then he could also answer questions about the product and any possible pros/cons of how it would interface with XP and older OSs. Because it is called EMBR does not necessarily mean it's MBR. He could have called it RLBR so it would sound foreign and unrelated. His EMBR is proprietary so only licensed users of it could access the data on those EMBR drives on another machine. It is obvious if another person was using a licensed EMBR user's machine that's not a problem accessing the data. As for myself I use both internal and external drives (SATA and IDE) unplugged or plugged through USB SATA adapters if I need to transfer data to it while the system is on. Or if the system is off I would hook it directly internally to gain better performance. Most of my machines are desktops not laptops and are usually running 24/7. The GPT which is the new MS standard will become relevant now and in the future as legacy MBR is capped at 2.2TB. However since not everyone or I could be the only one that hasn't been quite ready to stop using XP which does not have native GPT support but I may be switching to a GPT compliant OS soon so this might not be an issue in the future. In the meantime MBR > 2.2TB via USB is more of a stop gap way of continuing to use XP on more than one system without needing to patch each machine and purchase a license for each. Remember he just said it was per machine. So if I had 20 machines and I were to use all 20 machine with EMBR that would be a costly approach for one person. But also my EMBR data could not be read by another person who doesn't use EMBR. This con has nothing to do with internal or external drives. Now GPT read/write for both internal and external drives doesn't exist so GPT adoption on XP hasn't materialized yet. The closest is the Paragon GPT Loader but that is for "internal" drives only. So in my situation I have no large capacity GPT drives here. All of them are MBR based so even Paragon GPT Loader has no actual usage until 18TB or possibly 32TB drives when I would be forced to GPT if I want to consolidate the amount of drives I have to use. You can consider one 18TB MBR drive for one USB port or in the future one USB port for a 256TB GPT drive. That's 13 USB ports saved to access that capacity. Concerning internal capacity most OS will be fine with a 128GB MBR drive. Windows 7 could squeeze in a 32GB partition just fine. XP can run in 2GB. So comparing apples to oranges XP still has plenty of usefulness if you steer it in the right direction. Which is the reason why I'm suggesting RLoew to try to get a Windows 2000 and XP GPT Loader created so that legacy users can continue using XP with extremely large capacity drives that also work in Vista -> W10 without any need for the other computer to have a license to read/write to my GPT drive. You have to remember even RLoew can't live forever and if he doesn't do it soon and there's no one else willing then XP will be abandoned post 32TB timeline. Don't forget that everything takes time to complete. If he were to start today it could take a few years before it's done or it could take a week. But if it never gets completed and no one is around to do it then I can honestly say XP's usefulness as time goes on will be limited. GPT is practical. Again most people won't be using anything more than 2TB in XP because they don't know how or they moved to a GPT capable OS. GPT is here and however resistant legacy OS users are it is the future. The large capacity drives are already here. 16TB SSDs from Samsung in 2.5 laptop form are extremely expensive but more affordable 12TB WD 3.5" drives are already here for $521.99. https://www.wdc.com/products/internal-storage/wd-gold-enterprise-class-hard-drive.html 18TB is nothing to laugh at and reaching the Windows NTFS limit of 256TB is around the corner. Even though the latest attempt by Jaclaz / Tripredacus to exceed that they were still stuck with two partitions and neither partition could exceed 2.2TB in size. Also the 2.2TB MBR barrier is "broken" so this thread is already in a sense no longer relevant and you can see visual proof. "www.msfn.org/board/topic/177171-what-a-single-8tb-mbr-hard-disk-drive-looks-like-in-windows-xp/" I'm not sure if anyone else has posted an 8TB MBR drive running in XP anywhere on the internet. Although most probably can't even figure out how to install XP on Coffee Lake so that number is even lower. Any healthy discussions of GPT become more apparent as capacities toward 256TB will be reached sooner than you think. Meanwhile most XP novice users will have to choose to stick with 2TB limits or succumb to Windows 10 and GPT. This is why whomever creates the first GPT Loader for 2000 and XP will reap the benefits first if done commercially or if someone made it freeware the Legacy OS world would cheer. Bananas or Pineapples?

If it has the correct adapter technology then yes it works. In theory D: to Z: gives you 23 possible drives connected externally via USB ports. If I connected all my 8TB drives and had 23 USB ports to plug them in simultaneously then 8TB x 23 = 184TB but in actuality you will get approximately 167.21TB due to partitioning capacity loss. In the not too distant future, 18TB x 23 = 414TB might be possible which will actually be around 376.2225TB. However if 4KB sector drive limits cannot be broken soon then the current max would be 17.6TB x 23 = 404.80TB and the guaranteed max usable capacity should be around 367.862TB. However with a working GPT Loader for 2000/XP we can see pure GPT drives of 32TB+ x 23 = 736TB and higher. The jump to 64TB x 23 = 1472TB breaking the first PB barrier on one computer with ease. Since it is all hardware based this 8TB MBR external USB drive should also work in Windows 2000 with SP3 for LBA48 support. No software patches or drivers are necessary seeing this 8TB MBR drive in 2003, Vista, Windows 7-8.X, and Windows 10. http://www.datarecovery.com.sg/data_recovery/large_disk_size_120gb_barrier_for_windows.htm

3TB Floppy? The maximum Floppy disk I'm aware of would be 240MB. There is probably the final capacity for floppy disks since optical discs killed them in cost per capacity. Here I've composed a detailed graphical snapshot of the 8TB drive in operation in Windows XP in all its legacy glory. "www.msfn.org/board/topic/177171-what-a-single-8tb-mbr-hard-disk-drive-looks-like-in-windows-xp/" A more descriptive DOS CHKDSK: The type of the file system is NTFS. Volume label is 98SE 8TB MBR EXTERNAL USB HDD. WARNING! F parameter not specified. Running CHKDSK in read-only mode. CHKDSK is verifying files (stage 1 of 3)... File verification completed. CHKDSK is verifying indexes (stage 2 of 3)... Index verification completed. CHKDSK is verifying security descriptors (stage 3 of 3)... Security descriptor verification completed. Windows found problems with the file system. Run CHKDSK with the /F (fix) option to correct these. 7630874 MB total disk space. 7630652 MB in 16782 files. 13440 KB in 798 indexes. 0 KB in bad sectors. 213888 KB in use by the system. 65536 KB occupied by the log file. 0 KB available on disk. 65536 bytes in each allocation unit. 122093996 total allocation units on disk. 0 allocation units available on disk. U:\> As for a Live Linux DVD not at the moment. Do you have a DOS or Windows equivalent program that would gather the information you're interested in seeing?

Say what? 2.2TB MBR Barrier?

If the 2000 pages are available for GPT then why was Paragon unable to say extend support to 2K or add external USB GPT drives to be readable/writeable? It seems like a half baked GPT Loader. That would be the first obvious use for it. No one really needs a 32TB GPT internal drive and I think you would agree even a 128GB internal drive is more than enough for a Primary MBR Boot device and GPT isn't really necessary to be bootable. I still see GPT at least from 32TB onward or possibly > 18TB onward if 4K->512 Byte translation adapters have maxed out and GPT to be the forward compatible choice. Yes I agree with the Clone = "byte by byte" or "bit by bit" or "nibble by nibble" sorry Apple Talk. But imaging would not be a clone but can restore it to appear identical to a clone? For example when you image a partition, let's say you only are using 2MB of data of the 2GB partition. When you restore back the image it should be byte for byte identical to the original partition. The image would probably not store the unused/blank data on a new drive as it would be unnecessary. However if say there was left over unwiped data on a "used" drive a "clone" would also retain those "hidden" bits which a data forensic might find useful for clues. But for the layman this wouldn't be important and any real true "cloning" of empty non relevant data would be a complete waste of space. But one that detects the "blank/empty/unused areas" for example if a 128GB brand new drive had been Zeroed out and then added a 98SE DOS boot a clone would see the first 1MB and then properly store that data onward that "0"s were filled from 1MB+ to 128GB saving a ton of space. Curiously what would be the best partition and drive cloner that would do what I just stated? If I wanted map my drive or analyze how the data was stored and had no idea what kind of drive it was what would be the best program to probe it? The last paragraph that you had previously linked Microsoft "System Partition" = partition "with the boot files". Microsoft "Boot Partition" = partition "with the operating system" I think you have me reversed because I didn't agree with this which was Microsoft's definition. Or is my definition somehow a hybrid of the two because I have my Windows Boot Loader separated from the System Partition? I call the C: Boot Partition = the Boot Files (IO.SYS, MSDOS.SYS) for example in DOS. now the 98SE main operating system files can be put on D: XP on E: In this case D: and E: according to my definition are "System Partitions" or "Operating System" partitions. The C: still contains the 98SE DOS and the Windows Boot Loader (2K/XP/Vista/W7/W10) that redirects to the correct "Operating System" partition to continue the OS booting process. The C: doesn't contain the actual 2K, XP or later Operating System files because those still are on the "Operating System" partition D: or E: where respectively the "Operating System" files of the corresponding OSs are stored. Have I confused you further? Po-Tay-Toe, Po-Taw-Toe Let's call the whole thing off.

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

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

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

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

Downloaded the suggested programs for later testing. Nice SS. What's with the garbage characters on the bottom of the DirectX Windower?

Dibya take a look at W8 32-bit for GPT boot support. 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 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+. 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. 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. 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? Would this increase GPT limit increase to 64ZB on 4KB sector drives? 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? 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? 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. 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. 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.

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.

LOL. Cheers! Relating to XP 32-bit, Which DJ program are you using? More importantly what is the computer Motherboard Chipset? I remember the MAYA44 was quite popular in the old days what sound card are you using for it?

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

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. I hope you were making a joke here? 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. 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. 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. 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?

From my perspective it only makes sense to maintain the standard MBR profile but add GPT support to older OSs that I previously mentioned prior XP 32-bit to DOS. But it's really a suggestion. I can't see anyone really wanting to use an EMBR if it involves needing to patch their OS in some manner and can't be read on other computers without the drivers required installed. And let's assume they purchased your EMBR license would this be restricted to the user only? Unless you are offering a free version of the read access only (not write) driver for all to download otherwise the data would be inaccessible except to the license users. Now adding GPT access (read/write) has forward compatibility built in so anyone using DOS to XP 32-bit could then read/write to GPT drives and if they were to bring their drive to another person's computer who had XP Pro 64-Bit, Vista or higher OS they would be able to read the GPT drive without needing a new driver. That was the entire point I was hoping was made clear. Nothing against your own EMBR but compatibility and accessibility are tied together and adoption as well. Even if a DOS 256TB technique was created and offered free to all it's still hard to gauge how many people would use it. Despite my resistance to GPT I now find it is the only sustainable compatibility path forward. That's why if 4.4TB JTEMBR worked and could be used on any OS then that would be something people could adopt as it would not require any kind of OS patching since the patching is on the drive itself.

Yes I noticed it way before I posted. My statement had nothing to do with when he originally created his account. And other messages already hinted to the "welcome back." IT is the right place to return to now that I'm here with the right info and experience applicable to his query, And since you're also here it adds to the relevance. "Cheers theme song playing" in the background.

Check your Event Log Viewer. A clue might be in there as to what's causing it. Did you check your Services to see if the DCOM was still showing as enabled or Automatic startup? or Disabled and stopped? When I get more time to test Windows 7 64-Bit to see if this login problem happens on SL.

Can you try New Moon on Windows 2000 or 2000 SP4 minus BWC Extended Kernel? What computer system was this installed on?

You've come to the right place. I've done dual and multi OS booting from DOS to Windows 10. I've done multiple Windows 2000 installations on the same drive and each is selectable. The same goes for XP, Vista, and Windows 7. For Windows 10 I haven't done this but I don't see any reason why it won't work. You'll have to have to make a separate partition for the #2 Windows 10 to reside. Now since this is meant to be a clean install of Windows 10 then yes you can have a #2 installation on the same drive and the boot loader will show both Windows 10 installations. Now if your DJ software works on XP-Windows 7 I don't see any reason why not install the DJ software on those older OS which will run faster and possibly less bloat if it works on XP. Just remember for the novice it's much easier to install the older OS in that order to the newer ones. So if you already have a W10 system up and running you'll need a 3rd party tool to restore the boot loader if you install an older one like XP or Windows 7 which will kill off the W10 from being seen. But for your case try the dual Windows 10 setup and don't activate the 2nd installation. It will still function but will have W10 activation pop ups so when it expires you could reinstall #2 Windows 10 again without activation. With this method you won't need to purchase a second Windows 10. You will have to disconnect your ethernet or wifi connection and disable your ethernet and Wifi devices in the Device Manager so they don't try and connect to the internet or it may try and reactivate or add self updates to this clean copy Windows 10 installation you want to use. If you're 100% certain you won't change your hardware configuration from the #1 Windows 10 installation then you can activate the #2 Windows 10 installation since it won't count towards the hardware changes and will assume you're still using the #1 Windows 10 copy. If you change enough of the hardware around removing/adding it could trigger a hardware change so the safe way is to not activate the #2 Windows 10 install if you only have (1) Authentic Windows 10 license. The new Windows 10 hardware change detection might not be as stringent as in the past. I seem to recall they only lock down the motherboard and all other hardware changes will not trigger anything but don't quote me on that. If you're okay with reinstalling #2 Windows 10 from time to time without activating you should be fine with using it in this manner privately. If this is for some DJ gig and you have your Windows 10 OS screen outputted on a large display and using software in real time the Windows 10 pop up might be annoying and a little embarrassing. Behind closed doors if it doesn't bother you this will work.

So in your EMBR tests you concluded 4.4TB would be the highest maximum capacity possible as spanning only one partition allowed before the 2.2TB limit? Would this JTEMBR scheme have any corruption issues if both partitions created were FAT32 and accessed under 98SE DOS for reading or writing (Example: writing data in FAT32 Partition 2 (Above the 2.2TB) region. Would data corruption occur on Partition 1? Was there a way to seamlessly bridge the two partitions to be identified one entire partition? Any impact on data corruption when reading/writing on FAT32 or NTFS in the 2nd partition region exceeding the 2.2TB barrier with XP SP1 or other compliant > 128GB OS support. Hence GPT support for internal and external drives would be the best path forward for older Operating Systems with only native MBR support. I think the death of XP will be related to the SATA controller. If compatibility is broken that will be the death of XP on most builds. For example if a switch to entirely new storage controller with no SATA backward compatibility. However a work around would be internal PCIe SATA cards. ReactOS will only succeed in replacing XP 32-bit if it has full XP 32-bit compatibility including DX9, Window 7 64-Bit compatibility including DX 10-11.1 support and if possible DX 12.0. Otherwise it will be relegated to being another Linux flavor with GPT support if Windows compatibility is just for non graphics/non gaming and only office related software. XP Pro 64-Bit would already do the same thing and have DX10 support. This software would be the best alternative but you'd have to write the drivers to be loaded for DOS, 9X,ME,NT,2K,XP if the goal was permanent usage. Currently my hardware version should work on these older OS without needing these drivers but I haven't tested to see how 8TB via USB is detected except on XP. I have doubts of needing to bring in your EMBR because if that were chosen and brought to another system it would not be able to read it. GPT support read/write support seems to be best path forward for XP and older Operating Systems down to 98SE DOS. Well to be more precise even 2TB up to 5TB had these special USB SATA bridge adapters. I'm not sure why the 2TB model had it as it could have been used internally. Perhaps the drive was 4K and not usable in XP directly. All 6TB models are guaranteed to be GPT without the bridge adapter as they dropped these. I agree with the "bootability" issue. I see large drives 2.2TB+ to be data drives not requiring it to be a bootable drive. Though the preference would be for bootable SSDs for a primary drive and not a USB stick if used in conjunction with a large GPT drive. Exactly. But so far USB sticks natively (without some modifications) cannot be used to boot into XP 32-bit. 98SE seems to be the exception which could mean any DOS based are fine booting into the OS on these. NT 3.X/4.X and 2000 may have the same issue as XP. 512n HDDs will exist for a long time as long as laptop hard drives will be 2TB and less capacity. Then replaced by SSD but you can find alternatives which will keep to this. Such a DDO or controller might come around on eBay. If I were to send the USB SATA translation bridge adapter to one of these sellers for them to reverse engineer and replicate we could see these adapted for laptop USB powered hard drives for over 2.2TB. Currently these adapters are only for 3.5" drives and require an external power source making it not ideal. But we all know China probably made this adapters and could leak them out on their own. Later when 8KB and larger sector drives become available (hoping for 64KB sector drives) then you will see 256TB MBR partitions possible in Windows XP. It would seem this might easier to analyze it then the one in 2001: A Space Odyssey. After booting into 98SE DOS at the command line could you boot into XP from the command line or call up the NTLDR without rebooting?

There might be a bunch of older reviews but I'm more interested in recent testing of the Paragon GPT Loader with 8TB hard drives and larger. A lot of the < 6TB drives still came as MBR if found in an enclosure. I find the probability quite low if people had a 3TB hard drive they would use this program to get that extra 800GB of data. It would be more than likely they would sacrifice the 800GB and convert GPT to MBR for internal usage as a 2.2TB MBR drive. Now if there are some 8TB GPT drive users using this internally that would be a relevant review if you found such to refer. The use of an extended MBR from 2.2 to 4.4TB would be more useful on 4TB and 5TB drives. The 4TB would be better divided into two half capacity of 2.0TB partitions. On the 5TB the 2.2 Part1 and 2.2-4.4 Part2 with a loss of 600GB would be allowable and acceptable for most people. 6TB and larger hard drives would be wasted with this method. The idea of splitting a 4TB-5TB would create two drive letter consumptions if both partitions are being accessed in XP. This is the reason why an 8TB MBR is a better option via external USB method and still a better choice even up to 17.6TB or 18TB if it exists. 20TB and larger (64TB is where I would consider using GPT entirely) if it cannot be fully utilized in the same manner with MBR is when GPT will be a necessity and if GPT Loader only works internally up to the 256TB Windows limit where it will shine for XP. But I feel by the time 64TB-256TB drives are out most people would have moved onto to Windows 7 64-Bit so GPT Loader would become irrelevant except for some niche XP 32-bit users. In your experiment were you still capped at 4.4TB max or do you see the possibility of multiple 2.2TB partitions as long as the partition information was properly stored within the first 2.2TB. For example if you had somehow had a 12TB drive to test could 5 (2.2TB) Partitions be spanned? As for XP when there was originally a 128GB limit. You could try and break it artificially on an OLDER 28-Bit (not 48-Bit) LBA system and by not installing SP1 to do your tests. Would it be possible to split 500GB to see if 4 120GB partitions were accessible in XP with No SP? For a 2TB MBR hard disk with NTFS you can choose 512 Bytes Allocation Unit Size. But on the other end you can choose 64KB Allocation Unit Size. That's a 1/128 fold difference in allocation units which has less overhead. http://graveyard-buffet.blogspot.com/2011/02/sector-size-vs-cluster-size.html https://blogs.technet.microsoft.com/askcore/2010/02/18/understanding-the-2-tb-limit-in-windows-storage/ https://support.microsoft.com/en-us/help/140365/default-cluster-size-for-ntfs--fat--and-exfat I think hard drive manufacturers should have considered larger sectors. 512 Bytes to 4KB was not enough and 64KB sectors would have brought a higher capacity threshold for MBR with an adapter even up to the 256TB Windows limit. MBR's fate seems sealed for Windows. Did your EMBR also work with external USB drives? Looking forward perhaps developing DOS,9X,ME,NT3.5/4.0,2K,XP GPT support for both internal drives and external USB drives might be a better solution to maintain compatibility. It could be a popular bridge for old OS hold outs from upgrading.

This is what I suspected. What about a smaller Extended MBR based off of the Partition 1 up to 2.18TB, Partition 2 extended from 2.19TB to 4.39TB? Would this type of 4.39TB Extended MBR drive work without updating DOS or 9X files on another system? Could 4.39TB read access work on an unmodified DOS/9X and would the only issue be write access is where data corruption would occur?

In the Event Viewer Log it seems to have errors pointing to DCOM. I'm not sure if this could be the cause of all the login related problems as I am kind of spent on Vista. https://www.grc.com/freeware/dcom.htm If you disable the service with this program and see if this fixes the problem. https://www.grc.com/files/DCOMbob.exe