I still think Windows app compat for Linux (i.e. as Wine does and Valve productized with a gaming focus) is the better solution since it offers a true upgrade path out.
I realize ReactOS has a potentially wider useful scope (I think device driver compat is part of what they're attempting to do, so it'd offer a solution to keeping niche HW running) but I think it's just a smaller audience.
>it'd offer a solution to keeping niche HW running
Preservation. It ensures WinNT survives as a platform even if Microsoft abandons it, which some would argue the present state of Win11 counts as doing.
If MS abandons WinNT, then people will likely continue to use the existing versions of Windows which are out there for any existing software (just as people continue to use MS-DOS and Win 9x for old games and software).
As for new software - I think it's open to debate just how much new Win32 software will be created after a hypothetical abandonment by Microsoft of Windows.
Windows 11 is the enshitification late stage advertisement economy product that no one asked for, and everyone in the C Suite at Microsoft is excited about. Probably the only thing they are more excited for is yet another terrible branding decision.
i don't get this take. i've been on win11 since the closed "beta" (i think, it's been a real long time). i wrote guides on how to "fix" the most common and also tricky issues with the upgrade path from win10 to win11, as well as guides from 7/8 to winten.
however, i should note that i actually don't like windows 11 at all, but for different reasons. for the first two years or so, third party apps would crash to desktop if a folder had a literal "@"[0] in the name. That was patched on the "big patch" that a lot of people complained about, about 8-10 months ago.
Currently i have another issue, for brevity's sake, i'll just list these two. If i reboot, but don't log in, my computer will freeze. if i log in fast (within about 5 seconds of the login screen accepting input (enter, mouseclick, etc)), and get to the desktop, if i walk away, computer will freeze. My computer freezes (hard freeze, reset button/power button to fix) if it is idle. it's the silliest thing i've ever seen, surpassing even crashing with "@" in the directory name.
my fix? I run an idle game (nomad idle or idle pins) and that stops it from crashing forever. But once a month i wake up to a hard-locked computer because of an automatic update + reboot.
ugh.
[0] i think the newer windows terminal and/or the newer powershell API used to assume an "@" was something else, on powershell, it turns green and autofills stuff like "@Alias" and "@args". My assumption is they didn't sanitize it and let powershell hook everything when that's just silly. Windows 11 is silly.
Has anyone thought about making the linux kernel roughly compatible with NT? Like how FreeBSD is compatible with Linux? I know it'd definitely be harder as NT is proprietary but syscalls (in my very uninformed opinion) seem all that difficult to implement, even without a userland
At what level do you mean that? Kernel level? Driver level?
Wine[1] is the de facto compatibility layer with NT executables. Driver compatibility is too complex and obscure to worth the while. Often information is undocumented or hard to get.
There are a few implementations of windows behaviors at kernel level for a few subsystems features, ntsync, samba, ntfs, etc. they can be used by wine to improve compatibility or performance
FreeBSD is not "compatible with Linux", it provides a way to run Linux applications under a Linux-like syscall environment. What you're suggesting is as if you could load Linux kernel modules into the FreeBSD kernel.
The issue with NT is the driver ecosystem. You'd have to reimplement a lot of under-documented NT behavior for NT drivers to behave themselves, and making that work within the Linux kernel would require major architectural changes. The userland is also where a lot of magic happens for application compatibility.
Me as a kid thought this would be a great idea, and started implementing a PE binfmt. I actually did make a rudimentary PE binfmt, though it started to occur to me how different Windows and Linux really were as I progressed.
For example, with ELF/UNIX, the basic ELF binfmt is barely any more complex than what you'd probably expect the a.out binfmt to be: it maps sections into memory and then executes. Dynamic linking isn't implemented; instead, similar to the interpreter of a shell script, an ELF binary can have an interpreter (PT_INTERP) which is loaded in lieu of the actual binary. This way, the PT_INTERP can be set to the well-known path of the dynamic linker of your libc, which itself is a static ELF binary. It is executed with the appropriate arguments loaded onto the stack and the dynamic linker starts loading the actual binary and its dependencies.
Windows is totally different here. I mean, as far as I know, the dynamic linker is still in userland, known as the Windows Loader. However, the barrier between the userland and kernel land is not stable for Windows NT. Syscall numbers can change during major updates. And, sometimes, implementation details are split between the kernel and userland. Now, in order to be able to contribute to Wine and other projects, I've had to be very careful how I discover how Windows internals works, often by reading other's writings and doing careful black box analysis (for some of this I have work I can show to show how I figured it out.) But for example, the PEB/TIB structures that store information about processes/threads seems to be something that both the userland and kernel components both read and modify. For dynamic linking in particular, there are some linked lists in the PEB that store the modules loaded into the process, and I believe these are used by both the Windows loader and the kernel in some cases.
The Windows NT kernel also just takes on a lot more responsibilities. For example, input. I can literally identify some of the syscalls that go into input handling and observe how they change behavior depending on the last result of PeekMessage. The kernel also appears to be the part of the system that handles event coalescing and priority. It's nothing absurd (the Wine project has already figured out how a lot of this works) but it is a Huge difference from Linux where there's no concept of "messages" and probably shouldn't be.
So the equivalent of the Windows NT kernel services would often be more appropriate to put in userland on Linux anyways, and Wine already does that.
It would still be interesting to attempt to get a Windows XP userland to boot directly on a Linux kernel, but I don't think you'd ever end up with anything that could ever be upstreamed :)
Maybe we should do the PE binfmt though. I am no longer a fan of ELF with it's symbol conflicts and whatnot. Let's make Linux PE-based so we can finally get icons for binaries without needing to append a filesystem to the end of it :)
I mean something a bit different. I mean using PE binaries to store Linux programs, no Wine loader.
Of course, this is a little silly. It would require massively rethinking many aspects of the Linux userland, like the libc design. However, I honestly would be OK with this future. I don't really care that much for ELF or its consequences, and there are PE32+ binaries all over the place anyways, so may as well embrace it. Linux itself is often a PE32+ binary, for the sake of EFI stub/UKI.
(You could also implement this with binfmt_misc, sure, but then you'd still need at least an ELF binary for the init binary and/or a loader.)
(edit: But like I said, it's a little silly. It breaks all kinds of shit. Symbol interposition stops working. The libdl API breaks. You can't LD_PRELOAD. The libpthread trick to make errno a thread local breaks. Etc, etc.)
Wine has no problem loading Linux programs in PE format. It doesn't enforce that you actually call any Windows functions and it doesn't stop you making Linux system calls directly.
Well yes, but you'd be spawning a wineserver and running wineboot and all kinds of baggage on top, all for the very simple task of mapping and executing a PE binary, and of course you would still wind up needing ELF... for the Wine loader and all of the dependencies that it has (like a libc, though you could maybe use a statically-linked musl or something to try to minimize it.)
Meanwhile the actual process of loading a PE binary is relatively trivial. It's trivial enough that it has been implemented numerous times in different forms by many people. Hell, I've done it numerous times myself, once for game hacking and once in pure Go[1] as a stubborn workaround for another problem.
Importing an entire Wine install, or even putting the effort into stripping Wine down for this purpose, seems silly.
But I suppose the entire premise is a little silly to begin with, so I guess it's not that unreasonable, it's just not what I am imagining. I'm imagining a Linux userland with simply no ELF at all.
[1]: https://github.com/jchv/go-winloader - though it doesn't do linking recursively, since for this particular problem simply calling LoadLibrary is good enough.
I recently learned that Windows binaries contain metadata for what version they are (among other things, presumably). I was discussing in-progress work on making a mod manager for a popular game work on Linux with the author of the tool, and they mentioned that one of the things that surprised them was not being able to rely on inspection of a native library used by most mods to determine what version they had installed on Linux like they could on Windows. It had never occurred to them that this wasn't a first-class feature of Linux binary formats, and I was equally surprised to find out that it was a thing on Windows given that I haven't regularly used Windows since before I really had much of a concept of what "metadata in a binary format" would even mean.
Are you talking about the "Linux version" it targets or the version of the library? If its the latter, then it is the case, that versioning works per symbol instead of per library, so that a newer library can still contain the old symbols. If you want the latest version a library implements, you could search all symbols and look for the newest symbol version.
If you want it the other way around you could look at the newest symbol the library wants.
I probably could be more clear about what I'm trying to convey. Tool A is written to manage mods for game B, and lots of mods for that game utilize library C. Tool A does not directly load or link to library C, but it does inspect the version of library C that currently exists alongside game B so that it can detect if mods depend on a newer version of it and notify the user that it needs to be updated.
I'm realizing now that I forgot an important detail in all of this: the metadata of the library existed as part of the metadata that the filesystem itself tracked rather than something in the contents of the file itself. This metadata doesn't seem to exist on Linux (which library C only supports if running via Proton rather than any native Linux version of the game). I could imagine it might be possible for this to be set as some sort of extended attribute on a Unix filesystem, but in practice it seems that the library will have this extended filesystem metadata when downloading the DLL onto a Windows machine (presumably with an NTFS filesystem) but not a Linux one.
> so that it can detect if mods depend on a newer version of it and notify the user that it needs to be updated.
The dynamic linker will literally tell you this, if you ask it.
> the metadata of the library existed as part of the metadata that the filesystem itself tracked rather than something in the contents of the file itself.
So does this metadata has anything to do with the file at all, or could I also attach it to e.g. an MP4 file? If that is the case than the difference is that the distributor for MS Windows did add the attribute and the distributor for GNU/Linux did not, it doesn't have anything to do with the platform.
EDIT:
> (which library C only supports if running via Proton rather than any native Linux version of the game
So library C isn't even an ELF shared object, but a PE/COFF DLL? Then that complaint makes even less sense.
I assume it's the ability to tag a .dll as version 0.0.0.1 or whatever (it shows up under the file name in Windows Explorer). I think company name is another one that Windows Explorer displays but there are probably a few other supported attributes as well.
Well, then the answer is that shared objects on GNU/Linux do not have a finite version, they just implement them. This is because they are expected to implement more than one version, so that you can just update the shared object, and it will still work with programs that expect to call the old ABI. You can however get the latest version. This is also what is in the filename. Note, that there are two versioning schemes: semver and libtool, they mean the same, but are notated differently. This version does not does not necessary equal the version of the project/package, APIs/ABIs can and do have their own version numbers.
I think this is just solving a different but related problem. Symbol versioning enables you to make observable changes to the behavior of some library like a libc while providing backwards compatibility by providing the old behaviors indefinitely. I've never gotten the impression that it is "prescribed" that shared objects on a Linux system don't have a specific/definite version, and I don't think that symbol versioning is necessarily appropriate for all programs, either-it just happens to be a mechanism used by glibc, and I don't think it is very common outside of glibc (could be wrong.)
On the other hand, the Windows NE/PE VERSIONINFO resource is mostly informational in nature. I think early on in the life of Windows, it was often used to determine whether or not the system library shipped by an installer was newer than the installed version, so that program installers could safely update the system libraries when necessary without accidentally overwriting new versions of things with older versions. That's just simply a problem that ELF shared objects don't try to solve, I reckon, because there aren't usually canonical binaries to install anyways, and the problem of distributing system libraries is usually left up to the OS vendor.
Actually though, there is another mechanism that Linux shared objects often use for versioning and ABI compatibility: the filename/soname. Where you might have a system library, libwacom.so.9.0.0, but then you also have symlinks to it from libwacom.so.9 and libwacom.so, and the soname is set to libwacom.so.9.
There is, of course, no specific reason why ELF binaries don't contain metadata, and you could certainly extend ELF to contain PE-style resources if you want. (I remember some attempts at this existed when I was still getting into Linux.) It may be considered "bad practice" to check the runtime version of a library or program before doing something, in many cases, but it is still relatively common practice; even though there's no standard way to do it, a lot of shared objects do export a library function that returns the runtime version number, like libpng's png_access_version_number. Since distributions patch libraries and maybe even use drop-in replacements, there is obviously no guarantee as to what this version number entails, but often it does entail a promise that the ABI should be compatible with the version that is returned. (There is obviously not necessarily a canonical "ABI" either, but in most cases if you are dealing with two completely incompatible system/compiler ABIs there isn't much that can be done anyways, so it's probably OK to ignore this case.)
So I think the most "standard" way to embed the "version" of a shared object on Linux is to export a symbol that either returns the version number or points to it, but there is no direct equivalent to the PE VERSIONINFO standard, which may be a pain when the version number would be useful for something, but the developers did not think to explicitly add it to the Linux port of their software, since it is often not used by the software itself.
But I personally wouldn't agree with the conclusion that "shared objects on GNU/Linux do not have a finite version" as a matter of course; I think the more conservative thing to say is that there is not necessarily a definite version, and there is not necessarily a "canonical" binary. In practice, though, if your copy of libSDL is an almost-unmodified build of the source tree at a given version 3.0.0, it is entirely reasonable to say that it is "definitely" libSDL 3.0.0, even though it may not refer to an exact byte-for-byte source tree or binary file.
That would require (among many other things) a stable driver API -- one of the things NT gets right and linux is wrong on. Linus has been quite clear that he does not see things this way. So ... not going to happen
Is money the issue for this project, or finding the right people?
Or another point of view, if you put a lot of money into it, it becomes a commercial endeavour - would it still be for a good cause?
More armchair internet commenter devil's advocate discussion starters than any opinions of mine to be honest. But, there's a lot of projects that would benefit from no-strings-attached donations.
As far as I can tell, the nearest thing to a stated goal or mission is on their “About” page:
Our main features are:
* ReactOS is able to run Windows software
* ReactOS is able to run Windows drivers
* ReactOS looks-like Windows
* ReactOS is free and open source
Building a replica of an old OS is a fun project, but if there was a purpose for it besides having an "is able to" replica, it would attract more people.
in the real world, most people use windows. most software that those people use is written for windows. if it can run windows exes out of the box, whilst not phoning home to microsoft, it becomes an attractive proposition. i want to get off windows but i dont want the headache of linux; to me its the only hope
Sure, but Windows has moved a long ways since the version that they're attempting to replicate. And again, their bar for success "is able to run Windows programs" is not actually high enough to achieve a practical Windows replacement, even if going back to Windows 95 is all we wanted.
It's interesting you mention Linux being a headache — it is, but there is an order of magnitude more people working full-time on just the Linux desktop experience than have ever even tried running ReactOS. That ratio would have to flip before the latter has a hope of being a useful Windows replacement. We’re much more likely to see Wine able to run 100% of Windows before ReactOS gets there.
> And again, their bar for success "is able to run Windows programs" is not actually high enough to achieve a practical Windows replacement, even if going back to Windows 95 is all we wanted.
how no?
> It's interesting you mention Linux being a headache — it is, but there is an order of magnitude more people working full-time on just the Linux desktop experience than have ever even tried running ReactOS
and hows that going these days? still a nightmare? basic functionality introduced maybe 50 years ago now, and the linux world is still working out the kinks with GUIs, probably part of the reason TUIs are becoming popular.
I suspect this would be a very risky proposition for them. The expense would be enormous, so it would either need to be a player with such huge economies of scale to make it work, or it would have to be a collection of businesses that in aggregate could make it economically feasible. I would suspect in most cases, it would be a lot cheaper to just port your software to modern Linux than to try to get react OS over the line. And that's before considering that a lot of the large players will be in contract situations with Microsoft that likely directly prevent this sort of thing
Valve has already proven that one moderately-sized corporate contributor added to your moon-shot FOSS project can get you places. (And Valve isn't anywhere near in size for the FANG+ corps you listed)
but why would any of those companies want to use ReactOS? They already build on top of Linux, except maybe Microsoft, but certainly Microsoft wouldn't want to fund ReactOS...
If I were an executive at those places and somebody proposed ReactOS to replace our foundation, I'd assume they were joking/trolling and would laugh (and genuinely find it funny)
There's still a ton of critical, often custom-written (read: hard to replace), corporate Windows software out there that still needs to run. If Microsoft continues their further decline of Microsoft Windows releases then a free alternative starts to look more attractive. Linux+Wine is definitely a good option today but compatibility shims add complexity and not all shops run Linux or want to.
i just want to program my old motorola radios without having to deal with virtualbox windows 98 VMs, you know? one can transcribe "motorola radio" for "bosch end mill from 1993" or "thermoplastic former from 1999"
who said they need to use reactOS or "replace their foundation", which is a term i cannot parse, i don't think anyone wants to use this as a server platform (that was my default assumption of that phrase.)
this is "we have a market cap of 61,271,506 times the median household income in the USA, we can afford to peel off 1/500,000th (0.0002%) of our market cap per year to make this project awesome because we like this project and want to see it grow"
Well if that's the case, then what you're arguing for is charity. That's fine, but the upthread topic has been about business case. If we're looking at it as charity and not a business investment, then it's a much different conversation. I'd certainly love if companies did things like this and would highly applaud it.
There's a sponsorship section but it just links to the donate page rather than a corporate focused sponsorship program. It seems most of the corporate activity in this space is around userspace compatibility rather than NT kernel compatibility, like CrossOver or Valve driving Wine and other codebases in that regard.
I'll throw in a few of the billions I made when I read this paper by "Satoshi Nakamoto" in 2009 and decided to turn over my dozen SETI@home machines to mining his imaginary internet money.
I wanna sponsor 9front. Merge in whatever we can salvage from Inferno, make a 64-bit Dis runtime, and Inferno's version of Rio which is a lot more comprehensible.
I want a VM that can run diskless Linux microVMs so I can just run a Linux binary and have it open and display a GUI in a new Equis window.
Ladybird has quite a few corporate sponsors now and is progressing quite well. I built and tested the latest sources over the winter break and it sort of works already. I posted on HN from it.
It is unfortunate it doesn't even run on SerenityOS anymore.
This does at least partially eliminate the appeal. e.g. SerenityOS has its own decoders for PNG, JPEG and other image formats and they are not bad, but the boring libpng, etc. were adopted instead.
It should be a net positive if not everybody uses the same implementations of everything.
