OSDev.org

Brendan wrote:

Prochamber wrote:Remind me again why all these tasks are needed.

Only a fool would attempt to predict how many tasks any end user might want. The only thing you can predict is "lower limits are less likely to disappoint".

Apparently, I'm currently using 188 processes on Linux; but Linux supports multi-threading - if it didn't support multi-threading some of those processes would "fork()" instead of using threads and there'd be even more processes. Of course your OS is very different to Linux. For your OS something like a "paint.exe " would need to use 500 processes just to get enough RAM to store a picture.

This is a hobby OS not a "windows killer" I will never need 500 processes or 188 or even 50.

How big is this picture? Why would a paint application need multiple processes? There is no limit to how much memory out of the free memory a single process can use, I don't think a picture would ever need as much memory as you seem to think it would. A 200x250 picture, which will occupy most of the screen space requires 50000 bytes of memory, which is not a huge amount and less than the video buffer used by a process but if you wanted bigger you could allocate additional memory.

Brendan wrote:

Prochamber wrote:Don't forget I still need to have the memory allocation bitmap somewhere where it can be read by the memory manager.
Sixteen kilobytes is half of the kernel buffer space. It's a nice round number and all the other buffers fit in nicely. The block size is the size it is because memory handles must of course be swapped in and out of application memory. I don't want blocks too large because that would force applications to allocate huge buffers but I don't want blocks too small because the would limit the amount of memory. What block size are you suggesting?

Given that you seem to want to do a lot of extra work just to make the OS more retarded; it's a bit hard to make sane suggestions.

However; I'd consider given each task one 512 KiB block. It's a nice round number and leaves about 100 KiB for the kernel to use (without copying) in real mode. You could even pre-allocate these blocks during boot and not bother having any memory manager at all (e.g. "task number 4 uses memory block number 4"). You could also do "max. tasks = RAM between 0x00100000 and 0xFFFFFFFF / 512 KiB" (and end up with a limit of about 6142 tasks on machines with 3 GiB or more RAM).

Basically; it'd be significantly less limited, and it'd also be easier to implement.

Of course it'd still be bad (e.g. lots of RAM wasted by tasks that only use part of the 512 KiB they're given), but it's a few orders of magnitude less bad than wasting 99.99% of RAM.

Just because it's there doesn't mean it's needed. This amount of memory is only available to modern machine anyway.

I still need a memory manager if programs required extra memory, which I'm sure there are plenty that will. Also the kernel allocates a small amount of memory.
A big problem with your proposed block size of 512 kilobytes is that the whole concept of memory manager is that data is swapped between extended memory and local memory segments. This won't work if the block size is greater than a real mode segment. Program need to allocate small amounts of memory as well without creating enormous swap buffers, i.e. currently the kernel allocates 1kb for the menu file, which two 512 byte blocks.

Extending the size of blocks to one kilobyte, two or maybe even four is possible, 512 isn't.

What I see is excuses for not using protected mode (perhaps due to spent efforts) but not reasons to use real mode(for anything good). If you see a major rewrite is not justified it's up to you, but think again what you said are compromises but not your goal.

bluemoon wrote:What I see is excuses for not using protected mode (perhaps due to spent efforts) but not reasons to use real mode(for anything good). If you see a major rewrite is not justified it's up to you, but think again what you said are compromises but not your goal.

I had intended to add simple multitasking not rewrite the entire operating system. The only real limitation (no pun intended) I've met is address space. I'm almost finished discussing my multitasking system, why change now?

I'm know everyone's ranting about how bad real mode and BIOS is but switching would be a lot of work and I can't see the advantages of it. Rather than talking about real mode and BIOS can you give me a clear explanation of the advantages of using protected mode apart from having more memory accessible?
That would be really appreciated. Also can you include differences would I need to observe when porting code?

Prochamber wrote:A 200x250 picture, which will occupy most of the screen space

Wait, hold on. 200x250 is "most of the screen space"? Do you plan on using nothing but 320x200? That was considered cramped for a UI in the late 80s.

