4 ms·
those written for e.g. Linux will likely cease working in a decade or two Have we already passed the era of DON'T BREAK USERSPACE when Linus would famously lou
by userbinator 1y ago
those written for e.g. Linux will likely cease working in a decade or two
Have we already passed the era of DON'T BREAK USERSPACE when Linus would famously loudly berate anyone who did?
I suspect Win32 is still a good target for stability; I have various tiny utilities written decades ago that still work on Win11. With the continued degradation of Microsoft, at least there is WINE.
- szundi 1y ago[dead]
- wolvesechoes 1y agoI would love ReactOS to succeed.
- Imustaskforhelp 1y agoIf I remember correctly, ReactOS just uses wine under the hood. Which can be used in linux and even mac or bsd too. Basically (compile to windows?) seems like a good enough tradeoff to run anywhere, right? But I prefer appimage or flatpak because of the overhead that wine might introduce I suppose
- wolvesechoes 1y ago> If I remember correctly, ReactOS just uses wine under the hood Nah. I think they share some effort and ReactOS team adds patches to WINE codebase, it is a separate thing.
- atq2119 1y agoNo, the issue in Linux is that userspace has traditionally had a tendency to break itself.
- cookiengineer 1y agoYou can account for that by using Go, with CGO_ENABLED=0. Then you have a self contained binary that relies solely on the POSIX syscalls.
- dpassens 1y agoLinux syscalls. There's no such thing as POSIX syscalls because POSIX defines a C interface.
- cookiengineer 1y agoYou're right that POSIX doesn't specify syscall tables. What I wanted to point out is that Go also supports BSDs and other kernels out of the box that implement the POSIX standard, though with slightly different syscall tables and binary formats on those target platforms and architectures. I was referring to POSIX as a standard specification, because it also includes not only Linux's syscall table, but also various other things that you can typically find in the binutils or coreutils package, which Go's stdlib relies on. See [2.1.3] and following pages. I guess what I wanted to say: If I would bet on long term maintenance, I would bet on POSIX compatibility, and not on one specific implementation of it. [2.1.3] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/ https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
- jwrallie 1y agoI am considering learning Win32 for that purpose, not that I plan to do anything complicated with it, but for small single purpose tools it should be useful, at least when some kind of UI is needed.
- rerdavies 1y agoDon't do it! Seriously! Terrible awful stuff to use. Even worse to program for!
- SkiFire13 1y agoThe kernel doesn't break userspace, but userspace breaks itself quite often.
- deleted 1y ago[deleted]
- whizzter 1y agoWhile the early core win32 parts are still fine, much COM based stuff will probably be a pain in the future. It's not direct breakage per-se (API's were generated from definition files and there was an encouragement to build new API versions when breaking API's), the issue will be that many third party things were to be manually installed from more or less obscure sources. Your Office install probably introduced a bunch of COM objects. Third party software that depended on those objects might not handle them being missing. I think I took some DOS-like shortcuts with some of my early DirectDraw (DirectX 3 level?) code, afaik it doesn't work in fullscreen past Windows Vista but _luckily_ I provided a "slow" windowed GDI fallback so the software still kinda runs at least.