[HN Gopher] Win32 is the stable Linux userland ABI (and the cons...
___________________________________________________________________
Win32 is the stable Linux userland ABI (and the consequences)
Author : todsacerdoti
Score : 204 points
Date : 2022-02-27 17:41 UTC (5 hours ago)
(HTM) web link (sporks.space)
(TXT) w3m dump (sporks.space)
| RcouF1uZ4gsC wrote:
| We might end up in a world, where all the command line
| applications are Unix/Linux (and run on Windows via WSL) and the
| GUI applications are Win32 (and run on Linux via Wine)
|
| This would be playing to their strengths. There is a much nicer
| command line/shell ecosystem in Linux and a much nicer GUI
| ecosystem in Windows.
| laumars wrote:
| Unfortunately the GUI world seems to be settling on web
| rendering. While this is a massive bonus for cross platform
| support I'm still having a hard time agreeing that running a
| dozen Chromium instances is a good thing.
| akkartik wrote:
| Favorited (https://news.ycombinator.com/favorites?id=akkartik&c
| omments=...)
| encryptluks2 wrote:
| I don't think Windows has a nice GUI. It is incredibly
| bloated.. and Windows has been pushing UWP apps for some time.
| Please no.. Linux already has an influx of Electron apps, we
| don't need Windows UI.
| ripley12 wrote:
| UWP has been unofficially done for a few years now (no
| official statements, but you could tell from the lack of
| updates) and they officially shut the door on future updates
| 4 months ago.
|
| https://www.theregister.com/2021/10/26/microsofts_uwp_unwant.
| ..
| gjsman-1000 wrote:
| It's actually kind of insulting, because if you were one of
| the few developers to believe Microsoft and write, say,
| business apps in it as they said, you just got the short
| end of the stick.
|
| It's not a huge surprise why Microsoft can't rally
| developers behind anything.
| ripley12 wrote:
| Yeah, it's a mess. It seems like eventually they figured
| out that UWP's sandbox+packaging requirements were a huge
| mistake (see Project Reunion/Windows App SDK), but that
| realization came much too late.
| dtx1 wrote:
| I developed for UWP, though during the early days when
| windows phone 10 was still a thing. Honestly it wasn't
| the sandboxing that turned out to be the biggest problem
| (see all electron apps nowadays) but that the UWP
| Plattform was just shit in every way possible, from the
| design language that forced a desktop to become a phone,
| the store that never got any traction or quality support,
| the SDK that needed at least 3 more years of hard work
| and lots of extensions to become useful but most
| importantly: The terrible monetization. Microsoft entered
| a market with android and iphones making developers and
| companys a lot of money, yet on windows phone and UWP
| Apps on Desktop it was impossible to make any decent
| amount of cash.
| ripley12 wrote:
| Yeah, I'm fond of the AppContainer sandbox in a way; I
| think most consumer applications can get by in a sandbox
| (my UWP app could), and sandboxing applications _can_ be
| empowering for users since it lets them run more code
| without worrying about trust.
|
| Unfortunately, the execution was a mess. Not having _any_
| way to opt out of the sandbox was an insane decision and
| it led to crazy workarounds; even first-party Windows
| software has to do things like ship a sidecar exe to
| bypass the sandbox (the Store does). And troubleshooting
| issues with the sandbox was a pain, configuring
| capabilities was a pain, and there was very little in the
| way of iOS-style user-facing permission controls.
|
| And don't get me started on the marketing; MS flacks kept
| telling devs how sandboxing benefits users while doing
| virtually nothing to convey those benefits to users.
| littlecranky67 wrote:
| Not the first time they had done this. My first job was
| actually developing a replacement for a Silverlight App
| from a company heavily invested in ms/.net/c# in
| JS/HTML5. They were super heavily invested in Silverlight
| (easy decision as most of their codebase was WPF/C#
| already) and in the end it bit them.
| pjmlp wrote:
| UNIX you mean.
|
| That is why so few bother to support Linux OEMs, having some
| kind of POSIX support is enough for the large majority.
|
| However I still disagree, structured shell with REPL like
| capabilities like PowerShell are so much better and so much
| closer to the Xerox PARC experience.
| laumars wrote:
| > UNIX you mean.
|
| Not the GP but generally speaking it's not a great reach to
| say that Linux is more widely supported than POSIX. GNU-only
| flags are often used in shell scripts and you'll often find
| binaries are packaged as a snap or Docker container thud
| anyone running a non-Linux system is left to compile that
| project themselves.
|
| Even WINE itself doesn't officially support all POSIX-
| compatible UNIXs.
| smoldesu wrote:
| Yep. WINE is a second-class citizen on any platform that
| isn't Linux (as is most POSIX-like software these days),
| and requires special patches just to run on MacOS (and even
| paying for Crossover won't give you 32-bit binary support
| on Mac).
|
| For better and worse, the POSIX spec is dead. Besides a few
| niche use-cases where compatibility with archaic software
| is necessary, Linux is the new standard for this stuff.
| q-big wrote:
| > Linux is the new standard for this stuff.
|
| Linux is _not_ a standard, because in opposite to, say,
| POSIX, it is not standardized, but is an everchanging
| implementation.
| smoldesu wrote:
| I don't mean it in a literal sense, though I get where
| you're coming from. Think of it this way: your server
| software's stability is more or less defined by how well
| it conforms to Linux compatibility. Even software that is
| designed with perfect POSIX compliance won't run reliably
| on the majority of servers. Linux, despite not being a
| standard, has become a spec for server software.
|
| The kicker is that nobody can really undermine them
| unless you can create a true alternative with a more
| compelling license than GPL. If our industry wants to
| return to a truly standardized status-quo, we need to put
| aside our differences and collaborate on a next-gen spec
| that _works_. Considering that we _barely_ did this in
| the 80s with POSIX, I seriously doubt today 's developers
| and researchers are capable of doing it again. I'd love
| to be proven wrong though.
| dundarious wrote:
| It's quite interesting. I'm not sure that broad use of
| Win32/Wine for all types of GUIs would even work well for
| things like apps communicating with the broader desktop, and
| accessibility -- never mind that the desktop software stack is
| already a crumbling tower of complexity.
|
| But I can see it being attractive for full attention/fullscreen
| apps (like games) that don't use those things or by design
| bring their own implementations for those things, where the
| benefit is the reduced decision space for the developer, at the
| cost of the increased complexity. However, as the article
| states, ports are often using "compatibility layers" that are
| just worse versions of Wine though, so for such quasi-ports,
| there really is no increased complexity in using Wine instead.
| benibela wrote:
| 20 years ago I was developing software for Windows 98. Recently I
| tried to run some of the programs on Linux and they still all ran
| fine unchanged.
|
| But the things I wrote for Linux need permanent updates because
| they break some function change. Especially major versions
| changes qt4 to qt5 or gtk2 to gtk3...
| stingraycharles wrote:
| Interestingly, it works both ways. I recently wanted to play some
| oldschool Command & Conquer with some friends, and it was very
| easy to get these old games running in Wine, but my friends (with
| modern Windows laptops) couldn't get it to work. Not even with
| compatibility mode.
|
| That was very interesting to me.
| [deleted]
| doikor wrote:
| Most that still play the old C&C games do it trough openra or
| with the newly done ultimate collection directly from EA.
|
| https://www.openra.net/
| Ericson2314 wrote:
| https://cncnet.org/ is the actual games, and it was via that
| modding / RE community that the remastered edition came with
| the reconstructed source.
| nly wrote:
| Hardly surprising. Your typical WINE user playing C&C will
| notice if an update in WINE breaks it, and report it to winehq.
| EA don't give two shits about legacy C&C games that aren't
| making them money.
| bennysomething wrote:
| Can I run wine on windows then? Only semi joking!
| hedgewitch wrote:
| Not sure if this would help in this exact case, but I've
| used OTVDM to run some old games successfully.
|
| https://github.com/otya128/winevdm
| __s wrote:
| Yes: https://www.reddit.com/r/bashonubuntuonwindows/comment
| s/6joy...
|
| Give it time, WSL support for graphics is in preview:
| https://docs.microsoft.com/en-
| us/windows/wsl/tutorials/gui-a...
| mwcampbell wrote:
| I think it would be interesting to package up ReactOS
| [1], which shares a lot of code with Wine, as a VM that
| could be shipped with an application along with something
| like QEMU. If I'm not mistaken, QEMU supports
| virtualization through the Windows Hypervisor Platform
| and macOS's Hypervisor.framework. Could be a good way for
| GOG to sell old Windows games.
|
| [1]: https://reactos.org/
| Koshkin wrote:
| Not to take away from ReactOS as a project, this somehow
| doesn't make much sense to me, as WINE (and its spin-
| offs, like Valve's Proton) is already good enough as a
| portable gaming platform.
| mwcampbell wrote:
| I was thinking in particular about the Wine on Windows
| use case. Running ReactOS in a VM seems a more direct
| route than running Wine in a Linux VM (e.g. via WSL 2).
|
| Edit: I also think it would have made a lot of sense for
| Valve to invest in getting ReactOS running on their Steam
| Deck hardware, so they could use that instead of Linux.
| They're clearly a Windows-first shop, and ReactOS is
| modeled on NT right down to the kernel. Having a Unix-
| like OS running underneath, when one really just wants to
| run Windows code, adds an extra translation layer and
| impedance mismatches that might even be user-visible.
| seba_dos1 wrote:
| You don't need a VM or WSL to run Wine, you can run it on
| Windows. Sometimes even WineD3D alone is enough to fix
| issues with old games.
|
| Also, Valve's interest in GNU/Linux is broader than just
| Deck.
| LeFantome wrote:
| WINE is Windows APIs running on the Linux kernel ( host
| OS kernel ). The Linux kernel is already high quality and
| high performance.
|
| ReactOS is Windows APIs running on the from-scratch
| ReactOS kernel that is not very good.
|
| The ReactOS project is not the source for most of the
| APIs a game is going to use. Many of the come from WINE.
|
| Using ReactOS instead of WINE on Linux makes little sense
| at this point. It would certainly be a lot more expense
| and time to create a commercial quality product. Most of
| the work creating API support to WINE / Proton is
| portable to ReactOS of the kernel ever gets there.
| usrusr wrote:
| About the ReactOS on Steam Deck bit: I'd suspect that
| this might be a bit too much for what looks like a
| fragile peace between Microsoft and Valve. Doing Deck on
| Linux is one thing (in the days of Linux on Azure it
| can't be much of a provocation), but ReactOS could still
| be too much I think. "If you want Windows, ask us for a
| good offer!" Technically Proton on Linux might be very
| similar (even the same code in key parts?), but on a
| subjective level, I could easily see one trigger a red
| line reaction the other would not.
| Koshkin wrote:
| Actually, WINE works in WSL 1, too.
| hedgewitch wrote:
| I think this is the wrong way to be looking at it.
|
| WINE is an open-source project that explicitly wants to run
| as much Windows software as accurately as possible on non-
| Windows systems. If something's broken, anyone can fix it.
|
| This isn't true for the proprietary software that is Windows
| and C&C, albeit C&C Remastered is partially source-available
| now, so that could improve matters somewhat.
| wongarsu wrote:
| Microsoft used to be quite dedicated to this too. If you look
| at the leaked Windows XP source code you can find
| compatibility shims to ensure that older Versions of Quicken
| or Acrobat Reader or Settlers 3 still work. A "don't break
| userland" policy is part of the reason they became so popular
| in businesses. Since then times seem to have changed
| somewhat.
| stevefan1999 wrote:
| That changed because they have a major refactor starting
| from Windows 7. They have it up to the spec and not so much
| more ad-hoc behavior this time.
|
| To me it seems like cutting the compatibility arm is worth
| the price of having to keep a shitty, inconsistent
| behavior.
|
| Apple has nailed it so well (don't make it backward
| compatible) for the last decade afterall, since Apple
| realized one the internet is so much better and source code
| management (and repository, backup, disaster recovery)
| became more accessible so that the cost of port became much
| lower.
| unicornfinder wrote:
| To be fair though I think there's a happy medium. For a
| while I really loved Apple's approach of just not giving
| a damn about backwards compatibility but I have to say
| using Windows did make me realise just how wonderful it
| is not worrying about whether the software I want to use
| will work.
| lostmsu wrote:
| I just had the opposite story with Need For Speed IV High
| Stakes. In wine it would crash, but somebody kept making hacks
| for it to run on Windows.
| smoldesu wrote:
| Did you try any of those hacks through WINE?
| aliswe wrote:
| CnC came out 1995 though - NfS 4 came out 99 ...
| cryptonector wrote:
| Oh! Maybe we can get Enigma Rising Tide running on WINE?
| philistine wrote:
| Command and Conquer and Red Alert both have DOS versions as
| well as Windows. The DOS one has very low resolution, but it
| means Dosbox is a possibility.
|
| But all in all, I'd say go with OpenRA. My friend and I played
| it for a couple of weeks and we scratched the itch of the
| original games, with none of the hardships and a bevy of
| wonderful changes to the core gameplay.
| stingraycharles wrote:
| We indeed ended up playing OpenRA, it's pretty decent and we
| had a fun time.
| nmz wrote:
| > After all, we all know the Year of the Linux Desktop is around
| the corner
|
| It's been a while since I've laughed out loud like when I read
| that.
|
| and its not an insult to linux, but I've been hearing about the
| year of linux on the desktop like I've been hearing about the
| apocalypse. Believing of the year of linux on the desktop is the
| same as believing in Nostradamus.
| phendrenad2 wrote:
| How do we fix this? A lot of good analysis of WHAT the problem is
| here (userland libraries have no "stable API" guarantee, and in
| fact revel in breaking backward compatibility in some weird sense
| of spite for people who don't update). Maybe Linus can release
| Linux II and say "everyone shall use the GTK4 and wayland 1.0 API
| or you can't use the Linux II trademark"
|
| Then again, maybe it doesn't need fixed, since it seems to be
| working great. Distros just need to ship with WINE preinstalled
| and better-integrated. Hell, write an entire distro using win32
| apps.
| marcodiego wrote:
| > Linux users tend to be less picky about any possible UX issues
| induced by Wine. They'll tolerate a lot of flaws if it means they
| can have your application at all.
|
| Definitely not true:
| https://news.ycombinator.com/item?id=28978086 , Ok, the linked
| article talks about a "native" port, but still...
| smegsicle wrote:
| > Despite having just 5.8% sales, over 38% of bug reports come
| from Linux
|
| > 3/400 bug reports were port specific
|
| it's a report about linux users being more likely to report
| issues in general, not being picky about port quality
| minroot wrote:
| I don't understand the whole thing. Instead of working on getting
| game developers releasing their game to run natively on Linux,
| people are doing brokenly trying to get things run on Linux with
| a pile of crap.
| TheRealPomax wrote:
| Except that it's (1) not a pile of crap (it actually works
| unreasonably well, and keeps improving) and (2) building for
| one platform and having third party tooling make that work on
| other platforms means you are not spending five, ten, or even
| more times as much on _purely_ supporting additional build
| targets.
|
| No sane PM would go "hey let's take a huge chunk of our budget
| and spend it on native builds and QA for at least five
| different-enough-to-all-have-their-own-bugs linux platforms in
| addition to Windows, rather than spending it on actual game
| development for a single platform".
| NavinF wrote:
| You realize that Linux has <2% market share across all distros
| and versions, each of which needs a different binary, right?
|
| "We shipped Planetary Annihilation on Win, Mac, and Linux.
| Linux uses we're a big vocal part of the Kickstarter and
| forums.
|
| In the end they accounted for <0.1% of sales but >20% of auto
| reported crashes and support tickets (most gfx driver related).
|
| Would totally skip Linux."
|
| "By the end of my time at Uber I believe very nearly 100% of
| both crashes and support tickets actually for the game were
| still Linux related, even after significantly engineering time.
| Way more Linux specific time put into that project than any
| other platform. And again, that was for a tiny fraction of the
| users.
|
| Adding Linux support ended up likely costing Uber hundreds of
| thousands of dollars for a few hundred dollars in sales
| revenue."
|
| https://mobile.twitter.com/bgolus/status/1080213166116597760...
| TeddyDD wrote:
| Counterpoint: https://www.reddit.com/r/gamedev/comments/qeqn3
| b/despite_hav...
|
| > all distros and versions, each of which needs a different
| binary
|
| You only need to support Steam runtime.
| pjmlp wrote:
| "What Was IBM's OS/2, and Why Did It Lose to Windows?"
|
| https://www.howtogeek.com/688970/what-was-ibms-os2-and-why-d...
|
| > Also, OS/2 had a chicken-and-egg problem. Its best selling
| point was its compatibility with MS-DOS and Windows applications.
| However, this meant few developers took the time to write
| OS/2-native apps. So, why run OS/2 at all?
| bogwog wrote:
| A more recent example of that is Blackberry 10. The way they
| tried to get developers was to ship an Android runtime so you
| can run Android apps. They even offered payments of $100 for
| every app a developer ported.
|
| That just led to the BB appstore getting flooded with low
| quality Android apps that looked out of place and had terrible
| performance.
|
| Which is not to say that BB10 would've succeeded if it had
| better apps, but it certainly didn't help.
|
| But with Proton/Wine it's different because the games actually
| run really well, sometimes even better than they do on Windows,
| and it's completely transparent to end users (unlike BB10,
| where Android apps behaved/looked different)
|
| Plus, it doesn't make a difference to the Linux desktop's
| success whether devs write native apps or not. If a new
| business makes a real effort to develop and sell a Linux
| desktop product, the only thing that will matter is if
| customers can adopt it without losing access to the
| software/workflow they're familiar with.
|
| If they can pull that off, then competing against Windows
| shouldn't be that hard; just _don't_ have a seething hatred of
| your own customers, and you'll have a head start on Microsoft.
|
| The only issue I see with the Proton reliance is the risk that
| Microsoft will do Microsoft things, and start introducing
| subtle API changes designed to break Proton/Wine and sabotage
| the competition. That's a legitimate concern, but maybe today's
| antitrust climate will make them a little hesitant to do that
| kind of thing? (Probably not)
| fartcannon wrote:
| Because Windows is spyware?
|
| Not to be inflammatory, but I don't want to be monetised when
| I'm just using my computer.
| userbinator wrote:
| Before Windows 10 (and later backports to 8), it wasn't.
| Lammy wrote:
| > Before Windows 10 (and later backports to 8), it wasn't.
|
| It has been since _NSAKEY shipped in Windows 95 OSR2's
| ADVAPI32
|
| http://www.stat.rice.edu/~dobelman/kstorm.txt
|
| https://www.geoffchappell.com/studies/windows/win32/advapi3
| 2...
| userbinator wrote:
| NSAKEY has already been thoroughly debunked, and was only
| ever a suspected backdoor, not active spyware.
| pjmlp wrote:
| I assume you also don't use anything Google related then.
| stevefan1999 wrote:
| I would think performance and forward compaibility are the two
| most likely reasons instead.
|
| Eventually DOS will die down due to its limitations (like TSR,
| interrupts, lack of VM, inability of handling devices in safe
| manner) with ever increasing hardware power.
|
| Porting over to OS/2 ensures it will have a much smoother way
| of keeping an edge over the competitors, if OS/2 ever did have
| a sequel. Thanks, Moore's Law!
|
| Of course, OS/2 is ill-fated due to corporate thinking and the
| disagreement in both sides, but the ideas are rooted deep
| within Windows 95/98.
| q-big wrote:
| > Also, OS/2 had a chicken-and-egg problem. Its best selling
| point was its compatibility with MS-DOS and Windows
| applications. However, this meant few developers took the time
| to write OS/2-native apps. So, why run OS/2 at all?
|
| I don't think this is comparable to the Win32 vs. (GNU/)Linux
| situation. There do exist lots of people who did write Linux-
| native applications in the past, but the APIs of many userland
| libraries of the GNU/Linux ecosystem tend not to be stable for
| a very long time, so these applications simply did not work
| anymore at some point in time.
|
| Because of the technical complications that shipping GUI
| applications for GNU/Linux involves, a lot of companies
| concluded that developing and shipping applications for
| GNU/Linux is not worth it.
| indymike wrote:
| OS/2's biggest issue was pricing. OS/2 was $200 per PC and you
| could only get it with an IBM PS/2. So if you were buying a
| clone, it would come with DOS + Windows and then you could buy
| OS/2. In 1994, IBM finally went for a broader market with OS/2
| Warp. It was marketed as a better Windows than Windows 3.11...
| and it was. Then Windows 95 happened. Any thoughts of switching
| to OS/2 died with Windows 95.
| jandrese wrote:
| OS/2 Warp was a day late and a dollar short. It had a weird
| multitasking thing where misbehaving apps could lock up the
| OS like Windows 3.11, even though they claimed it was better.
| I found the interface to be somewhat unintuitive as well.
| marcodiego wrote:
| Its not easy to "port" the OS/2 situation to the modern world.
| It as much possible to "run" windows software on linux with
| wine as it is possible to run linux software on windows with
| wsl.
|
| Of course, since "linux api" is open/public/floss, wsl may have
| an advantage in compatibility. What is hard to determine is
| which side this advantage will benefit.
| melony wrote:
| The latest version of WSL is a hypervisor running the Linux
| kernel. WSL1 was the real subsystem where they copied the
| kernel API.
| Koshkin wrote:
| Looks like Win32 is becoming the best GUI (and not only) API for
| Linux.
| marcodiego wrote:
| No it is not. There are very few win32 popular supported non-
| game apps on linux right now. Only one I can remember is
| teamviewer.
| pdenton wrote:
| Too bad win32 is such a finicky and verbose API that's painful to
| use for anything beyond the simplest of dialogs. I tried. The
| MSDN documentation doesn't quite cut it. TheOldNewThing by
| Raymond Chen is a must-read to get it right.
|
| But above all, a stable ABI is only needed for proprietary
| programs which I abhor for not being FLOSS. As a programmer, I
| really do think the 4 freedoms are important and loathe anything
| non-compliant.
| alkonaut wrote:
| Running Win32 UI code as WinForms through .net is a lot less
| painful than doing straight Win32. Not very good for deploying
| a tiny program obviously though.
| ripley12 wrote:
| There's been a lot of work happening to make WinForms
| trimmable. I think it will land in the upcoming .NET release
| (7) or the next one, I'm looking forward to being able to
| ship small WinForms apps with zero dependencies.
| https://github.com/dotnet/winforms/issues/4649
| phendrenad2 wrote:
| Now I'm curious, what exactly were you making where the win32
| documentation was insufficient, but the "one weird trick" blog
| TheOldNewThing was helpful? Did you buy any books on win32 or
| check stackoverflow?
|
| I've found win32 to be a bit hard to find documentation on
| sometimes (the official documentation is complete, but
| sometimes know which hook or function to use is up for debate,
| stackoverflow has good answers there), but overall it's a very
| good API that gets out of the way and lets me just build.
| pjmlp wrote:
| Win32 is beautiful when compared against Xlib, Athena Widgets
| and Motif.
| pdenton wrote:
| Which have very sparse documentation, but do work just fine.
|
| Win32 covers a lot more than xlib, athena and motif. And
| still I have to resort to porting over bits and pieces from
| the FreeBSD C library because in a pure win32 project (no
| msvcrt), things are missing.
|
| The thing is, getting all the details right requires
| extensive research and a lot of extra nonsense that shouldn't
| be necessary. For compatibility, accessibility, consistency,
| etc. Sometimes it's amazing things work at all.
| pjmlp wrote:
| Windows is not a UNIX clone, that is to be expected, and it
| isn't the only OS around that isn't from the UNIX school.
|
| Plenty of details documented across MSDN and Technet, and
| these old technology called books.
| pcwalton wrote:
| I mean, that's debatable. But in any case Xlib, Xaw, and
| Motif can be completely bypassed nowadays--XCB and Wayland
| are complete replacements for Xlib (with EGL finally
| providing the needed XCB-compatible alternative to GLX), and
| GTK+/Qt are alternatives to Xaw and Motif--while Win32 is
| still the only way to do many things on Windows. Granted, the
| vast majority of devs use wrappers around Win32, so they
| don't have to care about the low-level plumbing.
| pjmlp wrote:
| Gtk+ and Qt are cross platform middleware.
| zekica wrote:
| Linux has stable userland ABI. I managed to run a gui binary from
| Slackware 12 (from 2007) in a chroot and it worked completely
| fine. It didn't have modern theming or HiDPI support but it
| worked fine.
|
| Windows apps running via wine and old linux apps running via
| chroot or any other container (AppImage, snap or Flatpak) all
| work.
|
| The problem is not having specific (major) versions of old
| libraries in the new OS. If you manage to install them, they will
| work - this is difficult in most distributions.
| est31 wrote:
| > Linux has stable userland ABI. I managed to run a gui binary
| from Slackware 12 (from 2007) in a chroot
|
| The key word is _chroot_ here, and _managed_. Sure, a
| technology enthusiast might _manage_ to run binaries from 2007
| on a _chroot_ , as in, after having invested hours of work to
| find an outdated copy of an entire distro and then wasting
| gigabytes of hard drive space on making it work. But this
| doesn't help the average linux gamer who just wants their
| downloaded game from 5 years ago to still work. Nor does it
| help the ISV vendor who wants to sell GUI software that can be
| used on modern linuxes as well.
| jcelerier wrote:
| > after having invested hours of work to find an outdated
| copy of an entire distro
|
| you mean docker run -it debian/eol:potato
| /bin/bash
|
| ?
|
| (debian potato was released in 2000 for the curious)
| josefx wrote:
| Unless you depend on a central service like X11 where only one
| version runs on the whole system and newer
| implementations/replacements may intentionally break things.
|
| Last time I had to run some ancient software on Linux I just
| spun up a Virtual Box image with the Linux version it was
| released for (of course all the mirrors for that where offline
| by then too).
| zajio1am wrote:
| > The problem is not having specific (major) versions of old
| libraries in the new OS. If you manage to install them, they
| will work - this is difficult in most distributions.
|
| My experience was that often it is the opposite problem. Games
| came with bundled libraries of old versions (e.g. libSDL) that
| do not work properly with the rest of the OS. When they are
| forced to use system versions of libraries, they started to
| work.
| Wowfunhappy wrote:
| Does this work seamlessly alongside other apps on your machine?
| By which I mean:
|
| * Does copy-and-paste work?
|
| * Does the file picker dialog default to a logical location, or
| does it start out in some weird directory?
|
| * If you click on a URL, does it open in your default web
| browser?
|
| * Can you screen-share the application from Zoom?
|
| I'd also be curious whether there's a performance impact beyond
| disk usage.
|
| Basically, I'm wondering if the UX is substantially better than
| using a VM. VMs are _great_ for backwards compatibility, but
| the UX sucks, because apps don 't exist in a vacuum.
|
| If chroot _does_ work seamlessly for GUI apps, that strikes me
| as a perfectly reasonable backwards-compatibility solution, and
| better than what Windows does in some ways. Heck, distros
| should consider automating this when users try to launch old
| software.
|
| Edit: I also wonder how much of this problem would go away if
| Linux devs were willing to ship statically-compiled binaries.
| (Or mostly-statically-compiled binaries, since I know including
| e.g. gpu libraries is problematic.)
| stormbrew wrote:
| Assuming the GP was using x11, then yeah it's very likely
| almost all of those things worked fine (depending on how they
| structured the chroot to include their homedir). The only one
| that probably doesn't is the URL->browser one, just because
| the chroot probably wouldn't have access to run the browser
| directly, even if the right MIME-type/xdg config files were
| present in the chroot.
|
| X11 as a protocol if anything is probably more backwards
| compatible than windows has ever been, and most of the
| extensions that enable the things you're asking about have
| been available for decades. ABI and libc aside xclock from
| 1996 probably still works on ubuntu 22.04.
|
| > Heck, distros should consider automating this when users
| try to launch old apps, if at all possible.
|
| This is more or less what snap and flatpak are trying to do.
| dzaima wrote:
| X11 doesn't provide anything for opening a file dialog.
| afaik you have to just call GTK-specific things to achieve
| that (hell there's a C library specifically for just
| opening a file/folder open/save dialog). X11 itself doesn't
| provide that much beyond opening & managing windows (and
| the copy&paste mess it provides is, well, a mess.)
| stormbrew wrote:
| Sure, but the question wasn't "will a file dialog open at
| all" it was "will it open in a weird place". If the app
| was using gtk and you're running it in a chroot with
| period-appropriate gtk that gtk file open dialog will
| probably open just fine, and then it's a matter of if you
| bind mounted your homedir and /etc into the chroot so
| it'd know where to go. From there it'll open in
| approximately as weird (or un-weird) a place as it did in
| 2007. Like, this isn't a problem almost specifically
| _because_ x11 isn 't trying to do anything very clever
| here. There's no OpenFileDialog along with an
| OpenFileDialogEx and
| OpenFileDialogExtraArgumentsFor2016Ex APIs to keep going.
| If your program had a file dialog then, it has one now.
| It's probably just ugly.
|
| As for copy/paste, it is a bit of a mess but it's a mess
| that works pretty well for this kind of situation. If the
| copyer and paster windows are in the same x11 context and
| use the same (widely used) protocol over x11 window
| properties, they will be able to copy and paste with each
| other regardless of if they're running natively, in a
| chroot, in a vm, or on a remote machine.
|
| Incidentally I _really_ miss having the second
| "select/middle click" copy/paste context when I'm using
| windows or a mac. It's really frickin' useful and by far
| more useful than almost any other middle mouse button
| uses I've ever seen in any non-game. But then I also miss
| having normal copy/paste in the common linux gui terminal
| emulators so...
| Wowfunhappy wrote:
| Isn't the Linux world (slowly) moving away from x11,
| though?
|
| (If you can't tell, I'm not a Linux user, I was _many_
| years ago and I 'd like to go back some day. These types of
| library compatibility issues are a major part of what's
| keeping me away--I want to know that most apps from 15
| years ago will still work, and most of the apps I have
| today will still work in another 15 years.)
| stormbrew wrote:
| Things are moving to wayland, but x11 is never going to
| go completely away. Xwayland provides an xserver that can
| be used within wayland.
|
| Some of the things you listed as problems would be
| problems anyways in wayland, because they have to do with
| the fact that wayland doesn't, for example, give
| unrestricted access to every single program's image
| buffer from any program (for good reason).
| salawat wrote:
| It's trivial if you compile from source and onow how to massage
| the linker!
| NavinF wrote:
| Oh the linker needs a lot more than a massage; The linker
| wants full service.
|
| When a user needs to run a program, but the inconsiderate
| lazy dev only built, packaged, and tested the program on 24
| ABIs (4 versions of 6 distros) rather than 25 ABIs like he
| should have, this is what the user wants to see:
|
| /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.
| a && : /data/source/vcpkg/installed/x64-linux/debug/lib/libgl
| ib-2.0.a(gmain.c.o): In function `g_get_worker_context': /dat
| a/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/gl
| ib/gmain.c:5848: undefined reference to `pthread_sigmask' /da
| ta/source/vcpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/g
| lib/gmain.c:5853: undefined reference to `pthread_sigmask' /d
| ata/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.a(
| gregex.c.o): In function `match_info_new': /data/source/vcpkg
| /buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:58
| 8: undefined reference to `pcre_fullinfo' /data/source/vcpkg/
| installed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In
| function `g_match_info_next': /data/source/vcpkg/buildtrees/g
| lib/src/2.52.3-34a15219ec.clean/glib/gregex.c:734: undefined
| reference to `pcre_exec' /data/source/vcpkg/installed/x64-lin
| ux/debug/lib/libglib-2.0.a(gregex.c.o): In function
| `get_matched_substring_number': /data/source/vcpkg/buildtrees
| /glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:1076:
| undefined reference to `pcre_get_stringnumber' /data/source/v
| cpkg/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.
| c:1079: undefined reference to `pcre_get_stringtable_entries'
| /data/source/vcpkg/installed/x64-linux/debug/lib/libglib-2.0.
| a(gregex.c.o): In function `g_regex_unref': /data/source/vcpk
| g/buildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:1
| 262: undefined reference to `pcre_free' /data/source/vcpkg/bu
| ildtrees/glib/src/2.52.3-34a15219ec.clean/glib/gregex.c:1264:
| undefined reference to `pcre_free' /data/source/vcpkg/install
| ed/x64-linux/debug/lib/libglib-2.0.a(gregex.c.o): In function
| `g_regex_new':
|
| Clear as mud.
|
| Of course you could use the buggy 16 month old version from
| the package repo.
| spijdar wrote:
| Linux has a stable "userland ABI" only so far as the kernel
| interface stays (with very few exceptions) stable. This means,
| as you've said, you can run old applications, as long as you
| have entire copies of the rest of the userland to go with them.
|
| (One potential problem I can see with really old Linux
| userlands/games is old Mesa wanting the old user mode switching
| drivers from Linux, that are long removed. You'd need at least
| newer versions of Mesa, I think, which may be impossible to
| achieve due to dependency hell)
|
| This comes down to arguing semantics but I don't think this
| really constitutes a stable "userland ABI" in the sense it's
| used to describe Windows. Yes, you can use containers to
| effectively create independent copies of old userlands and run
| your code in them. But you can't just run old software without
| matching copies of the specific libraries it expects, which
| themselves have a rat's nest of dependencies, necessitating
| having ~N complete copies of Linux userlands floating around
| for N programs.
|
| One way we could circumvent this problem is static linking,
| since they the only interface would be the kernel one, that is
| mostly backwards compatible. That has its own problems (e.g.
| inability to patch libraries independently), but is probably
| better than just keeping copies of the shared object files in
| their entirety in containers...
| [deleted]
| my123 wrote:
| > One way we could circumvent this problem is static linking
|
| Out of the question for any app using the GPU.
|
| As that means statically linking with a given GPU user-mode
| driver version, not being able to get updates or support for
| any future GPU.
| [deleted]
| jcelerier wrote:
| > This means, as you've said, you can run old applications,
| as long as you have entire copies of the rest of the userland
| to go with them.
|
| isn't that why windows can run old applications though ?
| every game used to come bundled with their own copy of
| everything down to the C & C++ runtime (and that's why they
| still can run)
| electroly wrote:
| No, not really. Win32, the bit that you use to actually put
| a window on the screen, is a system library that is simply
| backwards compatible forever. You don't distribute Win32
| with your applications. Go ahead and try to find a copy of
| USER32.DLL distributed with your old applications; you
| won't find it.
| LanternLight83 wrote:
| Functional package managers like Nix and Guix can reproduce
| an exact build of a program, including it's dependency tree
| (build time and runtime), and package that into a container,
| which can be shipped as an executable image (stripped down to
| just the neccesary runtime deps). Nix Flakes in particular
| allow you to define an entrypoint, making the build+run
| process nearly as painless as "docker run $x"
| dzaima wrote:
| The kernel ABI barely matters for most things. You'd _hope_
| libc wouldn 't break. What's important is window managing APIs,
| graphics APIs, file system structure (your program location,
| user config location), environment variables, preinstalled
| binaries, and many smaller things (acceptable keyboard
| shortcuts, registering to open a specific file type, opening a
| native "open/save file/folder" dialog, etc). Those are a lot
| less stable and may require using various random libraries or
| writing code for specific WMs/desktops. It's not fun.
| jart wrote:
| The tragedy of the Linux desktop is that its CLI is superb
| and Chrome works really really well. The year of the Linux
| desktop happened with Android but sadly all that successful
| GUI stuff that Google did was never able to percolate back
| into the FOSS world as a WIN32 alternative. It's a sad state
| of affairs for Linux desktop app developers, because they've
| had the wind taken away from them on all possible angles. The
| only Linux desktop app I can personally remember using in the
| past year (aside from the terminal and Chrome) would probably
| be kcachegrind. I wish that we as a community could focus
| more on building outstanding TUIs (e.g. linux perf, gdb
| --tui, emacs) since most Linux installs are headless and it
| makes an app more functionally useful it can be used in a
| terminal via ssh.
| pjmlp wrote:
| The CLI is just like any other UNIX/POSIX, and as far as
| Android is concerned, Linux does not exist for userspace
| coming from Play Store, including apps written with
| NDK/AGK[0].
|
| Only OEMs have the ability to directly use Linux, doing so
| from userspace means using what Google considers as being
| private APIs.
|
| Not to mention that Google could at any moment change it by
| Zircon, if they could so feel inclined.
|
| So Android is hardly the best that Linux could make it as
| desktop.
|
| [0] - Native Development Kit/Android Game Kit
| unfocussed_mike wrote:
| > So Android is hardly the best that Linux could make it
| as desktop.
|
| Chrome OS Flex might be interesting when it does,
| eventually, support the linux environments.
| pjmlp wrote:
| Another Pyhric victory where Linux runs in a container
| WSL style and desktop is a browser.
| unfocussed_mike wrote:
| I guess, but I am weirdly fine with this if the desktop
| can see everything it needs from the container.
| pjmlp wrote:
| Another proof that only POSIX matters.
| Spivak wrote:
| Linux has a stable ABI but only if you don't include all
| userspace libs isn't really that much of a guarantee. Sure it
| means you can run ancient distros on newer kernels provided
| they don't depend too much on the specifics of X11 or OpenGL
| but that's not great unless we're happy with "oh this software
| works on Ubuntu 14.04 so we'll just ship all of a Ubuntu 14.04
| userspace with the app." (looking at you Steam Runtime)
| phaedrus wrote:
| This was the same conclusion I came to as well. Both for my
| personal projects, and what I now recommend at work when the
| subject of potential Linux ports comes up, is that if WINE is
| good enough to run it why not just do that?
| derefr wrote:
| I'm fine with this when it's some freestanding native-compiled
| C+DirectX application.
|
| But it really irritates me when the Windows version is, after
| all, just a bunch of scripts loaded into a scripting runtime
| (think e.g. Love2D, or RenPy); but then the first-party
| macOS/Linux downloads turn out to be WINE wrappers wrapping
| _the Windows version of the scripting runtime_ , rather than
| using the macOS/Linux versions of the scripting runtime.
|
| I get that people don't always have multiplatform development
| setups; and that there are easy-to-use tools that "wrap" a
| Windows application into macOS/Linux versions. But these
| runtimes usually _also_ have cross- "compilation" options that
| are just as easy to use!
| smoldesu wrote:
| As a Linux user, I'm generally fine with that "WINE support"
| mentality, as long as the application isn't demanding (like an
| NLE, photo editor, DAW, etc). There's a ton of Windows-only
| tools that I have no problem using on a regular basis, like
| Lunar IPS and Winamp.
| lnxg33k1 wrote:
| >> Winamp
|
| My hero
| derefr wrote:
| Is there still as yet no Linux-native reimplementation of
| Winamp? (in the sense that it's a lightweight program that
| 1. plays music and 2. loads Winamp skins + faithfully
| renders its UI using them, presumably being designed from
| the ground up primarily to use Winamp skins.)
|
| That's doubly-surprising, given that there's already a
| _web_ reimplementation of Winamp (https://webamp.org/) that
| does those things. (And it's "lightweight" in terms of not
| pulling in any JS frameworks; but not especially
| "lightweight" in terms of you needing a full web browser to
| run it.)
| smoldesu wrote:
| I don't really use Winamp through WINE very often, mostly
| just a party trick for disenfranchised Windows users :p
|
| If you're looking for a no-frills native Linux audio
| player, I recommend Quod Libet[0] wholeheartedly. Nothing
| fancy, but it has _loads_ of organizational features
| bolstered by a rock-solid GTK3 codebase. Genuinely have
| no complaints with it, I 'm really impressed with how
| polished and feature-complete it is.
| lnxg33k1 wrote:
| I would also suggest Quod Libet, also for the tag editor
| Ex Falso
| bitwize wrote:
| There's XMMS and Audacious. XMMS started life as X11Amp.
| lnxg33k1 wrote:
| Wasn't audacious (https://audacious-media-player.org/)
| supposed to be that? ;o
| marcodiego wrote:
| To get a good retro feeling, I once compiled the most
| recent gtk 1.x version available and then compiled xmms
| on a raspberry pi. Worked flawlessly.
|
| But yes, there are modern and maintained implementations
| that support winamp skins. I think qmmp is one of those.
| TaylorAlexander wrote:
| Just my little anecdote: I needed to run an old version of Eagle
| CAD and I wasn't sure how to get old Linux versions to run. The
| old windows version worked great in WINE.
| phendrenad2 wrote:
| Well, many Linux programs don't work out of the box, so it's
| possible that the program never worked without talking to an
| Eagle support rep.
| sprash wrote:
| The solution is very simple: static linking.
|
| Dynamic linking should be completely abolished. This would also
| solve the "package manger problem" immediately because there will
| be no dependencies.
| taftster wrote:
| You get all the failures of static linking, too. Security in
| underlying statically compiled libs, for example.
| calvin_ wrote:
| The deep irony is Windows has achieved its herculean backwards
| compatibility through dynamic linking.
| mahkoh wrote:
| I suppose you would then statically link all gpu drivers into
| your graphical application? And whenever a new gpu or a new
| driver is released, you will recompile your application. In
| case a new driver drops support for older cards, you would then
| include multiple versions of the driver in your binary.
| Naturally your binary will be several hundred megabytes large.
| An interesting idea. I was not aware that proprietary drivers
| even allowed this.
| sprash wrote:
| Graphics drivers is one of the rare if not the _only_ pain
| point with static linking. The reason is that drivers in
| general should be part of the kernel but GPU drivers are
| running in userspace. Proprietary blobs, fast evolving
| hardware and as a result fast changing APIs are to blame.
|
| But on the other hand high level GPU APIs are pretty stable
| and in general backwards compatible. A program from the year
| 2000 that _only_ links against OpenGL would still run today
| (with x86 libs obviously). This means to static link as much
| as possible still has value.
| andai wrote:
| Any distros following this philosophy? Apart from solving the
| constantly breaking packages problem it sounds like it would
| also have the fastest installs (at the cost of increased disk
| usage, though perhaps fs-level (block-level) deduplication
| could offset this?
| philo23 wrote:
| > Their goal is being able to suspend a game on your desktop and
| play it on your Deck will likely need them to standardize on a
| single platform [..] There are some additional challenges with
| this approach [..] but sticking to a single platform [..] removes
| some concerns with synchronizing lower level state across
| multiple platforms.
|
| My understanding with the suspend/resume stuff they've talked
| about for the Deck is less about actually suspending/resuming the
| game by syncing some low-level state like memory or graphics, and
| more about quickly syncing save games via Steam cloud saves.
|
| I only had a quick look over their docs when the Deck was
| announced and from what I could tell you basically opt into a new
| system-level save behavior where at any point the Steamworks
| library can tell the game "this device is going to suspend now,
| save your progress" then another computer can start the game and
| immediately load up the save file, giving the impression of
| seamless suspend/resume.
|
| So as long as your save game files aren't OS specific in some way
| there's no reason why this should lock you into any specific
| platform, Windows or otherwise.
| dathinab wrote:
| Probably that.
|
| Anything else also would be insanely hard.
|
| Just trying to "store the GPU state" on a system with AMD GPU
| and resume it on a system with a NVIDIA GPU (or just old GPU
| and new GPU from same Vendor) is likely around the area of
| "lets treat it as impossible".
| rektide wrote:
| > _Anything else also would be insanely hard._
|
| checkpoint restore of gpu state is much further along than
| you credit.
| LadyCailin wrote:
| You mean for the same GPU? Or across GPU brands and stuff?
| davesque wrote:
| Almost impossible and also rather impractical. What each game
| should care about are the high level details of its game
| state. Things like "In what map am I located and at what
| coordinates?" The game engine for each game basically
| represents a compression algorithm of sorts to decode the
| meaning of a few concise details like that. If you prefer to
| represent that information with the raw bytes and bits of
| internal processor and memory state, you're choosing a hugely
| inefficient and clunky encoding.
| philo23 wrote:
| Yeah exactly, it's probably impossible even between different
| generations of the same brand of graphics card.
| initplus wrote:
| Perhaps I've misunderstood but my understanding was that
| suspend/resume on the deck itself is recording some low level
| state (locally). So you can reopen the deck and be right where
| you left off with no loading.
|
| But they also provide a hook so the game has a chance to save
| and sync to the cloud before being suspended, so the user can
| pick up from the same point on another steam device. Loading
| the game normally of course.
| shmerl wrote:
| I was thinking someone should develop a Wine-like layer for Linux
| ABIs themselves, translating more historic ones into modern ones.
| That will allow running old native games for a much longer time.
|
| In that sense I agree that Wine provides a benefit of
| preservation and very long term support that native Linux ABIs
| don't.
|
| I completely disagree about regular desktop applications though.
| Games use case is different becasue they are developed as one
| time project and game companies move to the next game abandoning
| support for the old ones in essence after a relatively short
| time. Such kind of programs need stable ABIs to be usable long
| term.
|
| Desktop applications on the other hand (like browsers for
| instance) are evolving and are actively developed continuously.
| They don't need Wine on Linux. I'd simply stay away form those
| desktop applications which are abandoned.
| homarp wrote:
| See previously "Gabe Newell Wants to Support Linux, Because
| Windows 8 is a 'Catastrophe'" -
| https://news.ycombinator.com/item?id=4293046
|
| Proton is nice, but still is a wrapper 'behind' what Microsoft
| can decide to do to make sure they are 'ahead'.
|
| From a strategic point of view, this is annoying for Valve. It
| makes more sense for Valve to try to get more SteamOS only games
| (and the Steam Deck should help with that), because they control
| that platform end-to-end (apart from manufacturing their CPU,
| it's close to what Apple does: Steam store + Steam hardware )
| mahkoh wrote:
| If developers start targeting proton, then Valve will be the
| gatekeeper that decides which windows apis get widespread
| adoption in games. Contrary to what the title says, proton will
| become the stable win32 api. Microsoft's distribution of the
| proton api could then be called "upstream" or "rolling
| release".
| pjmlp wrote:
| Proton doesn't do XBox.
| eternityforest wrote:
| Maybe Linux should just agree on a standard runtime like Steam
| has. That can be free and open and cross-distro, and be based on
| "API Levels" like anything else, so your app can target "API
| Level 27", and _always_ be usable because API27 never changes,
| you just make a level 28 next year.
|
| Eventually people would get tired of patching old ones, but at
| that point you just freeze them and have people use a VM to avoid
| the security holes.
|
| Windows has compatibility mode for older windows. And it's great.
| johnny22 wrote:
| that's basically flatpak, although flatpak runtimes are
| versioned by year.month
| Geezus-42 wrote:
| I could see Steam/Proton evolving into a sort of gaming
| specialized cross platform runtime.
| moonbug wrote:
| sure are a lot of parentheses in that.
| dm319 wrote:
| Might be a crazy idea - but what do people think of repository
| owners compiling from the source code? Like Valve / Canonical
| could do it and put out binaries. Obviously there would be
| agreements about the security/management of the source code.
| Maybe it could even be done cryptographically so that no source
| code needs to be visible outside some kind of building machine.
| nynx wrote:
| Every time a post like this comes up, I state this opinion:
|
| I fully believe that Windows will _eventually_ be replaced with a
| desktop environment running on top of the linux kernel.
| calvin_ wrote:
| Not because it'd be any good, but because it'd be cheaper for
| Microsoft.
___________________________________________________________________
(page generated 2022-02-27 23:00 UTC)