Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content count

  • Donations

  • Joined

  • Last visited

  • Days Won


98SE last won the day on October 16

98SE had the most liked content!

Community Reputation

14 Good

About 98SE

Profile Information

  • OS
  • Country

Recent Profile Visitors

809 profile views
  1. 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.
  2. 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.
  3. 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.
  4. Downloaded the suggested programs for later testing. Nice SS. What's with the garbage characters on the bottom of the DirectX Windower?
  5. 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.
  6. 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.
  7. Dual boot Win 10 with Win 10?

    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?
  8. 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.
  9. 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?
  10. 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.
  11. Dual boot Win 10 with Win 10?

    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.
  12. 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.
  13. Can you try New Moon on Windows 2000 or 2000 SP4 minus BWC Extended Kernel? What computer system was this installed on?
  14. Dual boot Win 10 with Win 10?

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