OSDev.org

So, I've been working on an OS, and I've restarted several times due to not having a plan. I now have a plan, and some principals that I've laid out.

• The user has as much power as the OS. if the OS is capable of doing something, the user do it.
• Keep it as minimal as possible. E.g. C compiler/linker, Assembler, text editor.
• Programs use no dependencies other than the kernel itself. Make everything self contained enough to run on any system running the OS.

Other than that, I have a few other plans for the design.

• Users write their own programs and utilities for the large part, and any non-user made program can be rewritten, replaced, or modified and recompiled.
• 16 color text mode only, as that's easiest to implement and make programs for.

If any of y'all are interested in helping out, let me know

flossy wrote:16 color text mode only, as that's easiest to implement and make programs for.

What about hardware that isn't VGA-compatible?

Octocontrabass wrote:

flossy wrote:16 color text mode only, as that's easiest to implement and make programs for.

What about hardware that isn't VGA-compatible?

Isn't it reasonable to send ANSI escape codes and let a higher level sort that out, possibly with a fallback of only displaying text with no colors?

flossy wrote:So, I've been working on an OS, and I've restarted several times due to not having a plan. I now have a plan, and some principals that I've laid out.

• The user has as much power as the OS. if the OS is capable of doing something, the user do it.
• Keep it as minimal as possible. E.g. C compiler/linker, Assembler, text editor.
• Programs use no dependencies other than the kernel itself. Make everything self contained enough to run on any system running the OS.

Other than that, I have a few other plans for the design.

• Users write their own programs and utilities for the large part, and any non-user made program can be rewritten, replaced, or modified and recompiled.
• 16 color text mode only, as that's easiest to implement and make programs for.

If any of y'all are interested in helping out, let me know

What help do you require? I can provide public domain code to assist you to do most of those things. Actually, all of those things unless you want to quibble about the text editor.

Or maybe I can ask specific questions like how many decades you intend to devote to this task, how many lines of code you think each component will take, which one you want to do first, and why, whether you have a market lined up, how much you are planning on paying those who assist you, and whether it is more than other projects pay, and whether you think that pay is sufficient motivation, which of the 20 billion existing OS projects you intend to replicate (to the exact same state that they made it to), and why.

Sounds a lot like a very early MS-DOS. Does it differ in any way?

I think you’re going to have to give a lot more details about yourself and your project before you are likely to get anyone to join you. Even then it would be a long shot.

The good news is that, on the face of it, your project looks like one that could easily be accomplished by a single designer/programmer.

iansjack wrote:Sounds a lot like a very early MS-DOS. Does it differ in any way?

I think you’re going to have to give a lot more details about yourself and your project before you are likely to get anyone to join you. Even then it would be a long shot.

The good news is that, on the face of it, your project looks like one that could easily be accomplished by a single designer/programmer.

"easily"? How many people have written all of those things he mentioned by themselves? I'm not aware of anyone at all who has done the lot. And I've been doing mine for almost 3 decades. How many people have the motivation to work for free for 3 decades? Although there were years of gaps, but those gaps were often spent filling in theory. And mostly it was part time too. But other times, like now, it's more like 14 hours per day, 7 days per week.

Compilers, assemblers, and text editors already exist and can be ported to a new OS with little real effort. As for the OS described, it took Thompson about a month to write a more powerful OS than described here, complete with assembler and text editor.

Three decades seems a little long for such a simple system.

iansjack wrote:Compilers, assemblers, and text editors already exist and can be ported to a new OS with little real effort.

Well if you accept porting, rather than writing, the whole mission can be done in a few seconds by copying Linux.

As for the OS described, it took Thompson about a month to write a more powerful OS than described here, complete with assembler and text editor.

Maybe he's a genius then.

Three decades seems a little long for such a simple system.

Maybe I'm really stupid then.

So "easily" depends on whether the OP is stupid or a genius or something in-between. It's probably better to say that it varies from one month to 3 decades (and still going) depending on the talent of the programmer, so don't have false expectations, although you can always go for the "copy linux" option so you START with a billion-dollar working system. And if the problem is that Linux isn't "simple", then start DELETING code from Linux. The kernel is supposedly very small anyway.