You are imposing arbitrary limits on yourself that make your OS design seem right out of 1987. Unfortunately for your design, it's 2013. Example time: I have one 1920x1080 monitor and one 1600x900 monitor, 8 GBs of RAM, 64-bit processing capabilities, currently some 250 processes running smoothly, and a gigabit ethernet card, and this system could be considered modest on the enthusiast side. Why on earth would it make sense to design an operating system to use a resolution of 320x200 on my 24 inch monitor (EDIT: math time - that means each pixel is something like 1.6mm × 1.75mm), 8 MB of RAM, 16-bit processing mode, a maximum of 16 processes, and probably not even get to use those sweet gigabits of ethernet data?

I think my point is that you can put papier mache wings and a couple beanie propellers on a squirrel and say it's a 747 but it's never going to be a 747. And even after you're satisfied with your 747, you've learned nothing about airplane design and aerodynamics, even though you may think you have -- just that a squirrel with papier mache wings and a couple beanie propellers looks funny as hell, but no one else seems to think so.

Hi,

Prochamber wrote:

Brendan wrote:

Prochamber wrote:Remind me again why all these tasks are needed.

Only a fool would attempt to predict how many tasks any end user might want. The only thing you can predict is "lower limits are less likely to disappoint".

Apparently, I'm currently using 188 processes on Linux; but Linux supports multi-threading - if it didn't support multi-threading some of those processes would "fork()" instead of using threads and there'd be even more processes. Of course your OS is very different to Linux. For your OS something like a "paint.exe " would need to use 500 processes just to get enough RAM to store a picture.

This is a hobby OS not a "windows killer" I will never need 500 processes or 188 or even 50.

..or even 1.

Prochamber wrote:How big is this picture?

Digital cameras are currently 10 megapixels (cheapest) or more. Mobile phone cameras are currently 2 megapixels or more. Let's go for somewhere in between and say 5 megapixels. Let's also assume 4 bytes per pixel (even though a decent camera would be more). That works out to about 20 MiB.

Prochamber wrote:Why would a paint application need multiple processes?

Before, you were saying "Program Space - 64k", so I did some quick maths based on that. 20 MiB divided by 64 KiB works out to a minimum of 320 tasks (ignoring things like code, stack, etc) to get enough RAM. However, for a variety of reasons (blur, sharpen, etc) you need to be able to store "source data" and "destination data" so it'd actually be 640 tasks to get enough RAM. Of course most decent image editors let you undo changes (by storing previous versions), so you could add another 3200 tasks (to get enough RAM to be able to undo the last 10 changes). This gives us a total of about 3840 tasks to get around the "Program Space - 64k" problem.

In reality, it's not going to work like that - any application developer capable of writing a decent application would just switch to protected mode themselves and take whatever RAM they want (which is exactly what happened for DOS).

Prochamber wrote:There is no limit to how much memory out of the free memory a single process can use, I don't think a picture would ever need as much memory as you seem to think it would.

This must've changed then. Earlier you were saying "Program Space - 64k" and "8 MiB max." for the OS's memory manager. That's nice I guess, but if applications are in real mode they can only really access 640 KiB so you'd still want 384 tasks.

Prochamber wrote:A 200x250 picture, which will occupy most of the screen space requires 50000 bytes of memory, which is not a huge amount and less than the video buffer used by a process but if you wanted bigger you could allocate additional memory.

WTF? I can imagine it now - "Here's a picture of my new girlfriend, she's the pink pixel near the middle of the sixth row!".

Prochamber wrote:

Brendan wrote:Given that you seem to want to do a lot of extra work just to make the OS more retarded; it's a bit hard to make sane suggestions.

However; I'd consider given each task one 512 KiB block. It's a nice round number and leaves about 100 KiB for the kernel to use (without copying) in real mode. You could even pre-allocate these blocks during boot and not bother having any memory manager at all (e.g. "task number 4 uses memory block number 4"). You could also do "max. tasks = RAM between 0x00100000 and 0xFFFFFFFF / 512 KiB" (and end up with a limit of about 6142 tasks on machines with 3 GiB or more RAM).

