One man in Byron
Would incredibly forget all
One day he saw a man that aparently he did know
Oh, this means I had never seen him before!
And he moved on...
You are here: Main API -> Memory API ->
API_Memory_Alocate PROC STDCALL USES ecx,ebx,edi ARG nr_4k_chunks:dword
This function allocates the requested number of 4K blocks.
| Argument | Type | Description |
|---|---|---|
| nr_4k_chunks | dword | The number of 4K blocks to allocate. |
You can not allocate less than 4Kilobytes(4096bytes). If you need to allocate multiple very small sized blocks (a few bytes) then you should aggregate them into larger blocks and keep track of them yourself.
The API_Memory_Release function requires both the HANDLE and the SIZE of a memory block for deallocation. An application should strore both when an allocating variable size blocks.
Also you must take care not to write beyond limits of alocated memory or else you might corupt other application's memory.
Curently it is the responsability of the application to release memory. The last chance to do this is on ACT_CLOSE_CHILD message.
It is fair to assume that future versions will automatically clear any memory wrongly left alocated when an application (window) is terminated.
It is fair to expect future versions of this function to return -1 if not enough memory is available.
When running multiple instances of the same application one should save allocated memory handles and sizes into application's private variables. SOLAR OS and Private Variables
.data my_mem_handle dd 0 my_mem_pointer dd 0 .code ;----------------------------- ; alloc some memory ;----------------------------- Call API_Memory_Alocate,4 ;get 16k = 4 * 4K mov [my_mem_handle],eax ;store handle as we need it for Release mov [my_mem_pointer],esi ;store pointer ... ;----------------------------- ; Release the memory ;----------------------------- Call API_Memory_Release,[my_mem_handle],4
Current base for OS memory has moved at 6M+4k.
This leaves only 2M free for a system using 8M of RAM.
Move up was done because of 1280x1024x65536 that uses more than 2M.
And future 32bits per pixel will use up more than 4M ;)
If you do not intend to use high screen resolutions it is possible to move this down to 3M+4k and allowing SOLAR OS to run under 4Mbytes of RAM.
This can be done even at runtime by changing the folowing OS variable:
os_mem_base dd (6*1024*1024+4*1024)
and indeed should have been done as such IF I was not so lazy ;)
Any changes to OS memory base should be done BEFORE creating any windows/desktops because this might allocate some memory for childs.