One other trick when the administrator had locked down the Registry Editor was to use the EDIT.COM program to modify REGEDIT.EXE and corrupt the "DisableRegistryTools" string, and save it in some directory you have write access to. Then it wouldn't read the value keyed by that string in the registry. If I remember correctly you'd have to open EDIT with a command line parameter that enabled binary mode, something like "/78".
Sometimes the Run box and the Command Prompt were locked down too, to get around that you could navigate to C:\WINDOWS\SYSTEM32 in Explorer and run FTP.EXE, then use the "!" command to run whatever other commands you needed.
If Microsoft Office was installed, another easy way to run whatever you wanted despite lockdown settings was to open Excel or Word and go to the VBA (Visual Basic for Applications) window with Alt+F11, and use the Shell() function from the Immediate pane.
Exactly, EDIT.COM from Win9x had an incredibly useful binary mode (EDIT /xx filename), where xx is the number of columns to display. I'm really missing it in modern windows... it's very useful to sometimes quickly binary patch a file from a terminal.
But there was an optional registry key that prevents the user from doing anything until after you were logged into the network. So practically, it was a login dialog.
Cool. No substantial comment but found this quite entertaining to read.
> * I prefer to use VirtualBox because I am unable to make QEMU/KVM work, since I am not a rocket scientist. I don't see the advantage of a package manager when I have to edit random config files and hunt for tutorials. Why this can't be managed by APT or explained by the developer/maintainer? Seriously, why this needs to be another Wine-like experience is beyond me.
Not sure what this means to be honest: "I don't see the advantage of a package manager when I have to edit random config files and hunt for tutorials. Why this can't be managed by APT or explained by the developer/maintainer?" Nor this: "Seriously, why this needs to be another Wine-like experience is beyond me."
Of course, Virtualbox is substantially fine for this sort of thing, but Qemu/KVM isn't that absurd. Qemu is just an ordinary CLI program. Admittedly, forging a proper Qemu command for running a VM is an exercise in frustration because the CLI arguments have changed over time and some of them are now quite complicated to set up, but this is more FFMPEG-like than Wine-like.
That said, if you want to use Qemu/KVM more like a desktop virtualization solution, try libvirt with virt-manager. That will give you a GUI with wizards. It's a little weird, but very powerful.
Virtualbox may still be better for Windows 95. Honestly, 86Box may be best for Windows 95, being an emulator of older hardware rather than a VM.
To be honest, the qemu command line became more and more arcane over the years due to the large number of supported features, and is not very stable across major versions.
For example, until a certain point you could start a VM and install DOS/Win9x with
if you try to boot it like this now, it will complain that the hard disk has been guessed as "raw":
WARNING: Image format was not specified for 'harddisk.img' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
which is not as easy to remember, supports conflicting mnemonics (-cdrom and -hda vs -drive) and whatnot (for the added benefit of... what? I suppose the average qemu user can figure out that some stuff can be "dangerous". Why not print the warning and continue without bugging me?)... The network options are even more varied, and IIRC not even the official guide was up to date at some point.
I put up with qemu, but when possible I am happy to avoid it.
Yeah, there are increasingly more situations where the simple mnemonics no longer work and you now need to use the more advanced uniform syntax for specifying devices. The same is true, IIRC, of specifying sound card hardware: in the past it used to be one argument to enable Soundblaster emulation outputting to the default sound output on the host, now I'm pretty sure it's split in two. The more "advanced" options totally make sense, but dropping or limiting the simpler options feels like a shame given how handy the qemu CLI can be.
That said, while they can be annoying, there haven't been an enormous amount of these changes, which is why I liken it to FFmpeg, I still use the FFmpeg CLI all the time even though the CLI syntax for more advanced filtering has changed over time.
As someone who also has similar frustrations as the author I can explain.
I don't regularly run virtual machines, but I have been doing it for decades now, for a long time the install process was: install VirtualBox (or equivalent), tell what resources to allocate including disc images, run the vm, install the os, and your good to go.
To install Qemu/kvm/lib-virt you first have to find an installer tutorial. Then you hit up your package manager (like apt or pacman) to put the software on your machine (notice I didn't say install), then you have to go about installing and linking together a mess of programs, gotta tell systemctl to start up some stuff, gotta configure some networking stuff, then hope it all starts up. And it doesn't, you need to get some other packages to fix something else that your tutorial never mentions. Get that installed, manually after finding a supposed fix on some random message board, then maybe lib-virt fires up without issue. You point it at the resources, get it started up to install the os, and find that your vm is dog slow. Now you find yourself installing more packages, configuring more files with hardware memory addresses, and adding kernel boot flags just to get graphics working better. You can easily spend hours on this if you hit the right hiccups along the way. All because you wanted to spend an hour or two on a different problem.
I too wish the install for qemu was just easier, it would be nice if the packages for it came with some sane defaults or an installer script to get you up and running with a minimum install.
I don't have very many machines running VMs, but IIRC the last time I set up libvirt (on a tiny, cheap Lenovo box to virtualize Home Assistant), it went something like this:
pacman -S virt-manager
...and the whole libvirt/KVM/QEMU dependency tree got pulled down, installed, fiddled whatever I needed to fiddle to make it start at boot, and it generally worked. I manage it with virt-manager on another machine.
Performance seems fine, and configuring the virtual machines themselves is not really much different with virt-manager than it is with virtualbox.
I still don't understand what this means. In Debian installing qemu is no different from installing any other package, including Virtualbox.
Like:
> edit random config files
I have no idea what config files you have to edit to run a relatively basic qemu incantation. My best assumption is that they mean libvirt, but I also don't really know what you have to edit to make libvirt work.
Since the OP is using Debian, I can check the Debian instructions for setting up a KVM libvirt setup on Debian.
OK, this looks relatively straight-forward. You install packages, then you create VMs. It recommends AQEMU or virt-manager to use as a UI.
I am on NixOS because I like my coffee black, but I am kind of curious to see what the experience is roughly like, so maybe I can try to follow along in toolbox. It's not going to be identical but it shouldn't be any better of an experience than native Debian, for sure.
$ toolbox create --image quay.io/toolbx-images/debian-toolbox:12
...
$ toolbox enter debian-toolbox-12
Toolbox seems to mount some libvirt stuff in for convenience, but we want to actually run libvirtd in the toolbox container, so umount it. This doesn't need to be done on a real Debian installation.
Hmm, can't start libvirtd with no systemd, since I'm not on a real Debian machine. But, I can at least manually run libvirtd. Again, this doesn't need to be done on a real Debian installation.
$ sudo libvirtd &
$ sudo virtlogd &
OK. Theoretically the next thing I need to do is install the UI.
$ sudo apt install virt-manager
$ virt-manager
From here I had to Add Connection to connect to libvirt, but using the default settings worked. Admittedly this is not intuitive, but the UI will make you do it, so it's not like you can forget to.
Now I can create VMs! They don't really run in Toolbox for a variety of reasons that I could probably work around, but it's beside the point. On actual Debian this would be the end of things. Should be totally possible to install Windows 95.
--
Interestingly though, Debian recommends another tool called AQEMU before virt-manager. I think this is just a qemu frontend, so it probably doesn't need libvirt at all. (The instructions are unclear about this, which is very unfortunate.) I wonder how easy that is to use.
$ sudo apt install aqemu
$ aqemu
W00t, this one is really easy to use. No need to connect to libvirt, I created a Windows 9x VM pretty quickly. I am mildly alarmed that the default OS option is "Linux 2.6", the latest version of Linux that is in the list, and that the latest Windows version listed is "Windows 7". Since this just sets defaults it's not so important, but it definitely hints at this not being super maintained these days. Does it still work? Can I install and run Windows 98 in it?
Thankfully, yes. I followed the VM wizard using defaults, selecting only Windows 9x. Added CD-ROM image of Windows 98 SE, added a boot floppy (actually the Japanese DOS-V boot floppy for Windows 98, since that's all I had locally, still works with some awkwardness.) Started VM. Formatted, installed. (Mostly. It's actually sitting here on "Updating System Settings..." with "7 minutes remaining". But I reckon it'll be done in a couple more minutes.)
OK, so there you go: if you would like to use qemu+KVM to install Windows 9x, you absolutely can do it using aqemu on Debian 12. No need to edit random config files or even bother with libvirt, if you don't want to.
Well, given how long this post is, it certainly doesn't do anything to disprove the notion that Qemu is less accessible and intuitive to use for ordinary users than Virtualbox, that's for sure. And to be sure, I 100% agree and empathize with the fact that it is not, because it isn't.
That said, this only caught my attention because it seemed like the OP had gotten stuck in an unusually deep rut, as I have basically only ever needed to edit configuration files with qemu when doing ridiculous things in libvirt (like PCI-e passthrough and Looking Glass and the like.) Beyond that, setup and usage of qemu is typically not too bad, with the rather large caveat that you kind of have to know what to do.
I don't have full notes for my last adventure into QEMU, but you are correct that it was mostly an issue with libvirt and getting graphics to render correctly.
> Well, given how long this post is, it certainly doesn't do anything to disprove the notion that Qemu is less accessible and intuitive to use for ordinary users than Virtualbox, that's for sure. And to be sure, I 100% agree and empathize with the fact that it is not, because it isn't.
That's really the rub, choosing to be an ordinary user. The older I get the less I choose to tinker with things that I'm not going to use very often. I like it when software just sets itself up and lets me get to work.
This is true. If someone says "I just want something that works, and Virtualbox works" it doesn't really raise any eyebrows. It's really the tone of "I am unable to make QEMU/KVM work, since I am not a rocket scientist" that implies, maybe they would use QEMU, if only it wasn't horrifically difficult to get working. I think if your experience with QEMU is this bad, you may have just gotten a bit unlucky and gotten off into the weeds on a detour you probably did not need.
That said, are there reasons why someone who just wants things to work and doesn't want to tinker ever would choose QEMU over Virtualbox? Definitely. Here's a good one: the Virtualbox kernel modules were notoriously problematic. Back in the day, loading the vboxdrv module would add TAINT_CRAP in your running kernel[1], because the kernel developers were tired of dealing with bug reports that are the fault of the vboxdrv. Presumably it's better nowadays, but out-of-tree modules are generally a source of headache. Another good one is features: Virtualbox has a lot of great features for desktop end users, but QEMU can do a whole lot more; it supports absolutely tons of architectures and system options. You get access to a wide range of paravirtualization devices through Virtio drivers, including VirtioFS, a dramatically superior solution for mounting directories into VMs versus Virtualbox's Shared Folders feature, in my opinion. It's also possible to do a lot more advanced things, like setting up a discrete GPU passthrough and Looking Glass, or passing a portion of your Intel iGPU using GVT-g.[2]
Of course, some day Virtualbox may support a KVM backend, just as virtualization tools are starting to support unified hypervisor backends on Windows and macOS. There's even an existing patch, though I do not know what the status is and whether or not it could ever be merged upstream.[3] So maybe in the future, choosing between Virtualbox or KVM will become unnecessary.
For now though, it's definitely not clear what you should recommend to someone IMO. (For this particular use case, I don't even recommend a VM at all; I think for Windows 95, 86Box is a better solution.)
1 point by gonzodaruler 0 minutes ago | next | edit | delete [–]
> Of course, some day Virtualbox may support a KVM backend, just as virtualization tools are starting to support unified hypervisor backends on Windows and macOS. There's even an existing patch, though I do not know what the status is and whether or not it could ever be merged upstream.[3]
This is the official patch set for the VirtualBox KVM backend. Our plan is to support this for the near future. There are even packages for ArchLinux (AUR), gentoo and NixOS already if you want to test this.
> I prefer to use VirtualBox because I am unable to make QEMU/KVM work, since I am not a rocket scientist.
What this translates to is "I did not want to read the large and comprehensive QEMU/KVM documentation, go through each option one by one, take notes, and specify the ones I wanted."
Which is ... totally fine. `qemu` has a lot of options. But that's why they make frontends. You want a scary, difficult command to work with? Try `tc`. I would NEVER touch raw `tc` commands when configuring QoS - FireQoS all the way.
When I experimented with `qemu` to make a Debian-based headless hypervisor, I did have to put some time in it. I had to make some scripts to convert some easier-to-make "config" files into `qemu` commands (in addition to making the `tap` network interfaces for virtual networking). Got it working and it did its thing. It was cool that it could be done - launch VMs from a script with no need for a GUI.
It can't do literally everything Qemu/libvirt can do using only the UI, but given that it has escape hatches to directly edit libvirt configurations, and libvirt has escape hatches to directly pass arguments to Qemu, there's very little you can't do with it.
There's other fun hacks using print dialogs. When I was in jail the computers only ran one piece of legal software (on Windows Vista). But it would let you print. And the printer drivers from HP had a button to "Order more ink" which if you pressed it opened IE and tried to navigate to hp.com. From there you could just use IE as File Explorer and browse the hard drive and run explorer.exe.
Security just wasn’t huge back then. I remember once not having log in credentials so I was able to create a new admin account at the start up and then delete the old password on the original account. It was rather trivial to break into a pc back then.
In a similar flavour, on older versions of Mac OSX, you could touch an initial setup file and reboot which would start the out of box experience and let you make a new admin user if you ever found yourself locked out of one for some reason. Modern disk encryption put an obvious stop to that…
The old /var/db/.AppleSetupDone trick. At least as of 2-3 years ago this still worked. I _think_ they've renamed the file since; I haven't used this in a long time. If I recall correctly that file became SIP protected so had to disable SIP to delete/create it.
Even with FileVault2/FDE, it was still possible as long as you could unlock the drive. Now being able to authenticate as an administrator privileged user is (in some scenarios) a direct proxy for demonstrating ownership to recoveryOS, blocking access to the Utilities menu. It's a clever strategy from a security perspective.
Mixed, mostly past, tense because I'm not sure if this still works in 2024.
virt-manager/gnome-boxes haven't achieved the same mindshare as, say, virtualbox, so it is entirely possible.
I know when I took a break from VMs for awhile and came back, I found virt-manager about 3 days after I started trying to crack the nut of qemu/kvm from only the command line.
I as a CLI guy, usually have 2 or 3 open somewhere, I still find some CLI programs to be quite inscrutable. Pop it in a GUI though and suddenly the thing is dead easy to use. Have not quite figured out what triggers this response in me though.
I used to be a heavy CLI user when I was in college, after 10 years of professional experience I now prefer GUIs for most actions. For me the response you mention is automatic for every program with more than 10 CLI options. The longer the manual the easier is to just understand what to do in a GUI.
I only really prefer CLIs for two things: commands I use really often so I remember their usage and I can type the command faster than clicking the right things in GUI (e.g. "git rebase", "gh pr checkout", ...) and writing shell scripts, especially if I need to often do the same chain of actions, writing a .sh script saves a lot of time and mental energy.
For these reasons I especially love software which both has a good GUI and a good CLI, like VirtualBox for example.
I would like to thank all of you for reading my blog. It means a lot to me!
I think I need to address the many comments about my qemu/kvm rant... I think my experience could be best described by the user asciimov in his comment. I don't know what I do wrong, but I always get some error messages and barely make the virtualization work. Never even get to network the VMs.
I remember a similar thing with the Novell login at school on Windows XP.
If you just unplugged the ethernet cable at the right time, you would login straight away and even with a higher permission account compared to a normal login.
Nobody really cared about computer security back then.
At my school, you would get different levels of permissions depending on when you unplugged the cable and plugged it back in. Unplug it too early, and you get kicked out of the session. Too late and all the restrictions get applied. In the middle were two sweet spots, one that disabled the Internet filter and another that allowed running arbitrary applications instead of just the ones from the whitelist.
Once the other students found out about this, there were many damaged Ethernet ports as they yanked the cables out of the ports violently. The school administrators eventually fixed the Internet filter vulnerability but the application one remained because not many people cared about it.
There's a similar hack for some Android tablets that get stuck at the sign up screen, open keyboard, keyboard settings, help, now you have a web browser, open android settings from there and configure things
The NT4 login dialog looks like those of NT3.51 or Windows 2000 (and XP Pro if you switch do a domain-based login). See e.g. the one of Windows 2000 (on a machine visible not jointed to a domain) here: https://old.reddit.com/r/Windows10/comments/uyau0h/is_it_som.... And AFAIK there's no way to bypass NT login dialog.
Computers have kind of "converged on boring". This isn't a bad thing, obviously; a computer is a tool and you generally want your tools to work as expected without surprises. Basically any computer with any operating system you would use in the last fifteen or so years works basically "as-expected", more or less. The security models work alright, they don't really crash, and do their job.
This is boring though! I remember when I had an early Windows 95 machine, I genuinely kind of had fun figuring how to break things. I mean, hell, when I discovered you could click "cancel" on the login screen and get a default user so I didn't need to get my parents to unlock it, it felt like I was accessing forbidden knowledge. I think even at the time I knew that was a bit janky. That was kind of the 90's computing experience though; everything was kind of held together with ducktape and prayers, and it kind of worked.
It's probably weird to have nostalgia for a time when everything was a little broken, but what can I say?
It's still there, it's just Windows that became boring.
Take the most plain Ubuntu system and looking for "window manager" - there are dozens of hits! Install "wmaker" for that classical look and spend a few hours picking up the set of dockapps you like. Try a dynamic tiling manager and a static one.
One other trick when the administrator had locked down the Registry Editor was to use the EDIT.COM program to modify REGEDIT.EXE and corrupt the "DisableRegistryTools" string, and save it in some directory you have write access to. Then it wouldn't read the value keyed by that string in the registry. If I remember correctly you'd have to open EDIT with a command line parameter that enabled binary mode, something like "/78".
Sometimes the Run box and the Command Prompt were locked down too, to get around that you could navigate to C:\WINDOWS\SYSTEM32 in Explorer and run FTP.EXE, then use the "!" command to run whatever other commands you needed.
If Microsoft Office was installed, another easy way to run whatever you wanted despite lockdown settings was to open Excel or Word and go to the VBA (Visual Basic for Applications) window with Alt+F11, and use the Shell() function from the Immediate pane.
Exactly, EDIT.COM from Win9x had an incredibly useful binary mode (EDIT /xx filename), where xx is the number of columns to display. I'm really missing it in modern windows... it's very useful to sometimes quickly binary patch a file from a terminal.
The "login" dialog on Windows 95 was just providing network credentials. Windows 95 is a single-user OS. There is no actual login or security.
Technically True.
But there was an optional registry key that prevents the user from doing anything until after you were logged into the network. So practically, it was a login dialog.
But still no security.
Windows 9x does let users have separate profiles with their own files and settings, even if they aren’t super secure.
This, you could literally press escape to login.
The herein linked article discusses disabling that option, and the animated GIF linked at the beginning shows it not working.
Cool. No substantial comment but found this quite entertaining to read.
> * I prefer to use VirtualBox because I am unable to make QEMU/KVM work, since I am not a rocket scientist. I don't see the advantage of a package manager when I have to edit random config files and hunt for tutorials. Why this can't be managed by APT or explained by the developer/maintainer? Seriously, why this needs to be another Wine-like experience is beyond me.
Not sure what this means to be honest: "I don't see the advantage of a package manager when I have to edit random config files and hunt for tutorials. Why this can't be managed by APT or explained by the developer/maintainer?" Nor this: "Seriously, why this needs to be another Wine-like experience is beyond me."
Of course, Virtualbox is substantially fine for this sort of thing, but Qemu/KVM isn't that absurd. Qemu is just an ordinary CLI program. Admittedly, forging a proper Qemu command for running a VM is an exercise in frustration because the CLI arguments have changed over time and some of them are now quite complicated to set up, but this is more FFMPEG-like than Wine-like.
That said, if you want to use Qemu/KVM more like a desktop virtualization solution, try libvirt with virt-manager. That will give you a GUI with wizards. It's a little weird, but very powerful.
Virtualbox may still be better for Windows 95. Honestly, 86Box may be best for Windows 95, being an emulator of older hardware rather than a VM.
> Qemu is just an ordinary CLI program.
To be honest, the qemu command line became more and more arcane over the years due to the large number of supported features, and is not very stable across major versions.
For example, until a certain point you could start a VM and install DOS/Win9x with
if you try to boot it like this now, it will complain that the hard disk has been guessed as "raw": So the actual incantation to use is which is not as easy to remember, supports conflicting mnemonics (-cdrom and -hda vs -drive) and whatnot (for the added benefit of... what? I suppose the average qemu user can figure out that some stuff can be "dangerous". Why not print the warning and continue without bugging me?)... The network options are even more varied, and IIRC not even the official guide was up to date at some point.I put up with qemu, but when possible I am happy to avoid it.
Yeah, there are increasingly more situations where the simple mnemonics no longer work and you now need to use the more advanced uniform syntax for specifying devices. The same is true, IIRC, of specifying sound card hardware: in the past it used to be one argument to enable Soundblaster emulation outputting to the default sound output on the host, now I'm pretty sure it's split in two. The more "advanced" options totally make sense, but dropping or limiting the simpler options feels like a shame given how handy the qemu CLI can be.
That said, while they can be annoying, there haven't been an enormous amount of these changes, which is why I liken it to FFmpeg, I still use the FFmpeg CLI all the time even though the CLI syntax for more advanced filtering has changed over time.
> Not sure what this means to be honest: [...]
As someone who also has similar frustrations as the author I can explain.
I don't regularly run virtual machines, but I have been doing it for decades now, for a long time the install process was: install VirtualBox (or equivalent), tell what resources to allocate including disc images, run the vm, install the os, and your good to go.
To install Qemu/kvm/lib-virt you first have to find an installer tutorial. Then you hit up your package manager (like apt or pacman) to put the software on your machine (notice I didn't say install), then you have to go about installing and linking together a mess of programs, gotta tell systemctl to start up some stuff, gotta configure some networking stuff, then hope it all starts up. And it doesn't, you need to get some other packages to fix something else that your tutorial never mentions. Get that installed, manually after finding a supposed fix on some random message board, then maybe lib-virt fires up without issue. You point it at the resources, get it started up to install the os, and find that your vm is dog slow. Now you find yourself installing more packages, configuring more files with hardware memory addresses, and adding kernel boot flags just to get graphics working better. You can easily spend hours on this if you hit the right hiccups along the way. All because you wanted to spend an hour or two on a different problem.
I too wish the install for qemu was just easier, it would be nice if the packages for it came with some sane defaults or an installer script to get you up and running with a minimum install.
I don't have very many machines running VMs, but IIRC the last time I set up libvirt (on a tiny, cheap Lenovo box to virtualize Home Assistant), it went something like this:
pacman -S virt-manager
...and the whole libvirt/KVM/QEMU dependency tree got pulled down, installed, fiddled whatever I needed to fiddle to make it start at boot, and it generally worked. I manage it with virt-manager on another machine.
Performance seems fine, and configuring the virtual machines themselves is not really much different with virt-manager than it is with virtualbox.
I still don't understand what this means. In Debian installing qemu is no different from installing any other package, including Virtualbox.
Like:
> edit random config files
I have no idea what config files you have to edit to run a relatively basic qemu incantation. My best assumption is that they mean libvirt, but I also don't really know what you have to edit to make libvirt work.
Since the OP is using Debian, I can check the Debian instructions for setting up a KVM libvirt setup on Debian.
https://wiki.debian.org/KVM#Installation
OK, this looks relatively straight-forward. You install packages, then you create VMs. It recommends AQEMU or virt-manager to use as a UI.
I am on NixOS because I like my coffee black, but I am kind of curious to see what the experience is roughly like, so maybe I can try to follow along in toolbox. It's not going to be identical but it shouldn't be any better of an experience than native Debian, for sure.
Toolbox seems to mount some libvirt stuff in for convenience, but we want to actually run libvirtd in the toolbox container, so umount it. This doesn't need to be done on a real Debian installation. Now following the Debian instructions: Hmm, can't start libvirtd with no systemd, since I'm not on a real Debian machine. But, I can at least manually run libvirtd. Again, this doesn't need to be done on a real Debian installation. OK. Theoretically the next thing I need to do is install the UI. From here I had to Add Connection to connect to libvirt, but using the default settings worked. Admittedly this is not intuitive, but the UI will make you do it, so it's not like you can forget to.Now I can create VMs! They don't really run in Toolbox for a variety of reasons that I could probably work around, but it's beside the point. On actual Debian this would be the end of things. Should be totally possible to install Windows 95.
--
Interestingly though, Debian recommends another tool called AQEMU before virt-manager. I think this is just a qemu frontend, so it probably doesn't need libvirt at all. (The instructions are unclear about this, which is very unfortunate.) I wonder how easy that is to use.
W00t, this one is really easy to use. No need to connect to libvirt, I created a Windows 9x VM pretty quickly. I am mildly alarmed that the default OS option is "Linux 2.6", the latest version of Linux that is in the list, and that the latest Windows version listed is "Windows 7". Since this just sets defaults it's not so important, but it definitely hints at this not being super maintained these days. Does it still work? Can I install and run Windows 98 in it?Thankfully, yes. I followed the VM wizard using defaults, selecting only Windows 9x. Added CD-ROM image of Windows 98 SE, added a boot floppy (actually the Japanese DOS-V boot floppy for Windows 98, since that's all I had locally, still works with some awkwardness.) Started VM. Formatted, installed. (Mostly. It's actually sitting here on "Updating System Settings..." with "7 minutes remaining". But I reckon it'll be done in a couple more minutes.)
OK, so there you go: if you would like to use qemu+KVM to install Windows 9x, you absolutely can do it using aqemu on Debian 12. No need to edit random config files or even bother with libvirt, if you don't want to.
Well, given how long this post is, it certainly doesn't do anything to disprove the notion that Qemu is less accessible and intuitive to use for ordinary users than Virtualbox, that's for sure. And to be sure, I 100% agree and empathize with the fact that it is not, because it isn't.
That said, this only caught my attention because it seemed like the OP had gotten stuck in an unusually deep rut, as I have basically only ever needed to edit configuration files with qemu when doing ridiculous things in libvirt (like PCI-e passthrough and Looking Glass and the like.) Beyond that, setup and usage of qemu is typically not too bad, with the rather large caveat that you kind of have to know what to do.
Thanks for the detailed write up.
I don't have full notes for my last adventure into QEMU, but you are correct that it was mostly an issue with libvirt and getting graphics to render correctly.
> Well, given how long this post is, it certainly doesn't do anything to disprove the notion that Qemu is less accessible and intuitive to use for ordinary users than Virtualbox, that's for sure. And to be sure, I 100% agree and empathize with the fact that it is not, because it isn't.
That's really the rub, choosing to be an ordinary user. The older I get the less I choose to tinker with things that I'm not going to use very often. I like it when software just sets itself up and lets me get to work.
This is true. If someone says "I just want something that works, and Virtualbox works" it doesn't really raise any eyebrows. It's really the tone of "I am unable to make QEMU/KVM work, since I am not a rocket scientist" that implies, maybe they would use QEMU, if only it wasn't horrifically difficult to get working. I think if your experience with QEMU is this bad, you may have just gotten a bit unlucky and gotten off into the weeds on a detour you probably did not need.
That said, are there reasons why someone who just wants things to work and doesn't want to tinker ever would choose QEMU over Virtualbox? Definitely. Here's a good one: the Virtualbox kernel modules were notoriously problematic. Back in the day, loading the vboxdrv module would add TAINT_CRAP in your running kernel[1], because the kernel developers were tired of dealing with bug reports that are the fault of the vboxdrv. Presumably it's better nowadays, but out-of-tree modules are generally a source of headache. Another good one is features: Virtualbox has a lot of great features for desktop end users, but QEMU can do a whole lot more; it supports absolutely tons of architectures and system options. You get access to a wide range of paravirtualization devices through Virtio drivers, including VirtioFS, a dramatically superior solution for mounting directories into VMs versus Virtualbox's Shared Folders feature, in my opinion. It's also possible to do a lot more advanced things, like setting up a discrete GPU passthrough and Looking Glass, or passing a portion of your Intel iGPU using GVT-g.[2]
Of course, some day Virtualbox may support a KVM backend, just as virtualization tools are starting to support unified hypervisor backends on Windows and macOS. There's even an existing patch, though I do not know what the status is and whether or not it could ever be merged upstream.[3] So maybe in the future, choosing between Virtualbox or KVM will become unnecessary.
For now though, it's definitely not clear what you should recommend to someone IMO. (For this particular use case, I don't even recommend a VM at all; I think for Windows 95, 86Box is a better solution.)
[1]: https://lkml.org/lkml/2011/10/6/317
[2]: https://wiki.archlinux.org/title/Intel_GVT-g
[3]: https://github.com/cyberus-technology/virtualbox-kvm, https://news.ycombinator.com/item?id=39300317
*
1 point by gonzodaruler 0 minutes ago | next | edit | delete [–]
> Of course, some day Virtualbox may support a KVM backend, just as virtualization tools are starting to support unified hypervisor backends on Windows and macOS. There's even an existing patch, though I do not know what the status is and whether or not it could ever be merged upstream.[3]
This is the official patch set for the VirtualBox KVM backend. Our plan is to support this for the near future. There are even packages for ArchLinux (AUR), gentoo and NixOS already if you want to test this.
> I prefer to use VirtualBox because I am unable to make QEMU/KVM work, since I am not a rocket scientist.
What this translates to is "I did not want to read the large and comprehensive QEMU/KVM documentation, go through each option one by one, take notes, and specify the ones I wanted."
Which is ... totally fine. `qemu` has a lot of options. But that's why they make frontends. You want a scary, difficult command to work with? Try `tc`. I would NEVER touch raw `tc` commands when configuring QoS - FireQoS all the way.
When I experimented with `qemu` to make a Debian-based headless hypervisor, I did have to put some time in it. I had to make some scripts to convert some easier-to-make "config" files into `qemu` commands (in addition to making the `tap` network interfaces for virtual networking). Got it working and it did its thing. It was cool that it could be done - launch VMs from a script with no need for a GUI.
The very sad thing is that VirtManager (a gtk app) used to be able to handle pretty much everything qemu.
But it's getting deprecated, iirc ?
It's still being updated. I don't see anything on the virt-manager homepage or GitHub that would suggest it is deprecated.
https://virt-manager.org/
https://github.com/virt-manager/virt-manager
It can't do literally everything Qemu/libvirt can do using only the UI, but given that it has escape hatches to directly edit libvirt configurations, and libvirt has escape hatches to directly pass arguments to Qemu, there's very little you can't do with it.
My bad, maybe it's only getting deprecated in RHEL then?
>Qemu is just an ordinary CLI program.
Most of us here take for granted just how arcane CLI actually is.
Dosbox can also boot Windows 95 now. archive.org has an online version: https://archive.org/details/win95_in_dosbox
There's other fun hacks using print dialogs. When I was in jail the computers only ran one piece of legal software (on Windows Vista). But it would let you print. And the printer drivers from HP had a button to "Order more ink" which if you pressed it opened IE and tried to navigate to hp.com. From there you could just use IE as File Explorer and browse the hard drive and run explorer.exe.
Security just wasn’t huge back then. I remember once not having log in credentials so I was able to create a new admin account at the start up and then delete the old password on the original account. It was rather trivial to break into a pc back then.
Depending on the version you could just hit cancel and it would still log you in.
In a similar flavour, on older versions of Mac OSX, you could touch an initial setup file and reboot which would start the out of box experience and let you make a new admin user if you ever found yourself locked out of one for some reason. Modern disk encryption put an obvious stop to that…
The old /var/db/.AppleSetupDone trick. At least as of 2-3 years ago this still worked. I _think_ they've renamed the file since; I haven't used this in a long time. If I recall correctly that file became SIP protected so had to disable SIP to delete/create it.
Even with FileVault2/FDE, it was still possible as long as you could unlock the drive. Now being able to authenticate as an administrator privileged user is (in some scenarios) a direct proxy for demonstrating ownership to recoveryOS, blocking access to the Utilities menu. It's a clever strategy from a security perspective.
Mixed, mostly past, tense because I'm not sure if this still works in 2024.
The rant about qemu/kvm at the bottom is weird. Has the author never heard of virt-manager or gnome-boxes?
Now configure the network card on that thing
On most builds of QEMU, that command will start a VM with an e1000 card networked through SLIRP. It's the equivalent of something like:
virt-manager/gnome-boxes haven't achieved the same mindshare as, say, virtualbox, so it is entirely possible.
I know when I took a break from VMs for awhile and came back, I found virt-manager about 3 days after I started trying to crack the nut of qemu/kvm from only the command line.
I as a CLI guy, usually have 2 or 3 open somewhere, I still find some CLI programs to be quite inscrutable. Pop it in a GUI though and suddenly the thing is dead easy to use. Have not quite figured out what triggers this response in me though.
I used to be a heavy CLI user when I was in college, after 10 years of professional experience I now prefer GUIs for most actions. For me the response you mention is automatic for every program with more than 10 CLI options. The longer the manual the easier is to just understand what to do in a GUI.
I only really prefer CLIs for two things: commands I use really often so I remember their usage and I can type the command faster than clicking the right things in GUI (e.g. "git rebase", "gh pr checkout", ...) and writing shell scripts, especially if I need to often do the same chain of actions, writing a .sh script saves a lot of time and mental energy.
For these reasons I especially love software which both has a good GUI and a good CLI, like VirtualBox for example.
With .net ported back to 95, one should get his security ready too.
Love this reference, that MattKC video is so good.
For the uninitiated, I present this masterpiece: https://youtu.be/CTUMNtKQLl8
I would like to thank all of you for reading my blog. It means a lot to me!
I think I need to address the many comments about my qemu/kvm rant... I think my experience could be best described by the user asciimov in his comment. I don't know what I do wrong, but I always get some error messages and barely make the virtualization work. Never even get to network the VMs.
I remember a similar thing with the Novell login at school on Windows XP.
If you just unplugged the ethernet cable at the right time, you would login straight away and even with a higher permission account compared to a normal login.
Nobody really cared about computer security back then.
At my school, you would get different levels of permissions depending on when you unplugged the cable and plugged it back in. Unplug it too early, and you get kicked out of the session. Too late and all the restrictions get applied. In the middle were two sweet spots, one that disabled the Internet filter and another that allowed running arbitrary applications instead of just the ones from the whitelist.
Once the other students found out about this, there were many damaged Ethernet ports as they yanked the cables out of the ports violently. The school administrators eventually fixed the Internet filter vulnerability but the application one remained because not many people cared about it.
There's a similar hack for some Android tablets that get stuck at the sign up screen, open keyboard, keyboard settings, help, now you have a web browser, open android settings from there and configure things
In the same vein, navigating through help and accessibility menus could be used to bypass Android FRP lock.
I always thought that GIF was of NT 4, not Win95, because the Logon box has a Domain field. Question mark ?
Windows 95 "login" boxes are provided by the network driver, which can ask for any fields it likes.
In this example it's definitely Windows 95, because "Setup MSN" is on the desktop at the end. This was never bundled with NT.
Win9x could login to a domain-based network...
The NT4 login dialog looks like those of NT3.51 or Windows 2000 (and XP Pro if you switch do a domain-based login). See e.g. the one of Windows 2000 (on a machine visible not jointed to a domain) here: https://old.reddit.com/r/Windows10/comments/uyau0h/is_it_som.... And AFAIK there's no way to bypass NT login dialog.
Computers have kind of "converged on boring". This isn't a bad thing, obviously; a computer is a tool and you generally want your tools to work as expected without surprises. Basically any computer with any operating system you would use in the last fifteen or so years works basically "as-expected", more or less. The security models work alright, they don't really crash, and do their job.
This is boring though! I remember when I had an early Windows 95 machine, I genuinely kind of had fun figuring how to break things. I mean, hell, when I discovered you could click "cancel" on the login screen and get a default user so I didn't need to get my parents to unlock it, it felt like I was accessing forbidden knowledge. I think even at the time I knew that was a bit janky. That was kind of the 90's computing experience though; everything was kind of held together with ducktape and prayers, and it kind of worked.
It's probably weird to have nostalgia for a time when everything was a little broken, but what can I say?
It's still there, it's just Windows that became boring.
Take the most plain Ubuntu system and looking for "window manager" - there are dozens of hits! Install "wmaker" for that classical look and spend a few hours picking up the set of dockapps you like. Try a dynamic tiling manager and a static one.