Announcement

Collapse
No announcement yet.

Wine-Staging 4.15 Released With Framework For PnP Drivers, Various Updated Patches

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

  • Wine-Staging 4.15 Released With Framework For PnP Drivers, Various Updated Patches

    Phoronix: Wine-Staging 4.15 Released With Framework For PnP Drivers, Various Updated Patches

    Based off Friday's Wine 4.15, Wine-Staging 4.15 is now available that has its 800+ existing patches while adding a number of new patches and updating functionality for some of the existing feature patches...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Why are many of these patches still in staging? Most of them feel stable to me.

    Comment


    • #3
      the gtk3 theming is pretty nice.

      Comment


      • #4
        Originally posted by tildearrow View Post
        Why are many of these patches still in staging? Most of them feel stable to me.
        I guess because most of the Wine maintainers who review and accept the code are too stubborn and want it done their way only.

        Comment


        • #5
          Originally posted by Weasel View Post
          I guess because most of the Wine maintainers who review and accept the code are too stubborn and want it done their way only.
          I hope this changes someday and convert codebase to C++ too...

          Comment


          • #6
            Originally posted by Weasel View Post
            I guess because most of the Wine maintainers who review and accept the code are too stubborn and want it done their way only.
            That's not called collaboration then...

            Comment


            • #7
              Originally posted by tildearrow View Post
              Why are many of these patches still in staging? Most of them feel stable to me.
              Its not that simple. Feel stable and correct are two very different things.

              Originally posted by Weasel View Post
              I guess because most of the Wine maintainers who review and accept the code are too stubborn and want it done their way only.
              Really you should watch the patches.winehq.org and/or speak to the wine staging maintainers some time.

              Biggest thing the 3 maintainers of staging are having todo a lot of is write test cases. Guess what lots of patches have been written and given to staging without any test cases to confirm that they are in fact functioning correctly compared to windows. There are also patches stuck in staging that are known that when added the wine test suite in fact shows a error and those errors do mean an application somewhere is in fact broken by that patch.

              By the way the 800-900 patches in staging is higher than I would like. I would prefer to see that number somewhere 400-500 just from maintainable point of view. Half of the patch set is less than 6 months old. There is a huge volume of new work entering the staging patchset and a huge volume going up stream. But there are also patches that have been suck with no one to work on up-streaming for years in staging

              Originally posted by timofonic View Post
              I hope this changes someday and convert codebase to C++ too...
              Never happening in a big way. Sections of wine project code bases are C++ like winegecko .
              https://docs.microsoft.com/en-us/cpp...7?view=vs-2019
              The problem is C++ is not stable. Once you cut C++ to a subset that you can in fact depend on you fairly much have C and you don't have feature parody with C either. Having compiler process for c++ features when you will not be using them just results in slower build times.

              Yes Microsoft has differences in c++ implementation between the version you write drivers and the versions you build applications so all nicely incompatible. Wine using C with C flexibility it can do what ever strangeness implementations need.

              I would say if intel developer is successful making rust feature parody with C for system programming it might be a chance for something wine could migrated to and be able to replicate all the different C++ implementation behaviours that Microsoft Windows application support needs in wine.

              Feature parody with C is important when project is like wine and is having to use some of the more odd features C allows to replication behaviours.

              Its like those asking for C++ to build the Linux kernel same mistake. Linux kernel has structures named class, public.... Wine is in the same kind of location were it needs to be able to name functions and structures what ever without language imposing any limitation.

              System programming you need if possible no restrictions on what you can name things and that is not C++. Forth, C, asm are the three I can think of that meet that requirement.
              Last edited by oiaohm; 02 September 2019, 06:10 PM.

              Comment


              • #8
                Originally posted by oiaohm View Post
                Its not that simple. Feel stable and correct are two very different things.
                I see.

                Originally posted by oiaohm View Post
                The problem is C++ is not stable. Once you cut C++ to a subset that you can in fact depend on you fairly much have C and you don't have feature parody with C either. Having compiler process for c++ features when you will not be using them just results in slower build times.
                Can this be worked around by shipping multiple versions of the C++ library, Windows fashion?

                Comment


                • #9
                  Originally posted by tildearrow View Post
                  Can this be worked around by shipping multiple versions of the C++ library, Windows fashion?
                  The answer is in fact no because you have to make those c++ libraries some how. Wine is using C to make all multiple versions of C++ libraries in a dependable and predictable way on multi different compilers using the least lines of code possible with that limitation. Migrate to c++ you will break this.


                  Classic example in wine is looking through the msvcp libraries.

                  msvcp90 has source code and is the master. Msvcp60 requires some special stuff so has some source code.

                  But msvcp70/71/80/100/110/120/120_app/140 all don't have any real unique source code in wine other than .spec file to hook the c functions in the msvcp90 master to the C++ mangled function names for that C++ version. Yes 60/70/71/80/90/110/120/120_app/140 all align to unique MS Visual C++ versions unique idea of name mangling.

                  The big difference between C++ versions is not really the code the function contains its how the function inside classes and the like was the name mangling used the c++ compiler. Yes Microsoft likes altering the name mangling slightly every time they make a new C++ compiler version.

                  C++ is not stable this is the problem. In fact Microsoft version of C++ is more unstable than llvm or gcc versions of c++.

                  Yes at Microsoft I would suspect that almost all the msvcp libraries are in fact the same code but are built by using a compiler flag to say when building x library use X c++ mangling of course this basically restricts you to Microsoft compliers or 100 percent compatible compiler.. This basically means having to maintain a compiler in lockstep with the Microsoft compiler to go this route.

                  Wine route is use c and spec files. Yes spec files by wine tooling get turned into .c files. The c and spec combination is portable between c compilers to produce your c++ libraries for applications.

                  Wine is not using C for no reason. Using c is avoid wine having to maintain a full compiler so able to use many versions of gcc and llvm and msvc and product the same C++ application compatible dll files from all of them.

                  The means to name a function what ever is key to wine code recycling in building all the C++ libraries wine provides replacements for.

                  Please remember maintaining a compiler and updating for new cpus and hardware is a lot of hard and complex work and would take more resources than the wine project has so it has to be outsourced to gcc and llvm like it or not. Yes gcc/llvm does not do 100 percent MSVC matching name mangling on C++ code.

                  Comment


                  • #10
                    Originally posted by oiaohm View Post

                    The answer is in fact no because you have to make those c++ libraries some how. Wine is using C to make all multiple versions of C++ libraries in a dependable and predictable way on multi different compilers using the least lines of code possible with that limitation. Migrate to c++ you will break this.
                    Of course, I meant that, after making those C++ libraries.

                    Originally posted by oiaohm View Post

                    Classic example in wine is looking through the msvcp libraries.
                    I see.

                    Originally posted by oiaohm View Post
                    msvcp90 has source code and is the master. Msvcp60 requires some special stuff so has some source code.
                    I see.

                    Originally posted by oiaohm View Post
                    But msvcp70/71/80/100/110/120/120_app/140 all don't have any real unique source code in wine other than .spec file to hook the c functions in the msvcp90 master to the C++ mangled function names for that C++ version. Yes 60/70/71/80/90/110/120/120_app/140 all align to unique MS Visual C++ versions unique idea of name mangling.
                    I see.

                    Originally posted by oiaohm View Post
                    The big difference between C++ versions is not really the code the function contains its how the function inside classes and the like was the name mangling used the c++ compiler. Yes Microsoft likes altering the name mangling slightly every time they make a new C++ compiler version.
                    I see.

                    Originally posted by oiaohm View Post
                    C++ is not stable this is the problem. In fact Microsoft version of C++ is more unstable than llvm or gcc versions of c++.
                    What specifically makes the language unstable?

                    Originally posted by oiaohm View Post
                    Yes at Microsoft I would suspect that almost all the msvcp libraries are in fact the same code but are built by using a compiler flag to say when building x library use X c++ mangling of course this basically restricts you to Microsoft compliers or 100 percent compatible compiler.. This basically means having to maintain a compiler in lockstep with the Microsoft compiler to go this route.
                    I see.

                    Originally posted by oiaohm View Post
                    Wine route is use c and spec files. Yes spec files by wine tooling get turned into .c files. The c and spec combination is portable between c compilers to produce your c++ libraries for applications.
                    I see.

                    Originally posted by oiaohm View Post
                    Wine is not using C for no reason. Using c is avoid wine having to maintain a full compiler so able to use many versions of gcc and llvm and msvc and product the same C++ application compatible dll files from all of them.
                    I see I see I see I see I see.

                    Originally posted by oiaohm View Post
                    The means to name a function what ever is key to wine code recycling in building all the C++ libraries wine provides replacements for.

                    Please remember maintaining a compiler and updating for new cpus and hardware is a lot of hard and complex work and would take more resources than the wine project has so it has to be outsourced to gcc and llvm like it or not. Yes gcc/llvm does not do 100 percent MSVC matching name mangling on C++ code.
                    I see I see I see I see I see!!!!

                    Comment

                    Working...
                    X