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

Loss32: Let's Build a Win32/Linux

loss32.org

Post reply on HN
Print view View original

461–470 of 493 posts

Re: Loss32: Let's Build a Win32/Linux

#461

Post by lproven »

Y_Y wrote: post #168
senfiaj wrote: post #126

Earlier quoted context omitted.

Maybe it's better now in some distros. Not sure about other distros, but I don't like Ubuntu's Snap package. Snap packages typically start slower, use more RAM, require sudo privileges to install, and run in an isolated environment only on systems with AppArmour. Snap also tends to slow things some at boot and shutdown. People report issues like theming mismatches, permissions/file-access friction. Firefox theming co…

Ubuntu was getting too good so it had to snap half of its value out of existence. You can still get firefox as a .deb though. https://launchpad.net/~mozillateam/+archive/ubuntu/ppa

Mozilla has been publishing official Firefox .DEB packages for over 2 years now.

https://www.theregister.com/2023/11/01/official_mozilla_debi...

No need for any Canonical packages at all -- works fine on Debian; I use them myself.

Re: Loss32: Let's Build a Win32/Linux

#462

Post by MangoToupe »

sedatk wrote: post #326
MangoToupe wrote: post #324

Earlier quoted context omitted.

...isn't that the point of this entire subthread? The kernel itself doesn't provide the stable ABI, userland code that the binary links to does.

No. On NT, kernel ABI isn't defined by the syscalls but NTDLL. Win32 and all other APIs are wrappers on top of NTDLL, not syscalls. Syscalls are how NTDLL implements kernel calls behind the scenes, it's an implementation detail. Original point of the thread was about Win32, UWP and other APIs that build a new layer on top of NTDLL. I argue that NT doesn't break its kernel ABI.

> No

...and you go on to not disagree with me at all? Why comment then?

Re: Loss32: Let's Build a Win32/Linux

#463

Post by HeckFeck »

sedatk wrote: post #280
HeckFeck wrote: post #271

Earlier quoted context omitted.

Server 2003 was the last release supervised by Cutler, so would have my vote. It's even source-available... technically.

Cutler himself wrote code for Vista/Longhorn though. I don't know what you mean by "supervising" it. He also led the efforts for "PatchGuard" kernel protection mechanism that was introduced with Vista. Source: I reviewed Cutler's lock-free data structure changes in Vista/Longhorn to find bugs in them, failed to find any.

AH, I was repeating something I read elsewhere, but I'll defer to an eyewitness. Must've been pretty cool working on Windows back then. Maybe it was more varied than my line of work. I must escape the drudgery B2B SaaS Webcrapps.

Re: Loss32: Let's Build a Win32/Linux

#464

Post by ada0000 »

frumplestlatz wrote: post #9

Technically it's the only stable macOS ABI, too. The only way to run a legacy 32-bit binary on macOS today is a win32 exe running under Wine.

windows 11 for ARM, as bad of an OS it is in many aspects, is an incredible experience for backwards compatibility. I can run a 32 bit game built for windows xp in parallels and not have to think much.

Re: Loss32: Let's Build a Win32/Linux

#465

Post by microtonal »

forrestthewoods wrote: post #337
ben-schaaf wrote: post #224

Earlier quoted context omitted.

Only because people aren't putting in the effort to build their binaries properly. You need to link against the oldest glibc version that has all the symbols you need, and then your binary will actually work everywhere(*). * Except for non-glibc distributions of course.

> Only because people aren't putting in the effort to build their binaries properly. Because Linux userland is an unmitigated clusterfuck of bad design that makes this really really really hard. GCC/Clang and Glibc make it effectively impossible almost impossible to do this on their own. The only way you can actually do this is: 1. create a userland container from the past 2. use Zig which moved oceans and mountains…

We are using Nix to do this. It’s only a few lines of code. We build a gcc 14 stdenv that uses an old glibc.

But I agree that this should just be a simple target SDK flag.

I think the issue is that the Linux community is generally hostile towards proprietary software and it’s less of an issue for FLOSS because they can always be compiled against the latest.

Re: Loss32: Let's Build a Win32/Linux

#466

Post by johncolanduoni »

uecker wrote: post #460
johncolanduoni wrote: post #452

Earlier quoted context omitted.

Making an executable “request” older symbol versions is incredibly painful in practice. Basically every substantial piece of binary software either compiles against an ancient Debian sysroot (that has to have workarounds for the ancient part) or somehow uses a separate glibc copy from the base system (Flatpak, etc.). The first greatly complicates building the software, the second is recreating Windows’ infamous DLL h…

Is it painful? Why? You need a build environment that has the old libraries. It does not have to be ancient, just exactly what you need.

It has to be as ancient as the oldest glibc you want to support, usually a Red Hat release with very old version and manual security backports. These can have nearly decade-old glibc versions, especially if you care about extended support contracts.

You generally have difficulty actually running contemporary build tools on such a thing, so the workaround is to use —-sysroot against what is basically a chroot of the old distro, as if cross-compiling. But there are still workarounds needed if the version is old enough. Chrome has a shorter support window than some Linux binaries, but you can see the gymnastics they do to create their sysroot in some Python scripts in the chromium repo.

