Wine 5.0 Released With Big Improvements For Gaming, Countless Application Fixes

[starshipeleven]

Half Life 1.

Nope.

The original one (from the physical disks) does not run here (someone on the web claims it does, some claim they needed to change configs and add command line arguments, some claim they can't get it running while on Win7 it runs fine), tried all tricks, and then fresh reinstall and all (gaming rig, not a big issue), no dice.

The one from Steam usually runs, also on my PC, but not always (someone still has issues, but it's not prevalent). Coincidence? I think not.

Want to talk about another that does not work on Win10 if you install the one from physical disks (or old pirated downloads) but if you download from Steam/GoG works fine? What about Knights of the Old Repubblic.

I also have issues running the original Nexus the Jupiter Incident from disks, while the one in Steam was fixed to work properly on later Windows.

[starshipeleven]

So the best way to secure a device is to stuff some old unmaintained libs with hundreds of security flaws into a container and run your apps there? I rather run those apps on updated libs and you can still use namespaces if you want to secure them, that isn't something exclusive to containers...

The point is that if you are securing them anyway the need to have/use libs without security flaws is much less.

Actually updating applications and validating everything to not break with new library versions is not trivial in many cases, especially for smaller teams or proprietary applications where they live off sales and may very well not think it is profitable enough updating very frequently.

[RBilettess]

So does anybody know which games (could) benefit from PE modules at the moment?
I've installed MinGW and created a new prefix with Lutris. How can I verify that PE modules actually have been created?

[oiaohm]

So does anybody know which games (could) benefit from PE modules at the moment?
I've installed MinGW and created a new prefix with Lutris. How can I verify that PE modules actually have been created?

PE modules instead of the elf-pe hybrids make very little difference to application compatibility.

dir /opt/wine-devel/lib64/wine/*.dll these would all be pe. dir /opt/wine-devel/lib64/wine/*.dll.so would be all elf-pe hybrids. Of course you will have to alter those paths based on where you installed wine. Hybrid elf-pe can call out to native Linux .so files and a pure PE dll cannot.

Using PE in the fake dll made copy protection better. The modules themselves are still sitting behind the same fake dlls so make very little difference.

https://github.com/AndreRH/hangover

The PE modules stuff is more prep work for hangover. The work has basically got it down to ~70 dll.so(elf-pe hybrids still) that are reaching out to host libraries.~670 .dll (pure pe that are not reaching out to host libraries). With distributions wanting to get rid of providing 32 bit libraries large number of ~70 will have to be thunked from 32 bit to 64 bit mode.

[RBilettess]

PE modules instead of the elf-pe hybrids make very little difference to application compatibility.

Thanks for the clarification. I was somehow hoping this could help with Valves CEG DRM :-/

[Weasel]

https://www.reddit.com/r/HalfLife/co...ndows_10_help/

Original Half Life 1 had a very good run its dead on windows 10. There was also a update for windows 7 to fix Half life 1 issues on windows 7. So try again. There is a limited life span.

So another game wheeled out to claim ultra long windows ABI that is in fact example its not ultra long. You have about 5 years of stability once you start looking closer any more programs break with windows.

Works fine here, so it's definitely not an ABI problem (which would always crash in same place predictably everywhere), stop using the word ABI, didn't I tell you already? You're a true lost cause.

For your good I hope you're not using full screen because that's the issue with shit in 99% of cases.

Wine implementation of the windows API use windows version values to change how particular functions work. Also uses winetricks to use old microsoft runtime parts in different prefixes to make more ABI versions in the short term as well .

Microsoft runtimes are separated by versions and you always use the "old" one even on Windows, they're different DLLs. As for windows version checks, that's extremely rare in Wine, and usually it's for Win16 stuff (16-bit programs).

If not, provide sources and examples of different behavior based on it (link to the wine mirror on github if you want).

What is the safer outcome
1) The program fail out right when you attempt to run it.
2) The program go forwards and fails on the user at some random point in usage.

The Linux world is choosing one. Failure to Load is not exactly a bug. It fails from the start you place it in a container/chroot/flatpak/snap/... and use it from there with the correct parts the program expects.

I don't give a shit what you consider safe or not. The point is that failing to load is an ABI/API break. This is an objective fact, "safety" is subjective. So Linux userland, not Windows, breaks API/ABI left and right, period.

Glibc from version 2.0 has not in fact removed a function. This is 1997 has in fact included as many functions as possible to let old applications launch.

Stop using glibc as an example every time we argue about this. How many times did I say that glibc is indeed a library that preserves its ABI/API in general just like Windows (well, with rare exceptions).

I have no problems with glibc, but with the other pathetic libs that change API versioning periodically, and you know it, so fuck off with your ignorance.

Remember how Microsoft was giving people free vm with XP in it with windows 7 so old applications would work or do you want to forget that happened weasel. This is not the first time Microsoft has suggest a virtual machine/container of some form for older applications.

Again, that's because those apps abuse internal structures and other low level undocumented hacks.

https://devblogs.microsoft.com/oldne...23-00/?p=41373

Linux kernel does not keep deprecated syscalls around forever. http://man7.org/linux/man-pages/man2/syscalls.2.html It somewhere between 2 years to 30 years does a old deprecated version of a syscall disappear from the Linux kernel including the ID.

I don't see a single removed function there, neither your piece of shit CLAIM about 2 to 30 years.

CTRL+F on your page with "year", or "30" not found (except versioning).

You think posting a link and then making a bullshit claim, even if that link has nothing you claim, is an argument? Who do you think you're fooling? Go back to the circus.

[Weasel]

Nope.

The original one (from the physical disks) does not run here (someone on the web claims it does, some claim they needed to change configs and add command line arguments, some claim they can't get it running while on Win7 it runs fine), tried all tricks, and then fresh reinstall and all (gaming rig, not a big issue), no dice.

The one from Steam usually runs, also on my PC, but not always (someone still has issues, but it's not prevalent). Coincidence? I think not.

Want to talk about another that does not work on Win10 if you install the one from physical disks (or old pirated downloads) but if you download from Steam/GoG works fine? What about Knights of the Old Repubblic.

I also have issues running the original Nexus the Jupiter Incident from disks, while the one in Steam was fixed to work properly on later Windows.

Try without fullscreen, that's the cancer of compatibility problems in most cases. Hell, it's buggy even on current-generation games in many cases (especially when ALT-Tabbing).

[oiaohm]

Works fine here, so it's definitely not an ABI problem (which would always crash in same place predictably everywhere),

Sorry no games due to their locking methods don't always do stuff in 100 percent predictable way. So game crashes like it or not are randomised and race conditioned when there are API/ABI issues.

For your good I hope you're not using full screen because that's the issue with shit in 99% of cases.

Funny you go and says it would have crashes in the same place predictably and then you mention full screen mode. Allow for the annoying spinlocks in the game engine what are you look at.

There is another fun bug for those who really do know the game halflife 1 who have made maps like me. Monster randomisation also wrong if you don't have the updated versions of halflife 1 so the single player in places is way easier than it should be and others way harder so not playing the game how the maker of the game intended. All because a function that use to work one way and does not work that way any more.

I don't give a shit what you consider safe or not. The point is that failing to load is an ABI/API break. This is an objective fact, "safety" is subjective. So Linux userland, not Windows, breaks API/ABI left and right, period.

But there are two ways to have a ABI/API break.
1 is application fails to load.
2 application fails while running.

Fail while running the function in the API/ABI is different to how it was prior documented. This happens under windows. You are not considering the second API/ABI breakage route.

You have to break API/ABI at some point its a choice of one of two methods.

Stop using glibc as an example every time we argue about this. How many times did I say that glibc is indeed a library that preserves its ABI/API in general just like Windows (well, with rare exceptions).

I have no problems with glibc, but with the other pathetic libs that change API versioning periodically, and you know it, so fuck off with your ignorance.

I pointed to the loki game example. I can point to more Linux native games that have gone stupid due to glibc version changes resulting in minor behavour changes when using the API/ABI.

Reality I use glibc because its shows that keep on extending the dll/so to keep backward compatibility does not work long term. This is something you wish to ignore every time you bring this up.

I don't see a single removed function there, neither your piece of shit CLAIM about 2 to 30 years.

CTRL+F on your page with "year", or "30" not found (except versioning).

http://man7.org/linux/man-pages/man2/syscalls.2.html

get_kernel_syms(2) 1.0 Removed in 2.6 This one is 1994 to 2003. What is a function life span of 7 years. If you dig back it spent 2 years as deprecated.
Basically you are blind if you cannot find a single removed function there. There are many removed functions.

So the Linux kernel API/ABI to userspace is not 100 percent set in stone.

Something that you cannot simple search on but the evidence is that man page like it or not. You have to look up the release dates of the version of the functions were added and when they were removed completely. Yes that removed is not deprecated or disabled that gone.

Did I say that the exact numbers in year would be on my reference no. It contained the information to work out what the window is. It requires a little bit of work looking up the kernel release dates of when the function was added than when it was removed. There are some from version 1.0 covered in the Linux kernel mailing list to removed this year or next this is where the 30 year comes from.

Really you cannot see the word removed for remove function? That removed is completely removed.

Microsoft runtimes are separated by versions and you always use the "old" one even on Windows, they're different DLLs. As for windows version checks, that's extremely rare in Wine, and usually it's for Win16 stuff (16-bit programs).

If not, provide sources and examples of different behavior based on it (link to the wine mirror on github if you want).

There is no point doing this if you cannot read the syscall man page.

https://github.com/wine-mirror/wine/blob/6edf38c205a6f5db369bf24a7edd4623ee6e32f1/dlls/wined3d/directx.c#L584

But this is one example where wine does not always do the same thing based on what windows version it set to.

As for windows version checks, that's extremely rare in Wine, and usually it's for Win16 stuff (16-bit programs).

I just gave a example in 32/64 bit code of version check altering behaviour of wine. Just find one in the 16 bit code. Guess what weasel the idiot version check alteration of behaviour appears in 32 bit and 64 bit compadiblity libraries of wine not the 16 bits ones.

Microsoft in fact wrote a proper standard covering the 16 bit functions. Microsoft did not make a proper standard covering the 32 and 64 bit functions this has lead to a stack of implementation errors.

Try without fullscreen, that's the cancer of compatibility problems in most cases. Hell, it's buggy even on current-generation games in many cases (especially when ALT-Tabbing).

Stop being a Weasel. Half-life is a game that is in fact designed to run fullscreen. Old versions of half-life can can run fullscreen fully stable under wine and old versions of windows. So this is you basically admitting not working right.

ALT-Tabbing out of game causing game to crash is a intentional added feature to a lot of games to prevent switching away to access cheats.

https://answers.microsoft.com/en-us/windows/forum/all/will-microsoft-office-2000-work-on-windows-10/381df7b9-2a9d-454a-b74b-8de9cacebbc2

Microsoft answers repeatably that 5-10 years is all you can expect stuff to work right. Past 5-10 years expect programs to have random issues like not being able to run full screen when they should be able to.

[ZeroPointEnergy]

I pointed to the loki game example. I can point to more Linux native games that have gone stupid due to glibc version changes resulting in minor behavour changes when using the API/ABI.

Reality I use glibc because its shows that keep on extending the dll/so to keep backward compatibility does not work long term. This is something you wish to ignore every time you bring this up.

I just put this to the test, dusted off some old Alpha Centauri CDROM and went about analyzing why it doesn't run. There are 4! missing functions, and it looks like the issue isn't even in glibc. I created a shim that reimplements those functions and now it just works again.

https://github.com/ZeroPointEnergy/smacshim

So I actually was wrong in that Linux userland is actually remarkably stable it seems. At least when it comes to the libs this game uses. I mean the shim is literally just 24 loc and it works again. Not bad for a 20 year old binary.

BUT! It even works better and is exactly because of the updated libs as I said. That old Loki runtime that was usually used to run the old game, which is the approach you say is the best for compatibility had broken sound. Because the libs where so old they predated pulseaudio. Therefore the sound is not working with the Loki Runtime. It was actually recommended to use the gog windows version of the game on Linux because it worked better.

New versions of the libs have support for pulseaudio and that is why with the shim SOUND JUST WORKS.

I did not test this heavily, so maybe some stuff is still missing, I only played a couple of minutes.

[oiaohm]

I just put this to the test, dusted off some old Alpha Centauri CDROM and went about analyzing why it doesn't run. There are 4! missing functions, and it looks like the issue isn't even in glibc. I created a shim that reimplements those functions and now it just works again.

https://github.com/ZeroPointEnergy/smacshim

So I actually was wrong in that Linux userland is actually remarkably stable it seems. At least when it comes to the libs this game uses. I mean the shim is literally just 24 loc and it works again. Not bad for a 20 year old binary.

The Linux userspace is highly stable but is also stubborn as hell. Like distribution removed old gtk and old gtk applications don't run at all until you provide a runtime with the missing bits.

BUT! It even works better and is exactly because of the updated libs as I said. That old Loki runtime that was usually used to run the old game, which is the approach you say is the best for compatibility had broken sound. Because the libs where so old they predated pulseaudio. Therefore the sound is not working with the Loki Runtime. It was actually recommended to use the gog windows version of the game on Linux because it worked better.

I don't have that game right on my machine but from memory that sound issue is not pulseaudio change that is the 2010 remove oss support from kernel by many distributions.

https://sourceforge.net/projects/osspd/

Its use this program above to fix with the loki game runtime..

New versions of the libs have support for pulseaudio and that is why with the shim SOUND JUST WORKS..

Basically there are two ways to skin that problem and you are taking number 2.

I did not test this heavily, so maybe some stuff is still missing, I only played a couple of minutes.

The reality more often than not due to follow why small fix and little testing turns out to be perfect:

But there are two ways to have a ABI/API break.
1 is application fails to load.
2 application fails while running.

With Linux majority of the failures when something is wrong at the ABI/ABI is application fails to load. So you instantly know you have a problem and can work out the correct fix. Windows not so much.

HEAVY METAL: FAKK2 really old Linux native closed source game. Provide one old library use modern libraries for everything else and it works fine.

Linux ABI compatibility with old applications does not look that bad. Need a better user interface.

What is missing is not extend the libraries to hell.

http://www.alex-ionescu.com/?p=39

But a application compatibility database stuffed with these shims under windows. These shims can be distribution neutral.

And parties willing to step up to maintain like GTK2 runtimes outside distributions

Lets now look at Windows. Microsoft has the application compatibility database and has the runtimes yet you have less success getting old applications to work right. The core foundation ABI provided by windows you need to be stable so shimming/runtiming over the top in fact works is not stable.

Lot of ways lutris and programs like it could do all the shim and distribution neutral runtime stuff required.

So its not that modern Linux distributions cannot run really old Linux applications. Its more the number of hoops you have to jump though to-do it with the final result being a program that runs well once you have jumped though the hoops. Windows you jump though all the hoops and the old application still runs badly if at all.

Basically people have it backwards. Linux distributions are asking for more effort to use old applications but reward you for that. Windows asks for less effort to run old applications but they don't run like they should.

The fact the old Linux applications runs well after effort mean its a interface problem and resources not being put into this problem to make it easy. Windows problem is core issues.

Big thing people miss is Microsoft with Office would not be drawing the line at 10 years old for no reason for compatibility. Please note MS Office got updates for the first 5 years of it life. So this is only 5 years without updates before busted.

Really I am sick of people who make applications for Windows coming to the Linux world and asking for something that really don't get from Windows and not willing to put the resources in on the LInux side to get exactly what they are asking for. Its over due for the myth of windows long term ABI stability to die.

By the way the Windows ABI stability problems is one of the causes wine gets an application to work and a update to that application comes out and application no longer works with wine because application changed to using newer behaviour.

I remember the fun of maintaining windows machines and having the windows update hell. Where you install X update and Y program breaks then you remove X update to fix Y program and now Z program breaks because it updated for the new behaviour. Of course this is not breaking when you starting the program. Worst is breaking when you are at time saving so destroying the save file. This is behaviour I am happy to be without on Linux. If I have to jump though a few more hoops to run old applications so be it.