Modern 64-bit DOS Idea

[OgreVorbis]

I used to have an account here about 10 years ago when I briefly got into OS dev. I have not since written any assembly so my skills and knowledge are limited.


I have this idea for an OS:

OK, so for a long time I've wanted an OS like this and I decided to make this post to see if other people agree.
I've only programmed a very basic real-mode OS before, so I don't think what I am going to put down here will actually be something that I will be capable of. I can make a real-mode OS pretty easy because I rely on the interrupts. But to make a protected mode OS, I have no idea.

Anyway, here we go:

My ideal OS would be best described as a majorly updated and improved version of DOS. Everything is CLI except for the programs and apps themselves.
It's essentially what DOS would be like now if Windows never happened. The main goal is to make an OS where 3D graphics applications and games can run as efficiently as possible.

The filesystem would be very simple FAT with no permissions, no user accounts, no BS. This part would be kept traditional to focus more energy on the purpose. There's nothing wrong with FAT now that we have SSDs.

Everything runs in ring 0.

It would be protected mode written in x64 assembly/C and have VESA support by default.

It would have an easy programming interface for OpenGL (maybe SDL) integrated into the built in compiler.

The default CLI would be rendered in a VESA screen mode for more space.

There are no windows. The screen would be divided in two unequal parts horizontally. One third on the bottom is the CLI and the extra 2/3 on top is the application. This gives access to the interface while the program is running. A key can be pressed to make either of these "windows" full screen. When a text based app is running, the CLI is full screen by default. As soon as a GFX app is started, the screen becomes split.

It will be a single tasking OS, but with the ability to switch tasks. If you press Home, the CLI outputs the list of programs in memory with highlight on the current running process. You press Page-Up, Page-Down to switch to another app. Each process has a number next to it. You can run up to twelve apps and can press the F keys to switch quickly. Maybe it could have TSRs for certain background processes, but the idea is that there are no services running in the background, so as long as you're not running a disk accessing app, you can just switch off the PC with no harm like DOS.

The system has a built in BASIC compiler. Yes, compiler, not interpreter. It would run as fast as C. The BASIC language is built into the CLI. It has normal DOS like commands for file manipulation, but then it also has the commands of a full programming language. The emphasis of the language is on OpenGL graphics. It has built in functions to make programming OpenGL easy. The idea is to make it like a much more modern version of QBASIC. It has that immediate feedback of creating 3D graphics easily.

The OS would essentially be recreating old fashioned home computers/consoles using modern hardware and graphics. You can make games and other graphical based applications easily without the headache of compiler problems because most features are built into the language. I am blown away that there is no OS like this. All modern OSs seem to focus on having a GUI. This OS may provide some API for buttons, etc. but the OS itself will be entirely command line. If the command line is made very powerful, it will be more efficient to use than a GUI based OS. Yes, GUIs help the beginner get acquainted with the OS more quickly, but in the long term, the speed of use is actually much slower than typing in commands. And of course a GUI could still be created for certain users, but it would run as a separate system like it would on DOS.

There is currently NO OS like this at all. I guess the closest would be TempleOS, but even though the philosophy is correct, the execution is terrible and the UI is a clusterf*ck. The three most common OSs we all know (Windows, Linux, MacOS) are all bloat bombs and do not really cater to the hobbyist programmer. They cater to the masses. Linux used to be like this, but it never truly had the right philosophy. The correct philosophy is one of elegance and simplicity.

[iansjack]

Is there really a demand for an OS that has no security, where any user program can crash the system? And what do I do with the other 11 cores in my processor?

How about the Internet? Do you intend for your OS to be able to access it, despite the total lack of security? If so, what happens whilst you are downloading a file - do you have to twiddle your thumbs until the single task completed its job? If not, do people really want an OS that can't talk to the world?

Last comment: don't make me go back to interpreted BASIC now that I have tasted proper languages. You may want it to be as fast as a compiled language but it won't be.

[PeterX]

Sounds like you have a plan. Be prepared that it might sometimes be harder than planned.

I wouldn't call DOS elegant, but that's a matter of taste and opinion. (I call Smalltalk elegant in some ways.)

I think Plan9 (and its many derivates) have a similar divided screen like you mention.

I like the idea of OpenGL-Basic. Though with a little effort you can have similar (not exactly same) functionality with Gambas and Python.

Greetings
Peter

[Schol-R-LEA]

There most certainly are DOS-like 64-bit operating systems - it is common enough that the wiki has a developer archetype for it, Lino Commando - though none of them are mainstream. There have been at least two attempts to port FreeDOS to long mode, though I have no idea what the status of either of them is (I did find the SF page for FreeDOS-64, but it seems empty).

There's always room for one more, though, if that's what you want.

Most people who want a CLI or minimal panel-based interface use Linux or FreeBSD, either with just the shell, or with a stripped-down tiling window manager such as Notion or Awesome. While Linux is clearly not what you want, and these WMs are very different from what you have in mind, you may want to look at them to see if any of their ideas could be used in your OS interface (e.g., the way they use tabbing to switch between the panels).

Most people who want a BASIC interpreter as a primary interface seem to have thrown behind retro-computing projects such as Color Maximite or Commander X16, or else the various Raspberry Pi BASIC implementations, but again, none of those seem to be what you are looking for.

