[Bug 26715] New: Win1.0 executable triggers Dosbox
http://bugs.winehq.org/show_bug.cgi?id=26715 Summary: Win1.0 executable triggers Dosbox Product: Wine Version: 1.3.17 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: spammis(a)spam.la $ wine paint This seems to be a very old (pre-3.0) Windows executable. Expect crashes, especially if this is a real-mode binary ! DOSBox version 0.74 Copyright 2002-2010 DOSBox Team, published under GNU GPL. --- CONFIG:Loading primary settings from config file /home/user/.wine/dosdevices/c:/users/user/Temp/cfg1bc1.tmp MIXER:Got different values from SDL: freq 44100, blocksize 512 ALSA:Can't subscribe to MIDI port (65:0) nor (17:0) MIDI:Opened device:none $ The executable (paint/PAINT.EXE) is the Windows 1.0 version of Paint. Wine properly recognises it as a "very old" Windows executable, but after doing that, Wine thinks that it is a DOS executable and tries to launch Dosbox. Dosbox gives the usual message: "This program requires Microsoft Windows." The lines about the old executable come from Wine while the rest of the lines come from Dosbox. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26715 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX --- Comment #1 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2011-04-10 22:01:01 CDT --- It won't work even under modern Windows versions. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26715 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #2 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2011-04-10 22:01:13 CDT --- Closing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26715 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh(a)gmail.com --- Comment #3 from Jerome Leclanche <adys.wh(a)gmail.com> 2011-04-11 13:35:33 CDT --- (In reply to comment #1)
It won't work even under modern Windows versions.
It still shouldn't call DOSBOX, should it? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26715 --- Comment #4 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2011-04-11 21:29:33 CDT --- (In reply to comment #3)
It still shouldn't call DOSBOX, should it?
Depends on the executable I'd guess. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=26715 --- Comment #5 from Spammer <spammis(a)spam.la> 2011-04-13 13:19:37 CDT --- This seems to be true for most Windows 1.x and 2.x programs. I tested all the ones included with Windows 1.x and Windows 2.x and the only ones not sent to Dosbox were MSDOS.EXE (Win1+2) and MSDOSD.EXE (file only present in Win1), which instead gave a different error message: wine: Bad EXE format for D:\MSDOS.EXE Wine was set to emulate Windows 2.0 in winecfg when I tested this. I've also observed exactly the same result when running Win1 PAINT.EXE with winecfg emulation mode set to WinXP, so the Windows version set in winecfg probably doesn't affect anything. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 Serentty <noname422(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |noname422(a)gmail.com --- Comment #6 from Serentty <noname422(a)gmail.com> --- I don't get why this was closed. I understand that compatibility with such old Windows programs is not a priority for the Wine project, but given that Wine ostensibly offers some very minimal support for such programs (after all, those version of Windows are allowed to be set in Wine's configuration), one would expect Wine to at least try to run these executables, even if it fails, and that a bug preventing Wine from even trying to run them would at least be something to look at. Also, the comment that these programs will not work on modern versions of Windows is not entirely true. Some programs meant for Windows 1.01 will still run on the 32-bit version of Windows 10, at a significant number of programs meant for Windows 2.0 will. I get that this is not as glamorous as getting the latest DirectX 12 games working, but Wine is in many cases the best way to run 16-bit software for Windows on a modern operating system. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 Serentty <noname422(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry(a)baikal.ru -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 Serentty <noname422(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |spammis(a)spam.la -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|dmitry(a)baikal.ru | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Win1.0 executable triggers |16-bit real-mode |Dosbox |executables from Windows | |1.0 cause DOSBox to be run | |(vm86 mode not supported on | |64-bit Linux) Hardware|x86 |x86-64 CC| |focht(a)gmx.net --- Comment #7 from Anastasius Focht <focht(a)gmx.net> --- Hello Serentty, these 16-bit apps from Windows 1.0 are real-mode executables, hence require vm86 mode. This won't work on modern Linux distros with 64-bit kernel by design. You could probably make it work by using a 32-bit Linux kernel and Wine 3.0 (Wine 3.1+ adds requirement for DOSBox). You also need 'vm.mmap_min_addr=0' to allow DOS apps to be mapped into low memory range etc. Alternatively install Windows 1.0 using DOSBox along with FreeDOS/MSDOS on a virtual disk and run the applications from there. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 --- Comment #8 from Serentty <noname422(a)gmail.com> --- Ah, I see. So, it's possible to run 16-bit applications for Windows 3.1 because they run in protected mode, then. In this case, it still seems to be like it would be useful to have Wine detect that this won't work on a 64-bit operating system, and to prevent the behaviour of trying to run the executables in DOSBox (and to at least attempt to run them on 32-bit operating systems). If I can find where this happens in the loader code, I would be willing to submit a patch. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 Dave <daveypy(a)outlook.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daveypy(a)outlook.com --- Comment #9 from Dave <daveypy(a)outlook.com> --- How about emulation of "real mode" within Wine itself? Maybe with the help of virtualisation (which will not cause performance issues)? Emulation would overcome the hardware/kernel limitations and allow Wine to run many more Windows programs from the past, probably more than Windows 10 can. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 --- Comment #10 from Serentty <noname422(a)gmail.com> --- (In reply to Dave from comment #9)
How about emulation of "real mode" within Wine itself? Maybe with the help of virtualisation (which will not cause performance issues)?
Emulation would overcome the hardware/kernel limitations and allow Wine to run many more Windows programs from the past, probably more than Windows 10 can.
This is something I would really like to look into. I would be willing to work on such a layer, but I worry that it wouldn't be accepted for merging due to the low demand. I think it's a real shame that Wine has near 100% coverage of Windows history, but is missing the first two versions. Such a layer would also be useful for running Windows 3.1 programs in distributions that don't allow modifying the LDT. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 Rodesam <rodesam(a)proton.me> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rodesam(a)proton.me --- Comment #11 from Rodesam <rodesam(a)proton.me> --- DOSBox already has real mode emulation and is open source. Can that be merged into or utilized by Wine? Or conversely, DOSBox to be extended with Wine components, so that Win 1.x/2.x real mode programs can be run directly into DOSBox (with the help of the host OS) without installing Windows? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 --- Comment #12 from Rodesam <rodesam(a)proton.me> --- OTVDM reportedly supports those and works in wine, so can it can be backported? https://github.com/otya128/winevdm/issues/1231 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #13 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, I'm fine with Wine launching DOSBOX and the user installing MSDOS+Windows 1.x/2.x/3.x in that DOSBOX. I don't see the benefit of Wine duplicating what DOSBOX already does good. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=26715 --- Comment #14 from Rodesam <rodesam(a)proton.me> --- @Olivier, I think the purpose of Wine is to allow Windows programs to run under Linux. In DOSBox the user can install Win3.x (and Win9x in some forks), but regardless of that - Wine provides support for the Win3.x and Win9x programs to run *without* installing any Windows. Same is for Virtual Machines - you can install latest Windows there, but Wine strives to provide support for Windows programs directly. So, Win1.x and Win2.x programs compatibility should not be different from the above examples - Wine should allow to run them directly? OTVDM already has the solution for Win1.x and Win2.x - and I hope it can be backported to Wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla