The Big Highlights Of Wine 5.0 From FAudio Integration To Vulkan 1.1 + A Ton Of Bug Fixes

[danger89]

Yeah. Where are the Visual compilers and the Windows libraries?

You just don't compile for Windows.

[oiaohm]

This isn't true, there is missing support for multiple buffers/multiple buffer flipping in early DirectX in WINE. This is why Warhammer Dark Omen still doesn't work properly despite being a DirectX 5.0 game. The error displayed by wine is:
err:ddraw:ddraw_surface7_Flip Can't find a flip target

That is a DX 7 weakness in wine in fact. You have particular Dx 7 games with the exact same problem. Heck it turns up with Diablo II LOD that is DX 8 using DX7 in places.

Fun part about this one I did not say that Wine DX 7 implementation is complete. Also this ddraw_surface7_Flip is in the name. The 7 there is for dx7.

There is no Dx 5 or 6 runtime in windows 2000 and newer. Dx5 and 6 applications on Windows 2000 and newer use the dx 7.

Not all Dx5 or 6 games use that feature. I have a original roll-cage game from 1999 that is Dx6 that works perfectly under wine.

But there are a few missing features that hammer Dx 5-7 applications and some dx 8 applications that use dx7 rendering in places. Fairly much any problem you see effecting a dx 5/6 application there will be another dx7 application out there effected by the same problem because its the same code.

There's also the glaring problem that WINE can't run 16-bit colour modes in 32/24-bit colour X11 sessions. Another issue which affects this title.

Again this is another generic problem effecting a large number of applications. Xephyr can work around that to a point throwing you back to software rendering. Its not exactly wine problem its a opengl /X11 problem from hell. When vendor opengl is in 32 bit mode it does not want to have a bar of 16 bit only color buffers(this is why forced back to software rendering). Same with X11 itself session only is designed to accept 1 buffer type at if it sees more than 1 it kind of get confused..

16 bit color on 32/24 bit session effect native to Linux SDL applications as well.

[DMJC]

Its not in fact missing. I run old dx5 and 6 games on wine. Dx1-7 are progressive upgrades. So a dx5 and 6 applications run with dx7 runtime.

This isn't true, there is missing support for multiple buffers/multiple buffer flipping in early DirectX in WINE. This is why Warhammer Dark Omen still doesn't work properly despite being a DirectX 5.0 game. The error displayed by wine is:
err:ddraw:ddraw_surface7_Flip Can't find a flip target
There's also the glaring problem that WINE can't run 16-bit colour modes in 32/24-bit colour X11 sessions. Another issue which affects this title.

[oiaohm]

That said, I know there are Win9x-era 32-bit programs that won't run on 64-bit Windows... I just don't specifically know the underlying reasons. (Does Win32 on 32-bit Windows support thunked calls into 16-bit DLLs? I think I remember hearing that.)

Wine allows 16 bit in 64 bit prefixes mostly out of laziness so wine does not have to detect 16 bit programs and run a substitution with 32 bit version as windows does with particular 16 bit installers. So wine 64 bit and 32 bit prefix both support thunked called into 16-bit dlls when using the 32 bit parts.

There are functions in the 32 bit windows ABI that are meant to fail when you have a 64 bit install of windows as well as not having 16 bit applications support that wine pure ignores and has anyhow. So 64 bit wineprefix will trigger particular functions in wine to fail and some programs when running their 32 bit version use these failures as a sign they should run the 64 bit version of program they included instead of the 32 bit one. So bugger we have to implement it this way.

There was a security fault Linux kernel had to fix so wine could use 16 bit protected mode segments in 64 bit mode that windows did not fix so Microsoft just dropped 16 bit support instead of fixing it. Yes reality 64 bit windows could run 16 bit windows programs if Microsoft really wanted it to by fixing a few memory management problems.

[ssokolow]

No that is a little more horrible than one thinks. Even under windows there are some 32 bit programs that don't run on a Windows 64 bit install. Even when all the bugs are out the wine 64 bit prefix you will still need a 32 bit prefix for some applications. Basically wine 64 bit prefix really cannot be better than a Windows 64 bit install.

