OSDev.org

Hi,



Don't misunderstand me - I think aeBIOS (at least the idea behind it - I haven't seen the code or used it) is good; as it allows people that are interested in developing an actual OS to write 32-bit boot code (possibly using GCC) and avoid hassle.



Here's the problem - attempting to pretend that MikeOS (or MikeOS32) is an educational OS, and ignoring the fact that it's almost impossible for any OS to do anything right while still tethered to the BIOS, and therefore impossible for MikeOS (or MikeOS32) to do more than teach people how to do it wrong. It's like putting up a big sign that says "learn boxing here" to attract people that want to learn boxing, and instead of teaching them anything about boxing you just punch them in the face for hours (and trick them into thinking they've learnt boxing).

I try to teach people how to do it right (I'm definitely not perfect, but I do try). This means that after someone has become a victim of "MikeOS misinformation" and learnt how to do it wrong, I end up with a lot more work just trying to reverse the damage before these victims can even start down the "doing it right" path. It claims to be an educational OS but only makes it harder for people to learn. That's what annoys me. Calling it an educational OS (or saying it's "a learning tool to show how simple OSes work") is false advertising. It's far more appropriate to call it an "anti-educational OS".

Once you stop pretending it's an educational OS you see it for what it really is - an OS that made the fatal mistake of relying on the BIOS and then couldn't grow beyond the limitations that relying on the BIOS caused. It can't support IO APICs because that'd break the BIOS it relies on, it can't support USB controllers properly because that'd break the BIOS it relies on, it can't support HPET properly because that'd break the BIOS it relies on, it can't support PCI devices properly as that'd break the BIOS it relies on, etc.

Using aeBIOS (for MikeOS32) just makes it easier for all of the problems in MikeOS to continue existing and fixes nothing.


Cheers,

Brendan

Oh dear. Again: I could post here hundreds of mails I've received from people who got into OS development thanks to MikeOS, who enjoyed toying around with a simple real-mode OS, and who have now moved on to completely different (C-based, protected mode etc.) projects. They know the difference. Humans can learn different ways to do things, Brendan -- you need to understand that.



Er, I never intended it to grow beyond those limitations. As before, you are redefining MikeOS's purpose to support your argument. Every time when someone has asked me how to implement USB support and other advanced features in MikeOS, I tell them that the real mode, 16-bit approach is not suitable, and they need to go a completely different path with protected mode etc. I've never once said that MikeOS should be the basis of a fully-fledged, modern OS.

Mike

Hi,



So, hundreds of emails from people who got fooled by the words "a learning tool to show how simple OSes work" on the web site, who wasted time (hours? days? months?) playing around with it before they figure out they've been misled, and finally realise it's a pointless distraction and move on to something that's actually practical?



So, every time when someone didn't know it was a dead end and wanted to add USB support or other advanced features, you had to admit to these poor people that they've learnt nothing useful and that they have to go down a completely different path?



But you do say it's an educational OS, which is what I have a problem with. If you didn't try to pretend it's useful for learning (e.g. and only described it as a fun hobby OS) then I'd have no problem with it.


Cheers,

Brendan

Ah, so you know my own users better than I do! And you obviously have much more contact with them. I feel sorry for those who've learnt basic assembly language via MikeOS, and those who've created little hardware projects on old PCs using MikeOS. I know various hackers who have revived old kit and made custom OSes to drive obscure hardware using MikeOS.

But there we have it: Brendan declares that they've all been misled and wasted their time. Nobody should start doing anything unless Brendan has officially sanctioned it as practical. What breathtaking arrogance... I thought OSDev.org was "The Place to Start for Operating System Developers", but clearly it's "The Place to Discuss Operating System Projects that Brendan Approves."

MikeOS is hardly ever mentioned on these forums, and you've shown that you have no idea what people are using MikeOS for. This is all going on in your head Brendan. Try toning down your ego, instead of believing you're the ultimate judge of what is worthwhile. People hack on open source stuff for lots of reasons, and they don't care what you think

Mike

Hi,



All of the people that use MikeOS for learning assembly, or hardware projects, or whatever is fine; and has nothing to do with what I'm talking about. This is what's known as a "red herring", designed to distract everyone from my primary complaint.

You tell people that it's a learning tool to show how a simple OS works. Does it show how virtual memory (and paging) works? PCI enumeration? How about APICs? Does it show proper device driver interfaces? Asynchronous file IO? Scheduling? Network stack? Inter-process communication? A simple OS designed for learning (e.g. Minix) has all these things so that people can actually learn from it.

Is there anything that a beginner can learn from MikeOS that makes your "a learning tool to show how simple OSes work" statement more than an outright lie?

Please attempt to answer this without trying to dodge question.


Cheers,

Brendan

But before you said MikeOS is pointless. Now you've just admitted that people are learning things from MikeOS, as per the project's goal. Try to keep a coherent argument going...



Er yes Brendan: how to make a simple real-mode OS in 16-bit x86 asm. Exactly as described. Use all the bold and underlining you want, and keep ranting (nobody else seems to have the same problem), but it just makes you look a bit creepy. Relax, spend time outdoors, ignore threads with MikeOS and you'll be happier.

M

You could of course argue that showing people how a bubble sort works is not educational because it is hopelessly slow at sorting things, but it is of educational use for that very reason - you use it precisely to show people its limitations, and there is also a lot to be gained from it educationally if people experiment with modified versions of it to see how easy/difficult it is to improve on it, even if no such modified version will ever be worth using for anything in the real world.

If people are only allowed to study highly complex operating systems, it could be very difficult for many of them ever to get their mind round one at all. For educational purposes, what you want to do is start by looking at a range of simple operating systems and to discuss which ones are badly designed and which are well designed. The better designed ones will be the ones that are better able to be evolve into more advanced operating systems, but all of them will arguably be badly designed because at some point major aspects of them have to be abandoned and replaced in order to accomodate something that simply can't be done in a simpler OS. MikeOS is a useful illustration of a simple OS which is too simple to be able to do things the ideal way and which could be better designed in many simple ways. That doesn't mean it isn't worth looking at, and it's also useful for educational reasons to look at it's potential to be upgraded into something much more capable without giving it a radical redesign, even if it turns out that there is an impassable barrier higher up at some point which it cannot cross.

Young children play with simple toys which have limited capability. Older ones play with more complex toys which do not suffer from so many limitations. We don't throw out all the simple toys from the shops and say that children shouldn't be allowed to have them because they are more limited in what can be done with them than more advanced toys, but instead we allow children to explore those limits and push the capability of those toys as far as they can, and then we encourage them to move on to bigger things. That is extremely useful in helping them develop their intelligence. When I look at MikeOS I see something that has not been pushed anywhere near to its limits, and I also see something that does have severe limits and which is clearly not a place you would want to be trapped forever. There is plenty to be gained from playing with it and it is therefore useful, just so long as people are warned (as they are) that it is only a stepping stone (an optional one) to bigger things. If people want to step on it, that's fine, and if they want to skip over it or follow a different path, that's fine too.

What would ideally be done with MikeOS is that it would be developed into a series of example operating systems with small differences between them, and those small differences would enable significant advances for very little extra code, such as turning it into a multitasking OS, giving it a decent screen mode to work with, adding paging, switching the whole thing from using the PIC to APIC, and anything else you care to suggest. You could then introduce people to the simplest version, show them its limitations, move them on to the next version, most of which would already be familiar to them, and show them how it overcame some of the limitations of the previous version, then point out the limitations that are still there and move them on to another version, etc. That would provide people with a lot more value from studying it, building repeatedly on what they already know without them having to learn about a whole new OS every time. At some stage, the way it's tied to the BIOS could be overcome in MikeOS32 by writing alternative code to replace the BIOS functions (though it would be kept to a very small set of vital BIOS functions rather than trying to replace the whole bloated shebang), and it looks as if there is a route open to taking it beyond there into multiprocessing too just through a series of small evolutions without it ever needing it to be totally abandoned and replaced with something entirely new. The same thing could of course be done with many operating systems, taking people through a series of versions which illustrate the course of its evolution as it tries to overcome design limitations in earlier versions.

As it stands, MikeOS only comes in one primitive form, and then it leaves you to move on to look at other operating systems, but it clearly does show how many simple OSes work (as well as how they don't). I haven't looked at it, but it may be that Minix is a better place for some/all people to start and that it can take them through the whole journey already without them wasting time on MikeOS or any other simple OS. That I do not know. Perhaps the wiki should have (or maybe already does have) a page suggesting a good study route to follow through a range of operating systems which would show the best way(s) to people who have difficulty getting started in understanding/writing OSes so that they could be steered towards the best examples to study from the start and thereby learn to avoid all the major pitfalls before they start wasting years of their lives trying to write their own crap OS (though of course it isn't entirely a waste as they're bound to be learning some transferable skills along the way). I don't know if MikeOS would merit a mention on such a page because I haven't looked at the alternatives, but it seems reasonable to me to think that it could be listed as one of the really simple OSes that might be worth taking a look at before moving on, but the key to how long anyone spends working with it would be entirely down to how quickly they take on ideas and how difficult they find it to get their head round more complex OSes. Some people are able to start out looking at Windows or Linux from the off, while others need to start with something that's stripped right down to the minimum if they're to have a chance of understanding it at all.

Hi,



If it's done correctly (e.g. you show bubble sort, then you show other sorting algorithms, then you explain why bubble sort is bad), then showing people bubble sort can be valuable as it helps them avoid it. However, if someone only shows bubble sort, claims that it's "how sorting works" (even though no practical sorting works like that), and fails to show other sorting algorithms, then you end up with people who haven't learnt that bubble sort is bad that don't avoid it.



Yes; however nobody attempts to claim that a child's toy aeroplane is a learning tool that's going to help children design real aeroplanes. The child's toy aeroplane only helps the child recognise the general shape of an aeroplane; and if we had a toy that looked nothing like an aeroplane it wouldn't even do that. In that case you could call it a "fun abstract shape for playing" but an honest person wouldn't call it learning tool that's going to help children design real aeroplanes. In the same way, if MikeOS's web site claimed that MikeOS is "a fun abstract piece of software" it'd be fine, but calling it "a learning tool for OSs" is dishonest.



When I see MikeOS I can see "a fun abstract piece of software". More specifically, I see a wrapper around BIOS functions with none of the pieces that are needed in a real OS, where the only thing anyone could possibly learn about OS design and OS development is how to do it wrong; and instead of warnings to inform people that it's severely limited and entirely unsuitable for a real OS it only says "it's a learning tool!".



In theory, I agree with you completely. In practice you can't make incremental changes like that - as soon as you do anything that breaks the BIOS you have to completely rewrite the entire OS and you're back to the beginning and everything you learnt is useless/discarded. A far better idea would be to start with tools and booting, then add (e.g.) memory management, then add (e.g.) scheduling, etc; so that you're starting simple and adding more complexity, but don't hit the "it's all useless, throw it all out, sorry for wasting your time" limitation that relying on the BIOS causes. This is how most (all?) of the OS development tutorials do it.



It doesn't show how anything in any modern OS works at all.



To be honest; I'd suggest the best learning route would begin with theory; possibly starting with (e.g.) "monolithic vs. micro-kernel vs. exo-kernel" and the advantages/disadvantages of each; then moving on to memory management and virtual memory (and the advantages/disadvantages); then doing scheduling algorithms, etc.



MikeOS would probably merit several mentions; but they'd all be warnings and/or examples of things an OS shouldn't do.


Cheers,

Brendan

(disclaimer: I haven't ever tried MikeOS, so I'll go by what's been mentioned in this thread as fact)

There's a huge world of difference between a "Simple OS" and a "Multiuser multitasking OS", and neither of which is a proper definition of a "Modern OS" which only really means it's been written with the legacy lessons in mind - and might equally well make the same choices on purpose rather than out of ignorance.

There was an age where DOS was the operating system of choice. Windows might have peeked around and provide a tool to do things in a more orderly fashion, but many people then and many people now don't need to run more than one task at the same time. And even now DOS provides you with the easy ability to get to the hardware and directly poke away at it. You won't be able to do that nicely under the current standards, and it would be night impossible to do that in an OS that Brendan calls "modern", or more likely, "his own".

This is exactly the reason why we have things like Arduino's - you write the infrastructure and you have a bunch of called provided by the system that does the I/O for you. You still write the software and make yourself an autonomous system for your own use. The result is often simple, but it can be surprisingly "modern" - possibly more so than either BCOS or Mike's.

Arduino's are severely limited in their own right (We have raspberries that gives you more power at the cost of getting a Linux), but it is also their ease of use and simplicity into getting things done that gets people onto the platform, makes it entertaining, and the mere fact of not getting in the way results in more people learning from it as would be from a dry lecture.

_________________

I have told people on regular occasion to use something like DOSBox and assembly to mess around with computer internals and directly poke things so they can immediately see what the result is. I should probably read up and consider suggesting MikeOS for providing what these people really need without having them go through an install of DOS on real hardware and the increasing toolchain problems that come with it.

Hi,



Ah, no - don't do that. In fact, don't assume anything. Take a really good look at it yourself (it won't take you long - it's only 12 files of assembly).

You've been around long enough to know that most beginners have a tendency to emulate what they've seen; and I'd be willing to bet that you'd be able to look at 80% of beginner's projects and guess exactly which tutorial they started with.

With this in mind; have a really good look at MikeOS and then tell me if you'd recommend what you've seen to beginners. Is it something you'd describe as "a learning tool to show how simple OSes work"?


Thanks,

Brendan

My point was that based on the argumentation alone you couldn't demonstrate MikeOS to be a bad idea - and I think with this targeted request you only show you can't win this particular debate.


So if the actual source code matters, then it means that it will be in the details, and Mike is obliged to hear the improvements you are willing to share. But if it is something fundamental like you seem to argue, then I can only conclude we differ on what adequate educational material should actually encompass, that we're not going to agree on it, and most importantly, leave it at that before it gets religious.


I intend to look at MikeOS in more detail, but only after this is over.

IMO, using RM/OS as a tool to learn OS development limits one from many modern concept developed in the past 20 years, as the list Brendan suggested - This may teach some historical things, why things to be done that way (on legacy/already distinct stuff), about just as good as studying FreeDOS, but then lost the opportunities to learn knowledges advanced after that.

On the other hand, using tutorials suggested by OSDev.org, Bona Fide, or even buggy JameM's kernel provide an overview on basic components of an OS, and one way of "In what order to implement those components" - which is pretty simple enough, more complete overview, and still manageable for starter.

Although both side has its value, but starter has tendency to lock himself/herself to things first seen.
There is little loss if one start with PM/long mode tutorial; however one may miss too much if locked himself to the RM tutorials.

To prevent Brendan from starting this argument in any future MikeOS-related threads, I've tweaked the description on the MikeOS site:

"It is a learning tool to show how simple 16-bit, real-mode OSes work"

Nobody sane can dispute that now. Whether it's worth learning to make a limited real-mode OS today is a matter of discussion elsewhere, but given the cool projects that people have made based on MikeOS, driving old and obscure hardware, I know plenty of people have learnt a lot from it. They've learnt stuff that they've put to real use, so nobody else can say what's practical and what isn't.

MikeOS isn't perfect, and it's very limited. But it is an OS, it loads and executes programs and provides features via system calls. And people are learning from it -- perhaps not what Brendan says they should learn, but the feedback from my users is what matters most, and not hypothetical discussions on forums.

That's it from me on this matter; if anyone has any technical MikeOS questions, fire away

Hi,



This may be a reasonable compromise - not as far as I'd go, but probably further than you wanted to go.


Thanks,

Brendan

I am not going to comment on the debate itself but I have another issue I would like to bring up: 16-bit code and Real mode in general. Why using Real mode implicitly means that we have to keep BIOS involved in? We could build an OS that takes the hardware control regardless of the CPU operating mode. Of course, real-modes OSs are much more tempted to use BIOS at run-time. However, it does not have to be that way but perhaps it is correct to say "real-mode OSs use BIOS" because almost all of them surely do use it.

It is more than clear that discarding BIOS means that we can start making hardware configurations and things like that when we do not have to care of whether it has affects on BIOS or not. I think it is (or should be) "on/off relationship" with BIOS, you either use it for doing everything or not use it at all. Worst thing I could imagine is something between these two, e.g. do hardware configurations, hook up interrupts, etc. It will surely make BIOS think "what are you doing, I am in charge here. I you don't like it, please take care of everything by yourself". I am not saying this has anything to do with MikeOS. It will probably be "on" with BIOS like it should (if that is the design goal).

What if I made a small toy (like all my OS attempts so far) OS that is 16-bit OS that does not rely on BIOS? I would run the same binary on really old hardware and also in Long mode (16-bit) on modern hardware. Ok, I am just joking. I am not going to do that. However, it could be fun!