memory, video, and a few thoughts

[David Garfield]

I would like to apologize for not contributing much to date, but I
have been busy trying to set up my new USENET site, and have
fallen a bit behind....

I am now at     david%davgar@uunet.uu.net
instead of      garfield@snoopy.sra.com
I do not yet have a domain name, but I am looking in to it.

---------------

 From: "Gary D. Duzan" <duzan@udel.edu>
> =>> >      The starting address of the memory block will be returned by
> =>> > this function.  If the allocation fails a null address is returned,
> =>> > indicated by an address of zero.
> =>>
> =>> Firstly there is scope for a bug here -- consider what
> =>> happens if the system allocates a task memory beginning at
> =>> (virtual) memory location 0 ...
>    Simple enough to fix: just don't do that. :-)

I will again say: You can't allocate memory (address space)
because it already exists!  It is just invalid.  Memory
allocation is the process of changing invalid memory into valid
memory.  All that should be returned is the error code.
Additionally, address zero (and the nearby low addresses) should
be reserved as invalid addresses, so chasing NULL causes an
immeadiate error.  (One of VMS's best desicisions, pity we can't
also make hex 00 an invalid instruction...)

> =>> (2) We need to have a configuration facility to make
> installation of new
> =>>     software/devices/hardware totally painless.
>
>    This is an impossible goal on the ISA architecture. :-(

This is not impossible, and is in fact a VERY good idea.  MOOSE
should have a facility to install any and all additional software
components.  Then any new software being installed can use this
to install itself.  This will avoid the major MSDOS problem that
every piece of software (except the newest Windoze stuff) has a
different installation procedure.

---------------

 From: dmarer@td2cad.intel.com (Dennis Marer)
>         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.

The problem with this kind of definition is that terms like word
and long word have been used before, and have meant other things.
For instance, on an IBM 360 and so on, a WORD is 32 bits and a
HALF WORD is 16 bits.  On an IBM PC a WORD is 16 bits and a
DOUBLE WORD is 32 bits.  And this is just within IBM's products.

A (probably) better usage is something which specifies the number
of bits, the signed/unsigned/floating point nature, and whether
the size must (should) be exact.  Perhaps:
        u16             at least 16 bits, unsigned integer
        s32             at least 32 bits, signed integer
        f32             at least 32 bits, floating point
        u8e             exactly 8 bits, unsigned integer
About the only thing that should require an exact size is
something networked.
        u18             at least 18 bits, unsigned integer
We should support EVERY non-exact size up to the maximum
supportable by the achitecture.  This particular type is useful
to represent the time of day.

---------------

 From: ANDREASA@dhhalden.no
> I must fire my last shot at the moosers who want a textbased system :-(, but
> I have to.
..
> 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.

 From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
> What about a user who doesn't need
> virtual memory, because his/her applications are small? Must he/she
> live with a performance lack, because the system runs all through
> the virtual memory manager's code?

Both these complaints can be answered in the same way.  The
feature (character set remapping and virtual memory) does not get
invoked (save for one-time uses) until needed.

While I am on the subject, I will say again that if Moose is a GUI
only system I will disassociate myself from Moose.  I admit that
Moose needs GUI support, but it needs text support as well.  I am
not going to give up on Moose and text-based capabilities until
forced.

---------------

With reference to all the acronyms etc... being used by everyone,
Unicode and several file systems have been referenced.  Where does
one find information on these?  It would be really nice to know
just what they are.  When mentioning new technical information of
this source, it would be nice to provide the references.
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com