
The Secret Feature of EM-DOSBOX on Internet Archive - josephscott
http://ascii.textfiles.com/archives/4924
======
TazeTSchnitzel
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/](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.)

~~~
digi_owl
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...

~~~
TazeTSchnitzel
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](http://i.imgur.com/lcZZ5YU.png)

~~~
MrRadar
Reminds me of The Birth and Death of Javascript:
[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

------
arcatek
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](http://start9.io)

~~~
TazeTSchnitzel
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/](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.

~~~
arcatek
> 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).

------
kevan
>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.

~~~
db48x
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.

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

~~~
db48x
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.

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

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

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

------
erikb
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.

------
rocky1138
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.

~~~
arcatek
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).

~~~
mietek
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.

~~~
jvilk
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.)

