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

[ssokolow]

What specifically makes the language unstable?

Instability is the default. Stable ABIs require an effort by the implementors of the language to design and follow a standard despite it crippling their future ability to change things to improve performance or add features.

(C is a rarity in that respect.)

[oiaohm]

Of course, I meant that, after making those C++ libraries.

Really it surprising to a lot of people how much of core wine is in fact making C++ replacement libraries so MSVC programs work out the box.

What specifically makes the language unstable?

You would say what the C++ standard left undefined yet said had to be used and is defined no where else.

C++ standard does not define how name mangling or exception handling... will be implement. C++ standard is not ABI standard to be correct neither is the C standard.

C standard manages to work because it interfaces are simple enough that other standards cover what needs to be ABI defined like calling conventions https://en.wikipedia.org/wiki/X86_calling_conventions. C simple enough in most cases that calling conventions that is defined outside the c standard is enough to make predictable and useful results.

C++ is more complex than the third party standard ABI stable defined stuff out so the C++ standard. So the C++ built with different c++ compilers is not compatible.

Yes wine is going to have the problem that libraries it built with X compiler will be need to be run by application built with Y compiler using C this works even it its horrible .spec using C to replicate different c++ compiler results.

Rust currently is not really ABI stable enough for system programming language this is why I am watching what a particular Intel developers is up to..

Yes the C++ reality is why I look a Fuchsia and question if it going to follow the route of most other C++ based operating systems of fatality caused by C++ compiler changes. Or is google with Fuchsia going to follow the route of Microsoft of making their own define compiler for building the core parts? You have to be fairly big todo anything with C++ were you need ABI production stability.

[oiaohm]

Instability is the default. Stable ABIs require an effort by the implementors of the language to design and follow a standard despite it crippling their future ability to change things to improve performance or add features.

(C is a rarity in that respect.)

C is not a rarity when it come to language standards and being unstable. The C standard by default is a unstable pain in ass the people writing the C standard go out of their way not to define anything ABI solid . Just it a simple enough language that other ABI standards like calling conventions make C usefully stable.

There is a line that you programming language is low enough in complexity that the third party standards can make it ABI stable. C is basically right on that line any more complex of a programming language you need to define some extra stuff either in extra third party standards or in the language standard itself.

In fact forth, C and asm all fall into the camp of being simple enough to be covered by third party standards while their language standards themselves don't really define ABI stability.

Reality here is a true bugger.

[ShizzyG]

Of course, I meant that, after making those C++ libraries.



I see.



I see.



I see.



I see.



What specifically makes the language unstable?



I see.



I see.



I see I see I see I see I see.



I see I see I see I see I see!!!!

What do you see?

[timofonic]

GCC/LLVM does not do 100 percent MSVC matching name mangling on C++ code.

How can this would be possible to be solved? Any ideas about possible extensions and/or improvements?

[oiaohm]

How can this would be possible to be solved? Any ideas about possible extensions and/or improvements?

You have a never ending cat and mouse as long as Microsoft wants to maintain it.

https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2019

The decorated naming conventions have changed in various versions of Visual Studio, and can also be different on different target architectures. To link correctly with source files created by using Visual Studio, C and C++ DLLs and libraries should be compiled by using the same compiler toolset, flags, and target architecture.

This is Microsoft they don't even promise the name mangling will stay the same even using the same compiler all it takes is you use a different set of flags.

First reality is accepting the rules Microsoft operated their C++ by. Next it working out any form of straight up extensions is not really going to work because Microsoft by their own rules can change stuff without notice.

Wine project has solved the problem by using C that allows the Microsoft mangle name to be defined in the spec files. You need to be able to in fact state how functions/data structures will be exposed as a programmer for dynamic linking not leave it absolutely to compiler magic like name managing.

Solution is basically work out how to have feature parody with C. C++ language design in it current form does not include any means to define classes and the like and directly define how it will be name mangled.

Please note the name mangled is only the start you have like c++ new and delete and other features a person coding in C++ can use that make compatibility hard.

Basically C++ has some very strict limitations.

https://www.youtube.com/watch?v=l9hM0h6IQDo

The intel developer above speaking on working on rust I am following with interest. If he is able to make true feature parody with C this may provide a better language than C to make C++ compatibility libraries in wine.

[tildearrow]

Really it surprising to a lot of people how much of core wine is in fact making C++ replacement libraries so MSVC programs work out the box.

Yeah is.

You would say what the C++ standard left undefined yet said had to be used and is defined no where else.

...

C++ standard does not define how name mangling or exception handling... will be implement. C++ standard is not ABI standard to be correct neither is the C standard.

That is a problem, and especially the exception handling part. How in the world would they not define such a thing?

C standard manages to work because it interfaces are simple enough that other standards cover what needs to be ABI defined like calling conventions https://en.wikipedia.org/wiki/X86_calling_conventions. C simple enough in most cases that calling conventions that is defined outside the c standard is enough to make predictable and useful results.

Yeah, I know.

C++ is more complex than the third party standard ABI stable defined stuff out so the C++ standard. So the C++ built with different c++ compilers is not compatible.

Exactly, but what I meant is between versions of the same C++ library (e.g. GNU's libc++) built with the same compiler.

By the way, GCC and Clang use the same convention for function name mangling.

Yes wine is going to have the problem that libraries it built with X compiler will be need to be run by application built with Y compiler using C this works even it its horrible .spec using C to replicate different c++ compiler results.

Yes, exactly.

Rust currently is not really ABI stable enough for system programming language this is why I am watching what a particular Intel developers is up to..

OK

Yes the C++ reality is why I look a Fuchsia and question if it going to follow the route of most other C++ based operating systems of fatality caused by C++ compiler changes. Or is google with Fuchsia going to follow the route of Microsoft of making their own define compiler for building the core parts? You have to be fairly big todo anything with C++ were you need ABI production stability.

OK

What do you see?

Really I not feel like respondable a oiaohm post.

Yes I want reply but I do not know what a say.

[oiaohm]

That is a problem, and especially the exception handling part. How in the world would they not define such a thing?

C++ standard does not define it for the same reasons C standard does so not to hinder compiler/platform developers. We really do need those making a platform to write another standard or our language structures be able to cope. C is simple enough to be covered by platform ABI standards.

Exactly, but what I meant is between versions of the same C++ library (e.g. GNU's libc++) built with the same compiler.

Problem is multi versions of C++ library built with 1 C++ compiler is one problem. But the other problem is the same library version built with multi compiler versions being incompatible.

By the way, GCC and Clang use the same convention for function name mangling.

That is unfortunately myth. GCC and Clang use about 99.9 percent the same function name mangling for C++. The 0.1 percent does cause issues.

https://libcxx.llvm.org/

Yes the 0.1 difference is why we have libc++ and libstdc++.

Like the libc++/libstdc++ issue would be less if the C++ language could declare this Class function will be name mangled X way that could be different to the compilers own native name mangling.

Of course if you read the C++ standard mailing list every time something like this is suggested you see Microsoft complier developers say we cannot do this because making C++ compliers more compatible will run into memory management/exception handling..... issues of being different. Basically they don't want to address this incompatibility problem and will veto anyone attempt to fix it at standard level.

C++ standard will remain a mess as long as Microsoft wishes it so and there is not enough other parties unified to push the standard change though to fix it over Microsoft resistance.

C++ is easier than C until you pull back the curtain and see the ABI problem. C is a easier language than C++ to use when you need ABI stability, ABI repeatability.... I hope the intel developers work on rust will give as language that has good ABI stability and ABI repeatability with better type safety features than C.

With the current C++ standard body position on ABI I don't see C++ standard being fixed in my life time without some major change. Lot of people who ask project to move to C++ because in their mind it will make it simpler overlook how many of these projects in fact need ABI stability to be useful.

I don't class C as the best language but C++ like it or not has major drawbacks. We really do need someone to make a better programming language than C that in ABI stability between compilers can hold parody with C.

[tildearrow]

C++ standard does not define it for the same reasons C standard does so not to hinder compiler/platform developers. We really do need those making a platform to write another standard or our language structures be able to cope. C is simple enough to be covered by platform ABI standards.

Dang.

Problem is multi versions of C++ library built with 1 C++ compiler is one problem. But the other problem is the same library version built with multi compiler versions being incompatible.

The main problem is the latter one. The former is less of a problem.

That is unfortunately myth. GCC and Clang use about 99.9 percent the same function name mangling for C++. The 0.1 percent does cause issues.

https://libcxx.llvm.org/

Yes the 0.1 difference is why we have libc++ and libstdc++.

Dang it.

Like the libc++/libstdc++ issue would be less if the C++ language could declare this Class function will be name mangled X way that could be different to the compilers own native name mangling.

Exactly.

Of course if you read the C++ standard mailing list every time something like this is suggested you see Microsoft complier developers say we cannot do this because making C++ compliers more compatible will run into memory management/exception handling..... issues of being different. Basically they don't want to address this incompatibility problem and will veto anyone attempt to fix it at standard level.

Then that's Microsoft's problem. It can be done, but they don't want to.

C++ standard will remain a mess as long as Microsoft wishes it so and there is not enough other parties unified to push the standard change though to fix it over Microsoft resistance.

So Microsoft controls the C++ standard?
You know, the standard body isn't forced to lean towards a single company...

C++ is easier than C until you pull back the curtain and see the ABI problem. C is a easier language than C++ to use when you need ABI stability, ABI repeatability.... I hope the intel developers work on rust will give as language that has good ABI stability and ABI repeatability with better type safety features than C.

I hate how I have to do thousands of pointer passing in C, and we don't have real classes. It's just ugly.

With the current C++ standard body position on ABI I don't see C++ standard being fixed in my life time without some major change. Lot of people who ask project to move to C++ because in their mind it will make it simpler overlook how many of these projects in fact need ABI stability to be useful.

Wait wait, I just thought of a possible solution. What about a static-linking the C++ library?

I don't class C as the best language but C++ like it or not has major drawbacks. We really do need someone to make a better programming language than C that in ABI stability between compilers can hold parody with C.

Hold parody... That what are?

[DMJC]

Thanks for explaining these very valid reasons why WINE is written in C instead of C++. I have had my opinion of WINE change over the years from joy to disappointment, to a deep respect for the work the developers are trying to achieve. It will always be a bit frustrating to me as someone who struggles with programming that the progress in certain areas of wine is slow. But I must say that since I moved to Linux almost 20 years ago, basically all of my applications I wanted to have working on Linux 20 years ago are now working. That is a fantastic effort and something that I really think the WINE team should be deeply proud of.