??? 7/11/2002 1:02:47 ??, ?/? "ZN" <[EMAIL PROTECTED]> ??????:
<snip> >Then what you really want to say in the licence would be that additions to >SMSQ/E to add a feature of capability to one platform will not be accepted >if it may seriously hinder or even prevent adding an equivalent feature or >capability on another. Obviously, this excludes all platforms where such >feature simply makes on sense or is impossible (by design - leack of need), >but does at least suggest some form of forethought, so that we don't get >'my way or the highway' style features. This breeds tremenodous problems >with writing applications and further additions to SMSQ/E. > >Nasta While your original proposition (ca. 1995 IQLR) would already have solved the problem... Not to mention that with the exception of writing a Memory Manager, a Driver API or an internal IP stack (for other purposes eg. making it an embedded OS for Internet devices and even that wouldn't really qualify), nothing extremely new can be done to improve SMSQ/E which is extremely robust as it is... Mind you that I believe that the following are not (and should not) be part of the OS core: Drivers (keyboard/screen/serial/disk/sound etc.) S*Basic PE Command line I/F (although for obvious -and historical- reasons these are included and perceived as a part of the OS and this illusion isn't really bad) File System (although some may disagree, but for me the FS isn't nothing more than the root object on where other objects (devices) are attached - Again SMSQ/E does provide object functionality, just doesn't call it that ;-)) IMHO what SHOULD BE part of the os ONLY: Scheduler I/O API (The drivers framework) Housekeeper (process manager) Job communication (Call them pipes or what ever you like) Object Manager (The Thing system) Phoebus
