Live data from Hacker News

Loss32: Let's Build a Win32/Linux

loss32.org

81–90 of 493 posts

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

#81
post #15

It still puzzles me decades later how MS built the most functional, intuitive and optimised desktop environment possible then simply threw it away

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.

The problem with Windows after Windows 7 isn't really ads, it's the blatant stupid use of web view to do the most mundane things and hog hundreds of MB or even GBs for silly features, that are still present in enterprise versions.

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

#82

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.

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.

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

#83
post #42
post #21

Earlier quoted context omitted.

It's already been done, though. Wine has been around for 30 years and has excellent compatibility at this point.

5341 of the 16491 applications listed in the Wine AppDB have a compatibility rating of "garbage". This is not excellent compatibility.

Relative to (64-bit) windows 11, it might be.

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

#84

Earlier quoted context omitted.

I would pick Delphi (with which you can build Windows, Linux, macOS, Android, and iOS apps - https://www.embarcadero.com/products/delphi ) Alternatively, RemObjects makes Elements, also a RAD programming environment in which you can code in Oxygene (their Object Pascal), C#, Swift, Java, Go, or Mercury (VB) and target all platforms: .Net, iOS and macOS, Android, WebAssemblyl, Java, Linux, Windows.

> Alternatively, RemObjects makes Elements, also a RAD programming environment in which you can code in Oxygene (their Object Pascal), C#, Swift, Java, Go, or Mercury (VB) and target all platforms: .Net, iOS and macOS, Android, WebAssemblyl, Java, Linux, Windows. Wait you can make Android applications with Golang without too much sorcery?? I just wanted to convert some Golang CLI applications to GUI's for Android and…

> Wait you can make Android applications with Golang without too much sorcery??

Why don't you try it out: https://www.remobjects.com/elements/gold/

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

#85
post #67
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

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.

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

#86
I build a gaming VM and decided to go with Windows because the latest AMD drivers (upscaling etc..) only works there for now.

I wanted to be nice and entered a genuine Windows key still in my laptop's firmware somewhere.

As a thank you Microsoft pulled dozens of the features out of my OS, including remote desktop.

As soon as these latest FSR drivers are ported over I will swap to Linux. What a racket, lol.

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

#87

Building GUI utilities based on VB6 instead of status quo web technologies might actually be more stable and productive.

I would pick Delphi (with which you can build Windows, Linux, macOS, Android, and iOS apps - https://www.embarcadero.com/products/delphi ) Alternatively, RemObjects makes Elements, also a RAD programming environment in which you can code in Oxygene (their Object Pascal), C#, Swift, Java, Go, or Mercury (VB) and target all platforms: .Net, iOS and macOS, Android, WebAssemblyl, Java, Linux, Windows.

Yes, you can build cross-platform GUI apps with Delphi. However, that requires using Firemonkey (FMX). If you build a GUI app using VCL on Delphi, it's limited to Windows. If you build an app with Lazarus and LCL, you CAN have it work cross-platform.

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

#88
post #6

But would you want to run these Win32 software on Linux for daily use? I don't.

I use some cool ham radio software, a couple SDR applications, and a lithophane generator for my 3d printer. It all works great, if you have a cool utility or piece of software, why wouldn't you want to?

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

#89

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?

The last time I tried to run Tachyon: The Fringe was Windows 10, and it failed. IIRC I could launch it and play, but there was a non-zero chance that a FMV cutscene would cause it to freeze.

I see there are guides on Steam forums on how to get it to run under Windows 11 [0], and they are quite involved for someone not overly familiar with computers outside of gaming.

0: https://steamcommunity.com/sharedfiles/filedetails/?id=29344...

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

#90
Can somebody explain:

1. The exact problem with the Linux ABI

2. What causes it (the issues that makes it such a challenge)

3. How it changed over the years, and its current state

4. Any serious attempts to resolve it

I've been on Linux for may be 2 decades at this point. I haven't noticed any issues with ABI so far, perhaps because I use everything from the distro repo or build and install them using the package manager. If I don't understand it, there are surely others who want to know it too. (Not trying to brag here. I'm referring to the time I've spent on it.)

I know that this is a big ask. The best course for me is of course to research it myself. But those who know the whole history tend to have a well organized perspective of it, as well as some invaluable insights that are not recorded anywhere else. So if this describes you, please consider writing it down for others. Blog is probably the best format for this.

Post reply on HN