Even if you start entirely from scratch any competent programmer should be able to produce a kernel as simple as MS-DOS, a text editor, an assembler, and a compiler for a simple high-level language in less than 3 decades. That’s the sort of thing covered in a university CS course. I’d be surprised if many people here haven’t done that.

But if you really want to start from scratch you also need a boot loader, a BIOS or equivalent, a CPU, and support hardware. And don’t read any books on computer science - that would be cheating. I agree that implementing a working system with no reliance on previous work (although I hope you’ll allow me to use basic components such as transistors) would be a tough project.

I wouldn’t say that Thompson was a genius, a much misused word, but he was certainly good at his profession. He’s not unique in that.

iansjack wrote:Even if you start entirely from scratch any competent programmer should be able to produce a kernel as simple as MS-DOS, a text editor, an assembler, and a compiler for a simple high-level language in less than 3 decades. That’s the sort of thing covered in a university CS course. I’d be surprised if many people here haven’t done that.

I think you're overestimating how many "competent" programmers there are. When I completed PDOS/386 basic functionality, I deliberately stopped to see if someone else could maintain the code. There were still several bugs there. The main bug I wanted fixed was ld corrupting the disk when compiling a DLL. The bug was almost certainly in fat.c, about 3800 lines of code (12/16/32/LFN). I have previously tried paying programmers from the 3rd world some money to see what happened, and mostly nothing happened and mostly they ran away. First world programmers tend to want open-ended hours on full commercial contract rates to do anything. There are osdev hobbyists who are sometimes willing to do things, and normally don't want money, even if offered. A couple of osdev hobbyists took some money (US$50 is what I was offering for the things I wanted), but only for adding some extra functionality - they had showed interest in finding the bug, but changed their mind. A group of friends turned up asking to work on a project and I offered them the money and they were all excited. Then the "ace" programmer admitted he couldn't fix that bug and they all went away. I think they were traumatized.

So despite something like a year trying to ensure that PDOS wasn't going to be a one man show, I had to fix that, and the other bugs myself, and PDOS remains a one-man-show.

It took more than a decade, maybe more than 2 decades, just to get the C library banged into shape. That's 17,000 lines or so. That included abstracting the mainframe file system. It was in fact only a couple of years ago that I found out that the MVS portion of PDPCLIB was in fact misnamed and was really "block mode", and that PDOS/386 was fundamentally misdesigned, and PDOS-generic was the way to go, leveraging the C library instead of the OS.

I got my CS degree in 1998 or something, and I had started work on the OS in 1994. The OS degree was part-time, over 10 years or something.

But if you really want to start from scratch you also need a boot loader, a BIOS or equivalent, a CPU, and support hardware. And don’t read any books on computer science - that would be cheating. I agree that implementing a working system with no reliance on previous work (although I hope you’ll allow me to use basic components such as transistors) would be a tough project.

I read the books that were part of the CS curriculum, and I read most of the C90 standard, piecemeal, and I have read snippets of various things over the years, but I don't think a whole book.

Whilst I appreciate the work that you have done, you are talking about an OS that is considerably more complicated than that described in the OP.

But you certainly highlight the difficulties of making a project more than a one-man effort. If you could take the time to read just one book you might appreciate The Mythical Man-Month: Essays on Software Engineering.

iansjack wrote:Whilst I appreciate the work that you have done, you are talking about an OS that is considerably more complicated than that described in the OP.

