Just one little thing

[Francois-Rene Rideau]

>> 
>> (Excuse me if this doesn't get out, or gets Fubared along the way..)
>>  
>> On a different vein from what we have been discussing, but one that should
>> be considered is the format / use of executionable code.  While having
>> objects for them is just about a given, it remains the task of the 
>> kernel to load and execute programs, otherwise, the o/s will be about worthless
>> without "applications" 
Yes, we do have to consider this; but tha's kernel considerations and we
didn't even agree on the OOness of the kernel.
 My opinion is that code descriptors allow any possible means to pass 
parameters (through a stack, through registers, through a global variable,
etc. The execution handler should translate parameters as they should be
for the called function to operate. Of course, we must define the our own
preferences for the moose coding. I suggest using registers for quick
operations, a stack (not inevitably ss:esp) for common other operations, or
even typed stacks for OO operations (that is, an integer stack, a fp stack,
a typed object stack, etc). We'll what's the more efficient while coding.
This should be totally implementation dependent.
 As for C/Pascal parameter poping or not, I propose we rather say that
a C function returns its parameters before its usual result.


>> So, a suggestion would be to implentate, FORCED public/private key
>> authorization
>> of any application that would have a priority level over the lowest one.
>> While allowing for applications to be debugged / developed, but not allowing
>> viruses/worms/ other friendly things that chew away on your data.
What we were converging to is a dictionary of accessible functions: every
objects has access to a version of the dictionary. A method can thus be
more or less private (there's no more two possible states, but an infinity
of them at touch !) depending on wha dictionaries  it appears in.

>> As far as graphical/text interface goes, this seems that it should be 
>> related to the concept of a shell.. either a cmmmand.com equivalent, or a
>> "finder" equivalent.  to use examples from O/Ss that I suffer with.  This
 We suffer so much with those that I'd prefer the relation between our shell
and those to be more than distant.
 To me, the interpreter should be more like an interpreter (with both
infix and postfix notations if possible) which would allow to directly
call the objects in the dictionary; of course, all the useful stuff will
have been put in the shell dictionary. This also allow to have a shell
both standard and extensible.

>> would load a library into memory that would handle display calls.  If 
>> some features of the display library are necessary, ie, graphics, and the user
>> is running in text mode, there could be a loader program that would load up the 
>> library for graphics and remove it when no longered needed..  And those with
>> fast machines, or masochists, could enjoy the slow updating of a pixel base
>> interface.
I think we agreed to have a the same time GUI and a TUI (that is windows in a
text screen) and shells running inside terminals. The text windows are useful
when you use a computer with an old low-resolution (eg CGA) screen, or a
text-only screen (ever have used a vt100 ?).

		   ,
		Fare

BTW, who am I replying to ?
who is using this pseudonym Murphys's Law, fate@* ?
(just btw)
(it was well done anyway)