Wine 3.0 Still Expected Around EOY With D3D11; Wayland & D3D12 On Roadmap

[timrichardson]

Any information about Office 365 support? It would be nice to not have to load an entire Windows VM just to run Office.

LibreOffice, while fine for my own personal needs, doesn't cut it for the work I do that involves sharing with other people. It manages to completely garble the formatting of so many presentations and documents it's not even funny. I wouldn't dream of editing something in LibreOffice that was created in MS Office and then sending that edited file back out.

LibreOffice is pretty good now in terms of MS Office fidelity, lightyears ahead of where it was only two years ago. Using it with most MS Office files is reality, not dreaming, in my experience, although the whole MS Office file format is tedious now. Most of the time when a client sends me an MS Office doc, I convert it to a Google doc and share it back with them. no one complains.

Office 365 is a bundle of simple Web editors and desktop Office. You must be asking about the desktop office. I use Crossover Linux and it runs Office 2013 quite well and Office 2010 excellently which is good enough 99% of the time (Word, Excel and Powerpoint).

[nanonyme]

WSL under windows has most of the same problems wine does. Yes you can run some graphical applications under WSL but you start running into the memory difference nightmares. Both are compatibility layers and it unlikely that both will ever run everything because both sides be it windows or linux is a moving target.

Then again, use cases are often also different. WSL is more likely to be used for command-line-driven power-user things whereas Wine is more likely to be used for playing games with graphics

[nomadewolf]

An interesting sub project would be to implement DX 9, 10, 11, 12 and Vulkan itself all on top of Vulkan Linux.
But maybe it'd be too big of a project...

[OneBitUser]

Or maybe it's time for operating systems like MacOS and linux and BSD to impliment windows API's natively. And for those that choose not to, too fucking bad. Idiots. That way wine can -actually- be a wrapper and not an emulator. Because that's -exactly- what it is.

It should have been started 15 or more years ago, and probably -would- have started then if not for wine's flat out lies. Wine still has horrible compatibility and as long as they continue designing it to be such a high level emulator it never ever will.

I doubt you understand how an emulator or WINE works.
I also doubt you understand how software licensing and closed source software works.

"implementing Windows APIs"... sure, great idea, it should be easy once Microsoft open sources those APIs.
Just take a look at ReactOS: it aims to re-write Windows in open-source, and they have to reverse engineer everything, while they have had to fend off patent lawsuits from Microsoft. And they are ~10-15 years behind the current MS products. Imagine someone trying to implement D3D11, DX12 or any other current MS crap natively on linux. It would be a legal nightmare. It would also prevent any distribution from including these solutions in any way.

So I am rather hoping you're just trolling.

[oiaohm]

Wow, the leaps of logic you just made are astounding at the most fundamental levels. Just wow!So as a programmer you must have some idea what runtime behavior means right? It certainly is much more than just latency and timing. Passing data between one API's format and another API's format at the highest possible level while duplicating the runtime behavior of the first is not trivial. It's damn sure is not just a passthrough.

Duplicating run-time behaviour is something wine avoids as many times as possible. What a FIXME: message out of wine is you have hit a stub. A stub is copy of a windows function that either returns the success or failure value of the function what ever makes applications happy. There is really nothing implemented behind there. First thing that disappears when you are not a emulator is worrying about timing. Second thing is exactly matching run-time behaviour. Compatibility layer close enough is good enough as long as the applications run and functions correct for user.

That is the problem ideas of a emulator are the wrong ways of doing stuff under a compatibility layer. Compatibility layer just care that the targeted applications run correct for users no how wrong compared background it runs. You will hear Reactos developers saying Wine is done by someone insanely nuts because there is so many places where wine internal behaviours are nothing like windows. Wine run-time behaviours are somewhere between 9x and NT design operating systems with some of it own uniqueness thrown in for good measure.

If you trace execution paths inside some applications running in wine you will see them using different code paths to what they use under any version of windows. So wine run-time behaviour is unique. Unique run-time behaviour is not something you find in an emulator functioning correctly right. Unique run-time behavour is perfectly acceptable to something called a compatibility layer because its only compatibility not emulate.

One of the important differences about a compatibility layer and a emulator. Is that a compatibility layer has absolute contempt for run-time behaviours and be breaking them left right and centre this starts with timings then goes to execution paths..... All these differences add up and at some point its not valid to call it a emulator any more.