It is specifically designed to look like MSDOS and use the same API as MSDOS. It's true that I started supporting the Windows API as well, but that's not a significant amount of extra code (and note that it was someone else who did the initial work of that, as well as getting PDPCLIB to generate an MSVCRT.DLL). There was an awful lot of time wasted because the tools weren't generating relocation information (neither a.out nor PE, due to two separate things I consider binutils bugs). I didn't realize that that was a bug though, I thought that was just the way things were. And the mainframe was deliberately tamed to support MSDOS as well. In fact, it's an ongoing effort, even as of a couple of hours ago. So basically the question to the OP would be "do you want your MSDOS-like OS to run on arbitrary hardware, ie be portable?". It took me an awfully long time to find out what the "huge" memory model in MSDOS actually was, and it didn't help that I got incorrect information in a public group (alt.os.development) with no correction from anyone. So that's if you want to support 16-bit hardware, with an arbitrary segmentation/selector model. I still haven't sorted that out yet either. I still have the number "4" hardcoded in my MSDOS executables, so they won't be able to make use of the Turbo 186 for example, nevermind the 80286 or the 80386 in PM32 with the D-bit set to 16-bit. Even the design of the OS hasn't been sorted out yet either. It's unclear to me whether I can bend PDOS/386 and leave the OS running with 32-bit D-bits below 1 MB and 16-bit above. The extensions (if any required) to the MSDOS executable so that 64k boundaries are known so that I can adjust when I've got up to 512 MB available on an 80386 (run out of selectors preventing 4 GB from being reached).

Still. All. MSDOS. No consideration for multitasking or virtual memory (someone added that to PDOS, disappeared, and then I had to spend a lot of time disabling it so that I could actually understand and debug PDOS again).

Basically that's it really. I wanted to design MSDOS "properly". Basically - if MSDOS had been written in C instead of assembler, would it have been running everywhere, including the 80386 circa 1987-ish, and the mainframe circa 1985-ish? I doubt any of the above is in any book, but I haven't attempted to search. There was also a lot of confusion as to why ANSI had standardized ANSI output but not input, but I eventually found that it was MSDOS that was responsible for that. And Windows until Windows 10 (and even then they expect you to put non-standard time-sensitive code into your application programs instead of sending two ESC for an ESC key, plus backspace deletes an entire line instead of a character). And MVS to this day unless you count Unix as MVS.

Oh, also I didn't know what a "monitor" was until recently (like 2 years), nor INT 1 and 3, and they were only implemented some weeks ago so that I could start debugging things at the assembler level as required (which it was indeed required). If you rely on an external GUI debugger instead of your own OS on real hardware, that's not really developing an OS - even MSDOS. You haven't proven that your OS can be debugged with your OS.

But you certainly highlight the difficulties of making a project more than a one-man effort. If you could take the time to read just one book you might appreciate The Mythical Man-Month: Essays on Software Engineering.

Ok, thanks. I did buy (1 year ago or something) and start reading the SubC book, basically out of desperation as it was the last missing piece of UC386, but I didn't finish it. And actually I did manage to find someone who was willing to modify SubC for fixed, reasonable cost, but it was a year-long process, and progress was made, but not enough. I'm not good with books. I prefer learning in forums such as this.

Another thing is that merely supporting two very different platforms, the PC and the mainframe, was not enough to solidify PDOS.

It was only when I triangulated to the Amiga (68000) that I was able to "design MSDOS" (PDOS-generic).

There were 2 clinchers.

1. If you want to support hard disks, good luck with that, vendors may have only supplied binary drivers for Amiga OS, and the vendor no longer exists.

2. The number 4.

kerravon wrote:It took me an awfully long time to find out what the "huge" memory model in MSDOS actually was, and it didn't help that I got incorrect information in a public group (alt.os.development) with no correction from anyone.

What exactly was the confusion/incorrectness?

alexfru wrote:

kerravon wrote:It took me an awfully long time to find out what the "huge" memory model in MSDOS actually was, and it didn't help that I got incorrect information in a public group (alt.os.development) with no correction from anyone.

What exactly was the confusion/incorrectness?

https://groups.google.com/g/alt.os.deve ... iXRm-aBQAJ

I think at the time you mentioned this, I did in fact look at the code generated by Turbo C's huge memory model when a "long" was added to a pointer, and confirmed (what I thought was) your observation that the compilers didn't generate the code I wanted.

But I think it was only after an argument in comp.lang.c where I was repeating the (believed) assertion from you that I think I had rudimentally confirmed, that I decided to check Watcom (which I think I had moved on to) to prove I was right. And I was wrong. So I apologized in comp.lang.c and wrote the above. Actually I think there was a gap before I eventually tried Watcom and I apologized belatedly.

And as per the above link, I said maybe we were talking cross-purposes, as there was no reply with clarification.