dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/07/86)
>Steve Walton writes: > One further note: I compiled Matt's original Shell program with Manx. >I added some #define's in shell.h to get rid of most of his xstdio routines >so that the only routine I needed from MY.LIB was xprintf, and that only to >get fprintf() to an AmigaDOS file handle. (Memory allocated with malloc() >with Manx is automatically free()'d upon return from main() or upon a call >to exit()). The resulting executable was 23K plus a bit long. I believe >this compares favorably to what Matt gets with Lattice and MY.LIB. One has >to wonder about a company whose library can be bettered by one guy working >in his spare time... P.S. this is not a flame or anything, just a phase shift from a general point to what, in my opinion, are facts on a parallel line of reasoning. (In other words, I'm changing the subject) The difference is that I wrote it mainly for me, myself, and I, and thus didn't fudge on any of the routines. Lattice and Manx, on the other hand, do not have the quality of their libraries and compilers #1 on their list... they have other, more important (in their eyes) things to worry about. Certainly there are the programmers who write the stuff, and they may care, but they are still bound by a beaurocracy that wants certain results within a certain time-limit. What most companies don't understand is that it is the quality of their product that determines it's livability in the long-run. The following are true IN THE LONG RUN and eventually determine a product's fate. As applied to computers: -Hardware will never go beyond the design potential of the machine -Hardware that does go beyond the machine's design will never integrate well with the machine. -Software, no matter how good, will never be able to make up for deficiencies in the hardware. (assuming that in the long run a given software package will be available on ALL the machines in question) -Software, no matter how good, will never be able to make up for deficiencies in the OS. -Software that does attempt to go beyond the OS by bypassing it will never integrate well with the machine's design intentions. -A well designed machine will have rock-solid design intentions. (the MAC was rock-solid, but also surpressive. The Amiga is rock-solid.) The moral is that if you find a deficiency in your OS, FIX IT IMMEDIATELY. Do not worry about incompatibilities. Hardware is a different matter since you cannot easily propogate the changes to all concerned. In the same way, deficiencies in software should be fixed as soon as possible. The latter doesn't fit in well with most Companies since it involves a new release and updates, but fits extremely well with PD software. This is why there are umpteen revisions of most good PD programs, because the writer cares and because she/he can distribute a new version at any time. Example: (TSMCM-WB) The current Amiga's Directory structure is incompatible with the way WorkBench works. Neither the Workbench or the Directory structure is at fault, they just don't blend together well. The question is, which should you modify to become compatible with the other? Solution: In this case, it is obvious that the WorkBench ICON structure should be modified. Specifically, it is obvious that the ICON's should all be stored in a single file for each folder because this is what DOS is best at... finding a known file and reading its contents. The results: (A) No directory searches need be done (B) Window openning becomes an order of magnitude faster (C) The directory/folder structure is retained (D) The fix can be propogated without invalidating any software to date by the simple distribution of a new workbench and a utility to convert from the old (multiple files) to the new. It does not make sense to modify DOS: (A) Directory searches for most applications are now almost completely eliminated so modifing DOS may become superfluous. (B) Applications now have a new way of finding specific information (like DPAINT files) by having that information be represented by N ICONS (all of which can be accessed almost instantaniously). (C) Changing DOS would break everything in existance that does funny things with the disks, and probably more. -Matt
wagner@utcs.UUCP (10/10/86)
Well, matt, I generally agree with you, but this time, I have to tell you that I think you're out to lunch. To wit... In article <8610072043.AA18045@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >Example: (TSMCM-WB) > The current Amiga's Directory structure is incompatible with the > way WorkBench works. > > Neither the Workbench or the Directory structure is at fault, they > just don't blend together well. > > The question is, which should you modify to become compatible with > the other? > >Solution: > In this case, it is obvious that the WorkBench ICON structure should > be modified. Specifically, it is obvious that the ICON's should all Can not agree. It is not obvious (for reasons to be presented furthur on). Incidentally, I think you are guilty of having (in logic terms) used a conclusion as an assumption. > be stored in a single file for each folder because this is what > DOS is best at... finding a known file and reading its contents. Careful! We know something has to change. Your point here is that this version of DOS is good at finding files (and poor at doing wildcards, although you forgot to say that). Therefore, few changes would have to be made to the DOS in your scheme. Now, look at the other side. All sorts of things would have to change in the icon world. The current icon code is clearly poor at doing those new things (in fact, it can't at all, currently). The logic here, is, basically, lets compromise and do it the way I'm already doing it. "The way I'm doing it now" is at best an implementation detail. What happened to all the idealism about the 'right' way to do things that pervaded your original posting? Onwards.... > The results: > > (A) No directory searches need be done You should add "...to open windows". Directory searches are still done a lot in amigaDOS (and applications). In fact, this lack is one of the ones striking enough to merit your cries of 'the software should be fixed pronto'. Wildcards are hopelessly slow in amigaDOS. In fact, producing a list of all files in a directory (without wildcards) is ridiculously slow. I commented on this over half a year ago. (tongue in cheek) It is clear that the directory structure must be changed (!). (tongue back out of cheek) See my notes about this on the net at the time. The major problem is that file names are not stored together in one place (much easier to arrange than icons all in one place, let me tell you). As an (overly expensive) hack to avoid the need for immediate change, I pointed out that a disk sector cache would ease the pain, at cost of memory. Most existing end-user applications that I've seen interface to the file store by opening a requestor window, and giving you a list of files in your current directory. This takes too long. The paying end-users are going to get impatient. Fixing this problem will also fix the icon problem, and will make the machine much faster at the interface where it's going to make money (applications). > (B) Window openning becomes an order of magnitude faster Probably true. Perhaps even better than that. > (C) The directory/folder structure is retained I'm not sure its fair to say the structure is retained if you're going to change what goes into the folders dramatically. > (D) The fix can be propogated without invalidating any software > to date by the simple distribution of a new workbench and a > utility to convert from the old (multiple files) to the new. I'm not sure this is true (although it may just be my own ignorance). I expect there exist applications which have knowledge of .info files. Besides, it misses a major point. Icons as files had a very important property...they were just files. Everything I know how to do with a file I know how to do with an icon. I can copy it, rename it, move it...all knowledge I already possess (if I know how to use amigaDOS). (we will leave aside the fact that, on the WB interface, the icon is inseperable from the object it represents). If you remove the property of icon==file, you now have to supply me with commands to copy, rename, erase and otherwise manipulate the icons. Too bad, that. You're basically advocating building your own (sub)filing system inside the amigaDOS filing system because you've given up on theirs. That means you have to re-do the whole show. Although I can't give specifics, because I haven't thought about it enough, I can't believe it's going to be easy. The hardest part is that it's a user-visible change (well, amigaDOS-user visible, anyways). > > It does not make sense to modify DOS: > > (A) Directory searches for most applications are now almost completely > eliminated so modifing DOS may become superfluous. Huh? The only applications I can think of that don't need to search directories are those that either (a) don't use the file store once they get going, or (b) those where the user or the application already knows exactly which file is needed (hard-coded startup files, for example). Real, non-hacker users generally don't remember the name of the file they wrote yesterday, never mind last week, and they need to be shown, often, a list of their 'holdings'. > (B) Applications now have a new way of finding specific information > (like DPAINT files) by having that information be represented > by N ICONS (all of which can be accessed almost instantaniously). It's huh time again. Matt, I'm not even sure what this might mean! > (C) Changing DOS would break everything in existance that does funny > things with the disks, and probably more. Any change will break something, most likely the somethings that do 'funny' (read bypass the interfaces) things. You were the one advocating fixing things before they get cast in concrete. Now you're shying away from that attitude, precisely when it's needed the most - at a difficult decision! While C=A is still coming out with new releases on a regular basis, things can get fixed. And not all THAT much software is out yet. Sounds like the time is ripe. > > > -Matt To summarize, fixing the icons only produces a seperate filing system that will only become a maintenance headache, a needless duplication of effort and code, and fixes the problem by avoiding it. Fixing DOS gets a variety of performance problems fixed, including the icons, but also many others. It improves a basically good tool (the filing system), and introduces no user-visible changes. A prototype of the effects can be seen by using the cache support in 1.2 (a very nice concept in it's own right, but a bandaid in the context of this problem). I have a number of implementation suggestions on how this should be done (if I can only find my original submission, I won't have to reconstruct them all from memory), but that would be a different topic. At this point, it's useless to talk implementation until there is recognition that what you're implementing is conceptually sound. Sorry for the length, but this is important (I feel). Michael Wagner (wagner@utcs or ...utzoo!utcs!wagner)
acs@amdahl.UUCP (Tony Sumrall) (10/11/86)
In article <8610072043.AA18045@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > The moral is that if you find a deficiency in your OS, FIX IT IMMEDIATELY. > Do not worry about incompatibilities. Hardware is a different matter since > you cannot easily propogate the changes to all concerned. In the same way, > deficiencies in software should be fixed as soon as possible. The latter > doesn't fit in well with most Companies since it involves a new release and > updates, but fits extremely well with PD software. This is why there are > umpteen revisions of most good PD programs, because the writer cares and > because she/he can distribute a new version at any time. > > Example: (TSMCM-WB) > The current Amiga's Directory structure is incompatible with the > way WorkBench works. > ... > Solution: > ... > It does not make sense to modify DOS: > ... > (C) Changing DOS would break everything in existance that does funny > things with the disks, and probably more. > > > -Matt Isn't point C in conflict with the first line of the quotation (I hope I didn't take it out of context)? It is precisely the matter of breaking other innocent applications that makes the job of "fixing" deficiencies so difficult (and doesn't make fixing bugs any easier either). -- Tony Sumrall ...!{ihnp4,hplabs,seismo,sun}!amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]