Basically; it'd be significantly less limited, and it'd also be easier to implement.

Of course it'd still be bad (e.g. lots of RAM wasted by tasks that only use part of the 512 KiB they're given), but it's a few orders of magnitude less bad than wasting 99.99% of RAM.

Just because it's there doesn't mean it's needed. This amount of memory is only available to modern machine anyway.

Um? Computers have had several GiB of RAM (or more) for the last decade. Disposable mobile phones have several GiB of RAM now. By the time you've "finished" your OS (assuming you're not smart enough to give up and/or throw it away and start again in the next 6 months) people will be using 32 GiB or more.

Prochamber wrote:I still need a memory manager if programs required extra memory, which I'm sure there are plenty that will. Also the kernel allocates a small amount of memory.
A big problem with your proposed block size of 512 kilobytes is that the whole concept of memory manager is that data is swapped between extended memory and local memory segments.

Like I said before - the OS will be so lame that the overhead of copying 512 KiB during task switches won't be noticeable.

Prochamber wrote:This won't work if the block size is greater than a real mode segment.

How will the OS access more than 640 KiB of RAM if you're not using protected mode (or unreal mode), where the real mode segment limits are irrelevant? Even if there was some completely idiotic reason that doesn't exist that prevents you and nobody else from copying more than 64 KiB at a time, you could still copy 512 KiB by breaking it up into 8 smaller 64 KiB copies.


Cheers,

Brendan

Prochamber wrote:Rather than talking about real mode and BIOS can you give me a clear explanation of the advantages of using protected mode apart from having more memory accessible?

Isn't this alone (and getting rid of that stupid 64k per segment limit) a reason good enough to make the switch without hesitating?

And then there's obviously the isolation that you get with Protected Mode. If you want your multitasking system to work, then all processes have to play by the rules. In Real Mode you have to hope that they do, and if one doesn't (perhaps because it has a bug) it corrupts other processes or crashes the complete OS. In Protected Mode, this won't happen, the bug stays contained within one process. You also save copying data around for each task switch, which will definitely impact performance if you do it multiple times per second.

For me, this is already three show stoppers for Real Mode. How many other reasons do you want to hear?

Blacklight wrote:

Prochamber wrote:A 200x250 picture, which will occupy most of the screen space

Wait, hold on. 200x250 is "most of the screen space"? Do you plan on using nothing but 320x200? That was considered cramped for a UI in the late 80s.

You are imposing arbitrary limits on yourself that make your OS design seem right out of 1987. Unfortunately for your design, it's 2013. Example time: I have one 1920x1080 monitor and one 1600x900 monitor, 8 GBs of RAM, 64-bit processing capabilities, currently some 250 processes running smoothly, and a gigabit ethernet card, and this system could be considered modest on the enthusiast side. Why on earth would it make sense to design an operating system to use a resolution of 320x200 on my 24 inch monitor (EDIT: math time - that means each pixel is something like 1.6mm × 1.75mm), 8 MB of RAM, 16-bit processing mode, a maximum of 16 processes, and probably not even get to use those sweet gigabits of ethernet data?

And it can be 2050 with everyone using holographic interface for all I care that won't change anything. I sense most hobby operating system projects have failed to progress because their design was too complex to finish. I won't make the same mistake. I want to design a design a simple system that it each to use, build and write applications for. I don't care about ethernet and I don't care about screen sizes.

Prochamber wrote:I sense most hobby operating system projects have failed to progress because their design was too complex to finish.

Oh, the irony.

Prochamber wrote:I want to design a design a simple system that it each to use, build and write applications for.

Then use a simple system like protected mode where you don't need to deal with the convoluted crap involved in hacking the hell out of real mode and back in order to pretend you have a half-modern system that's "easy to use" but is as unstable as the Korean Peninsula in a world where North Korea is a starving lion and South Korea is a juicy T-bone steak.

