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.
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.
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).
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.
(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.
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.
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.
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.
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
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.
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.
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 ?
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.
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.
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.
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.
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.
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.
82 comments
[ 3.0 ms ] story [ 164 ms ] threadMaybe Quake II on DOS will run with less system memory than the Windows version.
https://www.mobygames.com/platform/dos/year:1997/ https://www.mobygames.com/platform/dos/year:1998/
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.
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.
[1]: https://en.m.wikipedia.org/wiki/Norton_Commander
Volkov was much faster on older machines...
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?
What has OS got to do with possession of some hardware?
Though even first Unixes "it's a file, just write to it" were better but just above the bare minimum
I really can't grasp the TUI hype that is going on nowadays.
We have command completion. And the GUIs have mostly become enshitified.
Also not true for FreeBSD and GNU/Linux GUIs.
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.
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.
One can be considered lucky if the GUI allows the export & import of settings.
The DOS PC was really clunky, inferior, and a struggle to use compared to any of the alternatives.
At the time, I was really annoyed I couldn’t convert my DOS knowledge into Unix (Linux) shell commands - when need came.
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.
Whatever folks think of Ratatui, Turbo Vison and Clipper did it first.
Re: TUIs, I wish there were more like the ones there were in DOS with CUA keybindings.
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.
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.
0, https://www.japheth.de/HX.html
It looks like at least some versions of Allegro and SDL supported it as a backend.
Nice breadcrumb: https://web.archive.org/web/19991008210746/http://webpages.m...
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.
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.
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.
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.
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
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.
So no reason not to use X/Wayland since it's just more comfortable to develop for.
why bother with anything slow as a p3?
I was able to load it on my phone though, and it looks bloody cool.
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