OSDev.org

I was seriously wondering that, if I have a kernel heap, a kernel core area, a stack area, and an user area to load user-space programs...

Where am I supposed to load things like disk data dynamically, and other possibly heavier things like the GUI of each program (as well as "window overlapping/dynamic transparency", etc.)?

Should I maybe put it in the same user-space area, and keep track to its process ID by using linked lists, binary trees, etc.?

Or should I use the video memory itself (in the case of video, which is said to be slower than normal RAM, at least to read) and, when it gets full, save the data to disk virtual memory?

---
And the same goes to dynamic decoding of images and such kind of processing tasks. Is there some way to assign memory for applications data other than the one I roughly mentioned?

Well, you probably want to load data from disk into some sort of buffer cache. Where that lives is up to you. Stuff like GUI depends on whether you want the whole GUI into your kernel.

Video memory is good for storing stuff that doesn't need to be read. Your current framebuffer (visible on screen) is obviously such stuff. Offscreen bitmaps are such stuff, if you are only going to copy them to the screen AND you have accelerated Blit available.

Typically only the user programs will know what's worth storing in video memory, and what should be kept in RAM. Without accelerated Blit you probably want to give the processes normal RAM even if they asked for offscreen memory so the question is a bit complicated..

Decoding of images I think is purely an application task, and system shouldn't need to care about how it's done. The application is going to need a malloc() or something like that, but even userspace malloc() is just a library issue..