VOGONS


First post, by twiz11

User metadata
Rank Member
Rank
Member

Can Wine be ran under say Windows 10 x64?

Reply 1 of 8, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

Wine itself has never really worked under Windows. It is too tightly-linked with X-windows. The WineD3D libraries work under Windows; I have not heard any suggestions that they should not work under Windows 10.

There have been recent reports that Microsoft will allow some components of Ubuntu to run under Windows 10, so perhaps things will change in the near future, but nothing has changed yet.

Reply 2 of 8, by Jo22

User metadata
Rank l33t++
Rank
l33t++

A few years ago I ran Wine on Windows XP using AndLinux. 😁

But I guess you're asking whether Wine can run on the shiny new Linux subsystem in Win10 x64 ("Windows Subsystem for Linux", WSL) ?

I think this should be possible somehow, but file association with *.exe files could be troublesome.

And to be honest I haven't tried this myself yet. In fact, I know very little of it. 🙁
I only know that this Linux system is based on Ubuntu and that it requires native ELF binaries.

But I don't know whether it is resticted to ELF64 binaries or whether it also features a WoW64 like mechanism to execute ELF32 binaries.

You may wonder as to why this is so important.

Well, only the "32Bit version" of Wine can execute Win16 apps, as far as I know (this may or may not important for Win9x games).
So if someone would have to use the native "64Bit Version" of WINE, then compatibility would go down hill.
(It gets worse: Even the 32bit version of Wine has dropped support for Win 2.x binaries the last time I checked.)

Btw, I'm not sure whether "32Bit" refers to the type of Linux binary (elf32,x86) or the ARCH type (Win32").
This is something important to clarify. Maybe someone can explain this ? I found very little information about this.

Read more here:
http://superuser.com/questions/631035/16-bit- … in64-using-wine
http://unix.stackexchange.com/questions/12956 … t-debian-ubuntu

Native version
A native version for Windows is also possible, but more difficult.
Wine was written from ground up to use the X11 windowing system. They used this thing for about 20 years now
and a code shift is rather unlikely. There's also Wayland and Mir (no, not the space station), but this doesn't make things any easier.
Wine relies heavely on X11, so it either has to be ported to Windows or to be emulated using an translation-layer (like Wine itself).
This layer could then be supplied in the form of a DLL file, for example (like SDL, which DOSBox uses).

I hope this clears things up a bit.

I just hope none of the linux gurus reads this post.. Haha. 😅

Edit: I was too slow again. 😊 Jorpho is right. Some Wine parts can be used in Windows (and some VMs do also take advantage of this).

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 3 of 8, by Bladeforce

User metadata
Rank Member
Rank
Member

"(It gets worse: Even the 32bit version of Wine has dropped support for Win 2.x binaries the last time I checked.)"

Use playonlinux instead of one install of wine and you will never lose support for win 2.x binaries

Reply 4 of 8, by Jo22

User metadata
Rank l33t++
Rank
l33t++
Bladeforce wrote:

"(It gets worse: Even the 32bit version of Wine has dropped support for Win 2.x binaries the last time I checked.)"

Use playonlinux instead of one install of wine and you will never lose support for win 2.x binaries

Thanks a lot for this tip! Haven't tried this one before. 😀

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 6 of 8, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Thanks for asking! It's nothing special in particular, just a few utilities and games i'd like to keep.
To name a few.. Klotz!,Easel,Tetris,Starbase,Daleks,Metric Converter and an old tape labeling program (Caselinr, useful for datasettes).

There are also a few commercial programs like PageMaker and and some old database program.
Again, nothing really important. It's just sad to see support for Win16 is starting to become somewhat neglected.

The next version to be affected will be Win 3.x, I'm afraid. The lower limit will be Win95 then, just like the "compatibility tab" in WinXP.
And that's what I'm concerned about. Even though it is 2016 now, I still use a few Win16 programs, like MOD4WIN or dBase for Windows.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 7 of 8, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

I would think those particular Windows 2.x programs would have versions for 3.x or later which are just as good.

http://toastytech.com/guis/misc.html suggests converting a Win 2.x binary to run under later versions of Windows is pretty trivial. (I wonder why Wine decided to drop support?)

Reply 8 of 8, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Thanks a lot, Jorpho! 😁
Converting them seems to be the only way to get them working now, or using playonlinux as Bladeforce said.
Maybe I can also get newer versions of them, if there are any. If I can't, there's still the possibilty to run them on an older Windows in a VM or an emulator (like PCem).
So nothing is really lost, I guess. Still, having an open-source project like WINE to seamlessly support 80's software was really cool to think of!

Btw, I remember there also was another way which worked for Win9x. Late Win 2.x products had an "Windows 3.0 aware" bit set,
which essentialy was a flag (two actually, the second was for font handling) for Win 3.x to see whether that program
uses real-mode specific memory managment or not. If it didn't (flag set), it was considered to be "clean" and protected-mode compatible.

This flag -or the lack of it- was also responsible for the warning message, that showed up sometimes when running Win 2.x programs on 3.x.
Despite this, Windows 3.1 allowed to continue to execute the application but Win9x did not (NT and OS/2 did, as they had 3.1 built-in).
I think someone made an utility for this a long time ago, it was called Mark30 or something.

Anyway, modifying the resources is the way to go. The problem with WINE is that it nolonger recognizes the Windows 2.x headers (it thinks these are DOS programs).
So even if the program was marked as Windows 3.0 compatible, it probably wouldn't help.

Another thing I'm a bit worried about is the Linux kernal. There was an issue with several versions to not support 286 protected-mode code execution.
It was later "fixed" again, but I think it's more of a temporary hack.
Albeit other systems like MacOS X or BSD were not affected, this issue could cause the developers of WINE to drop Win16 support in a few years.

Here are a few more links to this topic, because they are hard to find. I hope twiz11 doesn't mind..

Linux Kernel 3.14 Breaks Wine for 16-bit Windows Applications
http://news.softpedia.com/news/Linux-Kernel-3 … ns-447273.shtml

Why was the support for old versions of Windows removed?
https://forum.winehq.org/viewtopic.php?f=2&t=24041

"Wine can mimic different Windows versions required for some programs, going as far back as Windows version 2.0.[35]
However, Windows 1.x and Windows 2.x support was removed from Wine development version 1.3.12."

broom02.revolvy.com/main/index.php?s=Wine%20(software)

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//