Live data from Hacker News

Loss32: Let's Build a Win32/Linux

loss32.org

201–210 of 493 posts

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

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

You can also run a WinXP exe on any Linux distribution almost every time. That's the point of project and Linus' quip: The only stable ABI around on MS Windows and Linux is Win32 (BTW, I do not agree with this.)

I think it's not unlikely that we reach reach a point in a couple of decades where we are all developing win32 apps that most people are running some form of linux.

We already have an entire platform like that (steam deck), and it's the best linux development experience around in my opinion.

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

#202
post #167
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…

Yes, so that's why freezing the glibc symbol versions would help. If everybody uses the same version, you cannot get conflicts (at least after it has rippled through and everybody is on the same version). The downside is that we can't add anything new to glibc, but I'd say given all the trouble it produces, that's worth accepting. We can still add bugfixes and security fixes to glibc, we just don't change the APIs of the symbols.

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

#203

Earlier quoted context omitted.

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

Pretty much all the Renderware based GTAs have issues these days that only community made patches can mitigate. A recent example is that in San Andreas, the seaplane never spawns if you're running Windows 11 24H2 or newer. All of it due to a bug that's always been in the game, but only the recent changes in Windows caused it to show up. If anybody's interested, you can read the investigation on it here: https://cooki…

I remember seeing a thread about that bug here on HN a while ago, that was a fun read.

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

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

Isn't the kernel responsible for the ABI?

ABI is a far larger concept than the kernel UAPI. Remember that the OS includes a lot of things in userspace as well. Many of these things are not even stable between the various contemporary Linux distros, let alone older versions of them. This might include dbus services, fs layout, window manager integration, and all sorts of other things.

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

#206

Earlier quoted context omitted.

https://zapps.app/ is another interesting thing in the space. AppImage have some issues/restrictions like it cant run on older linux than one it was compiled on, so people compile it on the oldest pc's and a little bit of more quirks AppImage are really good but zapps are good too, I had once tried to do something on top of zapp but shame that zapp went into the route of crypto ipfs or smth and then I don't really se…

This is really cool. Looks like it has a way for me to use my own dynamic linker and glibc version *. At some point I've got to try this. I think it would be nice to have some tools to turn an existing programs into a zapps (there many such tools for making AppImages today). * https://github.com/warptools/ldshim

> At some point I've got to try this. I think it would be nice to have some tools to turn an existing programs into a zapps (there many such tools for making AppImages today).

Looks like you met the right guy because I have built this tool :)

Allow me to show my project, Appseed (https://nanotimestamps.org/appseed): It's a simple fish script which I had (prototyped with Claude) some 8-10 months ago I guess to solve exactly this.

I have a youtube video in the website and the repository is open source on github too.

So this actually worked fantastic for a lot of different binaries that I tested it on and I had uploaded it on hackernews as well but nobody really responded, perhaps this might change it :p

Now what appseed does is that you can think of it is that it can take a binary and convert it into two folders (one is the dynamic library part) and the other is the binary itself

So you can then use something like tar to package it up and run it anywhere. I can of course create it into a single elf-64 as well but I wanted to make it more flexible so that we can have more dynamic library like or perhaps caching or just some other ideas and this made things simple for me too

Ldshim is really good idea too although I think I am unable to understand it for the time being but I will try to understand it I suppose. I would really appreciate it if you can tell me more about Ldshim! Perhaps take a look at Appseed too and I think that there might be some similarities except I tried to just create a fish script which can just convert any dynamic binary usually into a static one of sorts

I just want more people to take ideas like appseed or zapp's and run with it to make linux's ecosystem better man. Because I just prototyped it with LLM's to see if it was possible or not since I don't have much expertise in the area. So I can only imagine what can be possible if people who have expertise do something about it and this was why I shared it originally/created it I guess.

Let me know if you are interested in discussing anything about appseed. My memory's a little rusty about how it worked but I would love to talk about it if I can be of any help :p

Have a nice new year man! :p

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

#207
> The late-90's-to-early-2010's PC desktop experience was great for power users, especially creative users. Let's keep the dream alive.

It sure was, if you were already bored by Windows 3.11/95 and were getting into Linux, it was fantastic. You were getting skills at the ground floor which could help keep you in good career for most of the rest of your life.

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

#208
post #174
post #79

Earlier quoted context omitted.

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

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…

> Kind of funny to realize, the NT kernel ABI isn’t even all that stable itself

This is not a big problem if it's hard/unlikely enough to write a code that accidentally relies on raw syscalls. At least MS's dev tooling doesn't provide an easy way to bypass the standard DLLs.

> makes me wonder how exactly Windows containers work

I guess containers do the syscalls through the standard Windows DLLs like any regular userspace application. If it's a Linux container on Windows, probably the WSL syscalls, which I guess, are stable.

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

#209

Cool. Having major distributions default to using binfmt_misc to register Wine for PE executables (EXE files) would be nice though. Next steps would obviously be for Windows apps to have their own OS-level identity, confined and permissioned per app using normal Linux security mechanisms, run against a reproducible and pinned Wine runtime with clearly managed state, integrated with the desktop as normal applications…

>Cool. Having major distributions default to using binfmt_misc to register Wine for PE executables (EXE files) would be nice though

This is something that is very much needed to make Linux much more user friendly for new users.

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

#210

Someone please create a windows 7 like user interface or even XP like interface too and you got yourself a serious fan I might seriously recommend it to newbies and like there is just this love I have for windows 7 even though I really didn't use it for much but its so much more elegant in its own way than windows 10 like it can be a really fun experiment and I would be interested to see how that would pan out.

XFCE plus a windows theme would get you pretty far. Is there anything specific you're thinking of which that plus some pre-configured Wine wouldn't hit?

I 100% agree with your comment.

Pro tip but if someone wants to create their own iso as well, they can probably just customize things imperatively in MxLinux even by just booting them up in your ram and then they have the magnificient option of basically snapshotting it and converting that into an iso so its definitely possible to create an iso tweaked down to your configuration without any hassle (trust me but its the best way to create iso's without too much hassle and if one wants hassle, nix or bootc seems to be the way to go)

Regarding Why it wouldn't hit. I don't know, I already build some of my own iso's and I can build one for windows (on MxLinux principle) and upload it for free on huggingface perhaps but the idea is of mass appeal

Yes I can do that but I would prefer if there was an iso which could just do that and I could share it with a new person in linux. And yes I could have the new person do the changes themselves but (why?), there really is no reason perhaps imo and this just feels like a low hanging fruit which nobody touched perhaps and so this is why I was curious too.

But also as the other comment pointed out, I feel like sure we can do this thing, but that there is definitely a genuine reason why we can probably create this thing itself as well and they give some good reasons as well and I agree with them overall too.

Like if you ask me, it would be fun to have more options especially considering this is linux where freedom is celebrated :p

Post reply on HN