There's a really high pitch sound when the emulator starts that hurt my ears (was wearing earphones with high volume). Beware.

We used to call it the “beep” :)

Yeah, but back in the day you didn't run the raw square wave signal into your headphones. Even if you used headphones the beep would go to the speaker either in the chassis or in the monitor

That's the true-to-life sound of the monochrome monitor. Bonus points for added realism!

Wish I've read the comments before opening the link.

This didn't happen for me, chrome on Linux. I was listening to Jimmy Dore in another tab, and there was no high-pitched sound.

I find it amazing that I can run Win95 fast in a browser on my phone.

I remember when my computer chugged trying to 95 after upgrading from 3.1!

An entire OS, which can still perform most of the tasks we ask of computers today, runs fast in a virtual machine on a device designed with a power budget in mind. Yet many apps that do basically just one of those tasks, and run natively, run slower and take up more disk space and memory. That's progress.

Nominally, apps do one of those tasks, but they also have to constantly mine you for data, so that takes a lot of overhead.

Writh's Law: Software gets slower more rapidly than hardware becomes faster.[1]

[1] https://en.wikipedia.org/wiki/Wirth%27s_law

I've always felt like this effect is just perception. LibreOffice Writer starts in a couple of seconds on my current laptop, for example. I remember when Word took a few multiples of that in the past.

And browsers now feel slow if they don't respond perfectly to touch input on my tablet. We used to tolerate much slower response times.

A lot of this is down to UX, or rather expectation management. If I click on something and nothing at all happens for 0.8 seconds until the UI updates with the task done, the app feels incredibly slow and laggy. If I click on something, a progress indicator opens immedietly and updates a real progress bar every 0.2 seconds until the task is done 10 seconds later the app feels fast and snappy.

The second app took more than ten times longer, but it never left me doubting if it even noticed my click and how long I have to wait. That makes a world of difference.

90s era software was written in the expectation that the computer is slow, and having progress indicators on screen or in the status bar for a lot of tasks was common (and if that was too much work at least the cursor was updated instantly to show that work is done). Today most software is written in the expectation that everything works instantly, and if it doesn't the user experience falls apart quickly.

One addition to this (excellent) post: it was much more common for applications to do all the work in a single thread, and so it often became important to be aware of stuff like chunking up a big workload so that progress bar could actually render. In doing so, this also improved application responsiveness through allocating time to drain the message pump.

While now the UI is more regularly decoupled from the application, the awareness that updating the user seems to have somewhat fallen by the wayside, and so a big ol' spinner, or a largely fictitious progress bar that isn't actually tethered to any measure of work, shows up and you get situations like "well, the progress bar is at 130%, but I sure don't feel like I'm at 130%...".

This isn't the tools, it's a poor use of them, and it lends a lot of ammunition to folks who want to back-in-my-day while ignoring that a lot of other parts of the stuff we had back in our day kinda...sucked. Some of it (not everything!) just happened to be good at this one thing!

Apples to oranges. Word is still slow.

The others have already evoked Wirth's law.

Indeed, even something like MS-DOS/Windows 3.1 or Amiga 500 would already be good enough for many office tasks that most people do.

Wirth's law in action.

Dang, Windows 95 looks like it ALMOST ran on my Apple Watch, but the browser crashed after it downloaded the image. https://i.imgur.com/DkbaWF6.jpg

Is there a way to make this go full screen? It'd be so much fun to turn my entire macbook screen into an IBM green character screen, and immerse myself in BASICA programming like the old days.

I realize aspect ratio could be a problem and I'm willing to put up with some black on either side.

It's not an emulator, but if you're looking for a little nostalgia you might get a kick out of Cool Retro Term (https://github.com/Swordfish90/cool-retro-term)

There's a full screen button, top right of the emulator

I keep seeing "PCjr Machines". It's actually close to what this is, using the console is bringing back memories of my first programs in basica! I poked around a bit, this doesn't support an actual PCjr does it (with colors & polyphonic sound)?

I can't get most of the disk images to load. It claims the images are too big. Or do I need to use a different DOS with HD disk support? Bit of chicken and egg since the more recent DOS images are on big disks, and usually more than one.

Still amazing.

What is also awesome is that after it boots DOS on that page that the CPU utilisation by my browser is pretty much zero.

Must be a patch. DOS didn’t use HLT until version 6 - it just spun instead.

https://blogs.msdn.microsoft.com/virtual_pc_guy/2004/12/20/w...

> after it boots DOS on that page that the CPU utilisation by my browser is pretty much zero

Presumably the processor is waiting for an interrupt, so there’s nothing for the emulator to do, so nothing for the browser to do.

That’s normal for an operating system, an emulator, and JavaScript.

I'm guessing (didn't try) it could be a slightly patched version that does actually halt the CPU when it has nothing to do, since DOS is well known for using up all the host CPU when run in a VM even when idle and leading to people writing utilities like this:

http://maribu.home.xs4all.nl/zeurkous/download/mirror/dosidl...

I also found this (somewhat amusing) page discussing the problem:

http://wiki.freedos.org/wiki/index.php/VirtualBox_-_Heat

The "Running the CPU at 100 percent for too long can damage your computer." message is probably legal ass-covering, since any system that can't 100% CPU usage 24/7 is defective. Indeed, back when DOS was common, that's what it did to the CPUs of the time, as did other applications which used a polling loop instead of waiting for interrupts.

That's normal for a full-featured OS, not for a single-tasking OS like MS-DOS. Additionally, x86 HLT instruction was quite obscure before the 80486 (IIRC).

Ah.. it sounds logical yes. But not for DOS where the CPU was not waiting, but instead just burning CPU cycles.

Try running DOS in any VM and you'll be shocked by the CPU usage. A constant 100% until you install a little program called DOSIDLE that properly runs a HLT instruction when the CPU is waiting.

>That’s normal for an operating system, an emulator, and JavaScript.

But apparently not for Electron apps...

The page claims to be "the original IBM PC simulation that runs in your web browser", but I think jslinux* predates this project. How do they compare?

* https://news.ycombinator.com/item?id=2555349

If I had to guess, I would say the claim is about running IBM DOS in a browser, as opposed to Linux.

This is incredible! Now we need an OS2 image.

Wow. I can't believe the amount of hours I spent on computers back in the day, even though they were so incapable and boring compared to today. It's as if I've never liked people.

This is fantastic. I got teary eyed running VB and actually making an Application. What a flood of wonderful nostalgic memories. Well done.

this is awesome.

The emulated screen is too big for my screen and there doesn't seem to be a way of making it smaller (zoom doesn't work either).

The screen is html. Find the div with id ibm5150.videoMDA in chrome/firefox devtools and edit the width. Aspect ratio is kept.

Or simply resize the width of the browser window until you can see everything. Half of the screen seems to be fine.

Since the problem is the aspect ratio, I just turned on the dev tools sidebar, so the content area is now taller than it is wide, that worked.

Any reason why is not compiled to WebAssembly?

It's written in JS, not compiled to JS. WASM isn't a good target to compile JS to, and there's little point in doing so.

So what you're saying is we need to rewrite it in Rust, then compile it to WASM, then compile an ASM.js backup as well? /s

Now all the browsers support wasm so you don't need to compile it to asm.js. You may use any language if you don't like Rust.

I think the reason they did not do that is because it's a JavaScript project and they didn't want to rewrite it in C or another language since there are already lots of emulators in C. But it could be faster if it was compiled to wasm.