craig@unicus.UUCP (Craig D. Hubley) (06/22/87)
> As far as this Facc interface vs. daemon stuff goes, it's sounds > fantastic ! What a logical division ! I think that we should all get > together and come up with a standard message set or template so that > some measure of compatibility among these things can be determined. > Something as extensible and accepted as IFF. Here we go again, another > Amiga First ! > If the rest of the micro market ever gets around to multitasking, they'll > just be playing catch-up all the time. Yes, this makes you an object-oriented OS, more or less, with a "standard message set" being a protocol and a "template" a class. That, I believe, is what the original Amiga hardware designers had in mind. Likewise the Exec supports a lot of good stuff, including message-passing in the first place. As to actually putting the guts of an object-oriented system into AmigaDOS, have a little patience: Libraries have been discussed a fair bit recently, > I believe the original message (lo these long days ago) was about load-time > linking (late binding) the actual names, rather than doing so at compile > or "link" time (early binding). I'm not sure what the advantage is, but > I don't think that early binding type solutions are relevant. Late binding of libraries gives you these advantages: A1) you can use a more recent (read: debugged) version of the library that the program was compiled with, so long as its interface and functionality are exactly the same. A2) you do not have to include the library itself in the code. - linking is quicker - writing a very small C-interpreter (no functions!) that uses the same code as your compiler is relatively simple. Interactive debugging now becomes possible. - many more multi-tasks can be kept resident at once. and these disadvantages: D1) you may not have the library around, or in the right place. D2) you might have overwritten the library with one of the same name To overcome these: Make binding level an option in " make". Thus your C code need not be changed for different (experimental, own use, product) versions of your code. EARLY level includes the library and resolves references, as now. LATE level loads the library when the program is loaded. If it can't find it (via a system-variable list of directories) then it puts up a requester and gets the user to find it. If he can't then the loader fails to load. SAFELATE level looks for the library via the path, but uses an internal version if it can't find it. This gives you a safe way to include the load-time binding but without the space savings. LATER level loads the library only when OpenLibrary is called. pardon me if that's what "load-time" is supposed to mean. This allows you to call OpenLibrary(), check the results yourself and go get another version if needed, then OpenLibrary() again. SAFELATER (as SAFELATE, only the safe version) VERYLATE could mean something in a threaded compile-interpretive environment, that is, use the interpreted version. VERYLATE binding is like the run-time binding in LISP interpreters. The AmigaDOS loader should, on loading a library, check all names in it to see if was overwriting a name already loaded. Since loading libraries is a bottleneck already, and name-checking has been optimized through centuries of search algorithms, this isn't too bad. It isn't really necessary, if names are in fact all kept different, but unless you want naive users to know their libraries intimately, it's nice. The system would throw up a window and tell the user what names it was overwriting, and let him abort it (and the operation). Since each run-time "environment" of libraries and programs would be slightly different, this is useful. Now, to these small changes, add the ability to dump the present memory configuration (the loaded libraries, the loaded applications, the system variables, the desktop) to a file, preferably on a hard-drive. THE AMIGA IS NOW A VIRTUAL MEMORY MACHINE. With four megabytes of memory and a hard drive, its very practical. Think: It already multitasks. It already maintains shared code resources (libraries). It could easily load them more flexibly. I know people already who let their Amiga chug away for 10 minutes loading up with everything they're going to use in the session. In fact, the Amiga is already a VM machine in some ways. All it needs is the ability to bind late, so that its software isn't all monolithic. Think about how a good UNIX utility works, adding something incremental to a bunch of lower-level functions, such as the classic example of the four-line spell-checker. If C can be given the same flexibility and memory economy as scripts, WITHOUT LOSING ANY of its power or reliability, WHY NOT? It would make C code much easier to debug. Just think, no waiting for Intuition to link. The code would be slower, but SO WHAT. You're debugging it, not selling it. I wrote a long posting on exactly how this could work, but my UNIX box ate it so for now just imagine this: A "Programming" environment consisting of your C compiler and stuff on the RAMDISK and several CLI windows open, running an interpreter shell that takes your input, searches all the libraries to find the functions, or looks in a common name space, and runs it. The shell can do simple type conversion: number string to int/long/etc., other string to variable (if bound) or filehandle if not, etc. Pointers are variables created by calling functions that create them: MakeMenu, MakeCursor, MakeWindow, etc. Now anything you can do with the libraries you can do interactively. Imagine that for debugging. Now write a cute little C parser with YACC. Wheeeee! And its only a 2-meg file on your hard drive. A "Using" environment that consists of all your favourite tools in their favoured places on your screen(s). When you're done for the day, you save it again and the whole thing goes to disk. Later you bring it back up, WITHOUT worrying if the power went off in the meantime, or if spikes hit your line, or whatever. Now that the Amiga crashes less often, people start to pack their 2 meg or whatever with lots of stuff. That takes lots of time to load. Most Amiga users I know leave their box on most of the time. That's sometimes bad. And in the recent vein of discussing Amiga ads: Someone turns on their IBM PC. They load their software. They do stuff. They change their software. They do more stuff. They change back. More stuff. They load an "accessory" program. They do more stuff. Meanwhile, an Amiga user just turns on his box, it loads his VM from hard drive, and he proceeds to work with several programs in several windows at once, including PC programs in PC windows. The same as the other guy, only without the loading and without the hassle. He gets a little bored. He pulls down his work screen and watches TV (using a genlock). On the TV is a short Amiga ad. We zoom in and actually watch the ad on the Amiga, which is about five seconds long, uses the sound, and ends with some worthwhile slogan. By then it probably doesn't matter what it is. Alternatively, a bunch of musical instruments and IBM PCs and artist's easels and stuff could come flying out of the ad, out of the Amiga, and hit the PC user in the head. He gets up, annoyed, and says "are you still playing with that thing? Do some work!" handing him a 5" floppy disk. The Amiga user puts the disk in his floppy drive, double-clicks on its icon and smiles at the camera. Wouldn't you?