So I’m curious - what’s stopping anyone from getting Linux, ReactOS or any desktop OS really from running purely client side using WASM?
From retro gaming to opening legacy files to safely testing out binaries, seems like a lot of personal use cases. I can imagine tons more for companies.
Is it performance? Missing features?
I don't think it's running in WASM, but I think it's linux in your browser.
If you want to run Linux on your Windows or MacOS machine, use something like VirtualBox.
No real reason to do so. Also it is pretty complex and anything at least modern requires ~GBs of data. There was a link here to the 'browsered' OpenOffice recentl and many said it didn't load for them, despite not a big for the most size of ~150MB. And if you dload it first, run a local server to handle it... what's the point then?
Also you can always run your whatever in whatever virtualization platform, you just need to find a way to connect to it in the browser, eg with Apache Guacamole or smth similar.
I recall when the golang folks were building the golang playland. Many similar issues. I think it's just hosted on server now.
https://archive.org/search.php?query=emulator%3Apsx
You could try Linux on 90s hardware though. A 486 or even a Pentium might be doable.
But even with Greenfield, getting things rendering & drawing is going to be a big challenge. Total Annihilation probably runs an old directx for graphics. We'd need some way to support that.
There's projects like DXVK[2] and VKD3D[3] to run directx 9/10/11 and 12 atop Vulkan. These are probably too new for a classic like Total Annihation, but would support many games. Yet, the web doesn't have Vulkan- it has a similar but different/less capable WebGPU. Perhaps someone could craft/hack-out another adapter layer, a Vulkan-atop-WebGPU translator, that could be stacked up. Or we could build WebGPU backends for these adapters. This is a pretty non-trivial effort. It's notable that projects like wgpu exist to provide a cross platform support for WebGPU, so if one were to build a DirectX-on-WebGPU translator, wgpu would let that game run on basically any platform: it'd be way cool. But again, that sounds like hella work.
There's a ton of other technical problems. Huge challenge #2 is that most games are precompiled for x86. Ideally we'd need to recompile them for webassembly, but it's unlikely many games would ever get ported. They could run at radically reduced speed via some machine-translation and games like TA might even work ok that way, given how much faster even a cellphone is than the pentium166 i rocked TA out on.
Challenge #3 is platform. These games rely on an native platform support for files, sockets, and dozens of other event loop & other concepts. Given time & effort, doubtless many of these could be platform libraries could be re-implemented. Projects like UMass's Browsix[4] purported to create similar platform libraries web-natively, creating a Linux-y/POSIX-y environment in the browser. This could perhaps be mated to something like Emscripten to expand the platform offerings significantly. Emscripten itself has adjacent projects for some platform support. Oh, wow, TIL it has OpenGL->WebGL conversion layers: some games could concievably be recompiled with emscripten without too too much fuss & work. But this would not be a Linux desktop, it would be just the game, in a canvas. There are projects such as QuakeJS[5] that appear to do just this!
The web itself is evolving many similar-ish capabilities for this #3. WebTransport is a better WebSocket that comes closer to being a viable network layer, and one day may perhaps, if we're all really really lucky, become a transport for WebRTC as well (fingers crossed). There are various File System API and File System Access API proposals going around for talking to files, which are only kind of semi needed, as a virtual filesystem is probably fine.
[1] https://github.com/udevbe/greenfield https://news.ycombinator.com/item?id=29239781 (71 points, 3 months ago, 26 comments)
[2] https://github.com/doitsujin/dxvk https://news.ycombinator.com/item?id=16199332 (216 points, 4 years ago, 51 comments)
[3] https://wiki.winehq.org/Vkd3d
[4] https://browsix.org/ https://github.com/plasma-umass/browsix many popular discussions, 5~6 years ago: https://hn.algolia.com/?q=browsix
[5] http://www.quakejs.com/ https://news.ycombinator.com/item?id=22797060 (357 points, 2yr ago, 158 comments)
What you could port is the GNU userspace (which is probably closer to what you're thinking.) One of the issues with porting software like that though is it expects complete control over its own process (and will put eg long running loops in it) which isn't how browsers expect software to run. Maybe you could do something fancy with continuations in the C runtime (emscripten probably already does) but it wouldn't be so strait forward.
I'm not sure what advantage having a shell in the browser would have over just running the individual apps as webasm ports. There's less to worry about then.
>retro gaming and opening legacy files
I don't think a webasm OS port makes as much sense for these use cases as a webasm VM. There are plenty of those: jslinux.org gives you a full Linux VM with an optional paid file sync service and internet access. Archive.org automatically opens com/exe files in the emscripten dosbox port, you can even run Windows 3.1: https://archive.org/details/msdos_win3_1
It would be kind of neat if more open source software had online "try me" pages that let you run the app in eg jslinux or dosbox before downloading and installing it.