Wine 3.0 Released With Initial Direct3D 11 Support, D3D Command Stream

[Hi-Angel]

Thing here is its the one who wrote the MSVC dlls you are implementing compatibility with so application can run with wine code instead have decide what you have to throw across dll/exe boundary. So GC and exception interactions have to match. If you break that you will cause problems. This is one of the major differences doing something like wine you have limitations based on achieving compatibility.

I see.

Prohibit their usage of everything that can cause problems you end up fairly close to C in the first place. So you don't have the advanced features of C++.

Nah, what makes C++ so much appealing to me than C is neither exceptions nor the standard library (I mean, it's nice to have vectors and stuff, but given situation where you can't use it…). It is, offhand, in no particular order: RAII (aka "forget about gotos!"), lambdas, references (aka "forget about guessing whether this function can get null argument or not"), foreach; and then if we remember that we compare not just with C but with ancient C89, it's also variables declared in place, initializer lists.

[oiaohm]

Nah, what makes C++ so much appealing to me than C is neither exceptions nor the standard library (I mean, it's nice to have vectors and stuff, but given situation where you can't use it…). It is, offhand, in no particular order: RAII (aka "forget about gotos!"), lambdas, references (aka "forget about guessing whether this function can get null argument or not"), foreach; and then if we remember that we compare not just with C but with ancient C89, it's also variables declared in place, initializer lists.

But wine is not using C89 every where it using GNU89+ in areas.

https://stackoverflow.com/questions/368385/implementing-raii-in-pure-c

So you have GNU __attribute__ stuff. Most of RAII can be done that way. You will find most of what you said as reasons is exposed in gnu89 in a different format to C++ but its still there.

So wine does and does not use C89. Parts that have to build back on MSVC C89 is preferred (mostly because MSVC version to version can through you results all over the place with C++ code). That parts that will only ever be build with a gnu89+ compiler you will see large usages of the different gcc __attribute__ options and usage of declare and define in structures in one step.

As I said wine is not pure C89 its has large sections of gnu89+ what is quite a different beast. It does take a little getting head around that there are other ways todo a lot of the liked C++ features just because you have a gnu89+ compiler. llvm and gcc are both gnu89+ compilers.

The differences between C++ and gnu89+ is not as great as many would first think. Of course for something like Mesa that is going to build on non gnu compadible compilers going up to C++ does have more motivation.

[Hi-Angel]

But wine is not using C89 every where it using GNU89+ in areas.

https://stackoverflow.com/questions/368385/implementing-raii-in-pure-c

So you have GNU __attribute__ stuff. Most of RAII can be done that way. You will find most of what you said as reasons is exposed in gnu89 in a different format to C++ but its still there.

So wine does and does not use C89. Parts that have to build back on MSVC C89 is preferred (mostly because MSVC version to version can through you results all over the place with C++ code). That parts that will only ever be build with a gnu89+ compiler you will see large usages of the different gcc __attribute__ options and usage of declare and define in structures in one step.

As I said wine is not pure C89 its has large sections of gnu89+ what is quite a different beast. It does take a little getting head around that there are other ways todo a lot of the liked C++ features just because you have a gnu89+ compiler. llvm and gcc are both gnu89+ compilers.

The differences between C++ and gnu89+ is not as great as many would first think. Of course for something like Mesa that is going to build on non gnu compadible compilers going up to C++ does have more motivation.

But how can one differ parts that supposed to build with MSVC from those that doesn't. Per my understanding, 80% of wine code can be tested by the substitution-test, and hence have to be buildable&debuggable with MSVC.

I don't know gnu89, so let me just take for granted the assumption that its level of features is almost equal to C++. Then if I'm going to write, say, the mentioned support for libusb with very heavy usage of gnu89, won't it be frowned upon? FWIW your first comment here about usage of gnu89 was quite negative.

And then, given we already know from the bugreport that it builds fine with higher gnu-c standards, what about, say gnu99, gnu11?

[oiaohm]

But how can one differ parts that supposed to build with MSVC from those that doesn't. Per my understanding, 80% of wine code can be tested by the substitution-test, and hence have to be buildable&debuggable with MSVC.

Also that is not dealing with just 1 version of MSVC you are dealing with many where the C++ can change on you so stuffing with what you are attempting to-do.

So a large area of wine code is C89 and that caused by MSVC being a total pain.

I don't know gnu89, so let me just take for granted the assumption that its level of features is almost equal to C++. Then if I'm going to write, say, the mentioned support for libusb with very heavy usage of gnu89, won't it be frowned upon? FWIW your first comment here about usage of gnu89 was quite negative.

