Misc (and graphics 1)

[Michael David WINIKOFF]

> 
> Hi everybody.
> 
> 
> 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

No. All PLs shouls use the system calls -- as a programmer you'd use new/malloc
which the compile would implement using the system calls.

> 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.

This is language dependant -- some languages don't actually use stacks.
(Eg. Scheme can be implemented using only a heap, FORTRAN doesn't need a stack
[Maybe modern FORTRANs do?])

> 
> 
> 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

Of course -- virtual memory schemes will not swap out pages unless one is trying
to use more memory then physically exists.
If you allways do stuff that completely fits into your physical memory then 
virtual memory won't actually do any swapping.

> 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.

In a relatively heavily loaded system (IE one which doesn't have as much 
physical memory as one would like :-) pages WILL get swapped out.
Some applications have a requirement that they never have to wait that fraction
of a second for a page of theirs to be read in from swap space (= disk).
Can you imagine the delay as a sample player waits for the disk?
It would be audible.

> 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

Ditto. Probly so for most of us - that's why it's so much fun :-)

> :-), 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 :-)

What's the difference between Amiga and Mac menus? (apart from having 
another mouse button in the Amiga)

Personally I'd like to have menus where you click once to bring up the menu then
release the button and click again to select.
I find it awkward to drag the mouse around while holding the button down.
Anyone else have this problem?

> Of course Mac and Windows menus is an alternative, but is it a real
> alternative?
> etc. Name the mail, 'Graphics query 1'.
> 
[Stuff about unicode plea deleted]
Yes. We should use Unicode.

> 
> 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.

Definately 4.

> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.