> If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app.
That's not the case anymore. If you're aiming higher than .net framework 4.x, you have the option of either self-contained package (your app + .net core - min 70MB - appimage approach), or framework dependent (requires .net version at installation - flatpak approach).
I find the "things are not shared" section a bit weird though. Yes, not everything uses the same base and that's sad. But I've got 8 flatpak apps and 7 of them do share the runtime. We'll never get 100% unified and deduplicated approach here - in the same way we'll never unify Gtk/qt/tk/wx/...
> Flatpak allows apps to declare that they need full access to your filesystem or your home folder, yet graphical software stores still claim such apps are sandboxed.
Yes, distros really need to start talking about permissions / capabilities rather than some generic "sandbox". Some apps need to effectively read the whole disk. But maybe they don't need to write to home. Or maybe they don't need internet access. We'll have to get mobile-phone-like permission descriptions at some point, because a single label just doesn't describe the reality.
Since Windows 3.0 it has only been the case when using OS APIs, without depending on C runtime library, C++ runtime library and respective frameworks, COM or DLLs from other SDK or third parties, xcopy installs and installers exist for a reason.
Even with .net framework 4.x you need to bring the framework with you, if you want to use the newest frameworks, as your customers might not have the most current version installed.
The point as formulated still stands though. You don't have to because you can always guarantee that your end users will have a Win32 runtima and a .NET runtime.
There is a choice, and it's between using a later framework, and relying on the OS one.
The choice being stuck with what a specific Windows version has available and using OS APIs directly instead of C ones, e.g. ZeroMemory() instead of memset(), as the C runtime library isn't part of the OS.
Yes, I was only talking about Win32 and .NET, which is always bundled in windows (Obviously newer versions of the OS may have newer versions of them).
How C libraries work has never been a problem I have encountered (I do deploy C++ libraries with apps though, and the tendency to move to "all apps deploy a full copy of whatever runtimes they need" is a much better situation for all 3 parties involved (developers, users and hackers...).
I get the point of memset (although that particular example I believe is now an intrinsic).
That's not the case anymore. If you're aiming higher than .net framework 4.x, you have the option of either self-contained package (your app + .net core - min 70MB - appimage approach), or framework dependent (requires .net version at installation - flatpak approach).
I find the "things are not shared" section a bit weird though. Yes, not everything uses the same base and that's sad. But I've got 8 flatpak apps and 7 of them do share the runtime. We'll never get 100% unified and deduplicated approach here - in the same way we'll never unify Gtk/qt/tk/wx/...
> Flatpak allows apps to declare that they need full access to your filesystem or your home folder, yet graphical software stores still claim such apps are sandboxed.
Yes, distros really need to start talking about permissions / capabilities rather than some generic "sandbox". Some apps need to effectively read the whole disk. But maybe they don't need to write to home. Or maybe they don't need internet access. We'll have to get mobile-phone-like permission descriptions at some point, because a single label just doesn't describe the reality.