Comments by "" (@grokitall) on "Wine Fixes Bugs in Windows 3.1 Software Running on Linux" video.

the reason for the lack of backward compatability is simple. if you develop a windows library, when you need to break backwards compatability, you create the library 2.0 binary. on linux, they don't keep the abi working, so at some point you have to choose between version 1 and version 2. this breaks things a lot. for old unix software, it mostly still works, as they don't make that mistake. wine does this the right way, by having the old windows libraries translate to the new ones internally, so you only end up maintaining the api and a small amount of glue logic, and the rest is current code.
11
@LTPottenger good, the last thing we need is the return of the unix incompatability wars from commercial vendors. however library providers could do a much better job than they do now.
1
@robertasm20 the unix wars were not about minor incompatibilities between vendors, but were about lots of mutually incompatible extentions to "differentiate" the products to the extent that it made it impossible to write programs on one system which would even compile properly on other vendors products. on linux the situation is completely different. most programs you can download and compile on any distribution, and be confident you will get working software. while we do have some issues with different basic tooling around packaging and the extent to which not every distribution is in thrall to systemd, most of that can be engineered around with the use of tools like ansible. this is because most of the tools in question were trying to solve near identical problems, and thus came up with very similar solutions, but with different tool names and flag names. this makes translation between them fairly easy. most of the desktop level issues are resolvable using flatpack packages. most of the remaining issues are due to library providers not doing versioning properly, and to things like the timings and support for switching over from one major subsystem to its replacement, where some distributions ship it before it is ready, and others are forced to wait too long, as the maintainers of the new subsystem cannot seem to understand that while it is done for them, it is somewhere between unusable and dev complete for whole other categories of users. i don't really have a good solution to either problem, but that does not make the issue go away.
1
@robertasm20 The only system where the measure of compatability is binary compatability is windows, as that was often the only choice. even there, you have the issue that backward compatability is often only supported for a few years, requiring the programmer to do a significant rewrite to get a new version working on the next version of windows, which because it needs to use the new framework, often won't work on the previous version of the os. pretty much every other operating system in modern times has been based upon source code compatability, often requiring just copying it across and recompiling. on these systems, binary fiĺes and packages are usually either about efficiency, or caching. in any event, this is usually done by your distribution maintainers, and is thus not an issue unless you want something unusual, in which case you probably have to compile it yourself anyway. as to the size of flatpacks, the issue there is that not every program is packaged by either the developer or the distributor for every specific distribution. flatpacks, snaps, and appimages were designed to overcome this problem until the distributions could get their act together and make things mostly work for most packages. The usual approach for all of these systems is to bundle the specific library versions needed in with the applications. for most people, neither the bandwidth nor the disk space are in short enough supply to force the distribution maintainers to fix the library versioning problem, so you just have to put up with it. this has been the standard for apple binaries for decades, storing every library in the same directory as the application. windows ships the same way, but ends up dumping the libraries in a common windows library directory, with mandatory library versioning, so that you can have version 1 for the programs that need it, and later add version 2 for programs that need that without breaking all the programs which need version 1. unfortunately, most library programmers on linux have not got that message, so lots of programs break when you break semantic versioning, with major versions keeping the same name, so you have to choose which programs to dump. until you fix that, the windows solution is not an option, so you have to fall back to the apple solution.
1