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

431–440 of 493 posts

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

#431

Post by chocochunks »

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?

Red Alert 2. Then there's games like Dark Forces II that work but don't work with hardware rendering out of the box so they look like crap. I've also had games like Grid complain I didn't have enough VRAM (because I had more than 2GB), games that were tricky to get working because I used a 4K monitor (Sims 2, Crysis 2). And there's games where the original release is borked but a newer version on GoG is okay like Alpha Centauri.

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

#432

Post by bigyabai »

0xbadcafebee wrote: post #357
guerrilla wrote: post #340

Earlier quoted context omitted.

> but Linux hardware support is still crap What are you talking about? Everything for desktops work out of the box unless you have something weird and proprietary, and even then most distros have support anyway.

By desktop I include laptops (many don't work out of the box) but larger systems can be weird too. Just the choice of CPU can decide whether hibernate or suspend works at all. There's a large ecosystem of accessories which have no Linux support. Video cards have been a nightmare on Linux for decades, famously the reason Torvalds gave Nvidia the finger. Even when something's technically supported, it may require obscu…

> Video cards have been a nightmare on Linux for decades,

Again, I question your experience in this regard. Do you actually use dGPUs on Linux, or are you repeating a 14-year-old meme?

GPU support on Linux is more comprehensive than macOS, and if you don't need DirectX it's arguably better than Windows too. Mesa drivers are unparalleled by Apple or Microsoft, in a myriad of ways.

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

#433

Post by tsujamin »

Const-me wrote: post #288
afishhh wrote: post #223

Earlier quoted context omitted.

> Hundreds of other widely-used open source libraries don't. Correct me if I'm wrong but I don't think versioned symbols are a thing on Windows (i.e. they are non-portable). This is not a problem for glibc but it is very much a problem for a lot of open source libraries (which instead tend to just provide a stable C ABI if they care).

> versioned symbols are a thing on Windows There’re quite a few mechanics they use for that. The oldest one, call a special API function on startup like InitCommonControlsEx, and another API functions will DLL resolve differently or behave differently. A similar tactic, require an SDK defined magic number as a parameter to some initialization functions, different magic numbers switching symbols from the same library;…

There’s also API Sets: where DLLs like api-win-blah-1.dll acts as a proxy for another DLL both literally, with forwarder exports, and figuratively, with a system-wide in-memory hashmap between api set and actual DLL.

Iirc this is both for versioning, but also so some software can target windows and Xbox OS’s whilst “importing” the same api-set DLL? Caused me a lot of grief writing a PE dynamic linker once.

https://bookkity.com/article/api-sets

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

#434

Post by cryptonector »

kccqzy wrote: post #85
kwanbix wrote: post #67

Earlier quoted context omitted.

I agree 100% with Linus. I can run a WinXP exe on Win10 or 11 almost every time, but on Linux I often have to chase down versions that still work with the latest Mint or Ubuntu distros. Stuff that worked before just breaks, especially if the app isn’t in the repo.

That’s actually an intentional nudge to make the software packaged by the distro, which usually implies that they are open source. Who needs ABI compatibility when your software is OSS? You only need API compatibility at that point.

The reason you're getting downvoted is that what you're saying implies a shit-ton of work for the distros -- that's expensive work that someone has to pay for (but nobody wants to, and think of the cost of opportunity).

But you're not entirely wrong -- as long as you have API compatibility then it's just a rebuild, right? Well, no, because something always breaks and requires attention. The fact is that in the world of open source the devs/maintainers can't be as disciplined about API compat as you want them to be, and sometimes they have to break backwards compatibility for reasons (security, or just too much tech debt and maint load for obsolete APIs). Because every upstream evolves at a different rate, keeping a distro updated is just hard.

I'm not saying that statically linking things and continuing to run the binaries for decades is a good answer though. I'm merely explaining why I think your comment got downvoted.

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

#435

Post by cryptonector »

jimbobthrowawy wrote: post #44
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.

Wine works on windows too. It's used by the shorthorn project to get software for newer versions of windows to run under XP.

Whoa. Can it be used to run older software on newer Windows too?

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

#436

Post by kccqzy »

josephg wrote: post #192
bruce511 wrote: post #165

Earlier quoted context omitted.

It also makes support more or less impossible. Even if we ship as source, even if the user has the skills to build it, even if the make file supports every version of the kernel, plus all other material variety, plus who knows how many dependencies, what exactly am I supposed to do when a user reports; "I followed your instructions and it doesn't run". Linux Desktop fails because it's not 1 thing, it's 100 things. An…

Yep. But docker doesn’t help you with desktop apps. And everything becomes so big! I think Rob pike has the right idea with go just statically link everything wherever possible. These days I try to do the same, because so much less can go wrong for users. People don’t seem to mind downloading a 30mb executable, so long as it actually works.

What do you mean docker doesn’t help you with desktop apps? I run complicated desktop apps like Firefox inside containers all the time. There are also apps like Citrix Workspace that need so specific dependency versions that I’ve given up on running outside containers.

If you don’t want to configure this manually, use distrobox, which is a nice shell script wrapper that helps you set things up so graphical desktop apps just work.

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

#437

Post by mikestorrent »

SvenL wrote: post #120
kwanbix wrote: post #67

Earlier quoted context omitted.

I agree 100% with Linus. I can run a WinXP exe on Win10 or 11 almost every time, but on Linux I often have to chase down versions that still work with the latest Mint or Ubuntu distros. Stuff that worked before just breaks, especially if the app isn’t in the repo.

Yes and even the package format thing is a hell of its own. Even on Ubuntu you have multiple package formats and sometimes there are even multiple app stores (a Gnome one and an Ubuntu specific if I remember correctly)

Ultimately this boils down to lack of clear technical and community leadership from Canonical. Too unwilling to say "no" to vanity/pet projects that end up costing all of us as they make the resulting distribution into a moving target too difficult to support in the enterprise - at least, not with the skillset of the average desktop support hire these days.

I want to go to the alternate timeline where they just stuck with a set of technologies... ideally KDE... and just matured them up until they were the idealized version of their original plan instead of always throwing things away to rewrite them for ideological or technical purity of design.

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

#438

Post by sedatk »

immibis wrote: post #376
sedatk wrote: post #322

Earlier quoted context omitted.

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.

NTDLL is NT’s kernel ABI, not syscalls. Nothing on Windows uses syscalls to call the kernel.

NTDLL isn’t some higher level library. It’s just a series of entry points into NT kernel.

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

#439

Post by dcrazy »

sedatk wrote: post #438
immibis wrote: post #376

Earlier quoted context omitted.

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

NTDLL is NT’s kernel ABI, not syscalls. Nothing on Windows uses syscalls to call the kernel. NTDLL isn’t some higher level library. It’s just a series of entry points into NT kernel.

Yes, the fact that functions in NTDLL issue a syscall instruction is a platform-specific implementation detail.

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

#440

Post by uecker »

201984 wrote: post #341
uecker wrote: post #251

Earlier quoted context omitted.

There is no ABI problem. The problem is a lack of standardization for important APIs and infrastructure. There once was a serious effort to solve this: the Linux Standard Base: https://en.wikipedia.org/wiki/Linux_Standard_Base Standardization would of course be the only way to fix this, instead of inventing even more packaging formats which fragment the ecosystem even more. LSB died due to lack of interest. I assume…

Archive link for your CADT reference: https://archive.ph/t5m32 I wish websites weren't allowed to know what site a user is coming from.

Hm right, sorry. Somehow this does not happen to me (maybe because of ublock)
Post reply on HN