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@winehq.org ReportedBy: spammis@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.
http://bugs.winehq.org/show_bug.cgi?id=26715
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-10 22:01:01 CDT --- It won't work even under modern Windows versions.
http://bugs.winehq.org/show_bug.cgi?id=26715
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-10 22:01:13 CDT --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=26715
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #3 from Jerome Leclanche adys.wh@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?
http://bugs.winehq.org/show_bug.cgi?id=26715
--- Comment #4 from Dmitry Timoshkov dmitry@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.
http://bugs.winehq.org/show_bug.cgi?id=26715
--- Comment #5 from Spammer spammis@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.
https://bugs.winehq.org/show_bug.cgi?id=26715
Serentty noname422@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |noname422@gmail.com
--- Comment #6 from Serentty noname422@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.
https://bugs.winehq.org/show_bug.cgi?id=26715
Serentty noname422@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry@baikal.ru
https://bugs.winehq.org/show_bug.cgi?id=26715
Serentty noname422@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spammis@spam.la
https://bugs.winehq.org/show_bug.cgi?id=26715
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|dmitry@baikal.ru |
https://bugs.winehq.org/show_bug.cgi?id=26715
Anastasius Focht focht@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@gmx.net
--- Comment #7 from Anastasius Focht focht@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
https://bugs.winehq.org/show_bug.cgi?id=26715
--- Comment #8 from Serentty noname422@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.
https://bugs.winehq.org/show_bug.cgi?id=26715
Dave daveypy@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |daveypy@outlook.com
--- Comment #9 from Dave daveypy@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.
https://bugs.winehq.org/show_bug.cgi?id=26715
--- Comment #10 from Serentty noname422@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.
https://bugs.winehq.org/show_bug.cgi?id=26715
Rodesam rodesam@proton.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rodesam@proton.me
--- Comment #11 from Rodesam rodesam@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?
https://bugs.winehq.org/show_bug.cgi?id=26715
--- Comment #12 from Rodesam rodesam@proton.me --- OTVDM reportedly supports those and works in wine, so can it can be backported? https://github.com/otya128/winevdm/issues/1231
https://bugs.winehq.org/show_bug.cgi?id=26715
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #13 from Olivier F. R. Dierick o.dierick@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.
https://bugs.winehq.org/show_bug.cgi?id=26715
--- Comment #14 from Rodesam rodesam@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.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla