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

[oiaohm]

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

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

https://devblogs.microsoft.com/cppblog/c-standards-conformance-from-microsoft/

We’re not just implementing the C++ Standard, we’re helping to develop it. The MSVC team is a major contributor to the development of the C++ Standard. In addition to our participation in the standards committee meeting, editors from three major Technical Specifications (Coroutines, Modules, and Ranges) work on the MSVC team. We also maintain an open source fork of the Ranges TS that works on our compiler.

This is the true Dang it. Microsoft does develop the C++ standard and has seat on the committee that decided what goes into the C++ Standard. So when Microsoft says they don't want to do something and you want to do something is for sure a fight in the standard committee room to get past. Unfortunately like it or not in ISO standard body that C++ standard owns to money talks. Its like how Microsoft was able to make OOXML a ISO standard even that the documentation provided was proven defective. Standard bodies are not a nicely neutral as one would hope in all cases some are in fact buy-able by money.

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

I agree its ugly but it works.

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

Does not work. Lets say you need to export something particularly way name managed and it happens to line up with the C++ compiler you are using to mean something different. Welcome strange errors. For the wine case static linking C++ does not dig you out of hell in fact digs you in.

See problem here to fix this basically will require a C++ standard change and C++ standard change now means lets argue with Microsoft for a change they don't really want.

Hold parody... That what are?

When I say Hold parody with C as in able todo what C is able to do with exports and imports so even the most odd item can be made work if programmer wishes it.

Really I do think rust has a better chance of becoming a language that rust can replace C before C++ can. Particularly with C++ you know that in the standard body you will have to argue with Microsoft who openly says they don't agree with the idea.

Rust being from Mozilla means that rust is based around the "Internet Standard" model where anyone with a idea submits a RFC and implements and the best long term implementations live. So you don't have the fatality of idea stuck in committee until forgotten about like C++ standard process does from time to time.

Its not what people trained in C++ really want to hear that C++ due how it standard is managed is basically screwed at least for quite some time and there will be a stack of things it cannot do.

Microsoft vendor lock-in is on a completely different level to what people think some of Microsoft vendor lock-in is how much control they have over particular key standards.

Yes all the idea you have come up with so far to attempt to get around the ABI issue with C++ I have heard before and other parties have responded that they don't work. In fact Linus the lead of the Linux kernel did a write up on C++ 15+ years ago listing all the same faults. So over decade and a half has progressed and C++ problem points are still exactly the same. At the rate things are going I am expecting another 15+ years of C++ being screwed up when needing to be ABI compatible across compilers.

I don't see the long term future being C++ unless the things change. C could be around for another few decades at least in these problem points. Yes intel developer working on improving rust is like you he does not like having todo all the pointer stuff in C because its a path to bugs even that it works.

You do have to remember Mozilla started the rust language because some of the other screw ball things about C++ was causing them major problems as well.

This is really C++ is basically no for system programming if you don't want major trouble. Lot of wine falls into system programming.

Heck if intel developer is able to make rust properly suitable for system programming maybe this will make Microsoft staff in the ISO standard committee of C++ standard take this problem more seriously but this will be like 5 years into the future from now if we are lucky. Of course by then items like wine could already be in rust migration. I seriously think if nothing changes by the time C++ standard get serous about fixing the ABI problem of the language it will be too little too late.

[Weasel]

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.

C++ has ABI stability, just use extern "C". Facepalm.

All your mumbo jumbo is basically you refusing to use it because you don't want to, and then blaming the language. Some parts of it are intentionally unstable. If you want stability, simply don't use them. It's not like using C will make it any better than using extern "C" in C++ in this case.

And nobody forces you to use the C++ standard library either. You can even compile with -nostdlib in case you want to make sure you aren't using it by accident.

[oiaohm]

C++ has ABI stability, just use extern "C". Facepalm.

All your mumbo jumbo is basically you refusing to use it because you don't want to, and then blaming the language. Some parts of it are intentionally unstable. If you want stability, simply don't use them. It's not like using C will make it any better than using extern "C" in C++ in this case.

And nobody forces you to use the C++ standard library either. You can even compile with -nostdlib in case you want to make sure you aren't using it by accident.

Moron keep your comment out of it. Take a spec from wine generate the .c file wrap it in your extern "C" stuff then attempt to build it with MSVC in C++ mode and watch it barf.

Turns out you cannot do name mangled names in extern "C".

Really Weasel this was demo as broken on the wine mailing list in 2004 and Linux kernel mailing list in 2006 and it still broken.

Extern "C" is not 100 percent in C++ compilers is C compatible.

Please note I had not referenced using C++ standard library. I had mentioned clearly the issue is with name mangling with the requirement to match it exactly for compatibility.

Just use extern "C" one of the common moron arguments to say use C++ and the people suggesting have never tried to fully use it to find out it broken.

[Weasel]

