9 ms·

I'm not sure I understand your complaints here, I believe dosbox has support for hardware passthru. and you can run dosbox on a modern 64-bit machine, so the i

by braveo 9y ago

I'm not sure I understand your complaints here, I believe dosbox has support for hardware passthru. and you can run dosbox on a modern 64-bit machine, so the idea of needing unsupported Windows XP (or similar) doesn't seem to be valid imo.

MaulingMonkey 9y ago
> I'm not sure I understand your complaints here I'll try to clarify. > I believe dosbox has support for hardware passthru. There's a huge difference between hardware passthru and hardware passthru working. I've spent a lot of time fighting e.g. VirtualBox trying to get the simple task of USB passthrough working with relatively modern host and guest OSes, and failed. I don't even want to imagine the fun of COM and LPT passthrough, to say nothing of more proprietary options. > and you can run dosbox on a modern 64-bit machine, so the idea of needing unsupported Windows XP (or similar) doesn't seem to be valid imo. You're thinking of the host OS. Yes, I've run dosbox on modern 64-bit hosts. You need a guest OS - the thing that runs within dosbox. I've often used DOS (what dosbox is named after, after all) or Windows 3.1 - both of which are unsupported and unpatched. These will run the 16-bit programs I'm interested in... and absolutely nothing else, including any less-legacy applications that have been upgraded to 32-bit. I could run those on the host instead of the guest, and that works for most of my needs, but now you get to manage trying to share data between the two OSes for all your existing workflows. If you've got a mixture of 16-bit and 32-bit stuff going on, a better idea might be to run a 32-bit version of windows (it can still run 16-bit programs after all) instead of DOS or Windows 3.1 - this way I can run everything on the same OS, and get rid of all those sharing issues. Because Microsoft still offers 32-bit versions of it's OSes (to the chagrin of the author of this article), that could be a fully up to date, supported, and patched 32-bit version of Windows 10. In the alternate history utopia for the author... where perhaps Windows XP was the last 32-bit version of Windows... well, XP is no longer supported, and basically no longer patched. I now have a significant tradeoff of convenience (single 32-bit OS context running all the programs) vs security (a supported and patched OS where possible), and that sucks. Back to our current timeline, a similar story will play out when Microsoft finally stops cutting new 32-bit versions of windows. But for now, we've got our 32-bit Windows 10 guest OS running inside of DOSBox, VirtualBox, or whatever. And we've got our 64-bit Windows 10 host OS running DOSBox/VirtualBox/???. If we aren't actually doing anything with that 64-bit Windows 10 host OS besides DOSBox/VirtualBox... why not simplify and just run the 32-bit Windows 10 guest OS directly on the actual hardware?

by braveo 9y ago

MaulingMonkey 9y ago

> I'm not sure I understand your complaints here I'll try to clarify. > I believe dosbox has support for hardware passthru. There's a huge difference between hardware passthru and hardware passthru working. I've spent a lot of time fighting e.g. VirtualBox trying to get the simple task of USB passthrough working with relatively modern host and guest OSes, and failed. I don't even want to imagine the fun of COM and LPT passthrough, to say nothing of more proprietary options. > and you can run dosbox on a modern 64-bit machine, so the idea of needing unsupported Windows XP (or similar) doesn't seem to be valid imo. You're thinking of the host OS. Yes, I've run dosbox on modern 64-bit hosts. You need a guest OS - the thing that runs within dosbox. I've often used DOS (what dosbox is named after, after all) or Windows 3.1 - both of which are unsupported and unpatched. These will run the 16-bit programs I'm interested in... and absolutely nothing else, including any less-legacy applications that have been upgraded to 32-bit. I could run those on the host instead of the guest, and that works for most of my needs, but now you get to manage trying to share data between the two OSes for all your existing workflows. If you've got a mixture of 16-bit and 32-bit stuff going on, a better idea might be to run a 32-bit version of windows (it can still run 16-bit programs after all) instead of DOS or Windows 3.1 - this way I can run everything on the same OS, and get rid of all those sharing issues. Because Microsoft still offers 32-bit versions of it's OSes (to the chagrin of the author of this article), that could be a fully up to date, supported, and patched 32-bit version of Windows 10. In the alternate history utopia for the author... where perhaps Windows XP was the last 32-bit version of Windows... well, XP is no longer supported, and basically no longer patched. I now have a significant tradeoff of convenience (single 32-bit OS context running all the programs) vs security (a supported and patched OS where possible), and that sucks. Back to our current timeline, a similar story will play out when Microsoft finally stops cutting new 32-bit versions of windows. But for now, we've got our 32-bit Windows 10 guest OS running inside of DOSBox, VirtualBox, or whatever. And we've got our 64-bit Windows 10 host OS running DOSBox/VirtualBox/???. If we aren't actually doing anything with that 64-bit Windows 10 host OS besides DOSBox/VirtualBox... why not simplify and just run the 32-bit Windows 10 guest OS directly on the actual hardware?