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

371–380 of 493 posts

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

#371

Post by jhasse »

duped wrote: post #167
amelius wrote: post #97

Earlier quoted context omitted.

Can't we just freeze glibc, at least from an API version perspective?

The problem is not the APIs, it's symbol versions. You will routinely get loader errors when running software compiled against a newer glibc than what a system provides, even if the caller does not use any "new" APIs. glibc-based toolchains are ultimately missing a GLIBC_MIN_DEPLOYMENT_TARGET definition that gets passed to the linker so it knows which minimum version of glibc your software supports, similar to how Ap…

That's exactly what apgcc from Autopackage provided (20 years ago). https://github.com/DeaDBeeF-Player/apbuild

But compiling in a container is easier and also solves other problems.

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

#372

Post by sedatk »

LeFantome wrote: post #359
sedatk wrote: post #323

Earlier quoted context omitted.

Changes in syscall numbers aren't necessarily breaking changes as you're supposed to use ntdll.dll to call kernel, not direct syscalls.

That was his point exactly.

Nope. https://news.ycombinator.com/item?id=46440942

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

#374

Post by danabramov »

josephg wrote: post #367
danabramov wrote: post #329

Earlier quoted context omitted.

>React’s approach is very inefficient - the entire view tree is rerendered when any change happens. That's not true. React only re-renders down from where the update happens. And it skips over stuff that is provably unchanged -- which, fair, involves manual memoization hints. Although with React Compiler it's actually pretty good at automatically adding those so in practice it mostly re-renders along the actually cha…

> That's not true. React only re-renders down from where the update happens. And it skips over stuff that is provably unchanged -- which, fair, involves manual memoization hints. React only skips over stuff that's provably unchanged. But in many - most? web apps, it rerenders a lot . Yeah, you can add memoization hints. But how many people actually do that? I've worked on several react projects, and I don't think I'v…

>React only skips over stuff that's provably unchanged. But in many - most? web apps, it rerenders a lot. Yeah, you can add memoization hints. But how many people actually do that?

Even without any hints, it doesn't re-render "the entire view tree" like your parent comment claims, but only stuff below the place that's updated. E.g. if you're updating a text box, only stuff under the component owning that text box's state is considered for reconciliation.

Re: manual memoization hints, I'm not sure what you mean — `useMemo` and `useCallback` are used all over the place in React projects, often unnecessarily. It's definitely something that people do a lot. But also, React Compiler does this automatically, so assuming it gets wider adoption, in the longer run manual hints aren't necessary anyway.

>Where is the rest of the complexity of react?

It's kind of spread around, I wouldn't say it's one specific piece. There's some complexity in hydration (for reviving HTML), declarative loading states (Suspense), interruptible updates (Transitions), error recovery (Error Boundaries), soon animations (View Transitions), and having all these features work with each other cohesively.

I used to work on React, so I'm familiar with what those other libraries do. I understand the things you enjoy about Solid. My bigger point is just that it's still a very different programming model as VB6 and such.

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

#375

Post by Rohansi »

kccqzy wrote: post #321
Rohansi wrote: post #232

Earlier quoted context omitted.

Software installed from your package manager is almost certainly provided as a binary already. You could package a .exe file and that should work everywhere WINE is installed.

That's not my point. My point is that if executable A depends on library B, and library B does not provide any stable ABI, then the package manager will take care of updating A whenever updating B. Windows has fanatical commitment to ABI stability, so the situation above does not even occur. As a user, all the hard work dealing with ABI breakages on Linux are done by the people managing the software repos, not by the…

Sure, it's better than nothing, but it's certainly not ideal. How much time and energy is being wasted by libraries like that? Wouldn't it be better if library B had a stable ABI or was versioned? Is there any reason it needs to work like this?

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

#376

Post by immibis »

sedatk wrote: post #322
mrpippy wrote: post #310

Earlier quoted context omitted.

The syscall numbers change with every release: https://j00ru.vexillium.org/syscalls/nt/64/

Syscall numbers shouldn't be a problem if you link against ntdll.dll.

So now you're talking about the ntdll.dll ABI instead of the kernel ABI. ntdll.dll is not the kernel.

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

#377

Post by forgotusername6 »

andsoitis wrote: post #56
mikkupikku wrote: post #33

Crazy how, thanks to Wine/Proton, Linux is now more compatible with old Windows games than Windows itself. There are a lot of games from the 90s and even the 00s that require jumping through a lot of hoops to run on Windows, but through Steam they're click-to-play on Linux.

> There are a lot of games from the 90s and even the 00s that require jumping through a lot of hoops to run on Windows What are some examples?

Anything written with SafeDisk DRM e.g. medal of honor allied assault.

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

#378

Post by follower »

Y_Y wrote: post #179
duped wrote: post #167

Earlier quoted context omitted.

The problem is not the APIs, it's symbol versions. You will routinely get loader errors when running software compiled against a newer glibc than what a system provides, even if the caller does not use any "new" APIs. glibc-based toolchains are ultimately missing a GLIBC_MIN_DEPLOYMENT_TARGET definition that gets passed to the linker so it knows which minimum version of glibc your software supports, similar to how Ap…

In principle you can patch your binary to accept the old local version, though I don't remember ever getting it to work right. Anyway here it is for the brave or foolhardy, here's the gist: patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 "$APP" patchelf --set-rpath /lib "$APP"

> [...] brave or foolhardy, [...]

Heed the above warning as down this rpath madness surely lies!

Exhibit A: https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...

Exhibit B: https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...

Exhibit C: https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...

Oh, sure, rpath/runpath shenanigans will work in some situations but then you'll be tempted to make such shenanigans work in all situations and then the madness will get you...

To save everyone a click here are the first two bullet points from Exhibit A:

* If an executable has `RPATH` (a.k.a. `DT_RPATH`) set but a shared library that is a (direct or indirect(?)) dependency of that executable has `RUNPATH` (a.k.a. `DT_RUNPATH`) set then the executable's `RPATH` is ignored!

* This means a shared library dependency can "force" loading of an incompatible [(for the executable)] dependency version in certain situations. [...]

Further nuances regarding LD_LIBRARY_PATH can be found in Exhibit B but I can feel the madness clawing at me again so will stop here. :)

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

#379

Post by malmz »

CorrectHorseBat wrote: post #244
senfiaj wrote: post #50

This might offend some people but even Linus Torvalds thinks that the ABI compatibility is not good enough in Linux distros, and this is one of the main reasons Linux is not popular on the desktop. https://www.youtube.com/watch?v=5PmHRSeA2c8&t=283s

Android makes a sport of breaking ABI compatibly and it hasn't stopped it from being the most popular mobile OS

What are you even talking about? Android is by far the most popular mobile OS worldwide. It's only in the US where iPhones are dominant.
Post reply on HN