You have designed a mess. The only solution is to abandon it.

Kevin wrote:For me, this is already three show stoppers for Real Mode. How many other reasons do you want to hear?

I'm down for a couple more.

Brendan wrote:

Prochamber wrote:This is a hobby OS not a "windows killer" I will never need 500 processes or 188 or even 50.

..or even 1.

I've already got it to run more than one.

Brendan wrote:

Prochamber wrote:How big is this picture?

Digital cameras are currently 10 megapixels (cheapest) or more. Mobile phone cameras are currently 2 megapixels or more. Let's go for somewhere in between and say 5 megapixels. Let's also assume 4 bytes per pixel (even though a decent camera would be more). That works out to about 20 MiB.

Wow. I definitely will not support images that big. I'm not going to be importing images from digital cameras.

Brendan wrote:

Prochamber wrote:There is no limit to how much memory out of the free memory a single process can use, I don't think a picture would ever need as much memory as you seem to think it would.

This must've changed then. Earlier you were saying "Program Space - 64k" and "8 MiB max." for the OS's memory manager. That's nice I guess, but if applications are in real mode they can only really access 640 KiB so you'd still want 384 tasks.

You still don't understand.

• Memory allocation is global.
• Applications can access more than 640 kilobytes by swapping memory while the memory manager, which uses unreal mode.
• Adding more tasks does not increase the amount of memory you can access.

Brendan wrote:

Prochamber wrote:A 200x250 picture, which will occupy most of the screen space requires 50000 bytes of memory, which is not a huge amount and less than the video buffer used by a process but if you wanted bigger you could allocate additional memory.

WTF? I can imagine it now - "Here's a picture of my new girlfriend, she's the pink pixel near the middle of the sixth row!".

Well, you can't display high resolution images. Simple as that.

Brendan wrote:

Prochamber wrote:Just because it's there doesn't mean it's needed. This amount of memory is only available to modern machine anyway.

Um? Computers have had several GiB of RAM (or more) for the last decade. Disposable mobile phones have several GiB of RAM now. By the time you've "finished" your OS (assuming you're not smart enough to give up and/or throw it away and start again in the next 6 months) people will be using 32 GiB or more.

See my previous post.

Brendan wrote:

Prochamber wrote:This won't work if the block size is greater than a real mode segment.

How will the OS access more than 640 KiB of RAM if you're not using protected mode (or unreal mode), where the real mode segment limits are irrelevant? Even if there was some completely idiotic reason that doesn't exist that prevents you and nobody else from copying more than 64 KiB at a time, you could still copy 512 KiB by breaking it up into 8 smaller 64 KiB copies.

The memory manager runs in unreal mode and different segment are used for different things so I won't be violating segment boundries.

Blacklight wrote:You have designed a mess. The only solution is to abandon it.

I respect you more than most here Blacklight but frankly the only design mistake I made was coming to OSDev to get help in the first place.
While there are some useful and knowledgeable people here there are far too many of the opinion that any operating system that doesn't comply with their complexity standards is crap or are just plain elitists. You guys can continue ranting about real mode and BIOS and about how rubbish my ideas are but I won't be there to dispute it.

I am going to get started with adding the multitasking code.
Goodbye.

Hi,

Prochamber wrote:

Blacklight wrote:You have designed a mess. The only solution is to abandon it.

I respect you more than most here Blacklight but frankly the only design mistake I made was coming to OSDev to get help in the first place.

I'm fairly sure you mean "coming to OSDev to refuse to listen to help".


Cheers,

Brendan

Prochamber wrote:I sense most hobby operating system projects have failed to progress because their design was too complex to finish. I won't make the same mistake.

I would say the complexity of such designs is not from CPU architecture or features. If one is incapable to handle protected mode or long mode (instead of decided not to use it for some reason), that only suggest a lack of knowledge or capabilities and a further study is required to prevent ultimate failure.

by the way, my OS development come to a halt too but simply because my increasing workload from paid job.