This is a really cool idea. My only gripe is that Win32 is necessarily built on x86. AArch64/ARM is up and coming, and other architectures may arise in the future. Perhaps that could be mitigated if someone could come up with an awesome OSS machine code translation layer like Apple's Rosetta.
Not sure on Windows but with Wine you can totally use Win32 on arm.
Loss32: Let's Build a Win32/Linux
211–220 of 493 posts
Re: Loss32: Let's Build a Win32/Linux
#212Earlier 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.
Everything after Win 2000 was a bad idea. Enterprise or not.
Re: Loss32: Let's Build a Win32/Linux
#213Someone 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.
It stuns me that a polished 1:1 2K/XP/7 clone DE (which it mimics is a setting) hasn’t existed for a 10y+ already. It’s such an obvious target for a mass appeal Linux desktop that many techies and non-techies alike would happily use. Rough approximations have been possible since the early 2000s, but they’re exactly that: rough approximations. Details matter, and when I boot up an old XP/7 box there are aspects in whi…
I think one of the friction could be ideological if not than anything since most linux'ers love Open source and hate windows so they might not want to build anything which even replicates the UI perhaps
Listen I hate windows just as much as the other guy but gotta give props that I feel nostalgic to windows 7, and if they provide both .exe perfect support and linux binary perfect support, things can be really good. I hope somebody does it and perhaps even adds it to loss32, would be an interesting update.
Re: Loss32: Let's Build a Win32/Linux
#214Building GUI utilities based on VB6 instead of status quo web technologies might actually be more stable and productive.
Re: Loss32: Let's Build a Win32/Linux
#215Earlier quoted context omitted.
It kinda works both ways, just yesterday I tried to play the Linux native version of 8bit.runner and it didn't work, I had to install the Windows (beta) version and run it through proton.
Funny story: I use Anki (the flashcard program), and I run it on my NixOS laptop. There is a NixOS/nixpkgs package for Anki. It doesn't work. You know how I run Anki, which has a native GNU/Linux version and even an actual nixpkgs package, on my GNU/Linux NixOS laptop? Yeah, I run AnkiDroid, the Android version, through Waydroid. Because the Android version works.
Re: Loss32: Let's Build a Win32/Linux
#216Earlier quoted context omitted.
There really isn't that much GNU on a modern Linux system, proportionately.
Exactly, Gnome/Linux or KDE/Linux would make a lot more sense.
Re: Loss32: Let's Build a Win32/Linux
#217Earlier quoted context omitted.
I can only speak for Flatpak, but I found its packaging workflow and restricted runtime terrible to work with. Lots of undocumented/hard to find behaviour and very painful to integrate with existing package managers (e.g. vcpkg).
Yeah, flatpak has some good ideas, and they're even mostly well executed, but once you start trying to build your own flatpaks or look under the hood there's a lot of "magic". (Examples: Where do runtimes come from? I couldn't find any docs other than a note that says to not worry about it because you should never ever try to make your own, and I couldn't even figure out the git repos that appear to create the offici…
The flatpak ecosystem is problematic in that most packages are granted too much rights by default.
Re: Loss32: Let's Build a Win32/Linux
#218This 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
To quote a friend; "Glibc is a waste of a perfectly good stable kernel ABI"
Honestly I might buy a T-shirt with such a quote.
I think glibc is such a pain that it is the reason why we have so vastly different package management and I feel like non glibc things really would simplify the package management approach to linux which although feels solved, there are definitely still issues with the approach and I think we should still all definitely as such look for ways to solve the problem
Re: Loss32: Let's Build a Win32/Linux
#219Building GUI utilities based on VB6 instead of status quo web technologies might actually be more stable and productive.
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…
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 reconciliation is insanely complicated. Hello world in react is like 200kb of javascript or something like that. (Smaller gzipped, but the browser still needs to parse it all at startup). And all of that diffing is also pure overhead. It’s simply not needed.
The solidjs / react model uses the compiler to figure out how variables changing results in changes to the rendered view tree. Those variables are wrapped up as “observed state”. As a result, you can just update those variables and exactly and only the parts of the UI that need to be changed will be redrawn. No overrendering. No diffing. No virtual Dom and no reconciliation. Hello world in solid or svelte is minuscule - 2kb or something.
Unfortunately, swiftui has copied react. And not the superior approach of newer libraries.
The rust “Leptos” library implements this same fine grained reactivity, but it’s still married to the web. I’m really hoping someone takes the same idea and ports it to desktop / native UI.
Re: Loss32: Let's Build a Win32/Linux
#220This is only ever relevant for proprietary software. Free software does not require a stable ABI. Great that wine exists but it should be useless. (That and Linux doesn't implement win32 and wine doesn't exclusively run on Linux.)
Free software can still benefit from a stable ABI. If I want to run the software, it's better to download it in a format my CPU can understand, rather than download source, figure out the dependencies, wait for compiling (let's say it's a large project like Firefox or Chromium that takes hours to compile), and so on.
If its a choice between downloading a binary that depends on a stable ABI and compiling the source. They way most Linux software gets installed is downloading a binary that has been compiled for your OS version (from repos), and the next most common way of installing is compiling source through a system that figures out the dependencies for you (source based distros and repos).