Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by duby229 View Post
    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..
    The computing world dictionary for software there is no such thing as a simulator. You are attempt to use general english defines.

    Simulation is a mathematical construct. Software Implementation of simulation is emulation. So the software form of a simulator is a emulator in the computing world dictionary. In the computing world dictionary the only thing that fits for what wine is the word compatibility.

    Originally posted by duby229 View Post
    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.
    Pull back and look inside windows and look what it does in compatibility modes. You will find that Microsoft windows does not give a rats about duplicating run-time behaviour either. Only gives a rats about being compatible that applications in fact work. Microsoft uses the word mode instead layer it is the same basic stuff.

    There is a resources thing as well. There are a lot of functions that Microsoft developers of windows created that no application other than Microsoft test applications ever used there is also a lot of functions inside windows 10 that are basically no operation functions like wine stubbed functions.

    Microsoft does not provide identical run-time behaviour between version of Windows. Microsoft only promise computer world define of compatibility.
    http://test.winehq.org/data/

    duby229 on that page Xp, 2003, Vista, 2008, Win7, Win8, Win10 is wine testsuite running on that version of windows testing stuff we know applications use. The wine test cases also include a list of tests that are disabled on particular versions of Windows so it does not crash windows.

    Microsoft only bothers about compatibility if you do a list of every exported function from windows dll compare between versions of windows you will find the newer version of windows will be missing functions out of different dlls that the prior one had. If no application has a error Microsoft classes this as acceptable if application reports an error about the missing function then Microsoft pushed out a patch fixing it. Most of this is found in the alpha/beta stage of windows. So the development pattern of wine is very much the same development pattern as Windows.

    Wine is called a compatibility layer because that is what it is. That applications work between different versions of windows is compatibility as well not any form of run-time behaviour promise if it was Microsoft could call their compatibility mode the title emulator mode..

    Really when Microsoft does not give a rats about duplicating run-time behaviour of windows libraries in Windows why should Wine.

    duby229 without understanding the terms you end up attempting to demand something of wine/reactos and others that Microsoft themselves don't do and will consume more man hours and slow development.

    Leave a comment:


  • dragon321
    replied
    oiaohm Good to know this from person affiliated with Wine, thank You for explain.

    Leave a comment:


  • duby229
    replied
    Originally posted by oiaohm View Post

    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.
    Last edited by duby229; 31 October 2017, 08:57 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by duby229 View Post
    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by duby229 View Post
    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.

    Leave a comment:


  • ruthan
    replied
    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..

    Leave a comment:


  • duby229
    replied
    Originally posted by oiaohm View Post

    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by duby229 View Post

    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.

    Originally posted by OneBitUser View Post
    "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.

    Leave a comment:


  • OneBitUser
    replied
    Originally posted by duby229 View Post
    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.

    Leave a comment:


  • nomadewolf
    replied
    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...

    Leave a comment:

Working...
X