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

321–330 of 493 posts

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

#321

Post by kccqzy »

Rohansi wrote: post #232
kccqzy wrote: post #228

Earlier quoted context omitted.

Your tone makes it sound like this is a bad thing. But from a user’s perspective, I do want a distro to package as much software as possible. And it has nothing to do with user freedom. It’s all about being entitled as a user to have the world’s software conveniently packaged.

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 user or by the developer. I'm personally very appreciative of this fact.

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

#322

Post by sedatk »

mrpippy wrote: post #310
sedatk wrote: post #278

Earlier quoted context omitted.

> NT kernel ABI isn’t even all that stable itself Can you give an example where a breaking change was introduced in NT kernel ABI?

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.

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

#323

Post by sedatk »

andrewf wrote: post #308
sedatk wrote: post #278

Earlier quoted context omitted.

> NT kernel ABI isn’t even all that stable itself Can you give an example where a breaking change was introduced in NT kernel ABI?

https://j00ru.vexillium.org/syscalls/nt/64/ (One example: hit "Show" on the table header for Win11, then use the form at the top of the page to highlight syscall 8c)

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

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

#324

Post by MangoToupe »

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.

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

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

#325

Post by c-hendricks »

josephg wrote: post #219
danabramov wrote: post #96

Earlier quoted context omitted.

I started with VB6 so I'm sometimes nostalgic for it too but let's not kid ourselves. We might take it for granted but React-like declarative top-down component model (as opposed to imperative UI) was a huge step forward. In particular that there's no difference between initial render or a re-render, and that updating state is enough for everything to propagate down. That's why it went beyond web, and why all modern…

> and why all modern native UI frameworks have a similar model these days. Personally I much rather the approach taken by solidjs / svelte. React’s approach is very inefficient - the entire view tree is rerendered when any change happens. Then they need to diff the new UI state with the old state and do reconciliation. This works well enough for tiny examples, but it’s clunky at scale. And the code to do diffing and…

Sure but the parents point was more about declarative UIs than React. SolidJS and Svelte are declarative.

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

#326

Post by sedatk »

MangoToupe wrote: post #324
sedatk wrote: post #322

Earlier quoted context omitted.

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

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

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

#327

Post by 0xbadcafebee »

I like the idea of it, but Linux hardware support is still crap, and will get worse as ARM becomes more entrenched.

What boggles my mind is why Google hasn't gotten more serious about making Android a desktop OS. Pay the money needed to get good hardware support, control the OS, and now you're a Microsoft/Apple competitor for devices. Yes there is the Chromebook, but ChromeOS is not a real desktop OS, it's a toy. Google could control both the browser market and the desktop computing market if they seriously tried. (But then again that would require listening to customers and providing support, so nevermind)

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

#329

Post by danabramov »

josephg wrote: post #219
danabramov wrote: post #96

Earlier quoted context omitted.

I started with VB6 so I'm sometimes nostalgic for it too but let's not kid ourselves. We might take it for granted but React-like declarative top-down component model (as opposed to imperative UI) was a huge step forward. In particular that there's no difference between initial render or a re-render, and that updating state is enough for everything to propagate down. That's why it went beyond web, and why all modern…

> and why all modern native UI frameworks have a similar model these days. Personally I much rather the approach taken by solidjs / svelte. React’s approach is very inefficient - the entire view tree is rerendered when any change happens. Then they need to diff the new UI state with the old state and do reconciliation. This works well enough for tiny examples, but it’s clunky at scale. And the code to do diffing and…

>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 changed path.

>And the code to do diffing and reconciliation is insanely complicated.

It's really not, the "diffing" is relatively simple and is maybe ~2kloc of repetitive functions (one per component kind) in the React source code. Most of complexity of React is elsewhere.

>The solidjs / react model uses the compiler to figure out how variables changing results in changes to the rendered view tree.

I actually count those as "React-like" because it's still declarative componentized top-down model unlike say VB6.

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

#330

Post by singpolyma3 »

0xbadcafebee wrote: post #327

I like the idea of it, but Linux hardware support is still crap, and will get worse as ARM becomes more entrenched. What boggles my mind is why Google hasn't gotten more serious about making Android a desktop OS. Pay the money needed to get good hardware support, control the OS, and now you're a Microsoft/Apple competitor for devices. Yes there is the Chromebook, but ChromeOS is not a real desktop OS, it's a toy. Goo…

> Linux hardware support is still crap

What are you talking about? The majority of hardware is supported by only Linux at this point.

Post reply on HN