Moron keep your comment out of it. Take a spec from wine generate the .c file wrap it in your extern "C" stuff then attempt to build it with MSVC in C++ mode and watch it barf.

Turns out you cannot do name mangled names in extern "C".

Are you retarded? You make your own names that don't conflict (add a prefix for example) and then use .def files to map and export them mangled the way they are supposed to be.

extern "C" literally gives you C linkage, not my problem you don't know even basics of shit you talk about.

[oiaohm]

Are you retarded? You make your own names that don't conflict (add a prefix for example) and then use .def files to map and export them mangled the way they are supposed to be.

extern "C" literally gives you C linkage, not my problem you don't know even basics of shit you talk about.

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.

Weasel you are a windows only programmer who has not had to work cross platform so you suggest .def todo something that someone doing cross platform is going to choose C because it works in more places. Not C++ extern "C" proper C files.

Also if you are using C linking from C++ code base you really don't have most of the advantages of C++ anyhow.

Really Weasel you really just wanted to have a point so you could say I was wrong. Reality here you are wrong so get lost.

[tildearrow]

I'd like to ask...Weasel vs. oiaohm again... Ring the bell. Round 1!

Some parts of it are intentionally unstable. If you want stability, simply don't use them.

Which parts?

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

(this is what I use often)

[oiaohm]

Which parts?

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

(this is what I use often)

This is my problem. Weasel was basically white washing the problem. The answer is all 4 you listed are unstable across C++ versions resulting in run-time structure differences and incompatibilities.

Basically if not something that will go out by extern "C" from C++ it basically unstable. Once you cut C++ back to what is stable you fairly much have C with extra coding restrictions that when you are attempting to replicate an ABI those coding restrictions get in the way.

The features people want C++ for are also the ones you mostly cannot give them when doing stuff like wine.

[tildearrow]

This is my problem. Weasel was basically white washing the problem. The answer is all 4 you listed are unstable across C++ versions resulting in run-time structure differences and incompatibilities.

Basically if not something that will go out by extern "C" from C++ it basically unstable. Once you cut C++ back to what is stable you fairly much have C with extra coding restrictions that when you are attempting to replicate an ABI those coding restrictions get in the way.

The features people want C++ for are also the ones you mostly cannot give them when doing stuff like wine.

No, not you, oiaohm. I meant Weasel.

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?
Seriously, I mean, typing something like this:

if (name=="Remilia") {
  return false;
}

is WAAAAAAY more readable and better-looking than this:

if (strcmp(name,"Remilia")==0) {
  return 0;
}

Or something like this:

std::string name="Sakuya";

is much more readable than this:

char name[4096];
​​​​​​​strncpy(name,"Sakuya",4095);

(plus it has the benefit that the string can be arbitrarily long and the C++ library will reallocate it for you)

So I didn't mean you but Weasel.

[tildearrow]

Also, to add to my last post, I don't want my application to be C++-version-compatible. I just want it to be compatible with this version (e.g. C++11) and work well on future versions of the C++ library.

[oiaohm]

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?
Seriously, I mean, typing something like this:

if (name=="Remilia") {
return false;
}

is WAAAAAAY more readable and better-looking than this:

if (strcmp(name,"Remilia")==0) {
return 0;
}

Or something like this:

std::string name="Sakuya";

is much more readable than this:

char name[4096];
​​​​​​​strncpy(name,"Sakuya",4095);

(plus it has the benefit that the string can be arbitrarily long and the C++ library will reallocate it for you)

Little thing arbitrarily long string in C++ is because the length value is being record the C++ standard does not say how the length of string will be recorded other than it somewhere in a class. To be up there in fun it C++ does not say how final string will be encoded inside the C++ string as well, Yes particular versions of MSVC using std::string you end up like UTF16 encoded instead of UTF8.

Do note in strncpy you had stated a length. strcmp is not recommend no length stated.

Like I do disagree that C++ code is cleaner to read. Problem here is everything that you did that makes it cleaner to read has a ABI trap.

Remember when you are needing ABI compatibility you cannot be really using std::string because each C++ compiler class of std::string can in fact require different amounts of memory causing different memory alignments so ruining your ABI compatibility.

This is why I am looking at rust. I hope to get features like strings with ABI predictability that you don't get out of C++.

The cross compiler ABI match is one hell of a restrictive rule once you apply this to C++ you don't have many features. I want a language with the features of C++ with the ABI predictability of C no matter the compiler used. Then when someone ask C++ in wine or equal project I will be able to suggest a language that is at least a practical idea.

tildearrow there is a long list of people like you who want to "freaking use C++" because it make code that is cleaner for human to read. Problem C++ makes a mess at the ABI side. Yes the machine readable side. C is minor-ally horrible to the human programmer but ABI side predictable and clean.

I want a language that is cleaner for human to read and ABI side predictable. Until then we have to make a horrible choices.