Quote:

[...] Perhaps you could make a MemManager which assigns special 4 KB blocks/chunks for 'drivers / TSRs' instead of a whole-whooping 16 KB ? Didn't MCM's MemMan 2.x support 4 KB block assigments too ? But you probably thought all that through I guess ... [...]

MemMan 2.x uses TSR-files which contain relocation information, and TSR's can be loaded anywhere between 0x4000 and 0x7FFF. For the rest MemMan works with 16 KiB blocks.

Relocating and packing programs like this can greatly reduce the amount of memory needed for program code. For the data things are not so easy because many programs do not have a fixed data size.
Sharing program code with multiple instances of an application also makes it necessary that the program code only contains constant data, the variables would need to be placed elsewhere.

The kernel must then provide a way for the application to find the data corresponding to the instance it is running for. This can be greatly simplified by using 16 KiB blocks with a fixed layout, but that is really overkill for some applications. another approach is to provide a pointer to the application data in a fixed placed place, in memory or registers, but an extra level of indirections does cost extra time.

It the classic speed versus space trade-off. A one-size-fits-all solution may not be appropriate for a general-purpose OS.

Quote:

Quote: [...] Perhaps you could make a MemManager which assigns special 4 KB blocks/chunks for 'drivers / TSRs' instead of a whole-whooping 16 KB ? Didn't MCM's MemMan 2.x support 4 KB block assigments too ? But you probably thought all that through I guess ... [...] MemMan 2.x uses TSR-files which contain relocation information, and TSR's can be loaded anywhere between 0x4000 and 0x7FFF. For the rest MemMan works with 16 KiB blocks. Relocating and packing programs like this can greatly reduce the amount of memory needed for program code. For the data things are not so easy because many programs do not have a fixed data size. Sharing program code with multiple instances of an application also makes it necessary that the program code only contains constant data, the variables would need to be placed elsewhere. The kernel must then provide a way for the application to find the data corresponding to the instance it is running for. This can be greatly simplified by using 16 KiB blocks with a fixed layout, but that is really overkill for some applications. another approach is to provide a pointer to the application data in a fixed placed place, in memory or registers, but an extra level of indirections does cost extra time. It the classic speed versus space trade-off. A one-size-fits-all solution may not be appropriate for a general-purpose OS.

and in this link
usuarios.arnet.com.ar/flyguille/EnMyProg.asm

you will found all the answers to that!
You can see how MNBIOS gives the variable space... (see at the end).

MemMan can load multiple TSRs in a single 16KB area. If it fits MemMan will put the TSR code there. If it doesn't MemMan will request 16KB more and will put it in there.

Quote:

MemMan can load multiple TSRs in a single 16KB area. If it fits MemMan will put the TSR code there. If it doesn't MemMan will request 16KB more and will put it in there.

Exactly the same method!

the file in memory where all the packages goes: M:\0001\MNBIOS.DAT

0001 is the kernel's thread subdirectory.

When the package don't fits in one page it enlarge that file one page more and use that new one.

Only one rule MAXSIZE of the package is = (16kb - 13b)

And that mean that the INSTALL.EXE utility doesn't support multipage drivers or libraries... for those cases, they needs be loaded in others file with others methods.

The other method is a lot more complex:

It is to make an aplication with a package inside...

the application needs to do:

To create a new file in the kernel subdirectory. (if it already exists, try another name).

To copy the package to the file created in the kernel subdirectory...
(the more easy option is using the filesystem, but is more slow).

With the path to the file, to subscribe it in the ADR system... it will returns a subscription ID.

then, call to the INIT function of the package using the ADR system.

If it is a device driver you needs to subscribe it in MFSL.

If it is a input device driver (mouse, keyb, joystic) you needs to subscribe it in MCSL.

Then kill the application thread....


NOTE: Those applications that already are in memory can't use the new package unless the INSTALL_INSTANCE function is executed from the thread of the application.



As you see this method that I used ONCE is a lot complicated.