Going In-Depth With Flatpak For Sandboxed Application Packaging

[Weasel]

Visual studio C++ optimisation for performance C++ runtime.
This is something high performance application can pay for. I would not be surprised if you have not seen it. Most parties use the general not optimised version. You will see this with programs with strange versions numbers of C++ runtime that don't match your Microsoft standard release versions they have been customised.

Please note I have no trouble paying for visual studio. I really hate having to debug programs that have broken the rules and mixed versions. Its taken quite a good tool off the table being the debugging libraries.

Sorry to burst your bubble but the visual studio runtime is a redistributable offered by Microsoft as a free download. So everyone can download it, not "paying for visual studio", otherwise an app wouldn't run without having the end user (who's not a programmer) buy Visual Studio. That's just nonsense.

Where's this "optimized" runtime? Links?

Question is how they avoid the conflict.

Super easy, I explained it at least 10 times. Just use sound coding practice and stop thinking the fucking standard library is "one thing", no, it's one standard library for each module -- a different one. When you have this mentality when coding, ALL problems go away.

http://siomsystems.com/mixing-visual-studio-versions/
Above is another person list of known faults when you mix versions.

He literally describes the bad coding practice I was talking about, so it's funny how he even starts with blaming others telling him "it's perfectly safe if you know what you're doing" and then he proceeds to write bad code.

This fucking mentality of "there is only one standard library implementation" needs to stop. NOW.

You know even that guy proves you wrong. He outlines what's safe to pass and what isn't. You're the only one still refusing to admit your coding practice is pure trash and it's YOUR fault not Windows or anything else.

[oiaohm]

Sorry to burst your bubble but the visual studio runtime is a redistributable offered by Microsoft as a free download. So everyone can download it, not "paying for visual studio", otherwise an app wouldn't run without having the end user (who's not a programmer) buy Visual Studio. That's just nonsense.

Where's this "optimized" runtime? Links?.

You are not paying for HPC versions of windows are you. I would guess you don't have a gold partner login or higher. The links require you paying that much to start off with.

Super easy, I explained it at least 10 times. Just use sound coding practice and stop thinking the fucking standard library is "one thing", no, it's one standard library for each module -- a different one. When you have this mentality when coding, ALL problems go away.

The VEH problem has not gone away so all problems gone away is a bull crap claim.
Not being able to properly using debugging libraries is still the case. Ok for a person who does not own visual studio with the debugging libraries you would not this problem. So using more than 1 is still bad coding practice.

Coding in ways that make debugging hard to impossible is bad coding practice.

He literally describes the bad coding practice I was talking about, so it's funny how he even starts with blaming others telling him "it's perfectly safe if you know what you're doing" and then he proceeds to write bad code.

All he describes is the stuff you can avoid by coding practice.
Even if there is a safe replacement version available, it is still a bad practice to have multiple CRT instances in your program.
He states this very clear because he is more than aware that debugging is going to disrupted. That different function usages in the CRT will trigger conflicts at the Windows API layer like the VEH one.

This fucking mentality of "there is only one standard library implementation" needs to stop. NOW.

Please note he did not cover the VEH one that hits you when you attempt to use debugging visual studio libraries or paid for optimised visual studio libraries. So using more than 1 you have locked yourself out from using those.

You know even that guy proves you wrong. He outlines what's safe to pass and what isn't. You're the only one still refusing to admit your coding practice is pure trash and it's YOUR fault not Windows or anything else.

http://siomsystems.com/mixing-visual-studio-versions/#comment-17326

Read the comments.

Its not my code practice that is pure trash. The reality is you use third party libraries you cross versions you will have issues because not everyone is going to code it correctly.

Weasel
1) Microsoft does not recommend using more than 1 CRT per program. If you need to use multi CRT the recommend from Microsoft is to in fact use like com/ipc and run in independent processes to avoid all issues.
2) Microsoft does not promise to maintain compatibility between CRT versions. Microsoft has for particular versions of visual studio provide runtime replacement for particular older versions of visual studio to force all that code into 1 CRT.
3) Microsoft own visual studio run-time neutral libraries you know the ones like user32.dll are coded intentionally using only win32/64 ABI no CRT.

4) Weasel like it or not CRT under Windows is coder incompetence. Bad news coder incompetence is common.

https://docs.microsoft.com/en-au/windows/desktop/api/combaseapi/nf-combaseapi-cotaskmemalloc

You know how you have those memory allocations issues with CRT. You can avoid them just use ole32.dll and other win32/win64 native allocates that don't have any of the CRT problems. Allocate and free memory use these interface.

This brings the question why did Microsoft C/C++ not use Windows ABI native allocates? Decide to to internal CRT allocates causing lots of these problems..

Really complete CRT mess is Microsoft developers being nightmare makers. Glibc for a long time under Linux has been ABI stable your application depends on that and avoids C++ runtime under Linux everything is fairly good.

Windows avoid C and C++ runtimes use pure windows native API and everything is good even less cross platform portable...

C++ is where things go hell on Linux. Windows things go to hell even using pure C.. Ok using pure windows ABI everything is good on windows.

By the way Weasel all the stuff you do working around to avoid CRT conflict is not much different to what is required to avoid C++ conflict under Linux.

[Weasel]

You are not paying for HPC versions of windows are you. I would guess you don't have a gold partner login or higher. The links require you paying that much to start off with.

Huh? But it's the same redistributable. Obviously I'm talking about release mode (there's a different one for debug).

Really all your argument is debug mode?

When you mix a 3rd party library, the library has no business being in debug mode. Period. That's bad coding practice. Debugging is for when you have access to its source code so in that case you don't have to mix anything anyway. If they give out debug mode they might as well give the source code since debug keeps a lot of traces for that and even needs it for proper debugging experience.

I'm not aware of any compiler with a debug mode that allows you to mix its output with a binary made by another version, so really you're grasping at straws here. Debugging code is typically "hardcoded" for the exact compiler you have, it's NONSENSICAL to distribute debug builds.

VEH conflicts are the least of your worries if you end up using debug builds of a 3rd party library without its source code. I question the sanity of the library dev.

[oiaohm]

Huh? But it's the same redistributable. Obviously I'm talking about release mode (there's a different one for debug).

They are not the same redistributes that the problem. You have the following visual studio runtimes
1) general redistribute release the one you find in Microsoft website.
2) Debugging release not allowed to be shipped with applications legally.
3) you have the architecture targeted releases of the runtimes(gold partner or better) not allowed to be shipped with application without paying fee.
4) Custom build optimised versions that you have to pay quite a bit for. If you have one these its unique for your company products. Welcome to pot luck.

Visual Studio 2017 not counting security updates at the end of last year there was already 300 known variations of the runtime. You don't want to think how many older versions of Visual studio have. This is truly fragmentation gone nuts.

When you mix a 3rd party library, the library has no business being in debug mode. Period. That's bad coding practice. Debugging is for when you have access to its source code so in that case you don't have to mix anything anyway. If they give out debug mode they might as well give the source code since debug keeps a lot of traces for that and even needs it for proper debugging experience.

I'm not aware of any compiler with a debug mode that allows you to mix its output with a binary made by another version, so really you're grasping at straws here. Debugging code is typically "hardcoded" for the exact compiler you have, it's NONSENSICAL to distribute debug builds.

VEH conflicts are the least of your worries if you end up using debug builds of a 3rd party library without its source code. I question the sanity of the library dev.

Sorry when you have patented stuff you need to use sometimes the only way you can use that stuff is use their library and you have to agree to that to get patent license. This means you need to be able to debug your code you wrote that works with a library you don't have the source of.

Real world does not allow to have source code to all the libraries to have to use all the time. To be correct visual studio runtime debugging libraries work quite well with 3rd party libraries closed source without debugging data using either the same visual studio runtime or no runtime. You only start screaming when you find out the library is using a different version of visual studio runtime due to nice levels of conflict. Please note is not the debugging symbols or lack of debugging symbols on 3rd party library its the lack of ability for the debugging version of visual studio libraries to understand what is going on. Like this allocated memory was in fact freed inside X library in x function does not tell you exactly what was going on inside x function but is useful for memory issues. Same with type of exceptions that are happening inside library.

