Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Convert Linux to Windows

philipbohun.com

Post reply on HN
Print view View original

421–430 of 459 posts

Re: Convert Linux to Windows

#421

Post by Gormo »

elmo2you wrote: post #291
feelamee wrote: post #277

> I can pull down a 20 year old exe and still run it today on Windows. Try doing the same with a Linux binary that's just a year old. There's no guarantee that it will be able to run based off some update that has happened IMHO, you just compare two different things. Traditional method of installing apps on Windows is packing all dynamic dependencies with it. While on linux dynamic dependencies are shared between app…

Aside from comparing two different things, as you correctly identify, I believe that even the author's original assertion just isn't true. Maybe for some exe files, but I doubt for all or even most. I was involved in replacing Windows systems with Linux + Wine, because (mission-critical industrial) legacy software stopped working. No amount of tweaking could get it to work on modern Windows system. With Wine without…

Well, there's always LD_PRELOAD and LD_LIBRARY_PATH on Linux. My experience has been that most of the time when older binaries fail to run, it's because they are linked against old versions of libraries, and when I obtain those library versions -- exactly the same as obtaining the DLLs for the Windows executable -- things usually work just fine.

Re: Convert Linux to Windows

#422

Post by account42 »

ur-whale wrote: post #331
mappu wrote: post #6

I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no archaic libc5). Glibc has great backwards compatibility and the binary will work on any glibc distribution today as long as you have all the .so's, same as needing the .dll's on Windows.

> Glibc has great backwards compatibility We're clearly not living in the same universe here. glibc backward compatibility is horrible. Every. Single. Time. I try to use an old binary on a modern distro, it bombs, usually with some incomprehensible error message with GLIBC in all caps in it. And these days, you can't even link glibc statically, when you try it barks at you with vehemence. As a matter of fact, as poin…

[citation needed]

Please post actual issues encountered, including non-paraphrased errors instead of FUD.

And if you want to statically link your libc there is nothing forcing you to use glibc. You're only stuck with glibc (and even then you don't actually need to use any functions from it yourself) if you need dynamic linnking for e.g. OpenGL/Vulkan. Also, glibc wasn't designed for static linking even before they put in safeguards against that.

Re: Convert Linux to Windows

#423

Post by Gormo »

a3w wrote: post #247

> I can pull down a 20 year old exe and still run it today on Windows Barely - most bigger programs did not adhere to all standards, but got custom fixes under the hood in follow-up windows versions. Also, around 2001 was the big architectural change for desktop from DOS to NT, so this might seem like cherry-picking the timeframe selected.

> Also, around 2001 was the big architectural change for desktop from DOS to NT, so this might seem like cherry-picking the timeframe selected.

It's true that the entire Windows product family converged onto the NT codebase with the release of Windows XP, but this isn't really relevant -- Windows executables and DOS executables were always different things, and despite being built on top of a DOS-based kernel, Windows 9x still supported the same Win32 binaries that ran under NT.

There was even an extension called Win32S that allowed Win32 executables to be run under Windows 3.1. The Win32 API dates to the early '90s, and modern implementations do support executables dating all the way back to the beginning.

Re: Convert Linux to Windows

#424

Post by Gormo »

graemep wrote: post #338
d3Xt3r wrote: post #191

Earlier quoted context omitted.

> sub-par desktop experience. I strongly disagree. Linux (KDE) is a far superior desktop experience these days, compared to Windows 11. Have you even seen the new Win11 taskbar and the shitty Start Menu - they ruined something which they perfected in Win7. The overall UX has taken a deep dive - like with the unwanted removal of classic Control Panel applets like "Window Color and Appearance" (which doesn't have a rep…

I agree. I prefer KDE to any other desktop I have tried, although i also like XFCE. > Please don't put nVidia and AMD in the same sentence. and in general I have not had hardware issues. You can pretty much avoid them completely by buying hardware intended for Linux.

XFCE is probably the closest thing around to a traditional Windows desktop environment.

Re: Convert Linux to Windows

#425

Post by geokon »

Narishma wrote: post #347
geokon wrote: post #281

Earlier quoted context omitted.

I hit quirks with glib semi-regularly (~1/year) For example, recently I tried to run Emacs' Appimage and it has a glib issue https://github.com/probonopd/Emacs.AppImage/issues/22#issuec...

glibc, not glib. That's a different library.

that's embarrassing.. you're right. Thank you for the correction. Wish I could delete my comment

Re: Convert Linux to Windows

#426

Post by account42 »

LeFantome wrote: post #136
Const-me wrote: post #25

Earlier quoted context omitted.

> that's not what applications are coded against anymore Not sure I follow. Sure, most modern programs are not using old-school WinAPI with GDI, but the stuff they added later is also rather stable. For example, the Chromium-based browser I’m looking at uses Direct3D 11 for graphics. It implements a few abstraction layers on top (ANGLE, Skia) but these are parts of the browser not the OS. I view all that modern stuff…

I agree. On Linux (and Mac really), new APIs replace old ones and old binaries stop working. On Windows, new layers are applied over the old. There is DirectX 9-12. New binaries may use 12 but the ones still using 9 are perfectly happy. Things like .NET work the same. You can have multiple apps installed relying on different .NET versions.

You can still use OpenGL 1.0 and Xlib-like-it's-1999 on modern Linux distributions.

Re: Convert Linux to Windows

#427

Post by account42 »

Const-me wrote: post #14
devit wrote: post #5

That makes no sense: shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux, which is what flatpak/snap/appimage do. It can also be achieved with static linking and by shipping all needed library and using a shell script loader that sets LD_LIBRARY_PATH. Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in p…

> 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…

This is FUD. There isn't a single real desktop Linux distribution without OpenGL support. The basic OpenGL API hasn't changed ever, it's just been extended. It has even more backwards compatibility than Direct3D. Sure you can deliberately build a distro with only Vulkan or GLES (a mobile API) if you want to be an ass but the same goes for Windows. Same for X11 - Xlib works everywhere even any Wayland-only distribution that gives a single crap about running binary distributed software.

Now GUI toolkits are more of an issue. That's annoying for some programs, many others do their own thing anyway.

Re: Convert Linux to Windows

#428

Post by account42 »

Const-me wrote: post #356
arghwhat wrote: post #343

Earlier quoted context omitted.

Apologies, but "I heard that..." is not an example.

The phrase you quoted is not from the comment I linked; you’ve quoted from a response. Here’s the comment I have linked above: > I have flatpaks from several years ago that no longer work (Krita) due to some GL issues. That’s an example of Linux GPU APIs being unstable in practice, and container images not helping to fix that.

It more likely is an example of immature container images causing issues.

I'm running Loki game binaries just fine today btw.

Re: Convert Linux to Windows

#429

Post by worthless-trash »

DeathArrow wrote: post #298
worthless-trash wrote: post #294

Earlier quoted context omitted.

You sure are not alone, your mindset is that of a user, not a developer. Its like expecting people who only eat food to understand how its made.. You're just not the target.

I am both. But I do not feel the need to look at the source code of all software I use or tinker with it.

I didnt see all in your original post.

Re: Convert Linux to Windows

#430

Post by account42 »

dwattttt wrote: post #40
arghwhat wrote: post #20

Earlier quoted context omitted.

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.

> 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. It's true, but this touches on another point they made: what apps code to is other dynamically linked libraries. The kind that wine (or other host environments) can provide, without needing to mess with the kernel.

That's what apps are supposed to code to. When it comes to games and especially anti-cheat that's not always the case though and so Wine does have to handle direct system calls, which needs support from the kernel (at least to not be unusably slow).
Post reply on HN