Add support for alternate source of MS-DOS files #870

Closed
ptr727 opened this Issue Dec 23, 2016 · 9 comments

Projects

None yet

2 participants

@ptr727
ptr727 commented Dec 23, 2016

Checklist

  • I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
  • I performed a search in the issue tracker for similar issues, using keywords relevant to my problem.
  • I clicked the Log button in Rufus and copy/pasted the log into the line that says <FULL LOG> below.
  • The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

  • I ran a bad blocks check, by clicking the "bad blocks" check box in Rufus, and confirmed that my USB is not defective
  • I also tried one or more of the following:
    • Using a different USB drive
    • Plugging the USB into a different port
    • Running Rufus on a different computer
  • If using an ISO image, I clicked on the # button (at the bottom of the Rufus interface), to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

Please re-add support for MS-DOS on Win10.

Yes, I understand that Win10 removed diskcopy.dll so no access to MS-DOS files, and the MS-DOS option was removed from Rufus on Win10.
Yes, I understand that FreeDOS is recommended for DOS.
But, some BIOS update tools (just experienced it again with a ThinkPad update) do not work with FreeDOS, yet they work fine with IBM or MS-DOS.
Yes, I understand I can log a defect with FreeDOS.

But, please just add an option where I can point you to the MS-DOS files, that are readily available many forms, directory, floppy image, or ISO boot image.

Log

<FULL LOG>
@pbatard
Owner
pbatard commented Dec 23, 2016 edited

Please re-add support for MS-DOS on Win10.

I cannot legally do that, as the files that Microsoft removed in Windows 10 are under Microsoft's copyright and are not redistributable (and if you happen to have a copy lying around, you are probably in breach of the law).

For what is worth, HP once tried to redistribute MS-DOS with their HPUSBFW utility (if you look hard enough, you might be able to find an old copy that includes these files), but they got promptly advised to cease doing that by Microsoft.

But of course, you're going to indicate that I shouldn't have to redistribute the files, just allow users to point to them. Unfortunately your:

MS-DOS files, that are readily available many forms, directory, floppy image, or ISO boot image

are usually also been distributed in a fashion that is most likely in breach of distribution rights.

The only semi-legal way I know would be to copy files from a system that is already licensed for MS-DOS use, but I'm not even sure if this is allowed from a Microsoft license, as I would posit that it probably only allows the use, and might not cover internal redistribution of the files, even if you do that between systems you legally own — then again IANAL. But of course, I don't expect many people to do just that, and instead, I'm pretty sure that the vast majority of DOS files that would be used with Rufus would be ones that have been obtained in breach of the license, a behaviour that I'd rather not encourage.

Finally, as a Free Software proponent, I'd rather have anyone who say that they cannot use FreeDOS, and encounter a genuine issue when trying it over MS-DOS, to contact the FreeDOS developers and work with them to improve FreeDOS compatibility with MS-DOS (since the established goal of FreeDOS is to be 100% compatible with MS-DOS). Thus, even outside of what I explained above, if I can frustrate users into helping improve Free Software, as opposed to complacently continuing to use proprietary and unsupported software, so be it.

→ Rejected.

@pbatard pbatard closed this Dec 23, 2016
@ptr727
ptr727 commented Dec 23, 2016 edited

Yes, I did not ask you to distribute illegal content, I asked to add an option where I tell the app where the content is. And rejecting the request because my sourced content may be illegal, has shaky legal grounds, it is, I believe, just an opinion.

I am confused by the purity of your motives, your code modifies the Microsoft binaries extracted from diskcopy.dll to re-enable real-mode, surely you have no legal rights to distribute modified Microsoft content?

It feels to me that you are placing your support for free software above the needs of the users of your software, you could just say no, without taking a shaky moral position.

But, this is open source, I made my own version of your app that loads a Win7 diskcopy.dll from the app directory, thank you.

@pbatard
Owner
pbatard commented Dec 23, 2016 edited

your code modifies the Microsoft binaries extracted from diskcopy.dll to re-enable real-mode, surely you have no legal rights to distribute modified Microsoft content?