Problem here is the beast of the visual studio debugging runtime optimises to attempt to reduce overhead of debugging that leads to hell when you have cross versions. Were you have debugging runtime tell you that using VEH it found a unhanded exception and that was caused because the other version visual studio C++ allocated a handler than it missed.

At this point you start purely hating mixed runtime applications not made properly. Because 30 second job to find a minor memory problem and fix it turns into days with your boss breathing down your neck.

Weasel besides Microsoft Windows/Visual studio runtimes are all third party code you don't have source code to. You debug all the time with libraries you don't have the source code to. Me working under Linux is one of the rare times I am debugging with all libraries where I have source code to.

[Weasel]

They are not the same redistributes that the problem. You have the following visual studio runtimes
1) general redistribute release the one you find in Microsoft website.
2) Debugging release not allowed to be shipped with applications legally.
3) you have the architecture targeted releases of the runtimes(gold partner or better) not allowed to be shipped with application without paying fee.
4) Custom build optimised versions that you have to pay quite a bit for. If you have one these its unique for your company products. Welcome to pot luck.

Visual Studio 2017 not counting security updates at the end of last year there was already 300 known variations of the runtime. You don't want to think how many older versions of Visual studio have. This is truly fragmentation gone nuts.

(2) is completely pointless since they have different NAMES in the first place. They're not even the "same" runtime, not even theoretically.

(3) and (4) are laughable, man. I mean, even if YOU have a custom build optimised version (which I doubt), the end users of your app will not, they'll just download the free one by Microsoft or the supposedly free one you bundle with your app's installer or whatever.

And really if YOU have a conflict on YOUR machine due to YOUR choices of using a "custom optimised build", it's on YOU.

You might as well just patch and fuck up system libraries and then say there's conflict. Fully your fault here. Normal end users who don't fiddle with their stuff won't have any conflicts and that's what matters.

Weasel besides Microsoft Windows/Visual studio runtimes are all third party code you don't have source code to. You debug all the time with libraries you don't have the source code to. Me working under Linux is one of the rare times I am debugging with all libraries where I have source code to.

This is completely besides the point.

I'm talking about a "debug build" not whether you're "debugging a binary without source code". A debug build is connected to the source code, even the line numbers and details like that, because it's not supposed to be distributed, at least not without the source.

You realize a debug BUILD leaks far more "information" about the source code than a release BUILD, right? That is, it's kind of pointless to not supply the source code while providing a debug build to someone.

[oiaohm]

(2) is completely pointless since they have different NAMES in the first place. They're not even the "same" runtime, not even theoretically.

The debugging runtime can be forced into a release version by a manifest modification. Debugging runtime placed in SXS has the same names. Application built against debugging runtime use different names for the library. Basically there are two ways to load the debugging libraries.

(3) and (4) are laughable, man. I mean, even if YOU have a custom build optimised version (which I doubt), the end users of your app will not, they'll just download the free one by Microsoft or the supposedly free one you bundle with your app's installer or whatever.

You missed paid fee to ship. This means you program installer has the customised version of the runtime include. I call this thing at time many bad names.

If the custom versions have been badly versioned what does happen. When the custom version installs into SXS all programs using that version of visual studio runtime think its an update and your system they can all go to hell particularly if that custom version happens to be missing functions that would have normally been included in the Visual studio runtime.

You have the free version of the runtime you can bundle with your installer or the paid for versions you can bundle with your installers. Yes it normally pays to avoid the paid versions unless you have some true need. Users can be really upset and send you really nasty letters particularly if they have end up reinstalling their computer because they could not use their computer because the custom version of visual studio runtime installed badly. It also an extra cost. How custom version goes wrong at times is worse than the cost to be able to ship them due to how upset customers get and how many customers you can lose.

I'm talking about a "debug build" not whether you're "debugging a binary without source code". A debug build is connected to the source code, even the line numbers and details like that, because it's not supposed to be distributed, at least not without the source.

I have not being talking about working with a debug build.

Please note when you build you release binaries you debugging data can be placed in independent files. The .pdb files for release contain the debugging stuff. So you do not need debugging build to have debugging symbols. You have your release binary + .pdb files for the parts you have source to. This is why there is a manifest way to force a release binary to use debugging versions of visual studio libraries.

