Live data from Hacker News

Loss32: Let's Build a Win32/Linux

loss32.org

301–310 of 493 posts

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

#301

I'm back to running Windows because of the shifting sands of Python and WxWindows that broke WikidPad, my personal wiki. The .exe from 2012 still works perfectly though, so I migrated back from Ubuntu to be able to use it without hassle. It's my strong opinion that Windows 2000 Server, SP4 was the best desktop OS ever.

Sometimes I have problems like this on Debian. I have a reliable solution: debootstrap and snapshots.debian.org

I haven't yet gone more than a decade in the past before, so I can't promise forever, and GPU-accelerated things probably still break, but X11 is very compatible backwards.

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

#302
post #4

Unironically, yes. It's time that Microsoft taste their own medicine of embrace, extend, and extinguish.

Here me out: Microsoft switches to Linux kernel for Windows 13. (also Microsoft has been heavily embracing Linux and open source in the last decade)

Why would you want to switch to in many cases, an inferior kernel? NTOS is the golden piece of Windows -- it's Win32 that's hot garbage.

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

#303

Earlier quoted context omitted.

Here me out: Microsoft switches to Linux kernel for Windows 13. (also Microsoft has been heavily embracing Linux and open source in the last decade)

When WSL first came out, I realized that Windows might be Linux + Wine in 20 or 30 years. Nowadays, with the Windows team barely able to produce a functional UI, what's happening with the NT kernel? Is it all graybeards back there? When they retire, the stability of Windows going to be in trouble, which is important for the things that really pull in the money. It'll get real bad, then they'll give up and move to an…

The NT kernel continues to evolve. The recent examples I can think of are VBS, HCVI, and Kernel DMA Protection.

No reason to dump a very good kernel.

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

#304
post #80

Earlier quoted context omitted.

It still is if you're an enterprise customer. The retail users aren't Microsoft's cash cows, so they get ads and BS in their editions. The underlying APIs are still stable and MS provides the LTSC & Server editions to businesses which lack all that retail cruft.

I'm an enterprise user and I find Windows 11 a complete disaster. They've managed to make something as trivial as right-clicking a slow operation. I used to be a pretty happy Windows camper (I even got through Me without much complaint), but I'm so glad I moved to Linux and KDE for my private desktops before 11 hit.

If anything, right click is faster thanks to dumping the ability for 3rd parties to pollute it with COM controls that needs to be init'ed.

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

#305
Rather than API/ABI stability, I think the problem is the lack of coherence and too many fragile dependencies. Like, why should a component as essential as Systemd have to depend on a non-essential service called d-bus? Which in turn depends on an XML parser lib named libexpat. Just d-bus and libexpat combined takes a few megabytes. Last time I checked, the entire NT kernel, and probably the Linux kernel image as well, has no more than single-digit MBs in size. And by the way, Systemd itself doesn’t use XML for configurations. It has an INI style configuration format.

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

#306
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

[deleted]

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

#307
post #305

Rather than API/ABI stability, I think the problem is the lack of coherence and too many fragile dependencies. Like, why should a component as essential as Systemd have to depend on a non-essential service called d-bus? Which in turn depends on an XML parser lib named libexpat. Just d-bus and libexpat combined takes a few megabytes. Last time I checked, the entire NT kernel, and probably the Linux kernel image as wel…

that's why they are doing varlink now

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

#308
post #278
post #174

Earlier quoted context omitted.

Kind of funny to realize, the NT kernel ABI isn’t even all that stable itself; it is just wrapped in a set of very stable userland exposures (Win32, UWP, etc.), and it’s those exposures that Windows executables are relying on. A theoretical Windows PE binary that was 100% statically linked (and so directly contained NT syscalls) wouldn’t be at-all portable between different Windows versions. Linux with glibc is the c…

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

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

#309

Earlier quoted context omitted.

So every Linux distribution should compile and distribute packages for every single piece of open source software in existence , both the very newest stuff that was only released last week, and also everything from 30+ years ago, no matter how obscure. Because almost certainly someone out there will want to use it. And they should be able to, because that is the entire point of free software: user freedom.

I am not an expert on this, but my question is, how does windows manages to achieve it? Why can't Linux do the same?

because they care about ABI/API stability.

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

#310
post #278
post #174

Earlier quoted context omitted.

Kind of funny to realize, the NT kernel ABI isn’t even all that stable itself; it is just wrapped in a set of very stable userland exposures (Win32, UWP, etc.), and it’s those exposures that Windows executables are relying on. A theoretical Windows PE binary that was 100% statically linked (and so directly contained NT syscalls) wouldn’t be at-all portable between different Windows versions. Linux with glibc is the c…

> 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/
Post reply on HN