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

  • #41
    Originally posted by oiaohm View Post
    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.
    Those are fake DLLs, unless you mean you actually tailored wine's source for it, but that doesn't count, lol.

    Originally posted by oiaohm View Post
    That the point in a pure C source built by MSVC you can use function names with @@ in them.
    But you can't in the C++ standard so Wine won't use it, hence your entire rant was meaningless.

    Besides, who even uses MSVC to build Wine to begin with? I was never even talking about MSVC.

    Comment


    • #42
      Originally posted by Weasel View Post
      Those are fake DLLs, unless you mean you actually tailored wine's source for it, but that doesn't count, lol.
      I did not alter the wine source todo it. I altered the compiler. Told configure to try the host compiler in place of mingw with the flags to produce PE output. Turns out wine build system detects that .def is not functional and falls back to .c from spec. I was basically asked to test if that functionally still worked. So no this was not producing fake dlls this was producing the same dlls mingw build path of wine does using the host compiler and wine own runtime instead of mingw.

      Originally posted by Weasel View Post
      But you can't in the C++ standard so Wine won't use it, hence your entire rant was meaningless.
      This was why not C++ from me. As you said here you can't in the C++ standard mode. Interesting enough the C++ standard does not say you cannot its compiler makers who have decided you cannot. Yes at times using a .def = feature on different compilers to redirect C++ name managled thing to a C name will also result in the link erroring out.

      So depending on the compiler in use if you have to use spec to def or spec to c. If you have both you cover all cases.

      [QUOTE=Weasel;n1125221Besides, who even uses MSVC to build Wine to begin with? I was never even talking about MSVC.[/QUOTE]

      Wined3d for windows do builds of sections of wine using MSVC from time to time hunting performance. VMware does builds of parts of wine using MSVC. Reactos does builds of parts of wine using MSVC. Some game vendors build wine parts with MSVC when they port forwards games so they don't have to rewrite a crap load.

      So there are quite a few users of wine source code. Things you were not considering at all.

      Yes wine has in it source the means to make MSVC project files for parts of itself and wine source is used that way.

      Spec files are way more detailed than your normal .def.
      https://docs.microsoft.com/en-us/cpp...s?view=vs-2019
      entryname[=internal_name|other_module.exported_name] [@ordinal [NONAME] ] [ [PRIVATE] | [DATA] ]
      This has your normal windows def encoding. Notice the encoding has a @ followed by a number. What todo when you have a C++ name mangle that happened to solve to like [email protected] where 10 is not a ordinal value. Yes this can in fact happen and shows that msvc C++ is not always using .def itself.

      It would also pay you to read over what in a wine spec file.
      https://github.com/wine-mirror/wine/...0/msvcp90.spec

      Wine spec encoding is using space separation. PE export name with space is not allowed by any means so there is no possibility of conflict.

      There are a lot more details in the wine spec file. Like the call type and the arguments these are required if you are going to make a .c file instead of a def.

      The really interesting one is the -arch=. Yes MSVC has different name mangling between the win32 and win64 version of a library also you have i386, arm differences as well.

      One wine spec file is somewhere between 1 to 3 def files. 1 def for all 64 bit. 1 def for i386 platforms and 1 def for 32 bit arm. Wine is using a single source for all 4 binaries.

      So wine spec files are going to remain because it make senses. If you have to maintain you own format anyhow because the Microsoft made .def format is not good enough you might as well cover all options so you can cope with compiler/linker issues when they turn up.

      Lot of ways it would be good if compilers took wine spec format instead of the def it makes your multi platform source code simpler as well as supporting all possible PE export names. Yes to support all possible PE export names you have to use the spec to c solution.

      Weasel like it or not wine .spec and usage of c is the best possible solution to cover any stunt Microsoft developer could do while not breaking the PE format. You are not much you can do if they decide to break the PE format. So the idea of migrate to .def instead of .spec makes no sense.

      C++ + .def route has its limitations. C++ + wine spec to c is also mess as hell. Core wine will remain C until some other language appears that does not have the name mangling problem and other problems.

      I have stayed way from items like garbage collection and other memory management issues using C++ compilers you run into. The reality is if you are screwed at doing the dll exports due to .def being too limited of a format so are forced to use a C compiler for those C++ is already doomed as a solution at that point let alone the other problems.

      Comment


      • #43
        Originally posted by oiaohm View Post
        There are a lot more details in the wine spec file. Like the call type and the arguments these are required if you are going to make a .c file instead of a def.
        Well, I don't feel like wasting time to explain such details to you when you obviously don't understand anything anyway.

        .def file is for the linker, it's not a .c file that gets compiled. It just maps the exports. Wine's .spec file does more, and the call type and arguments are e.g. for the relay used for debugging. Nothing to do with bogus language limitations.

        The point is that you don't need C for this. In fact, even if the rest of the source code is C++, the spec files could still generate C as well (Wine uses a bunch of other stuff that gets generated to C anyway, like bison). It's called build tools. It's not a language feature, it's a tool. You can write any binary file using C++, any tool, and parse any format (.spec or not).

        Same with C, mind you.

        Comment


        • #44
          Originally posted by Weasel View Post
          .def file is for the linker, it's not a .c file that gets compiled. It just maps the exports. Wine's .spec file does more, and the call type and arguments are e.g. for the relay used for debugging. Nothing to do with bogus language limitations.
          That so call bogus limitation does come back when you build wine with windows ce binary support. Yes microsoft in past has done a dll containing a export than cannot be put in a .def. Since it been done once in the past you need to be ready for it.

          Originally posted by Weasel View Post
          The point is that you don't need C for this. In fact.
          No this is because you are clueless. Please not saying something is not need because it does not suit your view of the world. Heck you admitted there was information in there that could help debugging. You did not look if build spec to c instead of spec to def activated that did you. Yes spec to c activates that extra debugging.

          spec to Def and spec to .c Both build to a .o file. Yes you are right building the .o from c from spec does also improve debugging because it has the size of arguments that function being redirected should have. Spec file of wine has more information the .c generated from spec file has more information in the .o than the .o made from .def. Make build time errors more sane when you have a issue to force wine to use the .spec to .c. .spec support in wine is going anywhere same with the spec to c conversion because it useful.

          Spec to C is requirement. Using spec to def instead of spec to c does make it harder to find particular problems.

          Sorry the rest of source code cannot be C++. Just like you run into @ not being usable in exports in C++ there are other things happen as you are attempting to name functions to emulate C++ so now your code will look a lot more horrible to emulate C++ libraries cross compilers.

          Then add in a programmer using like c++ strings or something somewhere so using different memory management and alignments on different compilers.

          For a project like wine C++ comes unworkable for the core. Name restrictions by C++ compiler than the C version of compiler does not have causes enough problems.

          If you had looked at the redirected to C names in the spec file I showed before some of those c names in fact error when you use a some C++ compilers because they contain restricted words in C++ that are not restricted in C. Thinking you are replicating a c++ function for a different complier being able to use the C++ restricted words in function name is useful.

          Comment

          Working...
          X