Just can't get enough of that Moose!

[ANDREASA@dhhalden.no]

> Hi everyone!
  ^^^^^^^^^^^^Make that my own :-)
[Stuff deleted about memory management]
>     Any feedback?
Exactly what I ment :-)
> > 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.
>
> I guess what it comes down to is whether we want a system capable of lightning
> speed response at the expense of multiple tasks and users, or one capable of
> average speed while allowing many multiple users and tasks to coexist.
>
> Lightning speed: Keep MEM_PHYSICAL, put a few restrictions on it.
> Average speed:   Restrict MEM_PHYSICAL to more privileged software.

If you have a realtime system and need lightning speed, you will probably
have a harddisk that will make up for the speed needed, even though you cannot
use the MEM_PHYSICAL flag.
Or we can make a council that decides whether or not an app can use MEM_P :-).
Or we can let devicedrivers only use the MEM_P flag, and if somebody needs
lightning speed he makes his own memory management device.

> > It would be nice if all apps could support Unicode, instead of
> > having to remap the character table twice a day.
>
> I think Unicode is a reasonable standard to agree on - ASCII is definitely
> not the 'ideal' choice for a new operating system...  Let's support our
> friends in Europe and give 'em those oomlauts!

The Kingdom of Norway, the land where polarbears walks on the streets and
where every man has killed his own whale hopes for the same positive response
from you others (at least from Peter and Fare').

> Hmmm...every machine I could think of that I'd want to use has at least a
> 32-bit word size.  Just a hint though - the Penitum has a 64-bit data bus!
> (This is public info, I'm not divulging any Intel secrets... :-)  I think the
> best approach is to define the interface in terms of 'at least': say, for
> example, this value is *at least* 32-bits in size.  This means if you write
> an application that counts on the value being larger than 32-bits, you are
> in trouble when you try to port it... :-(
>
>     byte:       always 8 bits.
>     char:       always 16 bits (remember Unicode?)
>     short word: at least 16 bits.
>     word:       at least 32 bits.
>     long word:  at least 64 bits.
>
> Any comments on that?

A small one :-)
I don't like the 'byte' type, if possible I would prefer a short char.

>             Dennis

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