This is a hobby OS not a "windows killer" I will never need 500 processes or 188 or even 50.Brendan wrote: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".Prochamber wrote:Remind me again why all these tasks are needed.
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.
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.
Just because it's there doesn't mean it's needed. This amount of memory is only available to modern machine anyway.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.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?
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.
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.