I'm not sure if a strictly monotasking system really makes sense for a long mode system, as you would still need to set up the Global Descriptor Table, Local Descriptor Tables, and Interrupt Descriptor Table; memory protection (which really isn't optional in either protected mode or long mode, even if you've disabled everything it is still present); a scheduler; and so forth - in effect, you'd have a multitasking system with just one permanent task. It is possible, of course, but you may be fighting the 64-bit mode itself to do it, especially on modern UEFI systems. In any case, what you describe isn't monotasking as such, but rather, multitasking with a very minimal scheduler which doesn't time-slice the CPU (something along the lines of the old 4DOS system).

Just some food for thought. As I said, there's always room for another OS project.

[moonchild]

There's nothing wrong with FAT now that we have SSDs.

SSDs are no less susceptible to data loss than spinning rust. FAT has no ability to do journaling or CoW, mirroring, or RAID.

[nullplan]

SSDs are no less susceptible to data loss than spinning rust. FAT has no ability to do journaling or CoW, mirroring, or RAID.

And, to my knowledge, it is impossible to have a FAT FS larger than 16TB. And larger than 2TB already requires some fiddling, and even SSDs are already at that size

[Solar]

In any case, what you describe isn't monotasking as such, but rather, multitasking with a very minimal scheduler which doesn't time-slice the CPU (something along the lines of the old 4DOS system).

Pre-X MacOS worked similarly; apps were expected to actively yield to the OS ("cooperative multitasking"). Yes, the obvious issue is that you would not be making use of more than one core, throwing away most of your CPU's power.

As for "no security", I concur that not having that would be a very bad idea for a desktop OS. We'd be looking at a novelty OS, or something that runs one specific application only, embedded style. Only that you aren't likely to throw a x86_64 at an embedded problem...

[eekee]

Sounds very much like a cross between DexOS and my as-yet unimplemented plans which I've written about rather more than necessary on this very forum! DexOS was a 32-bit single-tasking OS; it pretty-much predated 64-bit systems. It had a command line and a games-console-like program launcher because it was envisioned as a console with PC hardware. (There was a window system in a later version. I don't know why.) It didn't have a split screen.

My plans involve just such a split screen, but I'm not really planning for single-tasking.

I think Plan9 (and its many derivates) have a similar divided screen like you mention.

That's the Sam text editor. It is one of the editors included with Plan 9 (and one of the few editors ported to it altogether.) It's just the default configuration of Sam's windows, but it is a fairly good one. Plan 9 itself has a window system which would look fairly normal if it had title bars.

I was inspired by a bunch of things:

• colorForth where you can type commands with the last program's display routine still running
• Sam
• the split screen modes of my Ataris in the 80s, where you could type BASIC commands in a 4-line window below the graphics display
• a color picture on a magazine cover when I was a very impressionable kid, which had 2 80s monitors with commands on one one and graphics on the other

Anyway, I obviously think the UI is really cool!

Single-tasking on the other hand... I don't know, there's a ton of things that could be said for or against. Turning the computer off is an issue primarily due to disk caching, which you likely do want. If you used a disk cache in MS-DOS, you couldn't just turn it off. (And drives have built-in caching since the 90s.) On the other hand, Plan 9's diskless 'terminals' were multitasking systems which could just be switched off.

As for responsiveness, while my single-tasking Palm m515 is possibly the most responsive device I've ever owned, Linux was not noticeably far behind before they implemented preemptible kernel, fast timer ticks, and real-time features. In fact, all of these seemed to reduce the responsivity of my Linux systems, so I tend to distrust common wisdom here. A lot of what I do on DOS is starting programs (in an edit-compile-debug cycle), where DOS (MS- or Free) is far less responsive than Linux! It's better with a software disk cache. Bear in mind that a disk cache may need to do things in the background, especially if it caches writes. This isn't exactly meeting the goal of single-tasking. Then again, you could dedicate a core to the disk and maybe other IO.

Game performance... eh... I assume you mean 2D games. Load up an OpenTTD game with a lot of trains moving at once. I'm looking at one with 16 trains - 144 individual graphics - all as smooth as silk on a rather poorly-maintained Win10 machine. It's a multi-threaded game; can't even be build for DOS any more.

There *are* some tricks which can only be done on single-tasking systems, I think, but they depend on knowing precisely what hardware end-users have. This was once possible for PCs, but not for a long, long time. There's a document floating around the net and a website too which purport to be assembly-language references but are actually *timing* references for the 386 and 486 specifically. That's about the last time these tricks could be used, I think. Even then, there was a fairly wide range of bus and CPU clock speeds. Oh by the way, PCI will not help if you want very tight responsiveness, but really that comment applies to 33MHz PCI buses...

Overall, I think responsivity problems these days are caused by Linux (Android) trying to be clever and I guess app programmers not knowing they must use real-time facilities for accurate timing.

Edit: I once thought a single-tasking system with its hooks into interrupt handlers for driver extensions and other TSRs might well be more complicated than a well-designed multitasking system, but I don't remember my full reasoning now.

[FranchuFranchu]

This sounds really similar to TempleOS.