Just can't get enough of that Moose!

[ANDREASA@dhhalden.no]

Hi everybody.

> > No. The obvious restriction is not to have virtual memory. If the user wants to
> > use more memory then s/he has then s/he pays the price in speed.
> > I don't see any point in providing virtual memory and then saying you can only
> > use it to a certain extant.
>
>     It think the problem is not with virtual memory.  The problem is in
> a system which utilizes virtual memory but allows tasks to allocate memory
> which is guaranteed to always exist in physical memory (using MEM_PHYSICAL).
> This means less space is available for virtual memory to play around in.
> Consider if on a PC with 4MB physical memory I did:
>
>         MemoryAllocate(3*1024*1024,MEM_PHYSICAL);  // Allocate 3 megs
>
>     The rest of the system would be screwed.  I don't want to restrict
> physical memory to just device drivers (like with the other MEM_ flags) but
> there's no good way to limit how much physical memory a task can use.  I can
> see the need for this type of memory (audio and video applications) but those
> require special device drivers anyway.  Can anybody think of a reason a normal
> application might require a portion of its memory to be physical?   Is there
> any application which just plain wouldn't work if it couldn't respond to some
> event fast enough?

I have two comments on the memory issue. First how we should implement the
allocation code, and secondly virtual vs. physical memory.
There are 4 different PLs in a 386++ processor. I suggest that the 3 lowest
PLs can use the MemoryAllocate, MemoryReAllocate and MemoryFree calls, and
the fourth uses standard commands as new or malloc. In addition we have a
memory device that serves the purpose of memory management in PL level 2
(counting lowest priority level as beeing 0).
When an app starts it allocates some space, and contigous calls to alloc,
realloc and free then calls MemoryAllocate, MemoryReAllocate and MemoryFree as
needed, having it's own "stack" served by the memory device. When the space-
request grows over the stack space limit it calls MemoryReAllocate, and asks
for a larger amount of memory.


An app should allocate memory in physical mem as long as there are physical
mem available. The algorithms in the memory management device decides whether
or not, disk should be swapped.
I can see that some systems require fast response, and therefore will want to
have much data in mem, but if the response time is crucial, they will probably
already have a fast harddisk and a large amount of mem anyway. Considering
this, it might not be a need for the MEM_PHYSICAL flag in PL 3.

Maybe you shouldn't pay to much attention to my ideas about Memory Management
since this is my first OS project, and MM has never been my biggest interrest
:-), but my "common sense" says this could work pretty well.
Now a question to you all about the GUI device.
What kind of graphics capabilities do you have?
Do you prefer Amiga or X-menus? (Just to say, I'm no Amiga fan :-)
Of course Mac and Windows menus is an alternative, but is it a real
alternative?
Me and Dennis have discussed the possibility of making a virtual 8086 to get
the bios graphics initialization routines. Considering there are about 12
different graphics chipsets producers (with maybe 2 to 6 different chips each)
there would be a huge amount of time only to find out the correct register
values, and I have very limited access to other chips than ATI :-(.
Of course the bios code would only be neccessary as long as there aren't
finnished code for all chipsets. Hopefully I can get other netters to help me
with this part.
Please respond by mail about your chipset, what kind of menu you would like
etc. Name the mail, 'Graphics query 1'.

I must fire my last shot at the moosers who want a textbased system :-(, but
I have to. Living in the small kingdom of Norway, the land where people kills
whales as regulary as others goes to work. The land where polarbears walks on
the streets. The land that has got all gold-medals in the Ski World
Championship in Falun this year :-]. The land that uses omlaut a, aa and o,
and for the countries of europe, japan the mozlem countries and african
countries. It would be nice if all apps could support Unicode, instead of
having to remap the character table twice a day. Beeing able to write a letter
in arabic, then in kanji, or any other alphabet, how are you going to support
this in textmodus? Remap the character table all the time, stealing valuable
resources?
Ok, I know some of you will flame me for this one, but please don't. This is
a serious problem in many countries, beeing a slave of the ANSI comitte.
I know it is possible to remap the character table etc., and I have done it
before, but the world would be much more easy if we had a two byte character.
Give me another reason than speed, and I might listen more careful.

BTW, now when I have said this, will an integer correspond to 4 bytes or
will it correspond to 2, as it does under uglybuggly dos.

> > > =>Hmm. I think I detect the need for a glossary of terms :-)
> > > =>
> > >    Doubtless true, but we should probably decide what we want to do
> > > before defining terms. Otherwise, we would probably end up with a
> > > complete OS dictionary.
> >
> > Hmm. But if we don't we could end up with a comunication problem.
> > :-)
I wouldn't mind a glossary. What is IPC?

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--