It would explain why time seems to go by so slow when a person is bored: Not many people want to watch that simulation, so lack of CPU cycles slows everything down.
I always hoped we were running in a VM written in Rust rather than python or javascript. But it's hard to explain the platypus with a rust based one...
Yes, 0:00-29:23. The point of the talk is not laid out during a single moment; it's more like a story that unfolds over time, allowing the reader to understand its implications bit by bit.
I worked on the emscripten/wasm build of boxedwine. I can answer some questions.
The project has been around in some form for 9 years. It was originally in java, then straight c, now c++. Main author previously worked on jdosbox. I previously ported jdosbox to become jsdosbox (via GWT) a decade ago.
Runs horribly on macOS Firefox but, does indeed run at 60fps in Chrome with audio turned off. I wonder why the audio is such a problem? I'd think that audio wouldn't be that expensive even in an emulated environment.
I have no idea of the details as to why, but in all the years I've used emulators, turning off the audio has always increased the speed of emulation in emulators that are struggling.
I realize Wine is not an emulator...but...same shit.
The WASM build uses the 'normal' CPU core. In this core the CPU emulator is a collection of indirect calls that performs poorly in WASM due the runtime checks to verify the number of parameters and their types.
For other builds there is a dynamic code generator. A similar approach would work wonders. Assistance gratefully accepted! - see source folders under emulation/cpu for armv7, armv8 & x32 for the 30 odd method implementations.
To get native like performance a binary translator like that used for the x64 core is required
It's Wine running on Linux (which I gather from a quick look is not the actual kernel, but an minimal self written stub enough to run Wine. Is this correct?) which itself is running in an emulator, compiled into binaries for Window, MacOS, Linux and web.
Yes, the goal of Boxedwine is to run old Windows programs in a platform independent way without a VM or disk images. So basically it is Dosbox but for Windows. At first I started out writing my own Win32 API implementation, and it worked for the first couple of games. But eventually I saw it was more than 1 person could do. That is when I realized Wine was the only solution and since that only worked on Linux, I had to create minimal Linux emulator to run Wine. Implementing the kernal syscalls did take some time. But It is capable to running emulated threads and processes in a single threaded app, which is why it works with Emscripten.
Just like Wine, Boxedwine won't work with games that have CD checks. If it is just trying to find the CD in order to play a video off of it or grab a large file it didn't install, that might work, but only if the code isn't making sure its a real CD device. Seems like my UI should be able to handle the user dragging an installer into it from a CD where the CD will be used again. For that to work it would need to copy the CD and mount it internally so that the program can find it again while running. Right now I don't do that, but I think that would be a useful enhancement that isn't too hard to do.
As for the Putt-Putt, that has the look of flash or Adobe Air. I know that things like Java, and .Net don't work yet in Boxedwine, so if it is doing any kind of JIT then it won't work. I added that to the list of games I should look at.
You got pretty unlucky if you only tried 2 older games like that and neither worked.
I did get them working and playable some time ago on Linux using Wine though (my little brother likes to play them still, except he can't get used to Linux), even though they ask for CD-rom.
The Putt-Putt game is using some custom click 'n play Python2 based "SCUMM" engine, it doesn't require Java or .NET iirc. And I think they predate JIT a bit.
If someone releases an old Windows app for Mac and Linux using this and Electron I hope a story about it reaches HN. It'd be the ultimate combination of tech we love to hate. :)
> A while ago I was pondering getting emscripten working under Wine, but realised that it's not quite as simple as a typical program (because Wine relies on being able to just provide a compatibility layer for syscalls, so the compatibility layer for x86 would have to be provided by the port to emscripten).
> Seeing this post, I wondered if you'd found some cunning way around this so downloaded the project. No, you've just gone straight ahead and implemented an x86 emulator! Ok, but how is wine able to run on bare metal? Oh right, you've actually implemented parts of linux, including most of the syscall interface, your own executable loader, parts of procfs and assorted special devices! Alright, but (as Alon asks) how does this actually render things? Ah I see, you've implemented your own display driver in Wine which, when methods are invoked, dispatches interrupts to the emulated CPU which then forwards and translates the interrupt to an equivalent sdl call (with opengl working a similar way, but with a dll)!
BoxedWine does OpenGL passthrough on platforms where available.
This does not extend to the WASM/WebGL, but I really tried! I was able to get it working for some simple OpenGL applications with help from gl4es, but was unable to make it work with textures beyond one example [1].
I would appreciate some assistance if anyone has the required skills.
The project running on browser is not the main point. It can run standalone, and is mostly used to run old games that no longer work well on modern hardware / windows. Heck you can even use it on Linux.
I think the coolest part of the project is that it makes wine very portable though. Boxedwine seems like it could run on android as well for example.
ReactOS is a full OS, so it needs to run in a VM which requires disk images. Boxedwine emulates everything it needs and can use the users file system directly. So you can just drag a setup or game that doesn't require installation right into the UI and it will work.
Yeah, I implement a good amount of the kernel syscalls that Wine needs. It was easier for me to implement the 200-300 Kernel calls, like open file, etc, than implement the entire Windows API, which is why I used Wine for this project.