I'm just following what HP did with their HPUSBFW. AFAIK, they didn't get into a legal issue with Microsoft (who surely was looking at them closely after the MS-DOS embedding fiasco) for doing that, so I estimate that Rufus users probably won't get in trouble either. But there's only so far I want to try to see how Microsoft might differentiate between a large company with a hefty supply of legal resource, and a single Free Software developer.

It feels to me that you are placing your support for free software above the needs of the users of your software

And it seems to me like, even as you are reaping the benefits of Free Software, you have little interest in investing time to improve it for the greater benefit of everybody. Surely, helping the FreeDOS people identify and fix a possible incompatibility that may exist between their software and some BIOS flashers is of greater benefit than asking another software to work around the issue, and use unsupported, stale and closed source software. For one thing, FreeDOS has much better support than DOS when it comes to internationalisation, so it would probably be a lot more helpful for a lot of people to have proper support for their keyboard when using a DOS flasher than being limited to the ones MS-DOS has.

I made my own version of your app that loads a Win7 diskcopy.dll from the app directory

See? Even if you choose not to help the Free Software community as a whole, there's nothing preventing you from still reaping the benefits. I don't see much reason to complain about a developer's weighted decision then.

@ptr727 ptr727 added a commit to ptr727/rufus that referenced this issue Dec 24, 2016
@ptr727 ptr727 See: pbatard#870
MS-DOS system files are now loaded from a copy of diskcopy.dll located in the same folder as the Rufus EXE file.
Source a copy of diskcopy.dll from a Win7 or Win8 system.
0ac0b5c
@ptr727
ptr727 commented Dec 24, 2016

Helping FreeDOS to solve this problem will be a fruitless effort, the issue happens on a specific old unsupported model of hardware with a specific unsupported custom BIOS update, if it was a simple repro I would log a bug.

I do have interest in making this software better, but if you are unwilling to support MS-DOS on Win10, there is little point in putting my effort towards your project, I may as well look for or build an alternative.

Anyway, for anybody that is interested in MS-DOS support on Win10, look here:
ptr727@0ac0b5c

But thank you, up until this issue on Win10 and MS-DOS, Rufus was my go to USB stick tool.

@pbatard
Owner
pbatard commented Dec 24, 2016 edited

Helping FreeDOS to solve this problem will be a fruitless effort

Sure, it's a lot easier to ask Free Software projects for help than attempting to help them, isn't it?

But just in case you are being honest, it's not helping FreeDOS. It's trying to help the many other people who may run into a similar issue as the one you ran into, which you can do if you try to contact the FreeDOS people and explain your issue so that they can try to investigate it (that is, unless you already are a FreeDOS developer since you seem to know for sure that this is a fruitless effort). Even if I were to add external MS-DOS support, you can't really expect Rufus users not to first waste time trying to get their BIOS updated with FreeDOS, and then waste some more time trying to legally obtain MS-DOS files for use with Rufus. So, the decent thing to do here, instead of asking for MS-DOS support, would be to first try to sort the FreeDOS issue.

As far as I concerned, especially as I've seen it happen many times over, it just seems to me like you are devising a quick excuse not to help others, when you were so readily expecting others to help you.

@ptr727
ptr727 commented Dec 24, 2016

Ok, I logged a FreeDOS bug: https://sourceforge.net/p/freedos/bugs/171/
So, given your stated position, I understand that you will now add support for custom sourced MS-DOS files, right :)

@pbatard
Owner
pbatard commented Dec 24, 2016 edited

Ok, I logged a FreeDOS bug: https://sourceforge.net/p/freedos/bugs/171/

Thank you!

So, given your stated position, I understand that you will now add support for custom sourced MS-DOS files, right :)

That's unlikely, given that it is a factor of how FreeDOS will be able to confirm and address this and similar issues, then how large a proportion of Rufus users are expected to be in need of an MS-DOS alternative, then how helpful/easy to use that feature will be (if the requirement is that the user must have both a Win10 and Win8- computer, and happen to know that they need to transfer diskcopy.dll from one to the other, I can't say it looks that straightforward for a regular use). Also, custom sourced MS-DOS files may include non diskcopy.dll WinME DOS files, which would require handling the case of not having to patch the files for use.

