Q2DOS – Quake 2 backported to MS-DOS | Hacker News Reader

Q2DOS – Quake 2 backported to MS-DOS

dk.toastednet.org

119 pointsjsheard79 comments

It's sort of fascinating how much mileage people can squeeze out of MS-DOS. A part of me always wonders about the "What If" world where GUIs never caught on, and how different the world might be today.

It's a tiny OS that provides little more than a filesystem and program loader on top of the BIOS, and otherwise stays out of the way. Any large complex MS-DOS application itself contains functionality that would be in the OS otherwise.

I kind of figured that, just based on the fact that there seems to be a ton of DOS-compatible clones out there, even when DOS was relevant, like Concurrent DOS. If the OS were too complex there probably wouldn’t be a lot of clones.

Yeah. Basically, for most intents and purposes, any high-end MSDOS application is basically running bare-metal, as if no OS was installed in the system at all.

As close to the embedded world as possible.

I don't understand why is there so little documentation about MSDOS as a real-time operating system. I'd bet it would work beautifully for any piece of software that was developed with such use-case in mind.

You’d have to write your own scheduler.

With no memory protection a wayward process could easily overwrite the schedulers data structures, and probably hang the system.

(ms)dos has just a file system (it's the D in the name). It has no protected memory or scheduling, or any ability to "talk" between processes. It can load executable images .exe(MZ) or sub 64KB .com. ANd yes, it's possible to reserve memory and stay resident (TSR)

I have some experience repurposing 8259 (the interrupt controller), and if you hook on the timer (8), there is nothing else to return the execution back to the 'OS'. In short I'd disagree about the real-time.

FAT is not well suited to embedded use. The TFAT hack was patent encumbered and not widely supported outside of MS products.

Also, it was popular to use smaller, 3rd party programs that would provide what is now part of a typical OS; e.g. Norton Commander[1].

[1]: https://en.m.wikipedia.org/wiki/Norton_Commander

I still use Midnight Commander in Linux, as it reminds me of the DOS times with Volkov and Norton.

Volkov was much faster on older machines...

Yes

For today's applications? It sucks. A lot

Thread/Process control in MSDOS? In your dreams

Network? Are you running Netware? Otherwise you're SOL

Sound output? Sure, just set up DMA and IRQ yourself for your Soundblaster card. I mean, you have one of those right?

> Sound output? Sure, just set up DMA and IRQ yourself for your Soundblaster card. I mean, you have one of those right?

What has OS got to do with possession of some hardware?

If the OS doesn't provide an actual sound API developers will only write support for the most popular sound cards.

I remember games which had extra features if you had a Gravis UltraSound.

The knowledge gap of the modern js devs is funny, thinking MS-DOS has any concept of what a soundcard is.

Though even first Unixes "it's a file, just write to it" were better but just above the bare minimum

As someone that started using MS-DOS, when MS-DOS 3.3 was current, I rather have the GUIs world, thanks.

I really can't grasp the TUI hype that is going on nowadays.

> I really can't grasp the TUI hype that is going on nowadays.

We have command completion. And the GUIs have mostly become enshitified.

And GUIs often lack configurability among other things.

Since when you can extend CLI and TUIs, when not given access to source code?

A hell lot of CLI and TUIs are open-source, whereas GUIs are more often (than CLI tools) closed source, though, so it is mainly an issue with GUIs.

Not true for MS-DOS CLI and TUIs.

Also not true for FreeBSD and GNU/Linux GUIs.

Have you found it to be easier to configure GUI than CLI?

Via piping.

Unfortunately doing the same kind macros in GUI is a great deal more error prone.

As for CLI vs GUI, both have their places. I wouldn’t say I preferred on over the other except for when talking about specific tasks.

I’ve also been careful not to state “TUI”. Frankly I don’t see much value making a distinction between GUI and TUI in this type of conversation because they’re ostensibly the same paradigm.

There is also "expect" for automation.

Speaking of DOS and configuration. Everyone used to whine about that. Having to put cryptic lines of text in CONFIG.SYS and AUTOEXEC.BAT to get some game running. But I look back now and I see my old configuration files that I used on my last DOS computer, or the files I use to configure FreeDOS, and it is really not bad at all compared to any modern OS.

In two short text files, maybe typically a few dozen lines in total (and the OS installer is likely to give you good defaults) it sets up all preferences, from command-line keyboard layout to TCP/IP to what settings DJGPP need to compile C++. There is no control panel or other annoying settings GUI to hunt for settings, just two files.

Yes, pretty much, something you can carry with you, or have it backed up.

One can be considered lucky if the GUI allows the export & import of settings.

Meanwhile, if you had a Mac, everything Just Worked. There was no need to load an "extended memory driver" to use all the RAM in your system; it was all there from the start. If you wanted to change things, you could click on a few settings with sensible names without having to run arcane syntax. If a special driver or system extension was needed, just drag it to System Folder:Extensions.

The DOS PC was really clunky, inferior, and a struggle to use compared to any of the alternatives.

Poor students couldn’t afford Macs in those days. We built PCs by hand to save a few bucks.

I feel like the difficulty was in that you couldn’t just Google magic spells to make things work, you either knew how to do things or you didn’t. DOS didn’t even have manpages IIRC

You had the manual, and had magazines:

At the time, I was really annoyed I couldn’t convert my DOS knowledge into Unix (Linux) shell commands - when need came.

Here, history lesson, https://4dos.info/4dinfo.htm

I think you're wrong to presume that the TUI would have remained static at DOS 3.3 or sh as it was in the mid 80's - something like fish would have evolved anyhow, menu driven TUI's can be amazing, and efficient.

Marriott uses a TUI based PMS at most of their hotels, it has a learning curve like a hockey stick, but once you learn it, you can literally check a guest in 5+ min faster than using Lightspeed (what most Sheratons used), its just that much faster - a big part of that is typeahead, you dont have to wait for the screen to populate to make the next selection, something that isnt true for GUI's.

You are equally wrong to assume my TUI experience between MS-DOS 3.3 and MS-DOS 6.0, UNIX/Xenix, AS/400.

Whatever folks think of Ratatui, Turbo Vison and Clipper did it first.

Also started on 3.3

Re: TUIs, I wish there were more like the ones there were in DOS with CUA keybindings.

Oh I don’t disagree, I just like to ponder it sometimes, I think it’s better that we have GUIs now.

I guess I think of it in kind of the same way people think about steampunk; in that case it’s about thinking in terms of everything being steam-powered and clockwork instead of electrical and transistor’d like it is today. It’s not like most people who like steampunk would actually prefer to live in that universe, but more like it’s just a fun think to think about.

With DOSBox-X, and probably some other DOS emulators as well, you can set up any SVGA BIOS graphics modes you want to (up to at least 32-bit color with 16-bit integers for screen width and height), so a DOS application using just the standard BIOS functions can run in fullscreen on a modern monitor.

A bit trickier if you want to run on real hardware, especially since BIOS support is basically gone now. Not sure how old hardware you have to go back to to even boot up FreeDOS. I ran it on some late 00's hardware and everything runs insanely fast. I did not remember computers could be that responsive and not annoying to use.

You can still run it "on real hardware" by booting a VM. This saves the overhead of CPU emulation, though hardware access may still be slow.

It still runs on modern hardware. It'll depend on a few things if it works or not. Usual case is that CSM/bios boot support is missing.

I have FreeDOS installed on my Ryzen machine. It runs okay except that modern video hardware doesn't dependably support classic C/E/VGA modes.

How do you handle sound?

Macs could boot from BIOS until circa 2017, and had no trouble booting from a FreeDOS live disc.

The old Carmack .plan

We are not going to do another dos game. No amount of flaming hate mail is going to change my mind on this (PLEASE don't!). The advantages of good TCP/IP support, dynamic linking, powerfull virtual memory, device drivers, etc, are just too much to overcome. Yes, all of those can be provided under dos in various ways, but it just isn't worth it.

https://rmitz.org/carmack.on.operating.systems.html

Given that Quake 2 already runs on Windows 95 back in the days, and how Windows 95 is already somewhat of an "exokernel" to DOS, I wonder how hard it is to port to DOS, actually? Well, given that you can have almost full control to the hardware and framebuffer, and memory allocation and how you can directly issue BIOS calls...I guess the performance should be prettier right?

I don’t think you could fairly say Windows 95 is an exokernel to DOS. Windows 95 is a whole OS, which happened to go through DOS during the boot process, and keep bits of DOS around for certain pieces of functionality (device drivers?)

Maybe Quake II on DOS will run with less system memory than the Windows version.

Windows 95, like Windows 3.x enhanced mode and Windows/386 before that, is actually a hypervisor that runs DOS in VMs; and one of those VMs, the "system VM", runs a DOS extender that handles the Win32 and GUI part.

Notably, the DOS environment under Windows is running in a hardware mode called "virtual 8086 mode" which allows it to be isolated from the other DOS environments and, even more importantly, from full BIOS access. These limitations kept the whole system safer and more stable than DOS in "real mode" but made some DOS programs unusable under Windows.

Almost fully isolated. As far as I know Intel screwed 386 design forgetting about trapping POPF on interrupt flag change. https://devblogs.microsoft.com/oldnewthing/20160411-00/?p=93... https://docs.oracle.com/en/virtualization/virtualbox/6.0/adm...

Some context related to what you're saying: - https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24... - https://www.xtof.info/inside-windows3.html

Windows 95 is so good at pretending to not be there that it convinced a generation of nerds that it was a thin layer on top of DOS, but the reality is the other way round.

I'd heard this claim before too. For the unenlightened - what was the structure of Win95 and its DOS? As opposed to 3.1?

Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...

Windows 95 had a horrible reputation for games in the early days, for good reasons or not (maybe mostly because how bad Windows 3.x was for games?). Quake was possibly the first mainstream game that managed to convince many that it was possible to get good games performance without sticking to MS-DOS? 1997 was still a great year for DOS games really. Even 1998 was not bad. For someone playing games on a PC in that era there was really no hurry to switch to Windows 95/98 (but by 1997 I had moved on to Linux instead anyway).

https://www.mobygames.com/platform/dos/year:1997/ https://www.mobygames.com/platform/dos/year:1998/

DLL's were the most involved part of the port.

Does the original work on HXDOS?

Wow hxdos[0] looks like msdos extender nirvana

0, https://www.japheth.de/HX.html

What realmode in DOS offered was a boon for beginner programmers, i wonder has anyone done something similar in linux framebuffer without using X server. Perhaps a game in /dev/fb0 ?

I think the search term you want is "svgalib" - https://en.wikipedia.org/wiki/SVGALib

It looks like at least some versions of Allegro and SDL supported it as a backend.

One of the original Quake I implementations — as in authored by Carmack and Taylor themselves — used SVGAlib as a backend. I remember this because of having to configure my mouse to co-exist with GPM in some file in /etc for svgalib.

Nice breadcrumb: https://web.archive.org/web/19991008210746/http://webpages.m...

Allegro thats a name i have not heard since 2002 i think. Kids these days would know SDL, DirectX , LOVR or Raylib.

https://en.wikipedia.org/wiki/DirectFB

How do these Nintendo handhelds work? i thought they use some kind of framebuffer for such great performance for the substandard quality hardware they use. Every generation of Nintendo chip is way behind Apple and Android systems yet they achieve remarkable performance.

Yes they use some kind of framebuffer, just like 8 and 16 bit home consoles.

They also used plenty of Assembly programmer and special graphics units, the console percursors of GPUs.

However since the N64 that they use graphics APIs like everyone else, GBI, GX, GX2 and nowadays NVN. For porting purposes, the Switch also supports GL 4.6 and Vulkan.

Other than that, there is also a performance culture, and not using generic game engines.

The 8 and 16 bit home consoles did not use a frame buffer. The NES had 2KB of VRAM and an output resolution of 256x240 - even if you only had 1bpp it wouldn’t fit.

These consoles - along with everything handheld up until the 3DS - create images out of scrolling layers of background tiles and freely positionable sprites. You don’t have any kind of per pixel access, although you can manipulate the state of the hardware as the screen is being drawn to get unorthodox effects.

The GBA had 6 videos modes: 4 of them were tile based, and the other 3 were framebuffer based. That's how games like Doom could run on the GBA.

Others have pointed out DirectFB and SVGALib. Both very interesting. SVGALib was supported by a lot of commercial Linux game ports in the earlier days, whereas DirectFB was possibly one of the most serious alternatives to X11, although I think like most such projects it mainly found use in embedded devices (Coincidentally, Wayland seems to have finally unified some of the "embedded" and desktop use cases.)

These days SVGALib doesn't work and fbdev is deprecated. However, the "next-generation" Linux graphics stack can achieve a fairly similar goal using the DRM/KMS APIs, albeit it's definitely a lot more work if you just want a framebuffer. On the other hand, though, it's relatively straight-forward to get an EGL context and start doing hardware accelerated things. Maybe that takes some of the fun out of it, but I think it's pretty cool.

Yes, in the early days, as many others have replied.

What most have missed is that those libraries usually required root access, or setuid, unless you want to go clever with group permissions, which no one did.

Currently reading The BLUE Book About GW-BASIC and QuickBasic (Thomas C. McIntire, 1991, https://github.com/robhagemans/hoard-of-gwbasic).

It is full of fascinating and somewhat horrible advice. For rendering text-mode user interfaces the author recommends having a ~4000 bytes binary file saved that is just BLOADed straight from disk into graphics RAM (in text-mode that sets all the text and attributes/colors for the screen). Tricks like that would probably never cross my mind, being used to having to load some library to draw anything to a screen.

I discovered just some day ago pc-basic is a really impressive project. pip install pcbasic gives you a portable python-implementation of essentially GW-BASIC, running in a terminal or graphics window. But you can of course also grab the MIT-licensed GW-BASIC 1.0 that Microsoft released a few years ago (and that TK Chia modified to make it possible to build) and run that in DOSBox. I am having a lot of fun with both of those.

https://github.com/robhagemans/pcbasic https://gitlab.com/tkchia/GW-BASIC

Doing graphics via the framebuffer is really slow on modern hardware. Even if you want true pixel-perfect graphics (something that modern 3D-rendering API's aren't easy to use for, hence where simply relying on the framebuffer is the most obvious approach) it's just far better to use GPU compute.

Actually even simple GPU compositing (which can be feasibly made pixel-perfect, as shown by its routine use w/ modern desktop environments) gives you an unlimited amount of arbitrarily-large "sprites" - way better than what you get with pure CPU rendering on a framebuffer, and something which can be quite useful in a real program.

Yeah, I think it should be emphasized that the framebuffer (in this sense) is actually an outdated abstraction and not the "low-level" or "raw" access to the hardware that one might naively expect it to be.

The X server is mostly irrelevant, these days you'd use something like SDL for a simple 2D game, which abstracts it away entirely and works just the same on the framebuffer and under X.

So no reason not to use X/Wayland since it's just more comfortable to develop for.

This wants something like a fast P3 or P4 to get any usable speed, sadly. Good luck getting this operating on a Cyrix.

Indiana jones theme playing

True. I've tried it on a Pentium 166/MMX with a Voodoo 2 and it runs about 15 fps.

I think that this might be due to the specific version of VESA stuff it ships with causing the problems.

The Voodoo 2 completely takes over display output. VESA stuff shouldn't have any effect in this case.

The Voodoo2 can not completely take over display output - that's why it needed a 2D card for passthrough until the Voodoo Banshee.

when testing native builds I was using a Xeon E5v2.

why bother with anything slow as a p3?

Aside, this website is so nostalgic. Perfectly captures the 90s.

My public library has this website blacklisted due to "proxy avoidance". (I can't find anything about proxies on the site, so that's odd.)

I was able to load it on my phone though, and it looks bloody cool.

Reply on news.ycombinator.com