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

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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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


    Leave a comment:


  • Weasel
    replied
    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)

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:

Working...
X