Some cases wine is a passthrough lot of opengl is passed straight across. Sound system you get formats alsa and pulse and other sound systems understand.

"implementing Windows APIs"... sure, great idea, it should be easy once Microsoft open sources those APIs.
Just take a look at ReactOS: it aims to re-write Windows in open-source, and they have to reverse engineer everything, while they have had to fend off patent lawsuits from Microsoft. And they are ~10-15 years behind the current MS products. Imagine someone trying to implement D3D11, DX12 or any other current MS crap natively on linux. It would be a legal nightmare. It would also prevent any distribution from including these solutions in any way.

Why do a compatibility layer instead of straight up doing a emulator.

https://wiki.winehq.org/Clean_Room_Guidelines

OneBitUser is on the correct track. Implementing based of what application use and skipping what you can you avoid implement a lot of stuff that matches Microsoft Patents. So wine is independent development that happens to look like the Windows API. Its less of a legal fight doing a compatibility layer where you can ignore matching run-time behaviours alot then doing a emulator.

Gallium Nine does it for direct x 9 but this required having cooperation from driver developers. Its very hard to convince driver developers to support extra interfaces.

Of course wine project has a few reasons for not touching Gallium Nine a big one is that is only Direct X 9. It was kind of a shock to lead developer of Gallium Nine to find out that there are Dx10/Dx11/Dx12 applications that do at times run parts using Direct X 9 so now you need all those Direct X implementations to get along. Because you have programs passing items created in one version of direct x into a different version of direct x. He was not getting why wine mainline developers were like when are you doing DX10,DX11,DX12 support. So implementing a Direct X to support all Direct X applications with minimal behaviour requirements require doing all the direct x versions with compatibly between them.

[duby229]

Duplicating run-time behaviour is something wine avoids as many times as possible. What a FIXME: message out of wine is you have hit a stub. A stub is copy of a windows function that either returns the success or failure value of the function what ever makes applications happy. There is really nothing implemented behind there. First thing that disappears when you are not a emulator is worrying about timing. Second thing is exactly matching run-time behaviour. Compatibility layer close enough is good enough as long as the applications run and functions correct for user.

That is the problem ideas of a emulator are the wrong ways of doing stuff under a compatibility layer. Compatibility layer just care that the targeted applications run correct for users no how wrong compared background it runs. You will hear Reactos developers saying Wine is done by someone insanely nuts because there is so many places where wine internal behaviours are nothing like windows. Wine run-time behaviours are somewhere between 9x and NT design operating systems with some of it own uniqueness thrown in for good measure.

If you trace execution paths inside some applications running in wine you will see them using different code paths to what they use under any version of windows. So wine run-time behaviour is unique. Unique run-time behaviour is not something you find in an emulator functioning correctly right. Unique run-time behavour is perfectly acceptable to something called a compatibility layer because its only compatibility not emulate.

One of the important differences about a compatibility layer and a emulator. Is that a compatibility layer has absolute contempt for run-time behaviours and be breaking them left right and centre this starts with timings then goes to execution paths..... All these differences add up and at some point its not valid to call it a emulator any more.

Some cases wine is a passthrough lot of opengl is passed straight across. Sound system you get formats alsa and pulse and other sound systems understand.



Why do a compatibility layer instead of straight up doing a emulator.

https://wiki.winehq.org/Clean_Room_Guidelines

OneBitUser is on the correct track. Implementing based of what application use and skipping what you can you avoid implement a lot of stuff that matches Microsoft Patents. So wine is independent development that happens to look like the Windows API. Its less of a legal fight doing a compatibility layer where you can ignore matching run-time behaviours alot then doing a emulator.

Gallium Nine does it for direct x 9 but this required having cooperation from driver developers. Its very hard to convince driver developers to support extra interfaces.

Of course wine project has a few reasons for not touching Gallium Nine a big one is that is only Direct X 9. It was kind of a shock to lead developer of Gallium Nine to find out that there are Dx10/Dx11/Dx12 applications that do at times run parts using Direct X 9 so now you need all those Direct X implementations to get along. Because you have programs passing items created in one version of direct x into a different version of direct x. He was not getting why wine mainline developers were like when are you doing DX10,DX11,DX12 support. So implementing a Direct X to support all Direct X applications with minimal behaviour requirements require doing all the direct x versions with compatibly between them.

