OSDev.org

The answer I would like to give is...

This OS has everything exaclty the way I wish it could be, I wouldn't change a single thing. Put down the brush, the masterpiece is complete

mycroft wrote: So, OS Devs, what makes your OS special?

PD-Windows:
1. Is public domain.
2. Is capable of running certain 32-bit Windows applications.
3. Is written in C90 plus minimal (necessary) 80386 assembler.

kerravon wrote:

mycroft wrote: So, OS Devs, what makes your OS special?

PD-Windows:
1. Is public domain.
2. Is capable of running certain 32-bit Windows applications.
3. Is written in C90 plus minimal (necessary) 80386 assembler.

It's not different as already Reactos and GreanTeaOS exists. but GreaaTeaOS is in C++ and I think they are not Public Domain.

mmdmine wrote:I think they are not Public Domain.

That's right. So if you personally would like to make a closed-source commercial competitor to the closed-source commercial Microsoft Windows, the only starting point you have is PD-Windows.

kerravon wrote:

mmdmine wrote:I think they are not Public Domain.

That's right. So if you personally would like to make a closed-source commercial competitor to the closed-source commercial Microsoft Windows, the only starting point you have is PD-Windows.

GTOS and ROS are open source. ROS is GNU General Public license.

Mine (JSD/OS) is designed around an interesting multitasking model, which I am experimenting with. I call it pseudo-singletasking or pre-emptive-singletasking. I attempt to explain it here https://jakedelmastro.com/portfolio/jsd ... m-for-x86/.

Other than that however it is really super small without any bloat and everything is designed mostly the way I like it.

Under your model a badly behaved program can prevent anything else from running.

@iansjack, yes this is by design. But only if it is the "active process" and even then the user can simply switch out of it if it locks up, by using a key combination which triggers an interrupt.

Your model is basically that used by Windows 3. It's not really desirable to rely on user intervention to prevent the machine locking up so most OSs nowadays use more flexible tasking models.

Keep in mind that not every OS is designed with a general purpose desktop in mind. There's lots of embedded systems out there that work quite well without preemption and / or virtual memory.

(And while most ex-Amiga-users would agree that virtual memory would have been a nice to-have, we have fond memories of a general desktop OS that didn't have it.)

Not such a problem in embedded systems as they normally run programs supplied with the system rather than general purpose programs.

Although it didn't have virtual memory, the Amiga OS did provide pre-emptive multitasking (although tasks could impose non-preemptive task scheduling).

Even a relatively sophisticated OS like OS/400 could be (effectively) locked by a badly written program (as I found out to the ire of QSECOFR).

For quite some time after I moved away from AmigaOS, my impression was that shareware, and even some commercial software, was extremely badly written, in that it crashed / hung far more often than I was used to.

Because the fundamental assumption on Windows / Linux was (and still is), "hey, if it crashes, at least it can't damage anything other than the document / file / project you're currently working on, the system will take care of it". To the point where people on stackoverflow argue the point that you don't have to free() your memory before the program ends, because "the OS will take care of that".

In contrast to that, Amiga developers knew very well that a faulty program could not only take its own data, but all data currently in memory, down with it, and that unreleased resources remained locked until reboot. Using tools like efence while developing / testing your software came quite natural to them (whereas I've met quite a few Linux developers in the years to come who weren't even aware such tools -- like valgrind -- even existed, much less how to use them).

And disabling an Amiga's multitasking was quite easy, there were calls for that -- Forbid() and Disable(). You actually had to do that, manually, for several critical activities that accessed global OS structures. Again, programmers were quite aware what that entailed, and made very sure their software would behave well.

Because software that didn't wasn't used by anybody, and quickly left by the roadside. While a crash now and then might be acceptable behavior on a protected system, if you know you've got no second line of defense, you tend to avoid flaky software like the plague.

@PgrAm: Interesting! I like my systems to feel responsive too. Having said that, I had no problem with Linux in that department prior to preemptable kernel and high tick speed -- bad decisions intended to increase responsiveness but which actually reduced it. I don't think yours is a bad decision. Linux's high tick speed pessimized cache usage when low-cost processors had little cache. I don't know what was wrong with preemptable kernel, maybe some lock issue which I'm sure JSD/OS won't have.

Solar wrote:Amiga developers knew very well that a faulty program could not only take its own data, but all data currently in memory, down with it, and that unreleased resources remained locked until reboot. Using tools like efence while developing / testing your software came quite natural to them...

programmers... made very sure their software would behave well.

Because software that didn't wasn't used by anybody, and quickly left by the roadside. While a crash now and then might be acceptable behavior on a protected system, if you know you've got no second line of defense, you tend to avoid flaky software like the plague.

It's looking more and more like my OS will be like this, to the point where I'm thinking of including a memory use checker in the base system. Having said that, and on the topic of special features, I'm hoping to implement relatively safe allocation strategies at the language level. It'll take some thinking about, but shouldn't be hard to implement in Forth.

On the other hand, I would argue that giant memory-hungry applications on systems with virtual memory should quit without freeing. Why? Because I'm sick of waiting for Firefox to swap all its pages back in just so it can free them! Seriously, how laughable is that? I guess the real problem might be scattering allocation metadata all over the place, but whatev's.

iansjack wrote:Under your model a badly behaved program can prevent anything else from running.

This is becomming a non-issue in the new era of multi-core processors. The latest threadripper CPU for example has 32 cores, so we're basically now at the stage where each task can be run on its own core without competing with other tasks for CPU time. That fundamentally changes what scheduling algorithms can be considered acceptable for general purpose use.

You still risk running out of cores (and multithreaded applications will want to take over multiple cores at once, since they expect the threads to be able to run in parallel). Just because you reduce the likelihood of a total lock-up doesn't mean you don't want to completely avoid it if it's possible.

Reminds me of somebody who told me that I should disable swap and let the whole computer crash if it runs out of memory… Um, yes running out of memory is bad, but I'd like having a back-up mechanism in case of emergencies (even if just to give me a chance to stop the problem without having to shut down everything and lose all unsaved/unsaveable state).