bryce@COGSCI.BERKELEY.EDU.UUCP (06/11/87)
In article <10334@decwrl> jmsynge@sqm.dec.com (James M Synge, DTN 381-1545) > >Imagine two libraries named "Music.library". > >I would suggest that Commodore perform the same registration service with >library names as they've done with Zorro id's and IFF hunk names. I second the motion! All that is needed is a simple set-up at C-A. You would simply send a SASE to the mail drop at 1200 Wilson Drive with your desired name, and what you are using it for. The letter would come back with either a yes or a unique name. (eg. Music3.library) Libraries, IFF types, public ports, DOS ID's. input.device handler names, device names, DOS handler names, fonts, resource names, resident tags, and any classes of conflictable names that I forgot. ("DOS " "NDOS" and "KICK" are taken, but I will stake claim to "DOS2" or "DOS+") There are plenty of names to go around, so everyone would be encouraged to participate. PD and commercial. Keep it SIMPLE and people will use it. Make provisions for un-registering a name and also EMAIL (Bix, USENET, etc.). "Advertise" the service well (AmigaMail, paper in new RKM's, and EMAIL to all the services. Describe the procedure and list types of registration). This record will be permanent, provided someone a C-A keeps backup tapes :-)! Official comment from CATS/anyone else encouraged. ------------- Ack! (NAK,EOT,SOH) |\ /| . {o O} . bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce ( " ) U Single tasking? Just say *NO!*
page@ulowell.UUCP (06/15/87)
jmsynge@sqm.dec.com (James M Synge) wrote: >I would suggest that Commodore perform the same registration service with >library names as they've done with Zorro id's and IFF hunk names. bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) replied: >"DOS " "NDOS" and "KICK" are taken, but I will stake claim to "DOS2" or "DOS+" Hmmm. Good to see some support for this. If we're grabbing, I'd like "ADOS" or "CDOS" ... is case significant? And what are *you* working on, Bryce? :-) >Official comment from CATS/anyone else encouraged. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}
andy@cbmvax.cbm.UUCP (Andy Finkel) (06/16/87)
In article <1379@ulowell.cs.ulowell.edu> page@ulowell.cs.ulowell.edu (Bob Page) writes: >jmsynge@sqm.dec.com (James M Synge) wrote: >>I would suggest that Commodore perform the same registration service with >>library names as they've done with Zorro id's and IFF hunk names. >bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) replied: >>"DOS " "NDOS" and "KICK" are taken, but I will stake claim to "DOS2" or "DOS+" > We'll see if we have the resources to support something like you suggest. It is a much bigger effort, as anyone with a couple of hours to spare can crank out a library. Maybe we can publish the names in an occasional newsletter; that way you'll be able to scan the list before you name your library. There will still be conflicts of course, no matter what system is used. Unless...how about jimdos, brycedos, and bobdos ? :-) (Reserving names doesn't seem quite fair...at least reserving before the product is ready to ship :-) Maybe its time for a *brilliant* linker... andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "hy can't you be unique and original like everybody else ?" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
kent@xanth.UUCP (06/17/87)
In article <2025@cbmvax.cbmvax.cbm.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >Maybe its time for a *brilliant* linker... >andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Maybe what we need is something to take libraries apart, so that we can put the needed modules in an explicit order, and a half linker, that does a link of everything it's given, and produces an object module ready for more linking. That way I could take apart window_lib to get its "push" routine, link it to my window_rtn, giving window_rtn_half_linked, take apart stack_lib to get its "push" routine, link it to my stack_rtn, giving stack_rtn_half_linked, and then link main, window_rtn_half_linked, and stack_rtn_half_linked with the standard libraries, giving the great new program stack_windows_with_confusing_pushes. Still doesn't get you were you want to go if you call both pushes from the same routine, but at least you're closer. See the article "Design and Implementation of a C-based Language for Distributed Real-time Systems", A. Rizk, F Halsall, SIGPLAN NOTICES V22 N6, June 1987, Page 83-100 for the ultimate solution to the problem, a language MC that allows C modules like Ada(tm) modules, and, like Ada, allows a "dot" notation like the one for structures to refer to routines within the module: window_module.push() and stack_module.push(), for example, would solve the above problem at the source code level, assuming the libraries would keep the fully qualified names for functions, including the module names. Kent. -- Kent Paul Dolan, LCDR, NOAA, Retired; ODU MSCS grad student // Yet UUCP : kent@xanth.UUCP or ...{sun,harvard}!xanth!kent // Another CSNET : kent@odu.csnet ARPA : kent@xanth.cs.odu.edu \\ // Happy USPost: P.O. Box 1559, Norfolk, Virginia 23501-1559 \// Amigan! Voice : (804) 587-7760 -=][> Last one to Ceres is a rotten egg! -=][>
page@ulowell.cs.ulowell.edu (Bob Page) (06/18/87)
andy@cbmvax.cbm.UUCP (Andy Finkel) wrote: >We'll see if we have the resources to support something like you suggest. Yay! I'm glad you see that there is a potential problem. >Maybe its time for a *brilliant* linker... Fine, as long as you also SUPPLY a 'make' program with it, since you won't want to have to remember all the options you may potentially have to remember. kent@xanth.UUCP (Kent Paul Dolan) wrote in article <1315@xanth.UUCP>: >Maybe what we need is something to take libraries apart, so that we can >put the needed modules in an explicit order, and a half linker, that does Arggh. I doubt they would get much use, and you'd have to recustomize for each project you were working on. >Still doesn't get you were you want to go if you call both pushes from >the same routine, but at least you're closer. In fact, that would be the only problem left, solved by: >SIGPLAN NOTICES V22 N6, June 1987, Page 83-100: a language MC that allows >a "dot" notation, like window_module.push() and stack_module.push() ... This is interesting (I hadn't seen it) since I was in on the design of a similar system a few years ago called Modular C which acted just like this. It was preprocessor-based, so no changes to the C compiler were necessary. Oddly enough, the two or three papers published on it appaeard in SIGPLAN NOTICES. I think it was about 4-5 years ago, the author was Stowe Boyd, then of Azrex Inc. The more things change... >would solve the problem at the source code level if the libraries would keep >the fully qualified names for functions, including the module names. And that's the problem. It's not hard to integrate the two (MC/Modular C and K&R/ANSI C) but I doubt any library writer will make the descision to use the dot notation just to be nice to other library writers. Of course CBM could solve this by recoding the libraries in MC or Modular C for release 1.3 and requiring everybody to follow the dot convention. It would be substantially easier than recoding it in Modula-2 or Ada. I'll dig up refs to the Modular C articles if anyone is interested. Another solution would be to implement libraries like devices, and pass function codes to a library handler. This is a little messier but much more general, solves the name conflicts (except for people using the same DOS name for the libraries - solvable by FileZap I guess), and is as extensible as the current scheme (unless I'm forgetting something). It also can be done in straight C, a big win. The last option is for CBM to ignore it and let the users worry about it. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}
peter@sugar.UUCP (Peter DaSilva) (06/19/87)
> jmsynge@sqm.dec.com (James M Synge) wrote: > >I would suggest that Commodore perform the same registration service with > >library names as they've done with Zorro id's and IFF hunk names. > bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) replied: > >"DOS " "NDOS" and "KICK" are taken, but I will stake claim to "DOS2" or "DOS+" Then page@ulowell.cs.ulowell.edu (Bob Page) added: > Hmmm. Good to see some support for this. If we're grabbing, I'd like > "ADOS" or "CDOS" ... is case significant? How about "UNIX" or "TAR" or "CPIO"? :->
gray@labc.dec.com (06/21/87)
CATS,
Why not extend Exec via the shared-library facility itself, to
include a service which provides dynamic name-space translation
services for all application?
As each application began running, it would feed its application
name (as coded by the programmer) to an Exec service which would
then provide it with a unique key to be used in obtaining the
online-unique-name-translations for all of its system-wide resources
(including shared-libraries.)
A utility program would be available to the user (from Workbench
or a shell) to allow the user to "register" its applications, during
initial installation, with the Exec name-translation services.
This utility program would then conciously resolve any descrepencies
between application names, as new applications are added to the
system, for use in generating and assigning unique identifier keys.
This can be accomplished at the utility program level as within
its context, it knows exactly which applications are present in
the machine and which application names are unique.
The argument could now be made that the problem of coordinating
library-names has become the problem of coordinating-application
names; however, application-names are generally registered copyrights
or (in the case of pd-type software) are sufficiently unique to
not cause problems. It is my opinion that, in fact, application
names are generally so unique that very little, if any coordination
would be required on the part of Commodore.
Because the facility described would exist part in a shared library
and part in a utility program (and not in the actual os architecture),
it would only be effective for programs which chose to use it.
This would, however, provide backwards compatibility with existing
applications.
-Tom Gray
[ These views and opinions do not necessarily reflect those of Digital
Equipment Corporation. ]
uucp: labc.dec.com!gray
ARPA: gray%labc.DEC@decwrl.arpa
ENET: LABC::GRAY