The Secret Feature of EM-DOSBOX on Internet Archive | Hacker News Reader

The Secret Feature of EM-DOSBOX on Internet Archive

ascii.textfiles.com

146 pointsjosephscott36 comments

Em-DOSBox is incredible. I'd previously wondered if it might be possible to run DOSBox in the browser with emscripten, but there seemed to be nothing working out there. Then the Internet Archive started hosting DOS games, and I wondered what they were using, thus I found Em-DOSBox.

At the same time, I was getting a bit of nostalgia for Windows 95, the first upgrade to Windows I ever used. And it turns out with a bit of fiddling you can run Windows 95 in DOSBox and have it mostly work.

Thus http://win95.ajf.me/ was born. Windows 95 running in the browser. It's still rather unbelievable. You can listen to CANYON.MID on an emulated Sound Blaster 16!

(Unlike the Internet Archive's games, this doesn't do any saving to local storage, sorry. I'm not sure it practically could, because it's not using a fake filesystem mapped to fopen() calls by intercepting DOS system calls, as DOSBox typically does, but rather DOSBox is giving Windows 95 a real disk image, so you'd have to stuff 131MB into localStorage.)

Things like this just make my mind spin when contemplating the number of layers invoked to get it working.

an OS running inside DOSBOX compiled to JS deliver over HTTP/TCP/IP to be interpreted by a browser (at this point perhaps a OS in its own right) running on top of a OS on top of a CPU.

It really feels like we are back in the leased terminal era...

Every few months someone finds a way to put another turtle on top, and some of those attempts stick.

Wonder if it would work in iOS Safari running on the iOS simulator ...

Yep! And you can even run DOS apps inside Windows 95, so you can have Virtual 8086 Mode inside your virtual x86 CPU (DOSBox) inside your JavaScript virtual machine, inside a sandbox...

Disk access here is fun through the sheer number of layers. Consider a DOS prompt inside 95. When a DOS application tries to perform an I/O operation, it will make a DOS system call. DOS, in turn, will call the BIOS. This BIOS call will be intercepted by Windows 95 which, since it has no 32-bit disk driver (DOSBox doesn't simulate a real disk controller), will pass it on to DOS (the one underlying 95), which in turn will make a BIOS call. Everything before this point has been under DOSBox's x86 emulation. We then go through to the C++ fake BIOS of DOSBox, which handles the BIOS call by calling the C standard library I/O functions. However, those have been replaced by emscripten's shims, which will grab that data from the asm.js heap somewhere (or does it ferry it out to JS? I'm not sure.)

And DOSBox itself has been compiled to asm.js (which your browser may compile to machine code through JIT) and is running in your browser's JS VM. Which, if the browser you're using is on Windows, may be a 32-bit version, which is running under Windows's WOW64 (Windows 32-bit on Windows 64-bit)...

The layers never end!

http://i.imgur.com/lcZZ5YU.png

Reminds me of The Birth and Death of Javascript: https://www.destroyallsoftware.com/talks/the-birth-and-death...

You might be able to just store the sectors that have been modified in localStorage, loading the unmodified ones from the original template.

It's working really slow even on my own, pretty fast, computer.

But then, I am running Windows in DOSBox in JavaScript. I have no right to complain.

edit: welp, now I tried to run Internet Explorer 3.0 on the machine and it never finishes running, maxing out at 100% CPU and Chrome then wants to kill the tab.

And on Firefox, it crashes with "uncaught exception: SimulateInfiniteLoop". Well, it's not perfect!

Well, it's not infeasible. We don't use localStorage -- we use IndexedDB, which can store gigantic files. But I've never tried stuffing 100+MB into IndexedDB before.

(Sidenote: I'm the author of the BrowserFS library, and helped implement this feature.)

Keeping a copy of the disk around might actually be a good idea, as that means the browser has to hold on to it. I've found that in practice, Firefox and Chrome never hung onto the disk image in their cache.

I think your work is amazing and you should link to it: https://github.com/jvilk/BrowserFS

I can't believe the nostalgia. It's not just bringing back good memories, it's actually making me feel like I'm 16 again, in my old room, with all my old things around me.

It's amazing how much I'd associated the Windows 95 startup sound with that room... Thanks for that.

EDIT: Hey, can I mount win95.data on DOSBox locally? Do you know the command line?

The file is an emscripten package, I don't know if it's possible to extract it. If you want to try 95 on your local machine, I'd grab the install CD ISO from somewhere and use it in a proper virtual machine. Probably not VirtualBox, since it emulates graphics hardware 95 can't handle (so you're stuck at 640x480 at 4bpp) and lacks MIDI emulation (no music).

You could also try to run Windows 95 in DOSBox itself, just like this page does, but unfortunately DOSBox has a few issues with it. There are tutorials out there for doing it, though, and DOSBox supporting the right graphics and sound hardware is a big plus.

Thanks for the information! I tried installing it in DOSBox and VirtualBox with no luck. Which emulator would you recommend?

You couldn't get it to install in VirtualBox? That's strange. Are you sure you were using a bootable ISO?

Setup would just randomly hang in places, I'm afraid. The ISO booted fine, and I disabled VT-x, so that's not it either...

EDIT: Managed to get it running in the end, these two guides helped:

http://eduardprogramming.blogspot.gr/2014/01/20140120-window...

https://forums.virtualbox.org/viewtopic.php?t=9918

Windows 95 in a browser? What a time to be alive..

I tried loading up Internet Explorer (3.0!) but it crashed the whole thing. This thing is very accurate.

Something that most emulators have failed to achieve (and that the Start9 project[1] aims to fix) is the user experience. It's great to have a working emulator, but it's even better to have an emulator that doesn't have a learning curve bigger than the everest. It won't work if we ask our users to download things from the internet (often from third-party websites), especially if they're shipped with adwares (as it happens with some official emulators), or require third-party plugins (remember EPSX?), or don't have any easy screen sharing features, or ... Things like what the article is about are a small step in the right direction.

[1] http://start9.io

There's a free service called Console Classix where you can download their app, and it gives you a large library of games for retro consoles you can just click and play straightaway:

http://www.consoleclassix.com/

I've used it before, it's a pretty good experience. You have to pay to be able to play non-NES and Colecovision games, though.

They justify the obvious copyright violation by only letting you play games they have physical copies of, and not letting more people play concurrently than they have cartridges. This... doesn't really avoid the copyright issues, but they do it anyway.

> They justify the obvious copyright violation by only letting you play games they have physical copies of, and not letting more people play concurrently than they have cartridges. This... doesn't really avoid the copyright issues, but they do it anyway.

We found this service before creating Start9, and considered using the same thing. We talked to a lawyer before, who advised us not to do it, and fallbacked on letting people upload games that they are able to according to their local regulation (usually, games they dumped themselves), and forbidding them to lend their accounts to their friends.

It's 100% legal, but unfortunately it's still hard for some users to understand why this limitation exists. What I would love to do would be to have kind of a deal with game publishers, but as a single man currently working on the project, I don't the time to contact these studios (especially since most of them have closed since the games have been released, or are under Nintendo's copybag, which won't be ever available to third-parties such as ourselves).

If you have a Mac, OpenEmu is the best console emulation experience I've ever had.

http://openemu.org

http://retrospec.sgn.net/game/hyperspeed

>Of course you can’t save your games! They’re not some actual thing playing on your operating system. They live inside a window...But we got a lot of complaints about it...So we fixed it.

Great example of usability winning out over technical purity here. Just because something is behaving as we expect it to doesn't mean it can't be changed to make the experience better for everyone.

Your point isn't wrong, but there was no "technical purity" motivation for not implementing it from the start. It's just difficult to do well, so we only implemented the easy case (DosBox), and only the easiest of the easy cases (only one saved filesystem, no disk swapping, no ui, etc).

It's the same as printing. Everyone writes hilarious complaints in the comments on the word processors about how printing didn't work. Of course you can't print! It's an emulator running in JS in your browser!!!1! But we have ideas for how to implement it, so maybe one day it will work after all.

Saved games and networking are higher priority and are further along though.

Ah, I was assuming there would be a kludgy hack to bridge between the emulator's filesystem and localStorage on the browser.

Fear not, there are in fact some kludgy hacks in there. The BrowserFS stuff is really clean though, and since DosBox is written in C and uses the normal POSIX file api (DosBox thinks it was compiled for Linux), plugging the two together was pretty easy.

Can the LocalStorage API be used to store supercookies and thus track users?

It's a persistent storage API, so yes. Browsers usually offer the option to clear localStorage alongside cookies, though.

Since you can clear it it's not a supercookie.

Maybe I'm not enough into the details, but from my perspective it seems as it should be very normal to save things in an emulator. It should not just be possible by default it should be much better than in the original, since we control how we set up the emulator. E.g. I would expect a game that had 3 saving slots to have 1 mio now. I would expect that these files would be stored in my host file system in a way that I can back it up and sync it via dropbox and github. Is that really that uncommon?

I mean, there are people who hack games that should not be modified and change the userinterface etc. We should have enough control over our virtual machines to let them do anything.

The comment in TFA about exporting the saved game data via URL is a great idea. Imagine being able to send someone to a specific point in a videogame by URL or share an old Wordperfect document, including the content, via a huge URL.

Depends on the browser but there's usually a 1k character limit which isn't a great deal of state. Perhaps that's counted badly so you can get 1000 char * 4 bytes for unicode, but I wouldn't bet on it being handled the same in different browsers anyway.

It wouldn't work. Most browsers have a limit of about 2000 characters. Assuming a base64 encoding, it means you have about 1K of available data (since most saves have a power-of-2 size), far from being enough for any real game (especially if you want a save state, instead of an actual save - that would require to store the entire emulator state, which are at least a few megabytes tall).

State could be stored to something like Amazon S3 and referenced using a unique ID, which would then become part of the URL given to the user.

BrowserFS actually supports Dropbox integration already... so you could do the same with a Dropbox shared folder.

(Sidenote: I'm the author of BrowserFS, and helped implement this feature.)

I suppose that's true. But, remember, a lot of old console games used passcodes instead of saved states. So for some of this, it might actually work!

Reply on news.ycombinator.com