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

291–300 of 459 posts

Re: Convert Linux to Windows

#291

Post by elmo2you »

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 a hitch, once all the required DLL files were tracked down.

While Wine may indeed be quite stable and a good solution for running legacy Windows software. I think that any dynamically linked legacy software can cause issues, both on Windows and Linux. Kernel changes may be a problem too. While Windows is often claimed to be backwards compatible, in practice your mileage may vary. Apparently, as my client found out the hard/expensive way.

Re: Convert Linux to Windows

#292

Post by bregma »

jchw wrote: post #155
CrossVR wrote: post #152

> While the Linux syscalls themselves are very stable and reliable, the c library on top of them is not. Practically all of userland is based on libc, and therefore by proxy Linux itself has a binary compatibility problem. People who primarily use Linux often forget that Windows has the exact same problem. In the case of Windows libc is distributed as part of the Visual C++ runtime. Each version of Visual Studio has…

Is libc updates really the primary problem with the ABI breaks on Linux? Glibc isn't perfect but it has versioned symbols going back a long time now. My guess would be the problem is actually abandoned versions of other libraries (e.g. SDL1, old versions of gtk2?) and maybe a handful of other things.

The problem is backwards compatibility.

Someone comes along and builds their software on the latest bleeding-edge Linux distro. It won't run on older (or even many current) Linux desktops. People curse Linux ABI instability because new binaries aren't supported by an older operating system. It is in fact the opposite to the Windows situation, in which older software continues to run on newer operating systems, but good luck getting the latest Windows software to run on a Windows 95 desktop. People are very quick to conflate the two situations so they can score more fake internet points.

The situation is not limited to desktops. For example, a very popular commercial source forge web service does not work on browsers released more than about 10 weeks ago. The web itself has become fantastically unstable and almost unusable for anything except AI bots consuming what other AI bots spew.

Re: Convert Linux to Windows

#293

Post by madduci »

csdvrx wrote: post #135
pbohun wrote: post #122

Earlier quoted context omitted.

This is great! Someone else mentioned binfmt_misc. I didn't know about that.

The next step is to isolate the Windows applications: you could use different WINEPREFIX, but I think the better way is to do it like android: one "user" per application. It's not just to prevent applications to read other applications files, but also to firewall each application individually For example, if you don't want the application you've mapped to user id 1001 to have any networking, use iptables with '-m own…

Lutris creates dedicated wine prefixes for the applications/games, so you can use it directly. A lot of apps are also installable with some patches provided by Lutris itself

Re: Convert Linux to Windows

#294

Post by worthless-trash »

DeathArrow wrote: post #234
worthless-trash wrote: post #142

The shitty thing is, this just encourages closed source software on the open platform, giving vendors another reason not to port natively. Good luck with the hellscape you're building.

I do not care about access to source code or not. I use apps, I do not want to look at their source code or compile them. So open/close, I do not care as long as it does what I need, how I need. And I feel I am not the only one thinking like this.

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.

Re: Convert Linux to Windows

#297

Post by hnlmorg »

boricj wrote: post #286
hnlmorg wrote: post #271

This problem is related to the fact that Linux distos typically dynamically link executables and don’t retain older versions of those libraries vs Windows which does. It’s on of the many reasons Windows base install is so much heavier than a typical Linux base install. The reason Windows retains older versions of executables while Linux doesn’t is because Windows doesn’t have a package manager like Linux distros. Ok,…

It's not just about dynamically linked executables. The userland of Linux simply isn't as stable time-wise as Windows, especially when the timescale is measured in decades. As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. To run this on a modern Linux system, you need to: - Bump vm.mmap_min_addr from 65536 dow…

> It's not just about dynamically linked executables. The userland of Linux simply isn't as stable time-wise as Windows, especially when the timescale is measured in decades.

That’s exactly what dynamically linked executables are: user land

> As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable.

That’s not a user land problem. That’s a CPU architecture problem. Windows solves this WOW64 which provides a compatibility layer for 32bit pointers et al.

There are 32bit compatibility layers for Linux too but they’re. It going to be going to help if you’re running an a.out file because it’s a completely different type of executable format (ie not equivalent to a 32bit statically compiled ELF).

Windows has a similar problem with COM files (the early DOS executable format). And lots of COM executables on Windows don’t work either. Windows solves this problem with emulation, which you can do on Linux too. The awkward part of Linux here is that it doesn’t ship those VMs as part of its base install, but why would it because almost no one is trying to run randomly downloaded 32bit a.out files.

To be clear, I’m not arguing that Linuxes backwards compatibility story is as good as Windows. It clearly isn’t. But the answer to that isn’t because Linux can’t be backwards compatible, it’s because Linux traditionally hasn’t needed to be. However all of the same tools Windows uses for it’s compatibility story are available to Linux for Linux executables too.

Re: Convert Linux to Windows

#298

Post by DeathArrow »

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

Earlier quoted context omitted.

I do not care about access to source code or not. I use apps, I do not want to look at their source code or compile them. So open/close, I do not care as long as it does what I need, how I need. And I feel I am not the only one thinking like this.

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.

Re: Convert Linux to Windows

#299

Post by thatjazz »

> I can pull down a 20 year old exe and still run it today on Windows.

Why, oh why, I have to deal with exe files that are not even 5 years old and don't work on my windows laptop after update... I wish I lived in Author's universe...

Re: Convert Linux to Windows

#300

Post by 3036e4 »

xxs wrote: post #240
wyldfire wrote: post #97

Earlier quoted context omitted.

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

>Aren't .class and .jar files "binaries"? Not at all. jar is just a zip with a different extension +some metadata in META-INF (including dependencies). class are compiled java files but they do contain all kinds of metadata, including variable names and debug info (if you choose to retain it). they contain all methods and fields with their original names (along with annotations), so the reflection APIs work. Decompil…

Java can be optimized beyond all recognition, into bytecode that can no longer be represented by the Java language. At least that used to be the case in the past. It is not different from other binaries, except the target system is a virtual CPU rather than a real one.

Java also deprecated all sorts of things over the years. Not to mention applets being completely killed off. I have Java binaries from 25 years ago that could no longer run at all with a contemporary run-time already 10-15 years ago.

Not to mention much of real-world Java is platform-specific. Not often native code perhaps, but more subtle things like hardcoded paths or forgetting to properly use the correct path-separator. Installers used to often be platform-specific as well. Maybe that has been solved, but you would still run into trouble trying to install an old Java application that has an installer only supporting contemporary Windows and Mac systems.

Post reply on HN