So the good thing in my opinion is that the next time I hear someone complain about why doesn't wine work right, I can point them right here at this post.

After reading this I'm nearly convinced what you call an emulator is what I would call a simulator. Very, very different concepts. Emulation is the striving for compatibility and simulation is striving for the bit exact function.

[ruthan]

Is somewhere some working Android package for download and test it on ARM or Android x86? Because i saw only Crossover videos and its long, long time without progress and real release..

[oiaohm]

So the good thing in my opinion is that the next time I hear someone complain about why doesn't wine work right, I can point them right here at this post.

After reading this I'm nearly convinced what you call an emulator is what I would call a simulator. Very, very different concepts. Emulation is the striving for compatibility and simulation is striving for the bit exact function.

You have a major term errors.

https://en.wiktionary.org/wiki/emulation

(computing) Running a program or other software designed for a different system, by simulating parts of the other system.

https://en.wiktionary.org/wiki/emulator

(computing) A piece of software or hardware that simulates another system.

Emulation is form simulation in computing define. So a simulator is an emulator the strictest form of an emulator.

https://en.wiktionary.org/wiki/simulator

It also surprises most people computing terminology there is no such thing as simulator in software. Simulator is a physical thing that people do training in not software. The software for a simulator is in fact an emulator.

Compatibility layer is striving for compatibility without caring about simulating parts any more than it has it. So if you can achieve application compatibility by doing something completely different and provide user with better performance this is acceptable to something that is a compatibility layer. Not acceptable to something called a emulator/emulation under computing world defines.

Wine is strictly and absolutely not an emulator or emulation by computer word defines as it method is not simulating but compatibility.

There are benefits and disadvantages to emulator or compatibility layer paths. It is important not to mix the two up as there are massive number of differences.

https://en.wiktionary.org/wiki/compatibility

(computing) the capability that allows the substitution of one subsystem (storage facility), or of one functional unit (e.g., hardware, software), for the originally designated system or functional unit in a relatively transparent manner,

Like how computing define of compatibility includes the word relatively. Compatibility does not require perfection.

Emulation is striving for Simulation. Compatibility layer is striving for compatibility. Very different development goals.

[oiaohm]

So the good thing in my opinion is that the next time I hear someone complain about why doesn't wine work right, I can point them right here at this post.

After reading this I'm nearly convinced what you call an emulator is what I would call a simulator. Very, very different concepts. Emulation is the striving for compatibility and simulation is striving for the bit exact function.

You have a very major term error. In computing terms for software simulator does not exist. Software that runs on a simulator is an emulator.

Emulatior is striving for simulation.
Compatibility layer is striving for compatibility.
This is the computing world defines.

[duby229]

You have a very major term error. In computing terms for software simulator does not exist. Software that runs on a simulator is an emulator.

Emulatior is striving for simulation.
Compatibility layer is striving for compatibility.
This is the computing world defines.

You're just so wrong, and what makes it shameful and retarded is the position you have. A simulator tries to recreate a bit exact environment, wine doesn't that, it translates from one API's format into another API's format to emulate the former API's environment. That's exactly what it is whether you ever admit it or not. You're own damn links that you posted talk about this, you should consider trying to comprehend them. A simulated environment strives to be bit exact. Where-as an emulated environment strives to be compatible without being bit exact and that's exactly what wine does to the letter. Simulation and emulation is -NOT- the same thing. Wine is -NOT- a simulator it's an emulator.

EDIT: Also what I find to be totally screwed up is the implication you made that you don't give a shit about duplicating the runtime behavior of windows libraries.... Astounding.... In other words although you call wine a compatibility layer, which is just another way of saying emulator, you don't give a shit about compatibility. With your mindstate I just don't see how wine will ever be capable of meeting Linux users needs. I don't see it happeing ever. Wine will always be a case by case basis in every single case permanently. That's so unfortunate.

As long as you guys don't care about runtime behavior you will always continue to break it for various windows apps on every version, just the same way as you always have. And that's wines biggest problem. Not caring about runtime behavior is -EXACTLY- the same thing as not caring about compatibility.