The FreeDos project offers a number of downloads, but all of these contain an installer that tries to install FreeDos from an installation media onto the harddisk. Selecting the mobile stick as installation target is not supported. Since typical USB sticks typically large enough to contain the OS plus applications, writing onto the harddisk is often not intented. Some pages point to tools like Rufus, which can create a bootable FreeDos installation from a template, but this disk is then missing the typical FreeDos components. So how can a complete FreeDos be installed onto a bootable usb stick to create a live USB version with FreeDos?
FreeDos – How to Install onto a USB Stick
freedosinstallationliveusbusb
Related Solutions
It won’t work because you have a non-official ISO image. You need an unmodified Windows 7 x64 ISO image. Windows 7 x86 aka 32-bit is not UEFI-compatible.
Rufus developer here.
Why Rufus can't block this device while using it?
Well, we try to do just that, with exclusive access, but Windows doesn't exactly play nice.
For instance, what most people don't know is that Windows (e.g. VDS) won't let you clean up the existing partitions of a physical disk unless you have unlocked that disk first... which is very counter-intuitive and means that, during that time, there's no way of preventing other applications from accessing that disk.
In short, Rufus very much tries to lock both the physical disk and logical volumes as required, but it isn't always as logical as one expects. Another example of it is that, to get a newly formatted volume recognized, Windows also forces you to dismount the volume (as per the notes here), which means that, even if you acquired a lock on the volume, you have no choice but to relinquish it to keep Windows happy. Therefore, whereas there are many instances where Rufus would like nothing more but to keep a lock to the drive to prevent external interferences, Microsoft have designed their OS in such a manner that we can't do that, which of course opens the door for the kind of problem you observed.
Just note however that, according to your message, it is unlikely that it is actually explorer.exe
itself that is the issue, as the (r)
you see means it's only requesting read access, which shouldn't prevent Rufus from getting exclusive access to the volume. Most likely the actual conflict comes from one of the internal Windows processes or services, that are high level enough that they can't be listed (while Rufus tries to help by listing the processes accessing the drive, there's only so much it can do against Windows privileged processes, which are incredibly hard to enumerate). Most likely, you'll want to check that you aren't using one the the applications that is listed at the end of the Rufus FAQ, as some of these are known to be a bit too trigger happy with accessing volumes that they shouldn't be accessing when they have no business to do so.
Alternatively, since ironically your issue is likely the result of Rufus not being able to "block this device while using it" (by not being able to obtain the exclusive lock it requests to keep other applications at bay), you may want to press Alt-, (that's the Alt and comma keys) in Rufus, so that it won't try to lock drives.
Of course, if you do so, then there is always a risk that whatever other process is also trying to access said drive might modify it at the same time as Rufus is performing its operations, which could result in corrupted data or an unbootable drive (which is the precise reason why Rufus requests an exclusive lock by default)...
Hope that helps.
Best Answer
Unfortunately the current information on the FreeDOS Wiki is not up to date, but with the help from FreeDos Developer Jim Hall I could find the solution:
Edit first and last two lines in D:\FDCONFIG.SYS as follows
Edit D:\AUTOEXEC.BAT as follows (Windows will hide this file, but you can open it by directly giving the filename). Only the line setting the DOSDIR needs to be changed and some display code at the end of AUTOEXEC.BAT are to be removed
Delete D:\SETUP.BAT
Boot and test
The USB key now boots directly into FreeDOS and loads into high memory, leaving roughly 600KB of common memory for programs.