Please note my personal feelings to gnu89 goes up and down depending on if I have had porting issues that day because of it. libusb has to be cross platform and cross compiler and that normally causes the same problem you have MSVC in the mix..

And then, given we already know from the bugreport that it builds fine with higher gnu-c standards, what about, say gnu99, gnu11?

You do find gnu99 and gnu11 in places behind #ifdef for gcc versions in the wine source that don't need to be build out side gnu supporting compilers and even some #ifdef wrapped inside sections that are exported out to MSVC.

I would be nicer to set a gcc min version. So that the #ifdef for really old gcc could be got rid of in some places this would clean the code up a lot. So gnu99 or gnu11 in areas that would not have to be build by MSVC would be really nice.

[timofonic]

Professional Non-Linear video editing software on Linux you would be talking lightworks and blender. Blender is interesting with addon scripts it can replicate the work flows of about 5 other closed source windows only Non-Linear video editors and be platform neutral.

In circuit design http://kicad-pcb.org/made-with-kicad/ kicad is coming quite common.

I always have the question exactly what features do the cross platform options lack and do they exist as feature requests if so bugs please? Yes doing feature request to wine so wine improves is an option but it should not be the only option.

Lot of times I hear people say "I want Wine to better support:" big long list. More often that not that list is filled with items that native applications are more than up to the job of doing and those people just don't want to change workflow or submit feature request or update wine appdb entries so developers know if particular applications need work. Then they wonder why stuff does not improving when they are not doing anything to make it improve.

Wine project every time someone has been working on USB support or other ports they don't have employment to fund the process. Reality is a lot of people say they want wine with better support for hardware ports but they are not reaching into pocket and paying for it. It not like implementing USB support is a nice process.

The reply would be quite big, but a feature and UX comparison between proprietary and FOSS equivalent software would be quite interesting.

About Blender: Are you able to compare the work flow in a professional environment? It would be very interesting to see an study about it.

About ECAD/EDA: KiCad seems quite interesting, but high end EDA/ECAD software offer lots of features KiCad lacks. It would be nice to do a really good comparison. About UX, I noticed KiCad is weird in comparison to more used workflows in other ECAD/EDA software.

There's one really important reason about being able to use these software: File format interoperability. Even LibreOffice has big issues rendering office file formats the same way the original program does, despite their constant efforts at improving it. Even Microsoft Office has issues rendering files properly that are made by older Microsoft Office versions.

Anyway, I see Wine as a short term solution against native FOSS implementations

[timofonic]

Also that is not dealing with just 1 version of MSVC you are dealing with many where the C++ can change on you so stuffing with what you are attempting to-do.

So a large area of wine code is C89 and that caused by MSVC being a total pain.



Please note my personal feelings to gnu89 goes up and down depending on if I have had porting issues that day because of it. libusb has to be cross platform and cross compiler and that normally causes the same problem you have MSVC in the mix..



You do find gnu99 and gnu11 in places behind #ifdef for gcc versions in the wine source that don't need to be build out side gnu supporting compilers and even some #ifdef wrapped inside sections that are exported out to MSVC.

I would be nicer to set a gcc min version. So that the #ifdef for really old gcc could be got rid of in some places this would clean the code up a lot. So gnu99 or gnu11 in areas that would not have to be build by MSVC would be really nice.

Why is MSVC really required to generate equivalent .dll files and such? Why isn't GCC adequate for that? If it isn't: What efforts/changes/improvements would be necessary to make GCC be able to replace MSVC in such cases?

[oiaohm]

About Blender: Are you able to compare the work flow in a professional environment? It would be very interesting to see an study about it.

https://cloud.blender.org/welcome

Really its insanely hard to compare blender workflow to anything else. As blender really does not have one workflow. 90 percent of blender interface is changeable. Blender the software might be free the training videos and documentation to use well costs you $9.99 dollars a month for access. Yes when you save a .blend file or download a .blend file from the blender cloud it can contain your interface configuration. Blender is a truly like the mythical creature of a ShapeShifter.

This is why there are the training videos that teach you how to set up blender for different areas of workflow in a professional environment. Then you even see compares for workflows between blender of different configurations.

https://www.blender.org/about/projects/

Open project here are project that have been done using blender + only open source software.

About ECAD/EDA: KiCad seems quite interesting, but high end EDA/ECAD software offer lots of features KiCad lacks. It would be nice to do a really good comparison. About UX, I noticed KiCad is weird in comparison to more used workflows in other ECAD/EDA software.

Companies producing circuit boards and doing assembly report over 60% of the files they get these days were generated using KiCad. Prior to license change 80 percent were Eagle. So fairly much KiCad is replacing Eagle as the dominate.