On Windows, you install the latest SDK and pass a target version flag when setting up the compiler environment. That’s it. macOS is similar.

Re: Loss32: Let's Build a Win32/Linux

#467

Post by guerrilla »

0xbadcafebee wrote: post #443
guerrilla wrote: post #441

Earlier quoted context omitted.

> Video cards have been a nightmare on Linux for decades, famously the reason Torvalds gave Nvidia the finger. What are you talking about... The situation is the same as on Windows, an officially supported and maintained proprietary driver maintained by Nvidia. Unless you're trying to run a 12+ year old car, it'll work fine. AMD on the other hand is amazingland and works perfectly, officially supported and maintained…

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

Hardly. Besides so much packaging (which isn't relevant), my qualifications are the same as yours. Don't be rude.

Re: Loss32: Let's Build a Win32/Linux

#468

Post by Maskawanian »

bsimpson wrote: post #316
ori_b wrote: post #79

Earlier quoted context omitted.

To quote a friend; "Glibc is a waste of a perfectly good stable kernel ABI"

I only learned about glibc earlier today, when I was trying to figure out why the Nix version of a game crashes on SteamOS unless you unset some environ vars. Turns out that Nix is built against a different version of glibc than SteamOS, and for some reason, that matters. You have to make sure none of Steam's libraries are on the path before the Nix code will run. It seems impractical to expect every piece of softwar…

No, that's every bit of software out there. Dynamic linking really does cause that problem even though allegedly it has security benefits as the vendor is able to patch software vulnerabilities.

NixOS actually is a bit better in this respect since most things are statically linked. The only thing is that glibc is not because it specifically requires being dynamically linked.

This issue also applies to macOS with their Dylibs and also Windows with their DLLs. So saying that this is an issue with Linux is a bit disingenuous.

Until everybody standardizes on one singular executable format that doesn't ever change, this will forever be an issue.

Re: Loss32: Let's Build a Win32/Linux

#469

Post by ok123456 »

mikkupikku wrote: post #263
ok123456 wrote: post #230

Earlier quoted context omitted.

If it requires effort to be correct, that's a bad design. Why doesn't the glibc use the version tag to do the appropriate mapping?

I think even calling it a "design" is dubious. It's an attribute of these systems that arose out of the circumstance, nobody ever sat down and said it should be this way. Even Torvalds complaining about it doesn't mean it gets fixed, it's not analogous to Steve Jobs complaining about a thing because Torvalds is only in charge of one piece of the puzzle, and the whole image that emerges from all these different groups…

> In other words, the Linux desktop as a whole is a Bazaar, not Cathedral.

This was true in the 90s, not the 2020s.

There are enough moneyed interests that control the entirety of Linux now. If someone at Canonical or Red Hat thought a glibc version translation layer (think WINE, but for running software targeted for Linux systems made more than the last breaking glibc version) was a good enough idea, it could get implemented pretty rapidly. Instead of win32+wine being the only stable abi on Linux, Linux could have the most stable abi on Linux.

Re: Loss32: Let's Build a Win32/Linux

#470

Post by m01 »

keyringlight wrote: post #393
m01 wrote: post #258

Earlier quoted context omitted.

Have you tried kid3 ( https://kid3.kde.org )? It has both a GUI and a CLI. From a quick glance at the feature lists it looks quite comparable.

I just did, have you actually tried using them side-by-side? It's hard for me to look favorably on kid3. I actually gave myself 5-10m to try and learn kid3 and a lot of what seems like obvious ways to accomplish a task like 'rename these files using their tags' didn't do anything. I even broke out the manual which didn't help/explain if there was a different mindset I need to adopt. I could manage to manually edit ta…

I get that you wanted to make a general point. In case you're still curious about this specific case:

It's been a long time since I last used Mp3tag, so I tried the latest Mp3tag in WINE (seems to work nicely) for comparison. I think the basic operations (editing tags) actually do work similarly: in both you select file(s), edit the tag you want to in the GUI and changes get applied to any selected file(s) when you press save.

Renaming filenames based on tags also works according to that principle in kid3, you select the files you want to change (rename) and then use the `Format (arrow pointing from tag fields to filename field)` to specify what the filename pattern should look like and then use the `Tag 1` or `Tag 2` button to fill the placeholders from the (e.g.) ID3v1/ID3v2 tag, and click save to apply the changes.

In Mp3tag you'd also highlight the files, but unlike other tag editing operations you use the `convert->tag to filename` menu item/button, which pops up a wizard asking for the pattern and confirmation.

I'm guessing coming from Mp3tag you tried to use kid3's `Tools->Apply filename format` option, which I believe ensures the filename doesn't include special characters by doing string replacements (these are configured in the settings under `Files->Filname format`). I was wondering if that was perhaps confusingly named, so I had a look in Mp3tag to see what this functionality was called there, but I couldn't find it. I'm sure it's possible somehow, but it probably involves scripting [1].

I noticed that Mp3tag seems to be able to automatically fetch album art whereas in kid3 you need to get the image yourself. I suspect more advanced functionality (scripting etc) will work differently in the two tools.

[1] https://community.mp3tag.de/t/character-replacement-for-tag-...

Post reply on HN