Yes when are debugging a release binary that uses a closed source library you don't have the source to. You can still monitor different things with the debugging run-time does not tell you lots of information like line numbers or exactly what the code is doing but you do get to see exceptions and guess from there why third party library is failing to run. Like you see exception about memory error and then third party library returns failed this is a useful clue.

Here something critical you can have bugs that only appear in the release version build. This is why you have to know how to debug that and how to enable the useful features like debugging libraries if they will work. If you have cross versions of visual studio run-times you have ruined that..

[Weasel]

You missed paid fee to ship. This means you program installer has the customised version of the runtime include. I call this thing at time many bad names.

If the custom versions have been badly versioned what does happen. When the custom version installs into SXS all programs using that version of visual studio runtime think its an update and your system they can all go to hell particularly if that custom version happens to be missing functions that would have normally been included in the Visual studio runtime.

You have the free version of the runtime you can bundle with your installer or the paid for versions you can bundle with your installers. Yes it normally pays to avoid the paid versions unless you have some true need. Users can be really upset and send you really nasty letters particularly if they have end up reinstalling their computer because they could not use their computer because the custom version of visual studio runtime installed badly. It also an extra cost. How custom version goes wrong at times is worse than the cost to be able to ship them due to how upset customers get and how many customers you can lose.

I've never seen this "paid" installer, so I can only assume it's either nonsense you're speaking -- or it's extremely rare and nobody in their right mind would use it when distributing to others (maybe only for personal use or internally).

Even if it were true, not only would you have to prove such a custom "paid" version of the runtime exists, but also that it uses VEH in the first place which is kind of laughable but whatever. You've since made 2 claims and haven't proved either of them. It's not "known" either, since I've never seen it, so maybe provide some backup to your argument not just CLAIMS which anyone can do.

Here something critical you can have bugs that only appear in the release version build. This is why you have to know how to debug that and how to enable the useful features like debugging libraries if they will work. If you have cross versions of visual studio run-times you have ruined that..

You're missing the point, you can have a debug version on YOUR app, but not on the third party library your app depends on. You aren't supposed to debug other people's libraries. If it's a bug in the library, the library dev will use debug version and will do it on HIS library (he has the source code after all) while not having the debug version on your app. See? No conflict.

[oiaohm]

I've never seen this "paid" installer, so I can only assume it's either nonsense you're speaking -- or it's extremely rare and nobody in their right mind would use it when distributing to others (maybe only for personal use or internally).

You have to look closely for it. I have noticed it with some versions of MYOB being a true custom version. Its checking out the versions you have in the SXS and you will see a odd version numbers that don't match any of the Microsoft general release provided. The optimised versions for particular cpu types are normally used internally only by those with gold registration. The paid installer when visual studio runtime installs behaves exactly the same as normal release versions. Only clue that you have one is the fact the versions in the SXS and on the dlls are different to release versions and possible applications being stupid until you install the release version or remove the version the application installed..

Even if it were true, not only would you have to prove such a custom "paid" version of the runtime exists, but also that it uses VEH in the first place which is kind of laughable but whatever. You've since made 2 claims and haven't proved either of them. It's not "known" either, since I've never seen it, so maybe provide some backup to your argument not just CLAIMS which anyone can do.

Do you know someone with a gold partner registration. Its no point tell you where you have to go if you cannot login to see it.

You're missing the point, you can have a debug version on YOUR app, but not on the third party library your app depends on. You aren't supposed to debug other people's libraries. If it's a bug in the library, the library dev will use debug version and will do it on HIS library (he has the source code after all) while not having the debug version on your app. See? No conflict.

Like it or not you use the Visual studio debugging runtime. Its put a VEH in it now trapping the SEH. Its the way VEH is design to work. If your application and third party library are using the same visual studio runtime you normally don't incorrectly trap SEH with VEH.

Yes you are not meant to exactly debug other people libraries. The fact the library is failing can be your code with problem. Having the list of exceptions that are happening are clues. Is this a library problem is this something simple like where you have passed a unallocated pointer into a library function that should have been allocated. Looking the exceptions allows you to work out is the problem the fault of the library or is it the fault of your code or is it some hardware fault.