At this stage, I'd say that, if the issue you describe is confirmed to boil down to FreeDOS not providing the same level of DOS compatibility as MS-DOS, and there are a few more reports to indicate that this is likely to affect a non insignificant number of Rufus users (you may bark at the subjectivity of this condition, but I'll try to be fair here, and, depending on their content, a minimal number of similar reports should do), I'll probably add a cheat-mode for advanced users that will make MS-DOS selectable on Windows 10, if the user happens to have a copy of diskcopy.dll in the same directory as Rufus. There are a few conditions that need to be met before that happens (especially, I'd really like to see if the FreeDOS people can shed some light on what might be happening in your bug report), but I hope that sounds fair to you.

@ptr727
ptr727 commented Dec 24, 2016

FreeDOS asked me to try the next release, expected. I said fruitless in the beginning, because I already updated my notebook firmware, can't do it again, thus not a reproducible case, at least not something I want to spend my time on.

Using diskcopy.dll was the smallest code change for me to get a USB stick made, if I were to make a more elaborate change, I'd do it the same way you allow selection of media, and then determine the type from the selected media.
I.e. leave MS-DOS as a built-in option if on a system that includes diskcopy.dll, and add the ability to detect MS-DOS / IBM-DOS / FreeDOS boot media when selecting an ISO (made with a DOS bootable image) or IMG file (of a DOS bootable floppy).
Or, just look for diskcopy.dll in system32 or in the local folder.

As for other users, I counted a few more closed requests for MS-DOS on Win10, so I am not alone in asking. Other users that need MS-DOS support may just find an alternate solution, some may log a report, some may search and see you close such requests and move on. Let's say this was a different feature, that went missing on Win10, if the feature existed in the first place, it had some value, so loosing it, has some loss.

Anyway, I think we've drawn this discussion out way longer than necessary, thank you for humoring me.
I'd be happy with a cheat mode, I'd be ecstatic with an option to select my DOS version of choice.

@pbatard
Owner
pbatard commented Dec 24, 2016 edited

because I already updated my notebook firmware, can't do it again

Are you positive of this?

if I were to make a more elaborate change, I'd do it the same way you allow selection of media, and then determine the type from the selected media.

Which is a lot of code that needs to be validated and tested (as well as require 35 translation updates), for very limited usage. Plus then I'd have to spend time educating users about what that feature is all about, and how they are supposed to legally obtain MS-DOS files (you do realize that the author of an application, especially one that gets downloaded ~3 million times each month, gets a significant volume of e-mail about what this or that feature does). So, considering that this would be for the limited corner case scenarios where FreeDOS doesn't work (and I'll point out my own anecdotal evidence of having flashed tens of firmwares using FreeDOS, and never having seen it fail once as some corroboration that the cases where FreeDOS would fail will be exceedingly limited), there's no chance I will make an MS-DOS Win10 support anything but something that doesn't require any change to the existing UI. → re-appearing of MS-DOS in the boot selection list, if you happen to have diskcopy.dll in the same directory is the best you'll get, if you get that at all. And I'm not even going to bother trying to validate if the diskcopy.dll is compatible with the DOS file extraction & patching process.

As for other users, I counted a few more closed requests for MS-DOS on Win10, so I am not alone in asking.

Yup, I'm well aware of those. However, some of these requests were flat out asking to embed MS-DOS files in Rufus, and others were simply refusing to even try to collaborate with FreeDOS to try to see if their issue could be fixed, which is really the first thing that should be tried if one is really aiming at helping others. Unless someone is actually willing to exhaust the possibility of trying to fix their problem within FreeDOS (and if the issue is common, then the FreeDOS people absolutely must be made aware of it so they can investigate), I'll always have a hard time to find much incentive into adding a feature in Rufus that will simply act as a workaround that relies on using closed source proprietary software.

But again, I said I would evaluate how the situation plays out with regards to FreeDOS compatibility reports (right now, I don't think that these issues have been investigated enough on the FreeDOS side, due to lack of reporting, but at least you took one step to help raise the awareness), and then decide if I should add support for local diskcopy.dll into Rufus.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment