Live data from Hacker News

Convert Linux to Windows

philipbohun.com

91–100 of 459 posts

Re: Convert Linux to Windows

#91
post #74

Ask IBM how well that idea worked. I think it's fair to say that OS/2 had better Windows compatibility (for it's era) than Wine offers (in this era). The problem was that Microsoft introduced breaking changes with the introduction of Windows 95. While old Windows applications would continue to run under OS/2, IBM felt that it would take too much effort to introduce a compatability layer for Windows 95. If I recall co…

A windows95 compatibility layer would have been feasible if OS/2 had more sales volume.

The latest multi-platform packaging systems like Nix or Flatpak have largely solved the binary compatibility problem but providing some guarantees of library versions. This approach makes more sense in modern contexts with cheap storage and fast bandwidth.

Re: Convert Linux to Windows

#92

Earlier quoted context omitted.

And if memory serves one of the important features of Proton is to control how each app is configured individually, precisely to let you do needed tweaks at a local level.

Yes, and you can do this application specific tweaking but it’s largely less required now than it was in the past.

Less required in general or by the user? I sort of had it in my head that part of what Proton did was to just bundle all of those tweaks so you didn't have to think about it, but I haven't actually looked under the hood.

Re: Convert Linux to Windows

#93
post #88

Java already solved this problem, for the most part. This whole ABI nonsense really grinds my gears. It's essentially just a result of the silly decision to compile software into dubious blobs and ship those to users. You could get rid of an awful lot of malware and massively simplify software distribution if you were to distribute a platform agnostic intermediary representation of source code that preserves enough s…

[flagged]

Re: Convert Linux to Windows

#94

Earlier quoted context omitted.

> shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux That doesn’t work for GUI programs which use a hardware 3D GPU. Linux doesn’t have a universally available GPU API: some systems have GL, some have GLES, some have Vulkan, all 3 come in multiple versions of limited compatibility, and optional features many of them are vendor specific. In contrast, it’s impossible…

Question, from an application developer's perspective: What is the implication in regards to cross-platform Vulkan applications? I.e., my 3D applications all use Vulkan, and they compile and just work on both Windows, and Ubuntu. Does this mean that on other or older distros, they might not work?

> Does this mean that on other or older distros, they might not work

Yep exactly. While Vulkan API is well defined and mostly stable, there is no guarantee in Linux implementation will also be stable. Moreover Khronos graphics APIs only deal with the stuff after you allocated a buffer and did all the handshakes with the OS and GPU drivers. On Linux none of those have API / ABI / runtime configuration stability guarantees. Basically it works until only one of the libraries in the chain breaks the compatibility.

Re: Convert Linux to Windows

#95
post #88

Java already solved this problem, for the most part. This whole ABI nonsense really grinds my gears. It's essentially just a result of the silly decision to compile software into dubious blobs and ship those to users. You could get rid of an awful lot of malware and massively simplify software distribution if you were to distribute a platform agnostic intermediary representation of source code that preserves enough s…

> dubious blobs

I think you are just suggesting to replace binary blobs with other binary blobs e.g. CLR/.NET assemblies/executables or WebAssembly files.

Or do it the JavaScript way: distribute compressed minified (kinda compiled) source code and the runtime JIT compiles it at runtime (e.g. V8 engine Turbofan compiler).

Re: Convert Linux to Windows

#96
By the way, Wine is more stable than Windows itself in supporting older Windows ABIs.

Someone should develop an analog for Linux itself. I.e. support for older / historic ABIs that would be translated into whatever modern Linux has.

Some isolated example of that is SDL 1.x translated to SDL 2.

Wine itself already exists, you don't need to develop any new distro for running Windows programs on Linux. Just improve Wine if anything is missing.

Re: Convert Linux to Windows

#97
post #88

Java already solved this problem, for the most part. This whole ABI nonsense really grinds my gears. It's essentially just a result of the silly decision to compile software into dubious blobs and ship those to users. You could get rid of an awful lot of malware and massively simplify software distribution if you were to distribute a platform agnostic intermediary representation of source code that preserves enough s…

> Shipping binary files is just plain bad in every way.

Aren't .class and .jar files "binaries"?

> Java already solved this problem, for the most part

Maybe, just maybe, there are some drawbacks that mean that in fact it's not solved. Otherwise perhaps Java would've completely obsoleted C, C++. Some of us design applications which can't tolerate the worst case GC pauses, for example. Some of us design applications which we can't afford to spend extra time heap-allocating nearly everything.

Re: Convert Linux to Windows

#98

Earlier quoted context omitted.

> shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux That doesn’t work for GUI programs which use a hardware 3D GPU. Linux doesn’t have a universally available GPU API: some systems have GL, some have GLES, some have Vulkan, all 3 come in multiple versions of limited compatibility, and optional features many of them are vendor specific. In contrast, it’s impossible…

Note that this also underlines that the post's premise of Windows having a simple stable ABI - win32 sure is stable, but that's not what applications are coded against anymore. Sure, you can run a 20 year old app, but that is not the same as a current app still working in 20 years, or even 5.

Win32 is quite extensive for an OS API. It covers the space from low-level stuff like syscalls and page allocation and all the way up to localization, simple media access and GUI. So everything from glibc, libsystemd, libpam to libalsa and egl on Linux side. And it is all stable.

Microsoft also provides quite good stability for DirectX and other extension APIs. You can still run old .Net apps without issues as long as they didn't pull a Hyrum's Law on you and depended on apparent behavior.

Re: Convert Linux to Windows

#99
post #68

To the extent binary distribution is "unstable" on Linux, it's because users aren't expected to just download random binaries from wherever, as is normal on Windows (and Mac, for that matter). Users are expected to either obtain binaries from their distro, or compile them from source. In either case, all of the issues about binary distribution being "unstable" are invisible to users. Which is the point. People who wa…

Thank you very much! I was about to post almost the same thing, so I'll reply to your post instead (and upvote):

It's pretty funny to read a critisism of linux s/w distribution along the lines of the dificulty of distributing binaries.

This is one of the biggest security vulnerabilities of windows. 3rd parties distributing binary executables.

At least in a typical linux distro the binary is built by the distributing org, with some review of where the source comes from.

Downloading a windows app from the internet one has no idea what source is included in that binary.

I'm also not a fan of non-distro based systems such as flatpack. Again, I would prefer my binaries built by the distribution, or if need be, locally.

Re: Convert Linux to Windows

#100
post #90

Earlier quoted context omitted.

Is this sarcasm? Some of my favorite games are 20 years old. Windows is popular in a lot of manufacturing spaces because the equipment software doesn't get updated and only connects to old programs over 16 bit serial ports. There's a whole world out there of legacy software that is happily churning along, and doesn't need to be updated.

Okay, but then you could also keep it running on an old OS. Fork out the money for a RHEL license, and just never upgrade.

But I don't want to run a separate machine with 15, 20, 25 year old hardware to keep that OS working.
Post reply on HN