Please note trapping exceptions is not disassembly on the library.

The reality is something simple you have to debug your code and to debug what your code is doing wrong at times requires looking into the errors third party library can be hiding in its SEH handling. Because those exceptions can be telling you what your code has wrong and the libraries SEH masking over. Fault could be happening like in dll main where its error handled by SEH only turns up when you attempt to perform dll function latter that something is wrong. These case there is nothing wrong with the third party developer provided library. Ask them to debug library is asking them to waste their time if the problem is your code.

Once you have made sure that none of the exceptions that the library is dealing are not a coding error in your code then you report fault to library developer. The VEH in debugging runtime is there for very good reason. No point bothering a third party library developer if the fault turns out you did not init memory correctly or you have locked a bit of hardware the library needs..... Well written library can attempt to cope with these problems not always give nice clear error messages.

[Weasel]

You have to look closely for it. I have noticed it with some versions of MYOB being a true custom version. Its checking out the versions you have in the SXS and you will see a odd version numbers that don't match any of the Microsoft general release provided. The optimised versions for particular cpu types are normally used internally only by those with gold registration. The paid installer when visual studio runtime installs behaves exactly the same as normal release versions. Only clue that you have one is the fact the versions in the SXS and on the dlls are different to release versions and possible applications being stupid until you install the release version or remove the version the application installed..

Do you know someone with a gold partner registration. Its no point tell you where you have to go if you cannot login to see it.

I don't care? I'm talking about distributed apps. You know they usually have a vcredist_x86.exe or vcredist_x64.exe in a folder like "extras" or "redist" or "runtime" or whatever of their installer. That is the standard .exe file offered "for free" by Microsoft and it gets launched at the end of the install process by the app's installer.

So until you can show me an application that distributes your custom version then it's time to shut up cause I'm sick of arguing in circles.

All I care about is application distribution and those apps relying on it, not whether you installed the custom version on YOUR PC because you "paid for it". That, to me, is no different than you fucking up your Windows installation, you can't seriously blame Windows stability for that, so...

So, show me a fucking app that distributes your custom version and then prove it uses VEH, or shut up.

[oiaohm]

I don't care? I'm talking about distributed apps. You know they usually have a vcredist_x86.exe or vcredist_x64.exe in a folder like "extras" or "redist" or "runtime" or whatever of their installer. That is the standard .exe file offered "for free" by Microsoft and it gets launched at the end of the install process by the app's installer.

MYOB a few updates you will notice that vcredist_x86.exe and vcredist_x64.exe shipped with program is not the standard .exe offered for free. This is the catch the custom ones have the same exe name. Only clue is when you check the version information on those files or that everything has gone to hell. You also do notice at times when you using something like backuppc that a deduplicating backup and you notice that you have quite a few different versions of those files when you have backed up install folders more than the general release numbers.

Basically people running network management come across this at first you can think malware versions or damaged storage of vcredist_x86.exe/vcredist_x64.exe only to find out that you have programs using genuine custom versions.

MYOB updates for tax at times include these custom runtimes with custom VEH stuff in them kind of happens when you have horrible must allow divide by zero at x location and using NAN processing because 1 countries tax maths require it. You only get these updates if you have paid for MYOB. Same goes with all the other cases of custom programs. The demo programs come with standard versions. Custom version you pay per sold license. MYOB is about the cheapest program I can point to. Also for me to give you what updates you would have to be in the same country as me with MYOB because it the tax system updates. This is the cheapest program I know that ships with custom versions of visual studio runtime.

Reality is you could have a few of these programs and not even notice them. Because as you said lot of programs ship with the standard one. I first hit this problem when I did a clean install and installed MYOB from the update disc then installed a program that used visual studio runtime that did not ship with the runtime and it went stupid. If I had installed MYOB from the install disc then applied update that basically resinstall the complete MYOB program again no problem would appear because the custom and standard versions of visual studio runtime would be both in the SXS. This made me put visual studio runtime normal download versions in my automatic install system for programs that don't have it bundled and not depend on some other program in the que to install it just in case the version it installing is custom.