Basically your theory is wrong. 64 bit prefix should not support everything the 32 bit prefix does and cannot to replicate Windows behaviour. One of the big hints to this as well go into winecfg in a 32 bit and 64 bit prefix and check the windows versions on offer. Yes the 32 bit version offers more windows versions and more windows quirks than the 64 bit version allows.

Thanks for the clarification. What I said was what I believed after trawling through a bunch of unhelpful Google result to try to make sure I had it right.

That said, I know there are Win9x-era 32-bit programs that won't run on 64-bit Windows... I just don't specifically know the underlying reasons. (Does Win32 on 32-bit Windows support thunked calls into 16-bit DLLs? I think I remember hearing that.)

[oiaohm]

In theory, a 64-bit Prefix should support everything 32-bit that a 32-bit Prefix supports but, in practice, there's still the occasional bug in the 64-to-32 support that means some programs will work in a 32-bit Prefix but not a 64-bit one. (Microsoft's .NET runtimes and XNA frameworks used to be the most notable examples. I'm not sure how things are these days.)

No that is a little more horrible than one thinks. Even under windows there are some 32 bit programs that don't run on a Windows 64 bit install. Even when all the bugs are out the wine 64 bit prefix you will still need a 32 bit prefix for some applications. Basically wine 64 bit prefix really cannot be better than a Windows 64 bit install.

Basically your theory is wrong. 64 bit prefix should not support everything the 32 bit prefix does and cannot to replicate Windows behaviour. One of the big hints to this as well go into winecfg in a 32 bit and 64 bit prefix and check the windows versions on offer. Yes the 32 bit version offers more windows versions and more windows quirks than the 64 bit version allows.

[ssokolow]

Another question: is wine 64bit able to play 32bit microsoft windows programs? None 64bit programs could play 32bit programs... though DLL should be playable both 32 and 64bit.

That's a bit of a complicated question to answer.

64-bit Wine should also install 32-bit libraries, similar to how 64-bit Windows will provide 32-bit compatibility support. However, you also get to choose whether your "Wine Prefix" (the folder containing your virtual C:\ and settings) is a 32-bit prefix or a 64-bit prefix. (Equivalent to a 32-bit or 64-bit install of Windows.)

In theory, a 64-bit Prefix should support everything 32-bit that a 32-bit Prefix supports but, in practice, there's still the occasional bug in the 64-to-32 support that means some programs will work in a 32-bit Prefix but not a 64-bit one. (Microsoft's .NET runtimes and XNA frameworks used to be the most notable examples. I'm not sure how things are these days.)

[Azrael5]

Another question: is wine 64bit able to play 32bit microsoft windows programs? None 64bit programs could play 32bit programs... though DLL should be playable both 32 and 64bit.

[ssokolow]

a question about Wine. Does wine process the file automatically if I insert the disk and run it?

It depends on your distro. Some of them use a kernel feature called binfmt_misc to register Wine as the loader for .exe files so you can launch them as if they're native Linux executables and it'll just Do The Right Thing™. (I've also seen people using binfmt_misc to do that for .jar files so you can type ./name_of_jar.jar in a terminal after marking it executable and have it Just Work™.)

By default, in addition to putting C:\ in ~/.wine/drive_c/ Wine creates a drive letter for each removable drive and a Z:\ mapping to your Linux filesystem root, and maps folders like My Documents to their Linux equivalents so that "just double-click an arbitrary thing" use-case can work as expected (and, since Windows provides the standard Open/Save dialogs, Wine can provide one that's aware of the real filesystem structure) but I recommend using something like PlayOnLinux so you can put each program in its own little world for easy removal or for running different Wine versions or installed dependencies if you do find a program that's picky.

I also prefer to configure my Wine to omit the Z:\ and the special folder assignments. Just because a Windows program isn't malicious doesn't mean it won't doodle all over your walls like a kid with a marker. (It's bad enough when Linux ports of games dump non-hidden folders into $HOME without Windows games dumping their save folders into $HOME/Documents rather than the AppData inside Wine's C:\.)

[pal666]

Yeah. Where are the Visual compilers and the Windows libraries?

The Visual suite isn't obsolete. People still use it.

on windows. why do you need it on linux? people are compiling windows software with linux compilers these days. by people i mean tiny projects like chrome and firefox