Re: [Stormdos-develop] OPM

[stephane r. <sri...@to...>]

See my comments preceded by a *** distributed amongst your post.

----- Original Message ----- 
From: "Juras" <yb...@tu...>
To: "stormdos-develop" <sto...@li...>
Sent: Thursday, September 09, 2004 7:41 AM
Subject: [Stormdos-develop] OPM


> Hello stormdos-develop,
>
> By now BIOS calling from 32-bit PM works. Now the problem point is
> PAGIN MECHANISM which affects DLLs much... I don't want use
> complicated memory management, especially on an OS which is planned to
> be launched from a floppy...
>
>
> Please, tell you point of view to the following:
>
> proposed:
>
> Object Provider Modules
> ~~~~~~~~~~~~~~~~~~~~~~
>
> Instead of DLLs a special means could be implemented.
> OPM is a usual programme with the following exceptions:

*** OPM?  you mean Overlayed Program Modules ?  if so, well To me overlays 
are there because of the classic conventional memory limitations, a limit we 
don't have in a 32 bit environment.  So I would suggest simple flat memory 
addressing model would do the same thing probably much faster and smaller.

If you don't mean Overlayed Program Modules then for the sake of my 
knowledge, let me know what OPM is? :-).


>
> - loaded only once
> - doesn't have own threads
> - registers virtual objects with methods (COM-like) (records with
> pointers to functions/procedures)
>
> SD-32 uses the same address space for all threads and this way provides
> reusable code via near 32-bit calls (like in good old DOS INTerrupts
> were used).
>
> OPM file name 8.3 limitation.
> OPM object name - 63 symbols limitation,
> several limitations to character range.
>
*** Here I have an issue, a 32 bit (or 64 bit even on some systems today) 
should have NO limitations per se.  Other than system resources of course 
(assuming there will be no disk swapping).  Therefore if we could find 
perhaps a tad more complicated method, a bit bigger that can still fit on a 
floppy disk that would get rid of these limitations (or at least raise these 
limits to higher values) I would opt for that option.  A bit longer to code, 
perhaps, but I would think well worth it.

>
> Page addressing may be used just to protect areas of memory
> and could be easily switched off. No "shared" regions, i.e.
> the same page directory is used for all processes.
>
*** That I'm all for it exactly as described here.

> Page addressing (virtual memory) complicates the kernel much, so
> I want to use usual programmes as interface providers (OPM) and with
> a quite difference to call them OPMs rather than DLLs...
>
*** And how would that end up managing the memory?  IE garbage collection, 
defragmentation of fragmented memory blocks (if any), and limits of 
installed RAM on a given system.  Likewise if these don't manage the memory 
itself, then what happens?

> Of course, DLLs are better but I don't want to get a headake implementing
> them fully.
>
> With OPMs programmes can be highly modular and the memory being economized
> as with the DLLs...
>

> Finally, OPMs are better than no dynamic linking at all ;)
>
*** well of course they are :-).   I'm thinking however, if we do decide to 
go the DLL way, perhaps we could make use of existing DLL's hence make Storm 
DOS compatible with existing OS.  That might be a big feature that just 
might get popular fast.

> -- 
> Best regards,
> Juras                          mailto:yb...@tu...
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Stormdos-develop mailing list
> Sto...@li...
> https://lists.sourceforge.net/lists/listinfo/stormdos-develop