KiCad might be weird but it is currently the dominate workflow in EDA/ECAD field. What ever is the dominate one at the time always has the most complete footprint library for parts.

So high end EDA/ECAD have always been a minority.

https://en.wikipedia.org/wiki/Comparison_of_EDA_software

Also your list gets very short very fast. KiCad basically implements the bare min requirement. Gerber/drill, and Gerber X2 are both required so you have choice of production. Gerber X2 particularly reduces you list of EDA software to 4 and one being Kicad.

You can drop diptrace because it simulation is weaker than Kicad.
Pulsonix embed splice gets in the way. Same problem weaker simulation.

So it fairly much comes down to Altium Designer vs KiCad. Its not like Altium does not have UX quirks to be correct it has a lot of them that starting a new file has to be done exactly the right way or latter on you find out you have to export everything and go back to the start because a simulation you wanted latter will not work because you choose the wrong option. At 7000+ USD per machine Altium is not cheap.

There's one really important reason about being able to use these software: File format interoperability. Even LibreOffice has big issues rendering office file formats the same way the original program does, despite their constant efforts at improving it. Even Microsoft Office has issues rendering files properly that are made by older Microsoft Office versions.

Really this problem here answers the next question.

Why is MSVC really required to generate equivalent .dll files and such? Why isn't GCC adequate for that? If it isn't: What efforts/changes/improvements would be necessary to make GCC be able to replace MSVC in such cases?

Its when you have a issue and you are replacing a wine dll into a MSVC built program to find out if the problem is in the wine dll or elsewhere in wine.

https://mingw-w64.org/doku.php/contribute#documentation_of_the_pdb_file-format

The pdb file Microsoft own debugger uses is undocumented. Since its officially undocumented Microsoft is free to break it in backwards incompatible ways at any time and when they do they tell you to rebuild your application. Great fun when customer sends you a binary crash log and you have to find version of visual studio with exactly the right patches so the binary crash log can be processed because the old pdb files from when you built the binary don't work any more.

Yes this is a interoperability nightmare. So you cannot make gdb read pdb dependable way and you cannot make mingw generate pdb in a dependable way and this is Microsoft fault. So leaving you totally stuffed. The only way to get MSVC program built from source with a wine lib built from source to fully debug with each other is to build in MSVC.

[ssokolow]

The pdb file Microsoft own debugger uses is undocumented. Since its officially undocumented Microsoft is free to break it in backwards incompatible ways at any time and when they do they tell you to rebuild your application. Great fun when customer sends you a binary crash log and you have to find version of visual studio with exactly the right patches so the binary crash log can be processed because the old pdb files from when you built the binary don't work any more.

Yes this is a interoperability nightmare. So you cannot make gdb read pdb dependable way and you cannot make mingw generate pdb in a dependable way and this is Microsoft fault. So leaving you totally stuffed. The only way to get MSVC program built from source with a wine lib built from source to fully debug with each other is to build in MSVC.

Things aren't as bad as they used to be.

• http://blog.llvm.org/2017/08/llvm-on...pdb-debug.html
• https://github.com/Microsoft/microsoft-pdb
• https://llvm.org/docs/PDB/index.html

[oiaohm]

Things aren't as bad as they used to be.

https://github.com/microsoft/microsoft-pdb/issues

Not is truly as bad as it use to be there was some light in 2015 but that has disappeared. But it still very bad. in 2016 the git tree came not build-able has not been build since. No question since 2016 has been answered.

I will give LLVM team credit for doing impressive job with how adverse Microsoft is. Maybe making wine build-able with llvm will be a solution long term to allow newer versions of C to be used and not be stuck with MSVC very old c standard support.

Yes they did not update the github branch with the VS 2017 changes or any changes done to VS 2015 pdb due to updates. The next VS release could leave what LLVM has done so far broken again.

They never got to the part of the microsoft pdb of publishing writing tests and reading conformance suite so that there was a line in the sand you generate this it will work.

Yes source can be called documentation and a test suite is how you make sure what you are implementing does not have regressions or new introduced bugs.. With the pdb stuff released on github as the llvm guys report blocks of the code are just completely missing and they have had to fill in the blanks and hope they got it all right.

Basically it comes back to the same thing. Either Microsoft need to formally document pdb (and stick to it not like OOXML) or at least release a test-suite setting what is the bare min that is promised to work with future versions of Microsoft debuggers so giving other parties something that can implement they know will work. Its not like anyone outside Microsoft can stabilise the format. Its not like wine is in a position to ignore code built by MSVC.