Rufus checks the OS version, and no, I have no plans to allow users to provide their own diskcopy.dll because as far as I understand, what you are doing then is illegal. Only Microsoft has the ability to redistribute MS-DOS files, and by having software intentionally support the use of DOS files that were redistributed without Microsoft's agreement, I am placing my software in a grey area. HP actually got a cease and desist from Microsoft when they tried to embed MS-DOS files into their software. Granted, in this case, I wouldn't be doing the embedding myself, but from what I have seen, even long after DOS' "death", Microsoft doesn't take kindly to people facilitating the use of MS-DOS without first obtaining a proper license from them, so I am not going to take any risks here. Also, and this is the most important reason, I have yet to see a single verifiable instance of FreeDOS failing to run software that MS-DOS can, so, quite frankly, I find the requests I get here and there of "But I MUST use MS-DOS!!!" (because you're not the first person I see requesting something like this) a bit irrational. Especially as a Free Software developer, I'd rather nudge people into not using closed source software, when a perfectly viable Open Source alternative exists. Therefore, if you insist on creating an MS-DOS bootable drive on Windows 10, I will respectfully ask that you use other software than Rufus.
That's good to know. Saves me a lot of time of checking for myself. I have seen a few cases, and when I do need to use a DOS disk, I will go with what works in 99.9% of the cases. FreeDOS doesn't. It's just the way it is. And, FYI, it was not a request, merely a question.
Would you mind reporting these cases to the FreeDOS developer mailing list then? I have been subscribed to this list for more than 5 years, and I don't remember seeing a report from someone with a DOS application that worked with MS-DOS and not FreeDOS. Especially, the goal of FreeDOS is to be 100% compatible with MS-DOS (not 99.9%, 100%), so if you have data on applications that don't seem to work with FreeDOS, they will be very interested to hear from you and you should really report those there...
Hello I just used you RUFUS 3.2, after making a Windows 10 USB , I received the following error while booting It was a Windows 10 32 & 64 bit ISO. Cab anyone assist me with this error? Thank you...
The MCT created mult-arch iso can't boot x86 UEFI, you can test it in VMWare if needed. Though, when using @abbodi1406 his multi-arch iso script, the created multi-arch iso can boot/install windows on x86 UEFI, when extracted to FAT32 USB.
I did download the MS Official ISO of Windows 10 32 and 64 bit version. Then using DISM ( dism /Export-Image /SourceImageFile:"x:\install.wim" /SourceIndex:all /DestinationImageFile:"y:\install.wim" /Compress:max /checkintegrity) to create an AIO WIM file. Then I copied the AIO WIM to an x86 ISO using UltraISO. What I read in this thread, I need both efi/boot/bootx64.efi and efi/boot/bootia32.efi and it should work? Thank you
Which means you modified your ISO and created an unofficial one. It doesn't matter what you started with, the moment you change a single bit from the original ISO, it ceases to be official, and therefore it also ceases to be supported by Rufus. There are just too many ways you can butcher an ISO and make it fail to boot... No one said that. All we said is that, at the very least, to boot on a UEFI x64 system, like the one you showed from your screenshot, you must have an efi/boot/bootx64.efi file present. But whether that is the only modification you'll need to make it boot properly is another story. At any rate, what you are trying to do is not something I can support because you are not feeding an official Microsoft ISO to Rufus.
Thank you for your comments. I understand what you are saying. Basically I can't do what I'm attempting or at least with RUFUS. Again, Thank You...
https://forums.mydigitallife.net/threads/windows-10-esd-repository.59082/page-61#post-1303176 Put your separate x86 x64 iso's next to multi_arch_iso.cmd and run that .cmd script. there are two methods to create multi arch iso. merged x86 x64 install.wim/esd can be used to boot from x86/x64 uefi and legacy bios but can not be used to upgrade. (smaller iso size) separate x86/x64 install.wim/esd can be used to boot from x64 uefi and legacy bios and also can be used to upgrade. (same as mct) (bigger iso size)
Thank you, I finally got it to work correctly. What do you mean by can not be used to upgrade. I normally use a clean install of Windows. Thank You.
The iso with one combined x86/x64 install.wim/esd/swm is cleaned of all manual setup options (all unneeded files are deleted from the iso).