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

451–460 of 493 posts

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

#451

Post by jetbalsa »

immibis wrote: post #409
ogogmad wrote: post #172

Earlier quoted context omitted.

This might be why OpenBSD looks attractive to some. Its kernel and all the different applications are fully integrated with each other -- no distros! It also tries to be simple, I believe, which makes it more secure and overall less buggy. To be honest, I think OSes are boring, and should have been that way since maybe 1995. The basic notions: multi-processing, context switching, tree-like file systems, multiple user…

Because Linux not an OS. The flagship OSS OS is Ubuntu, and it's mostly pretty stable. But OSS inherently implies the ability to make your own OS that's different from someone else's OS, so a bunch of people did just that.

Is it the flagship of Linux Distros right now? I though RHEL (The most common to see paid software package for) would be up there, along side its offshoots of Rocky / Fedora

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

#452

Post by johncolanduoni »

uecker wrote: post #241
amelius wrote: post #202

Earlier quoted context omitted.

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…

It should not be necessary to freeze it. glibc is already extremely backwards compatible. The problem is people distributing programs that request the newest version even though they do not really require it, and this then fails on systems having an older version. At least this is my understanding. The actual practical problem is not glibc but the constant GUI / desktop API changes.

Making an executable “request” older symbol versions is incredibly painful in practice. Basically every substantial piece of binary software either compiles against an ancient Debian sysroot (that has to have workarounds for the ancient part) or somehow uses a separate glibc copy from the base system (Flatpak, etc.). The first greatly complicates building the software, the second is recreating Windows’ infamous DLL hell.

Both are way more annoying than anything the platforms without symbol versioning suffer from because of its lack. I’ve never encountered anyone who has packaged binaries for both Linux and Windows (or macOS, or the BSDs) that missed anything about Linux userspace ABIs when working with another platform.

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

#453

Post by OsrsNeedsf2P »

ogogmad wrote: post #266
OsrsNeedsf2P wrote: post #242

Earlier quoted context omitted.

Pretty sure it's Linux not being the default option

Doesn't explain why Chrome beat IE. Or why MacOS has higher market share on the desktop than Linux. Wine and Proton should have levelled the playing field. But they haven't. Also, if you've only just started using Linux, I recommend you wait a few years before forming an opinion.

Installing Chrome is a lot easier than installing Linux

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

#454

Post by aryonoco »

andsoitis wrote: post #61
rickcarlino wrote: post #7

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.

I’m always on the hunt for single language cross platform solutions, and I thought I knew every player in the field but had not heard of Elements before. So I followed your link enthusiastically. But these are just some of the excerpts from the website:

Java Build code for any of the billions of devices, PCs and servers that run JavaSE, JavaEE or the OpenJVM.

.NET Core

The cross-platform .NET Core runtime is the future of .NET and will fully replace the current classic .NET 4.x framework when .NET Core 5 ships in late 2020.

It really seems like it was last updated sometime in the last decade. Not sure I want to base a future project on it.

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

#455

Post by nineteen999 »

imtringued wrote: post #449
nineteen999 wrote: post #364

Earlier quoted context omitted.

I'm not disagreeing that glibc symbol versioning could be better. I raised it because this is probably one of the few valid use cases for containers where they would have a large advantage over a heavyweight VM. But it's like complaining that you might need a VM or container to compile your software for Win16 or Win32s. Nobody is using those anymore. Nor really old Linux distributions. And if they do, they're not rea…

>As C/C++ programmer, the thing I notice is ... the people who complain about this most loudly are the web dev crowd who don't speak C/C++, when some ancient game doesn't work on their obscure Arch/Gentoo/Ubuntu distribution and they don't know how to fix it. Boo hoo. You must really be behind the times. Arch and Gentoo users wouldn't complain because an old game doesn't run. In fact the exact opposite would happen.…

https://www.shlomifish.org/humour/by-others/funroll-loops/Ge...

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

#456

Post by andrekandre »

chocochunks wrote: post #431
andsoitis wrote: post #56

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?

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 Alp…

slightly off the main topic, but if you wanna run dark forces II with gpu acceleration and texture filtering etc, try out OpenJKDF2

i got this working on my linux install (on risc-v nonetheless!) with a compile and some small tweaks it works well (getting 100+fps with filtering and ssao etc)

[0] https://github.com/shinyquagsire23/OpenJKDF2

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

#457

Post by shakna »

shakna wrote: post #69
andsoitis wrote: post #56

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?

Anything around DirectX 10 and older has issues with Windows, these days. One more popular example is Grid 2, another is Morrowind. Both crash on launch, unless you tweak a lot of things, and even then it won't always succeed. Need for Speed II: SE is "platinum" on Wine, and pretty much unable to be run at all on Windows 11.

Sidenote:

Whilst Morrowind is fine under Wine, there's a fantastic engine rebuild called OpenMW [0]. It runs on both Windows and Linux natively.

Some of the memory limits are also lifted, which meant I have a few mods that weren't possible without hacks in the past [1].

[0] https://openmw.org/

[1] https://morromod.netlify.app/

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

#458

Post by bigyabai »

whoknowsidont wrote: post #284
GeekyBear wrote: post #116

Earlier quoted context omitted.

Windows 2000 was the last version where Dave Cutler was fully in charge of Windows. Things started going downhill after that.

Windows 2000 was a bug riddled, poorly architected punching bag for malware. Things definitely went up-hill AFTER Windows 2000. What on earth would cause someone to say Windows 2000 was a good release? It wasn't even a good release when it came out, and it definitely didn't stand the test of time.

> What on earth would cause someone to say Windows 2000 was a good release?

An unsubstantiated insistence that a single human being is the bus factor for a thousand-engineer org?

I'm just as confused as you, everyone I've ever met who liked Windows 2000 went on to love XP SP3, usually with the W2K skin on it.

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

#459

Post by tsoukase »

senfiaj wrote: 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

Using Arch Linux gets rid of all ABI annoyances: bleeding edge versions, everything compiled provided by the distro with signed packages, no incompatibilities all the way. Not to mention the support and docu. I don't know if I miss something.

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

#460

Post by uecker »

johncolanduoni wrote: post #452
uecker wrote: post #241

Earlier quoted context omitted.

It should not be necessary to freeze it. glibc is already extremely backwards compatible. The problem is people distributing programs that request the newest version even though they do not really require it, and this then fails on systems having an older version. At least this is my understanding. The actual practical problem is not glibc but the constant GUI / desktop API changes.

Making an executable “request” older symbol versions is incredibly painful in practice. Basically every substantial piece of binary software either compiles against an ancient Debian sysroot (that has to have workarounds for the ancient part) or somehow uses a separate glibc copy from the base system (Flatpak, etc.). The first greatly complicates building the software, the second is recreating Windows’ infamous DLL h…

Is it painful? Why? You need a build environment that has the old libraries. It does not have to be ancient, just exactly what you need.
Post reply on HN