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

  • #31
    Originally posted by oiaohm View Post
    Are you retarded yourself. .def is not a solution when you have to target multi compilers. Wine project is doing that .def stuff using pure native C. So using the C side of the compiler you get the stuff you were doing in a limit complier supporting solution in .def files without .def files.
    Obviously you can use .def files if you build your own tools to do it, if your compiler doesn't support it. All compilers that can emit .DLLs should support .def files though. (and wine needs to generate fake .dlls, recently it also relies on MinGW to build real DLLs, so that point is moot today, so you get lost).

    Comment


    • #32
      Originally posted by tildearrow View Post
      Which parts?

      Are any of these parts unstable?
      - string
      - stack
      - queue
      - vector

      (this is what I use often)
      All are unstable since they're part of the standard library.

      Originally posted by tildearrow View Post
      Look. If your statement of "only stuff in extern "C" is stable" were true then I would rather program in C. But I want to freaking use C++ as its fullest, otherwise what's the point of a language if I am not going to use its features, and especially useful ones such as reduced pointer passing, operators and templates?
      Because you only have to do it for the exported interface?

      I think if you can't clearly separate interface from implementation you ought to rethink your coding habits, as this is not a problem of the language in the least. With interfaces you need to be explicit, and thus use raw pointers and so on, not stuff that can change, because interfaces must not change. They must be well designed, well documented before even writing one line of code, not coded on a whim.

      Wrap them into your C++ functions that do the actual implementation or whatever if you want. That's besides the point.

      Comment


      • #33
        Originally posted by Weasel View Post
        All are unstable since they're part of the standard library.

        Because you only have to do it for the exported interface?

        I think if you can't clearly separate interface from implementation you ought to rethink your coding habits, as this is not a problem of the language in the least. With interfaces you need to be explicit, and thus use raw pointers and so on, not stuff that can change, because interfaces must not change. They must be well designed, well documented before even writing one line of code, not coded on a whim.

        Wrap them into your C++ functions that do the actual implementation or whatever if you want. That's besides the point.
        OK, thanks for the suggestion.

        Comment


        • #34
          Originally posted by Weasel View Post
          Obviously you can use .def files if you build your own tools to do it, if your compiler doesn't support it. All compilers that can emit .DLLs should support .def files though. (and wine needs to generate fake .dlls, recently it also relies on MinGW to build real DLLs, so that point is moot today, so you get lost).
          No Weasel wine maintains the means to build dll.so and real dll. dll.so for the case that mingw compiler is not a option so the issue is not moot when talking about wine. .def is only usable in some cases.

          Sorry to say there are a lot of compilers that can emit dlls that do not support .def.

          https://mottosso.gitbooks.io/clang/b...c_library.html

          There is a fun point not all the combinations of MSVC in fact support using .def files to make dll files either.

          __declspec(dllexport) and __declspec(dllimport) exist in MSVC based compilers because not all of them support on the linker side using .def.

          Basically there is a reason why wine is using C and .spec files weasel. MingW complier can be built without .def support if you leave it out of binutils as well. If the C part is missing you don't have a compiler either.

          Weasel like it or not .def support with Mingw and MSVC and llvm compliers is an optional part. You have got into the habit of presuming something is always present when its optional part.

          Wine .spec files do spec to def and spec to c this covers three possible cases.
          1) using a PE producing complier that linker takes .def
          2) using a PE producing complier that linker does not take def so you need the c file.
          3) using some ELF compiler that is not PE complier to produce something ELF-PE hybrid that wine loader can handle that does not take .def files.

          Basically weasel you just suggest something that only cover 1/3 of cases if you are lucky. You are not hitting 50/50 success here.

          Originally posted by Weasel View Post
          All are unstable since they're part of the standard library.

          Because you only have to do it for the exported interface?

          I think if you can't clearly separate interface from implementation you ought to rethink your coding habits, as this is not a problem of the language in the least. With interfaces you need to be explicit, and thus use raw pointers and so on, not stuff that can change, because interfaces must not change. They must be well designed, well documented before even writing one line of code, not coded on a whim.

          Wrap them into your C++ functions that do the actual implementation or whatever if you want. That's besides the point.
          Lets skip over some finer problem points here.

          Exported interfaces you have to match type handling. This is not always plain simple either. Sometime is replicate a class data structure because a function passes a c++ object pointer.

          Originally posted by tildearrow View Post
          OK, thanks for the suggestion.
          The suggestion from weasel is not without its traps and pitfalls. Wrapping from C to C++ areas of code get very complex very quickly.

          c++ to c for compadiblity is painful. If wine was coded in C++ in the c++ library areas you could be looking at X version C++ to C to Y version C++ this is going to add a performance over head lost doing translation from C to C++. C++ to C very little performance overhead but put pressure on developer how wine currently is.

          C++ to C++ with a middle of C once you work out C++ class objects that have to be reordered and the like you have one hell of a overhead due to ABI differences.

          Basically lack of ABI stability is a solid wall that forces you into making trade offs. Either in restrict the C++ features(what results in not very pretty code and other issue) you can use or performance prices for using those C++ features that can be quite high or stick to c with less pretty code.

          Current forms of C++ does not work for a project like wine very well at all.

          Comment


          • #35
            Originally posted by oiaohm View Post
            No Weasel wine maintains the means to build dll.so and real dll. dll.so for the case that mingw compiler is not a option so the issue is not moot when talking about wine. .def is only usable in some cases.

            Sorry to say there are a lot of compilers that can emit dlls that do not support .def.

            https://mottosso.gitbooks.io/clang/b...c_library.html

            There is a fun point not all the combinations of MSVC in fact support using .def files to make dll files either.

            __declspec(dllexport) and __declspec(dllimport) exist in MSVC based compilers because not all of them support on the linker side using .def.

            Basically there is a reason why wine is using C and .spec files weasel. MingW complier can be built without .def support if you leave it out of binutils as well. If the C part is missing you don't have a compiler either.

            Weasel like it or not .def support with Mingw and MSVC and llvm compliers is an optional part. You have got into the habit of presuming something is always present when its optional part.

            Wine .spec files do spec to def and spec to c this covers three possible cases.
            1) using a PE producing complier that linker takes .def
            2) using a PE producing complier that linker does not take def so you need the c file.
            3) using some ELF compiler that is not PE complier to produce something ELF-PE hybrid that wine loader can handle that does not take .def files.

            Basically weasel you just suggest something that only cover 1/3 of cases if you are lucky. You are not hitting 50/50 success here.
            I dunno what you're trying to say here. Wine builds its own tools to build the fake DLLs. The language those tools are written in does not matter in the slightest.

            But like I said, if MinGW is installed, Wine now builds a lot of real DLLs instead using MinGW. In the (distant) future they might even drop support for fake DLLs and make MinGW mandatory.

            Originally posted by oiaohm View Post
            Lets skip over some finer problem points here.

            Exported interfaces you have to match type handling. This is not always plain simple either. Sometime is replicate a class data structure because a function passes a c++ object pointer.
            You have to pass PODs (plain old structs) or basically C-layout structs not C++ classes. You wrap those in a class inline in the header (see below). The reason is obviously simple: you need to have control over its layout, because an interface specifies the layout.

            It has nothing to do with C vs C++ or the language, you simply need to use the feature of the language that guarantees the layout. Even D (the language) by default arranges its members how it wants, you need to explicitly tell it to not do that for interfaces.

            More options doesn't mean the language is not suitable, it means you ought to know what you're using for what purpose. Duh.

            Originally posted by oiaohm View Post
            The suggestion from weasel is not without its traps and pitfalls. Wrapping from C to C++ areas of code get very complex very quickly.

            c++ to c for compadiblity is painful. If wine was coded in C++ in the c++ library areas you could be looking at X version C++ to C to Y version C++ this is going to add a performance over head lost doing translation from C to C++. C++ to C very little performance overhead but put pressure on developer how wine currently is.
            No it doesn't, you literally make the wrappers inline in the interface header. There's literally zero overhead here for any sanely optimizing compiler.

            Comment


            • #36
              Originally posted by Weasel View Post
              I dunno what you're trying to say here. Wine builds its own tools to build the fake DLLs. The language those tools are written in does not matter in the slightest.
              No this is your mistake.

              Originally posted by Weasel View Post
              But like I said, if MinGW is installed, Wine now builds a lot of real DLLs instead using MinGW. In the (distant) future they might even drop support for fake DLLs and make MinGW mandatory.
              No this is not what is going on. Looks a lot like it. Wine is current altering a lot so when it build stuff it does not depend on Mingw runtime. The dll made in PE form are coming less and less dependant on the compiler being mingw.

              Next is the level of fun EFI has done. The default system binutils can spit out a PE file for UEFI guess what no .def support.

              So there is a strict possibility that you can build how wine has made elf/pe hybrid using the host compiler but instead have it spit out a PE file.

              Basically you have overlooked a complier that can spit out PE files and its limitations. Wine will have to built so many elf/pe hybrids for host communication so the complier for those is required. Reducing the dependancies of wine will see a decent push to support using the host compilers ability to make PE files that was added to make EFI binaries. Yes that has some restrictions because Microsoft did not release .def as a standard to EFI.

              One other thing to remember about gcc/llvm compiler solutions you don't need .def files to make .dll files heck you don't need it to make .so file either. Mingw runtime uses .def because it does not have the source to the dll files so cannot built them all. Wine has the source to all its dll files so can build all it dll files so use direct linking against dynamic libraries that gcc/llvm compiler solutions support.

              Basically .def is a work around to a problem that does not exist for wine and using them removed a host complier on Linux and freebsd as option to make PE binaries.

              There is a fun little stunt you can do with mingw. Make a ELF .so using mingw or host binutils with the windows platform define set name it the same as the dll using direct linking against that elf based dynamic library using mingw or host binutils to make a windows .exe and swap that elf .so with a standard PE .dll latter put both exe and pe dll on windows and it runs. So the ELF/PE of wine can be used for boot strapping.

              So those 3 build modes have there uses.

              Originally posted by Weasel View Post
              No it doesn't, you literally make the wrappers inline in the interface header. There's literally zero overhead here for any sanely optimizing compiler.
              That the problem. You cannot use a header as a wrapper and container something the language rejects or conflicts. Remember name mangling so you write class... and all this stuff you don't know what that is in fact named. Now you attempt to wrap something else to one of those already claimed names bad things are going to happen.

              The name mangling of C++ that you are blind to what it upto is what makes the C wrapper header file or redirection .c file beak it.


              Originally posted by Weasel View Post
              You have to pass PODs (plain old structs) or basically C-layout structs not C++ classes
              Tell this to Microsoft. Some of the libraries wine has to replace Microsoft does not obey this. The do in fact pass C++ classes. So wine has to turn those into PODs of C. Of course you have people asking why cannot code this area in C++ as it would be so many times simpler.

              Comment


              • #37
                Originally posted by oiaohm View Post
                No this is your mistake.
                You can write any binary file in C++ and make it output whatever you want. Case in point: GCC is a tool written in C++ and builds wine.

                Wine builds its own tools for its purpose so why do they have to be written in C again?

                Originally posted by oiaohm View Post
                No this is not what is going on. Looks a lot like it. Wine is current altering a lot so when it build stuff it does not depend on Mingw runtime. The dll made in PE form are coming less and less dependant on the compiler being mingw.
                What? Nobody said anything about "runtime". Wine does depend on MinGW today for a proper build without fake DLLs. If MinGW is not installed, it resorts back to the old method of building fake DLLs. But AFAIK someone said they will deprecate that in the far future, so MinGW will be a requirement.

                Originally posted by oiaohm View Post
                Basically .def is a work around to a problem that does not exist for wine and using them removed a host complier on Linux and freebsd as option to make PE binaries.
                This problem does exist for wine, it's just that they fixed it in-house with their own tools rather than using .def files, because MinGW was not a requirement originally.

                Originally posted by oiaohm View Post
                That the problem. You cannot use a header as a wrapper and container something the language rejects or conflicts. Remember name mangling so you write class... and all this stuff you don't know what that is in fact named. Now you attempt to wrap something else to one of those already claimed names bad things are going to happen.
                Nothing bad is going to happen. extern "C" literally means to not use C++ name mangling. You use it for the exported interface only, not for the inline functions (which btw never get exported so they can be mangled however they want to).

                Originally posted by oiaohm View Post
                Tell this to Microsoft. Some of the libraries wine has to replace Microsoft does not obey this. The do in fact pass C++ classes. So wine has to turn those into PODs of C. Of course you have people asking why cannot code this area in C++ as it would be so many times simpler.
                Yeah, you're right here that Microsoft abused their C++ implementation here, because they're lazy and their code is horrible, everyone knows that.

                For example, COM relies on pure virtual interfaces, despite the fact the C++ standard doesn't guarantee the layout for this.

                However, you can write pure virtual interfaces manually even in C++, they're just function pointers after all. Since you were going to write them as function pointers in C anyway, there's no reason to not just C++ with function pointers. I get that people will illogically whine like "but if I'm using C++ why should I use function pointers for the vtable?"... as if writing in C would be any different.

                The reason you use function pointers and manual vtables is because it's an exported interface. Lazy dumbs.

                Comment


                • #38
                  Originally posted by Weasel View Post
                  Wine builds its own tools for its purpose so why do they have to be written in C again?
                  You did not read did you how many times do I have to answer something before you wake up you missed something important.

                  Originally posted by Weasel View Post
                  What? Nobody said anything about "runtime". Wine does depend on MinGW today for a proper build without fake DLLs. If MinGW is not installed, it resorts back to the old method of building fake DLLs. But AFAIK someone said they will deprecate that in the far future, so MinGW will be a requirement.
                  Dropping ELF/PE hybrid does not mean mingw will come a solid requirement coming forwards. Using the Linux host complier to produce PE using the UEFI PE support instead of ELF/PE also sees the old method deprecated this still needs the .spec as its not windows compiler.

                  Originally posted by Weasel View Post
                  This problem does exist for wine, it's just that they fixed it in-house with their own tools rather than using .def files, because MinGW was not a requirement originally.
                  Take you blinkers off there is more than one Gcc complier that can make PE binaries. Mingw and cygwin is the most common but there is another for making UEFI executables. Like building your grub and linux kernels for straight EFI.

                  So going forwards with wine into the future mingw may not be a requirement. If you are using a binutils that configured to output Linux/Freebsd platform ELF and UEFI PE you don't have .def support.

                  ELF/PE hybrid was required for everything because the host binutils could not put out a PE file this has moved since the host binutils will output PE for UEFI this has moved. So your logic on mingw is off like it or not. ELF/PE hybrid usage will reduce but its not just because of mingw its because the host binutils has also picked up PE support when in past use to only have ELF support. So if host binutils can spit out a PE so avoid extra wrapping and extra memory usage why not. Yes it leaves you with the trap you still need the .spec file or wine that can output .def and .c . The C version of a def for when you are exploiting the linux/mac os/bsd host compilers means to make a PE.

                  Originally posted by Weasel View Post
                  Nothing bad is going to happen. extern "C" literally means to not use C++ name mangling. You use it for the exported interface only, not for the inline functions (which btw never get exported so they can be mangled however they want to).
                  No the way you wrote that means you don't get how MSVC complier some versions interprets it.

                  literally means to not use C++ name mangling
                  Some versions of MSVC complier linker says when in extern "C" if you declare a function that happens to possible decode using the C++ compiler name mangling I will error and refuse to build. So its that I will not use name mangling on any function inside extern "C" and you cannot declare any function that the compiler thinks is name mangled either. The way to get around this is use a .c file and tell MSVC complier it a C file and then it builds it.

                  Comment


                  • #39
                    Originally posted by oiaohm View Post
                    You did not read
                    Look in the mirror.

                    Originally posted by oiaohm View Post
                    Dropping ELF/PE hybrid does not mean mingw will come a solid requirement coming forwards. Using the Linux host complier to produce PE using the UEFI PE support instead of ELF/PE also sees the old method deprecated this still needs the .spec as its not windows compiler.
                    "Hybrid" (aka fake DLL + a .so in other place) DLLs are only for the core stuff like user32 that call into unix libs and interface with unix stuff. Most other DLLs are built straight as PE if MinGW is installed. It's as if you drop a native Windows DLL, is that so hard to understand?

                    When was the last time you built wine again?

                    Originally posted by oiaohm View Post
                    Take you blinkers off there is more than one Gcc complier that can make PE binaries. Mingw and cygwin is the most common but there is another for making UEFI executables. Like building your grub and linux kernels for straight EFI.

                    So going forwards with wine into the future mingw may not be a requirement. If you are using a binutils that configured to output Linux/Freebsd platform ELF and UEFI PE you don't have .def support.

                    ELF/PE hybrid was required for everything because the host binutils could not put out a PE file this has moved since the host binutils will output PE for UEFI this has moved. So your logic on mingw is off like it or not. ELF/PE hybrid usage will reduce but its not just because of mingw its because the host binutils has also picked up PE support when in past use to only have ELF support. So if host binutils can spit out a PE so avoid extra wrapping and extra memory usage why not. Yes it leaves you with the trap you still need the .spec file or wine that can output .def and .c . The C version of a def for when you are exploiting the linux/mac os/bsd host compilers means to make a PE.
                    It doesn't matter if you have .def support. What matters is that Wine uses its own tools to handle the exports. Period. It has nothing to do with using C or not.

                    Originally posted by oiaohm View Post
                    Some versions of MSVC complier linker says when in extern "C" if you declare a function that happens to possible decode using the C++ compiler name mangling I will error and refuse to build. So its that I will not use name mangling on any function inside extern "C" and you cannot declare any function that the compiler thinks is name mangled either. The way to get around this is use a .c file and tell MSVC complier it a C file and then it builds it.
                    More bullshit as usual. You can't even declare a function with extern "C" that matches name mangling because the mangled name on MSVC uses @@ symbols.

                    You do it during linking with .def file by mapping your function name to something [email protected]@this.

                    Or you can fucking write the exports table manually with your own tool, it's not that hard. PE files are not fucking magic they're like data files. Any tool, written in any language, can write a PE file with whatever exports it wants. (either reading .spec files or .def files or whatever you want, you can make your own tool read your own personal format if you want to)

                    Comment


                    • #40
                      Originally posted by Weasel View Post
                      "Hybrid" (aka fake DLL + a .so in other place) DLLs are only for the core stuff like user32 that call into unix libs and interface with unix stuff. Most other DLLs are built straight as PE if MinGW is installed. It's as if you drop a native Windows DLL, is that so hard to understand?

                      When was the last time you built wine again?
                      Last week I built the dll in wine using the host binutils as native PE without mingw installed. Something I was asked to try out due to my background spinning mingw compilers up from scratch and taught it to the reactos developer who maintains the build system.

                      There are 4 build paths to making wine dll.
                      1) ELF/PE hybrid these will remain required as they are how host to windows environment bridges are done.
                      2) Mingw/cygwin build PE DLL of wine
                      3) Host building PE dlls using UEFI something I was asked to try out.

                      Mingw does not need to be installed for wine to have as if you drop a native Windows DLL. Using host support for building UEFI PE support also generates like a Windows DLL.

                      Basically there is another way to skin the cat you have completely missed. In fact there are a few other ways to skin the cat that are being worked out as well.
                      https://bugs.llvm.org/show_bug.cgi?id=10638

                      Like here clang instead of just gcc.

                      At different times in the past MSVC was in fact used to make wine dlls as PE files as well just that build path has not been maintained. So since I had prior experenice building wine with MSVC I know how wine did it historically without .def.

                      Originally posted by Weasel View Post
                      More bullshit as usual. You can't even declare a function with extern "C" that matches name mangling because the mangled name on MSVC uses @@ symbols.
                      That the point in a pure C source built by MSVC you can use function names with @@ in them. In fact C++ MSVC may in particular cases only have 1 @ in the name. So you cannot to a straight C++ replacement function for a different versions of MSVC using C++ in MSVC but you can do it using C. Of course you are suggesting hacking around with def.

                      Really what you have written is bullshit in fact.

                      https://docs.microsoft.com/en-us/cpp...s?view=vs-2019
                      If pass the /TC /Za flags on MSVC to disable C++ you can declare functions in extern "C" segment that are exactly like C++ mangled. Of course C++ is turned off.

                      Really weasel you don't know MSVC as good as you think you do. Not bullshit I know this dirty trick due to in the past building wine .dll with MSVC.

                      Originally posted by Weasel View Post
                      You do it during linking with .def file by mapping your function name to something [email protected]@this.
                      So you don't need todo this when you code in C and force MSVC back into C.

                      Originally posted by Weasel View Post
                      Or you can fucking write the exports table manually with your own tool, it's not that hard. PE files are not fucking magic they're like data files. Any tool, written in any language, can write a PE file with whatever exports it wants. (either reading .spec files or .def files or whatever you want, you can make your own tool read your own personal format if you want to)
                      Spec files in wine covert to c then built into object when you have a compiler.

                      Weasel Its really simple to forget I have been building wine for a very long time and doing support around it. Something you are doing by .def does not need to be done by def at all instead just use the C part of the MSVC complier and produce the same result.

                      Wine current Spec solution covers
                      1) making PE/ELF hybrid using host.
                      2) PE using host using the PE part of binutils for UEFI
                      3) mingw.
                      4) and some very odd ball things HX DOS-Extender build in freedos.

                      Wine source is also used by things like HX DOS-Extender also using compilers that have no clue on .def to make PE files. Yes the old dos compliers understand do understand __declspec(dllexport) and __declspec(dllimport) in there C so will build spec covered to .o and link up a PE just fine.

                      Use to cover MSVC and has been used by clang and other C++ compilers.

                      Really Weasel take off you windows/linux/bsd use case glasses some time. Also by the way some versions of MSVC in def also take exception to using = on C++ mangled names. Wine spec path forcing MSVC back to C mode works on all versions of MSVC where you def idea does not in fact.

                      Spec idea of wine gives very broad coverage compared to .def

                      winebuild in wine has the means to turn .spec into .def or .c this route gives max compiler compatibility.

                      Weasel why do you have to choose one route when you can choose both. Both means two paths have to break for you not to be able to build.


                      Comment

                      Working...
                      X