Re: [Oslib-devel] Outsourcing the extender?

[Luca A. <luc...@em...>]

Hi Peter,

what's the advantage in making the extender an independent project? It
already is in a separate cvs module (the eXtender module in the sf cvs),
and can be downloaded separately from oslib (oslib and the extender are
different packages in the sf project page).

> And OSLIb should ignore, by which loader it was booted.
Well, let's say that it can ignore the loader by which it was booted.
But if it knows that it has been loaded by the eXtender it can take
advantages from this fact. For example, the eXtender can load oslib
programs from DOS allowing such programs to return to DOS when they
finish (very useful for debugging). But in order to safely return to DOS
a program must not corrupt the DOS memory. Hence, x.exe passes
information about the DOS memory to oslib (this is an extension to the
multiboot standard). If a program ignores the loader, it cannot safely
return to DOS.

I think this can be also done by using the memory maps supported by the
multiboot standard (and creating a fake memory map that marks dos memory
as ROM), but I still have to have a better look at this solution.

> For example, this means: example/mbdemo.c should show the loader name,
This is correct, thanks for pointing it out... I'll fix mbdemo.c in the
next days.

				Luca