cloos@acsu.buffalo.edu (James H. Cloos) (04/03/91)
I was thinking the otehr day about how I want to include copyright messages, etc. in my libraries. Given the number that are out there, I would like to avoid any possibility of name conflicts--at least with the version and copyright stuff. I'm looking at the following format for each of the commands to assure continuity and no conflicts: (Below, `name' refers to a libraries (possibly abbreviated) name and `number' to its (decimal) id number. Also, I'll use `@' to refer to \169, the copyright symbol.) @name [see next] @number paints a copyright screen, incl author's name, whether copyrighted or pd, whether freeware, shareware, or commercialware. This shows up as Cnumber in the menu. VERSname [see next] VERSnumber returns a version number to the stack. Should be design- ed so that a program that uses the routines in this lib call use this to confirm whether it'll work. This shouldn't add too much to the size of the libs. (I'll bet this will even be a concern when 3-d memory devices are perfected and the handhelds have 64 (or maybe 256 or 4K) address and data lines--word-addressed at that; no more of this byte-addressing nonsense (IMHO).) If there is a very large profusion of libraries out there, it would be nice to be able to have on-line mention of who wrote it; obviously copyrighted stuff in general and shareware/commercialware stuff in specific NEED this info. Further assuming that these libraries will not be static projects, allowing programs that use them to confirm that the needed version of the lib is there is helpful. (NB: the code /<< VERS1500 4.52 SAME \>> not only tests to see if the version is 4.52, but also tests whether the library is ATTACHed in the first place.) I thought I'd put this out onto the net to elicit responces. Please post all replies so that a resounding discussion can take place! ;^) Seriously, though, all replies are welcome! Happy (system (sh!)) Programming! -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>
grue@cs.uq.oz.au (Frobozz) (04/03/91)
In<68505@eerie.acsu.Buffalo.EDU>cloos@acsu.buffalo.edu (James H. Cloos) writes: >I'm looking at the following format for each of the commands to assure >continuity and no conflicts: >@name [see next] >@number paints a copyright screen, incl author's name, whether > copyrighted or pd, whether freeware, shareware, or > commercialware. This shows up as Cnumber in the menu. >VERSname [see next] >VERSnumber returns a version number to the stack. Should be design- > ed so that a program that uses the routines in this lib > call use this to confirm whether it'll work. >If there is a very >large profusion of libraries out there, it would be nice to be able to have >on-line mention of who wrote it; obviously copyrighted stuff in general and >shareware/commercialware stuff in specific NEED this info. Further >assuming that these libraries will not be static projects, allowing >programs that use them to confirm that the needed version of the lib is >there is helpful. (NB: the code /<< VERS1500 4.52 SAME \>> not only tests >to see if the version is 4.52, but also tests whether the library is >ATTACHed in the first place.) I like the idea of the VERS commands. I am not so sure about having specific copyright messages. I agree that a library should have a copyright message (or shareware message or declaration that it is public), I just wouldn't make a specific command for it. Much more irritating for the user would be to put up a title page whenever the package is started up (not for long). This would serve as a good reminder for shareware packages (even putting it up periodicly during the running of the package until the shareware fee is paid ;-) I'd also prefer to see the VERS used in more like the following manner: << VERS1500 4.52 >= >> assuming that libraries are upward compatable in some manner. Better might be something like: << IF IFERR VERS1500 THEN -1 END 4.52 < THEN cute message saying that the library isn't available END >> Using the compressed library name would also be a move in the right direction. How hard is it to change the ID of a library? After a quick glance at the format of a library it appears to be the changing of the ID number in a couple of places and the re-computation of the checksum. A utility to do this might be useful, I am certain that library conflicts are going to appear sometime in the future (there are not all that many IDs available are there ;-). I'll also say that I don't like the idea of programs depending upon the existance of non-public domain utilities. To use such a program requires the outlay of some cash to get the necessary utilities. This is only for programs that I intend to release to the world at large, for my personal programs anything goes. Pauli seeya Paul Dale | Internet/CSnet: grue@cs.uq.oz.au Dept of Computer Science| Bitnet: grue%cs.uq.oz.au@uunet.uu.net Uni of Qld | JANET: grue%cs.uq.oz.au@uk.ac.ukc Australia, 4072 | EAN: grue@cs.uq.oz | UUCP: uunet!munnari!cs.uq.oz!grue f4e6g4Qh4++ | JUNET: grue@cs.uq.oz.au --
sburke@jarthur.Claremont.EDU (Scott Burke) (04/04/91)
With respect to copyright notices and name conflicts: Sparcom has come up with a consistent framework for our products, as I will describe. Pick a product--say, the Personal Information Manager. The name of the that library is 'PIM', and in the Library sub-menu you will see two keys: |PIM| and |ABOUT|. Pressing |ABOUT| displays a screen with the Sparcom logo, the product name, the part number, the copyright w/ date, and the release version number of the product. However, the full name of the key/command is ABOUTPIM, if you were to want to type it in on the stack. In a similar vein, we have EEAPP, ABOUTEEAPP, MEAPP, GCAPP, GCREF, MEREF, EEREF, MATH2, and all the associate ABOUT... keys. APP stands for Application Pac, and REF for Reference Pac. One last library that is available is the File Manager, called FMGR and ABOUTFMGR. I would urge against TOO MANY different sub-programs in the Library sub-menu; instead, we have gone with a single ABOUT... key (an idea I stole from the Macintosh standard interface of an About Box). Sound reasonable? Scott.
sburke@jarthur.Claremont.EDU (Scott Burke) (04/04/91)
One last note about copyrights: Our very first few Personal Information Managers out the door flashed the copyright screen every time they ran, and we got some, shall we say, negative feedback? ;-) I would strongly urge people NOT to do that, because I suspect you will get instantaneous feedback on the matter... Scott.
grue@cs.uq.oz.au (Frobozz) (04/04/91)
In <11542@jarthur.Claremont.EDU> sburke@jarthur.Claremont.EDU (Scott Burke) writes: >With respect to copyright notices and name conflicts: [details of the ABOUT... scheme deleted] >I would urge against TOO MANY different sub-programs in the Library sub-menu; >instead, we have gone with a single ABOUT... key (an idea I stole from the >Macintosh standard interface of an About Box). >Sound reasonable? I like the idea with one reservation: if you ever upgrade a library to include extra functionality (which is quite likely to happen given the history of computing's love of creeping featurism) how do you indicate that the library is the later/earlier version? For a single purpose library that is a self-contained package, I cannot see any problems (since there isn't any decent method of accessing the internals of the library). For a utility library, this would cause more headaches. I suppose you could always try to use the command and fail if it doesn't exist ;-) Pauli seeya Paul Dale | Internet/CSnet: grue@cs.uq.oz.au Dept of Computer Science| Bitnet: grue%cs.uq.oz.au@uunet.uu.net Uni of Qld | JANET: grue%cs.uq.oz.au@uk.ac.ukc Australia, 4072 | EAN: grue@cs.uq.oz | UUCP: uunet!munnari!cs.uq.oz!grue f4e6g4Qh4++ | JUNET: grue@cs.uq.oz.au --