From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-037 Date: Sat, 18 Jun 1994 11:33:52 +0200 (MET DST) C.S.M.P. Digest Sat, 18 Jun 94 Volume 3 : Issue 37 Today's Topics: Finding a drive's SCSI ID How to tell which volume was booted from? Open Transport & ASLM (Was: Re: ASLM) Symantec at WWDC (Was: Symantec vs. Metrowerks? What to do?) [Q] Finding out if volume is locked The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From Jerry.Halstead@launchpad.unc.edu (jerry halstead) Subject: Finding a drive's SCSI ID Date: 27 May 1994 22:49:40 GMT Organization: University of North Carolina Extended Bulletin Board Service I am writing a program that uses GetVInfo to get a list of drives the Mac sees (and snarf information about them) and then a lower level SCSI routine to go out and find out what drives are on the SCSI chain. After getting this info I would like to be able to match the GetVInfo with the device info I found, determining which drives are Mac supported drives and which are unformatted or other types of SCSI devices. Any ideas how to accomplish this? Here's what I have so far, first here's the infor from GetVInfo: Drive 9: Volume Ref: -1; Bytes free: 92809728, Name: 'Quack' Then my low level SCSI routine returns the following: Device ID: 2 dev type: 0 qual: 0 version: 1 response: 1 add len: 31 vendor: MAXTOR LXT-340S 6.75 productId: LXT-340S 6.75 productRev: 6.75 data: 45 52 02 00 00 0a 26 38 00 00 00 00 00 00 00 00 00 02 00 00 00 40 00 05 01 01 00 0a 25 fffffff5 00 08 } I know these two collections of info are the same, but how do I enlighten my program? How can I get a drive's SCSI ID by using vRefNum, or how can I get the name of a Mac drive using low level SCSI routines? Is there a handy routine for this, or do I need to learn more about the format of Mac disks (say it ain't so!). Tanks! Oh, btw, the data below productRev is from reading sector zero on the drive: is there signifigance to the "45 52 02"? I found it on a couple of Mac drives I was peeking at. -- - ---------------------------------------------------------------------------- \ The above does not represent OIT, UNC-CH, laUNChpad, or its other users. / ------------------------------------------------------------------------ +++++++++++++++++++++++++++ >From dshayer@netcom.com (David Shayer) Date: Sat, 28 May 1994 03:13:44 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) jerry halstead (Jerry.Halstead@launchpad.unc.edu) wrote: : I am writing a program that uses GetVInfo to get a list of drives the Mac : sees (and snarf information about them) and then a lower level SCSI : routine to go out and find out what drives are on the SCSI chain. After : getting this info I would like to be able to match the GetVInfo with the : device info I found, determining which drives are Mac supported drives and : which are unformatted or other types of SCSI devices. Any ideas how to : accomplish this? You can match the driver refnum against the scsi id. See IM 2 p 191 for the formula for calculating the unit table slot for a driver if you know it's refnum. See IM 4 p 215 for a list of which drivers go where in the unit table. Another case of its obvious if you had only known to look there. To summarize IM, scsi drivers go in slots 32-40 in the unit table in order, so the dirver for scsi 0 is in slot 32, scsi 1 is in slot 1, etc. slot number = -(refnum-1) So the driver for scsi 0 has refnum -33, scsi 1 has refnum -34, etc. : Oh, btw, the data below productRev is from reading sector zero on the : drive: is there signifigance to the "45 52 02"? I found it on a couple of : Mac drives I was peeking at. $4552 is 'ER', the signature in block 0, the driver map. See IM 5 p 577 for the format of the driver map. I'd advise against modifying the driver map, unless you have a backup of your drive, and you intend on testing the restore option of your backup software. :-) David Shayer shayer@applelink.apple.com Freelance Hacker +++++++++++++++++++++++++++ >From tzs@u.washington.edu (Tim Smith) Date: 28 May 1994 11:37:15 GMT Organization: University of Washington School of Law, Class of '95 David Shayer wrote: >You can match the driver refnum against the scsi id. >See IM 2 p 191 for the formula for calculating the unit table slot >for a driver if you know it's refnum. See IM 4 p 215 for a list of which >drivers go where in the unit table. Another case of its obvious if you >had only known to look there. Here's another way, that has the advantage of working even if Apple stops using a straightforward mapping between refnum and SCSI ID. Do an illegal command via the SCSI Manager on the SCSI drive whose Mac driver you wish to find (reading block 0xFFFFFFFF is a good command here, unless it's a really big drive). Do not do a REQUEST SENSE command. Then, read a block through one of the Mac drivers. Now do a REQUEST SENSE via the SCSI Manager to the disk. If there is no sense data, then your access through the Mac driver must have issued a command to that drive, thus wiping out the sense data from the failed command, and you know that was the Mac driver for that SCSI device. If the sense data is still there, repeat the process, using a different Mac driver next time, and so on, until you find the right one. Drawback: this assumes SCSI devices that follow the SCSI spec. There are some popular disks out there that don't quite get this right. In particular, I seem to recall seeing one that does not clear the sense data for a failed command when it gets a subsequent command. Drawback: this is the kind of thing someone might do on DOS (in fact, that's how some DOS SCSI drivers that load from config.sys determine what mapping the SCSI BIOS set up from SCSI disks to INT 13h drives), so your reputation might suffer. Drawback: this assumes you can control all I/O. If someone can come in and do a file access (e.g., perhaps through file shareing?), they may confuse things. --Tim Smith +++++++++++++++++++++++++++ >From rang@winternet.com (Anton Rang) Date: 03 Jun 1994 00:04:59 GMT Organization: Minnesota Angsters In article dshayer@netcom.com (David Shayer) writes: > [ about ways to get the scsi id given a volume ] > >You can match the driver refnum against the scsi id. >See IM 2 p 191 for the formula for calculating the unit table slot >for a driver if you know it's refnum. See IM 4 p 215 for a list of which >drivers go where in the unit table. Another case of its obvious if you >had only known to look there. This works with the old SCSI Manager. If SCSI Manager 4.3 is installed, you should call one of its routines instead, as the old mapping only works for devices visible to the virtual SCSI bus. I think it's a "LookupRefNumXref", but haven't got my docs here. -- Anton Rang (rang@winternet.com) --------------------------- >From mpcline@cats.ucsc.edu (Matthew Paul Cline) Subject: How to tell which volume was booted from? Date: 3 Jun 1994 23:55:02 GMT Organization: University of California, Santa Cruz The subject says it all. Thanks in advance. -- Poodles have no honor. Have you hugged your shoggoth today? GE d? -p+ c++(+++) l++ u++ e+ m+ s/- n+(-) h+ f !g w+ t+ r y+ +++++++++++++++++++++++++++ >From mclow@coyote.csusm.edu (Marshall Clow) Date: 3 Jun 1994 17:31:48 -0700 Organization: California State University San Marcos Matthew Paul Cline (mpcline@cats.ucsc.edu) wrote: > The subject says it all. Thanks in advance. Depends how esoteric you want to get. If you want the current system volume (almost always the same volume that you booted from), call SysEnvirons and resolve the wdRefNum for the system folder into a vRefNum/DirID using GetWDInfo. If you really want to know what volume was booted from, I think that you are out of luck. Suppose (System 6, now), you booted from a floppy, switch-launched to a RAM disk, and unmounted the floppy. Marshall Clow Aladdin Systems mclow@san_marcos.csusm.edu +++++++++++++++++++++++++++ >From ivanski@world.std.com (Ivan M CaveroBelaunde) Date: Sat, 4 Jun 1994 01:56:27 GMT Organization: The World Public Access UNIX, Brookline, MA mclow@coyote.csusm.edu (Marshall Clow) writes: >Matthew Paul Cline (mpcline@cats.ucsc.edu) wrote: >> The subject says it all. Thanks in advance. >Depends how esoteric you want to get. If you want the current >system volume (almost always the same volume that you booted >from), call SysEnvirons and resolve the wdRefNum for the system >folder into a vRefNum/DirID using GetWDInfo. >If you really want to know what volume was booted from, I think >that you are out of luck. Suppose (System 6, now), you booted from >a floppy, switch-launched to a RAM disk, and unmounted the floppy. Actually, that's not quite right. I believe that the vRefNum of the boot volumes is *always* -1 (it's in a technote somewhere - the same one that states that the dirID for the root directory of a volumes is always 2). Hope this helps, -Ivan - - Ivan Cavero Belaunde (ivanski@world.std.com) Avid VideoShop Project Lead Avid Technology, Inc. +++++++++++++++++++++++++++ >From grobbins@apple.com (Grobbins) Date: 3 Jun 1994 20:07:46 -0700 Organization: Skunkworks In article <2sofsm$fsh@darkstar.UCSC.EDU>, Matthew Paul Cline wrote: >The subject says it all. No, it doesn't. At present, the boot disk has a vRefNum of -1. But that may not be true down the road; indeed, the system may use some more complex boot mechanisms, perhaps including the use of servers, volumes in ROM, temporary volumes, or disks made of toasted raisin bread. Applications should not generally assume anything about the boot volume; in particular, it may not be local, may not be writable, and may not have all of its raisins. So what is it you are trying to do? If you can use the call FindFolder or the application's file spec (from the GetProcessInformation call) those may provide more reliable information. For general information on booting and disk organization, take a look at Inside Mac:Files p 2-54 and following, and Inside Mac:Devices, ch 4. Grobbins grobbins@apple.com Usual disclaimers apply. +++++++++++++++++++++++++++ >From blob@apple.com (Brian Bechtel) Date: 4 Jun 1994 07:09:13 -0700 Organization: Apple Computer, Inc., Cupertino, California grobbins@apple.com (Grobbins) writes: >In article <2sofsm$fsh@darkstar.UCSC.EDU>, >Matthew Paul Cline wrote: >>The subject says it all. >No, it doesn't. At present, the boot disk has a vRefNum of -1. >But that may not be true down the road; indeed, the system may use >some more complex boot mechanisms, perhaps including the use of >servers, volumes in ROM, temporary volumes, or disks made of toasted >raisin bread. Applications should not generally assume anything about >the boot volume; in particular, it may not be local, may not be >writable, and may not have all of its raisins. Augh! First the Caffeine Manager, now the Toasted Raisin Bread Manager.... when will it all stop? Greg's right. Use FindFolder. --Brian Bechtel blob@apple.com "My opinion, not Apple's" +++++++++++++++++++++++++++ >From omh@cs.brown.edu (Owen M. Hartnett) Date: Sat, 4 Jun 1994 17:47:36 GMT Organization: Brown University Department of Computer Science In article <2sq1u9$c3p@apple.com> blob@apple.com (Brian Bechtel) writes: >grobbins@apple.com (Grobbins) writes: > >Augh! First the Caffeine Manager, now the Toasted Raisin Bread >Manager.... when will it all stop? In the new Universal Headers, both the Caffeine Manager and the Toasted Raisin Bread Manager fall under the direction of the Grocery Manager. -Owen -- Owen Hartnett omh@cs.brown.edu "FAITH, n. Belief without evidence in what is told by one who speaks without knowledge, of things without parallel." -Ambrose Bierce - The Devil's Dictionary +++++++++++++++++++++++++++ >From mpcline@cats.ucsc.edu (Matthew Paul Cline) Date: 4 Jun 1994 20:20:39 GMT Organization: University of California, Santa Cruz In <2sor62$rqh@apple.com> grobbins@apple.com (Grobbins) writes: >In article <2sofsm$fsh@darkstar.UCSC.EDU>, >Matthew Paul Cline wrote: >>The subject says it all. >So what is it you are trying to do? If you can use the call FindFolder >or the application's file spec (from the GetProcessInformation call) >those may provide more reliable information. For general information >on booting and disk organization, take a look at Inside Mac:Files >p 2-54 and following, and Inside Mac:Devices, ch 4. I am looking for a way to uniquely identify a Mac. One idea was to to use the format time of the boot disk as the Macs ID number. However, if identifying a suitable drive will become that complicated, I'll figure out another way. -- Poodles have no honor. Have you hugged your shoggoth today? GE d? -p+ c++(+++) l++ u++ e+ m+ s/- n+(-) h+ f !g w+ t+ r y+ +++++++++++++++++++++++++++ >From mclow@coyote.csusm.edu (Marshall Clow) Date: 4 Jun 1994 14:28:59 -0700 Organization: California State University San Marcos Matthew Paul Cline (mpcline@cats.ucsc.edu) wrote: >In <2sor62$rqh@apple.com> grobbins@apple.com (Grobbins) writes: >>In article <2sofsm$fsh@darkstar.UCSC.EDU>, >>Matthew Paul Cline wrote: >>>The subject says it all. >>So what is it you are trying to do? >I am looking for a way to uniquely identify a Mac. One idea was to to >use the format time of the boot disk as the Macs ID number. However, >if identifying a suitable drive will become that complicated, I'll figure >out another way. Why not use the format time for the current system volume? (instead of the boot volume) It's a lot easier to get! If the mac has built-in ethernet, then the (hardware) ethernet address is unique to that machine (NOT the IP address). Other than that, there is NO foolproof method to uniquely identify a Macintosh. The creation date for the system disk is a reasonable way to distinguish macintoshes, but you should plan for failure. In a lab environment, some sysadmins use disk-cloning software to keep a bunch of machines' configuration identical. Some of these programs just use SCSI commands to completely replicate a disk. Every bit. Imagine your software seeing 50 macs with identical disks, down to the volume's creation date. Marshall Clow Aladdin Software mclow@san_marcos.csusm.edu +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 4 Jun 1994 23:35:03 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <2sofsm$fsh@darkstar.UCSC.EDU>, mpcline@cats.ucsc.edu (Matthew Paul Cline) writes: > How to tell which volume was booted from? This will give you the name and vRefNum of the current system disk which (as many have noted) may or may not be the boot volume: OSErr result; short foundVRefNum; long foundDirID; Str255 systemDiskName = "\p"; long freeBytes; result = FindFolder(kOnSystemDisk, kSystemFolderType, kDontCreateFolder, &foundVRefNum, &foundDirID); if ( result == noErr ) { result = GetVInfo(foundVRefNum, systemDiskName, &foundVRefNum, &freeBytes); if ( result == noErr ) printf("%#s\n",systemDiskName); } - Jim Luther --------------------------- >From Steve Ethier Subject: Open Transport & ASLM (Was: Re: ASLM) Date: Wed, 25 May 1994 19:49:08 GMT Organization: Novell, Inc. In article John McEnerney, johnmce@world.std.com writes: >Jim.Matthews@dartmouth.edu (Jim Matthews) writes: > >>Me too; fortunately they don't. OpenTransport has a procedural interface >>that can be called from any development system that supports Pascal >>calling conventions (i.e. any development system that can call the Mac >>Toolbox). So I believe it's a true statement that anything you can do >>today with the driver-based network APIs (.mpp, .atp, .xpp, .ipp) will be >>possible under OpenTransport from CodeWarrior. I don't see any reason why >>I shouldn't be able to build an OpenTransport/TCP version of Fetch in >>CodeWarrior. > >If OpenTransport uses a 'pascal' procedural interface and uses ASLM only >as a DLL solution, then the calling convention/runtime representation >issue go away. It may be possible to get this to work with CodeWarrior >with a modest amount of effort. Can someone point me to the proper >documentation for building for OpenTransport? Jim and John (and whoever else if following this thread), maybe I don't understand what is going on with these interfaces, but this is my take on it. Apple's implementation of AppleTalk and TCP for Open Transport will support the old "paramblock" style APIs for backwards compatibility with existing applications. In this case, having Open Transport in the ASLM architecture is really a non-issue. As far as I know, Open Transport itself doesn't support the "paramblock" APIs, it is up to the protocol developer to provide that support (i.e., when I port MacIPX over to Open Transport, I will have to write additional code in order to support the existing "paramblock" style MacIPX APIs). Then, Open Transport provides the X/Open APIs in the following forms: standard XTI APIs which are procedural interfaces (and really are synchronous APIs), Apple's superset of the XTI APIs with a procedural interface (I believe their superset provides async operation, probably turns them into Pascal interfaces, etc.), and finally, Apple's superset of the XTI APIs in an object-oriented form. As I understand it, *all* of the XTI Open Transport interfaces are only available via ASLM. Even if you use the procedural XTI interface, you'll still need to communicate with the ASLM. Also, from my perspective, I don't need the OO APIs at this time. If I could get Metrowerks and Symantec support of procedural interfaces into Open Transport and the ASLM, this would make me happy for a while. At least developers would be able to use some of the new Open Transport APIs with Metrowerks and Symantec. I believe Garry Hornbuckle of Apple is acutely aware of all these issues and is working on getting them resolved. Steve Ethier ethier@wc.novell.com +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Thu, 26 May 1994 02:49:36 GMT Organization: The World Public Access UNIX, Brookline, MA >As I understand it, *all* of the XTI Open Transport interfaces are only >available via ASLM. Even if you use the procedural XTI interface, you'll >still need to communicate with the ASLM. Also, from my perspective, I >don't need the OO APIs at this time. If I could get Metrowerks and >Symantec support of procedural interfaces into Open Transport and the >ASLM, this would make me happy for a while. At least developers would be >able to use some of the new Open Transport APIs with Metrowerks and >Symantec. Someone has kindly volunteered to look into this for me. If there are no OOP issues and the 'pascal' calling conventions are used, it may be possible to use the OpenTransport interface from CodeWarrior. (In that case, although OpenTransport is using ASLM, your program isn't except to initialize/terminate it) This leaves only issues of importing the OpenTransport and ASLM .o files--it may not work the first time, but this is easier to fix than the C++ calling conventions. Everyone should feel free to keep me posted with new developments. -- John McEnerney, Metrowerks PowerPC Product Architect +++++++++++++++++++++++++++ >From Steve Ethier Date: Thu, 26 May 1994 17:13:54 GMT Organization: Novell, Inc. In article John McEnerney, johnmce@world.std.com writes: >Someone has kindly volunteered to look into this for me. If there are no >OOP issues and the 'pascal' calling conventions are used, it may be I didn't volunteer because I don't have the cycles at this time, but if the kind soul helping you out isn't already familiar with XTI/TLI code, I do have some test code that I would be willing to share with that person to jump start the effort. This code uses TLI (which is very similar to XTI), so it would take some work to move over to Apple's Open Transport APIs, but I think Open Transport also supports the XTI APIs, so maybe this person could just try those interfaces. The only other drawback to this code is that I think the server side of it was a NetWare NLM I had also put together. Of course, this code is 3 years old, so I don't remember exactly how it went together. Anyway, if this person is interested in seeing this code, please contact me. Steve Ethier Internet: ethier@wc.novell.com Phone: 510-975-4518 AppleLink: NOVELL.WCENG (Put [SLE] in the subject so that it'll get routed to me) +++++++++++++++++++++++++++ >From garryh@seeding.apple.com (Garry Hornbuckle) Date: 4 Jun 1994 01:06:54 GMT Organization: Apple Computer In article , johnmce@world.std.com (John McEnerney) wrote: > Someone has kindly volunteered to look into this for me. If there are no > OOP issues and the 'pascal' calling conventions are used, it may be > possible to use the OpenTransport interface from CodeWarrior. (In that > case, although OpenTransport is using ASLM, your program isn't except to > initialize/terminate it) This leaves only issues of importing the > OpenTransport and ASLM .o files--it may not work the first time, but this > is easier to fix than the C++ calling conventions. DISCLAIMER: I'm an programmer/software engineer turned marketing guy. I've written a lot of code in my life, but compilers, linkers, or dynamic loading architectures are not on my resume. The following comments are based on someone else's (informed) explanation to me of what the issues are here. If I screw-up or misstate something here, it's my error. Apple Shared Library Manager is one of several dynamic link and load architectures in the Mac OS today (others include the Code Fragment Manager, the upcoming implementation of System Object Model, the QuickTime component manager, and the Comm ToolBox). The differences between each of these, and when to use what, are important discussions...but not for this thread. If you possibly can, you should get access to a video or audio tape of the '94 WWDC session titled "DLLs and Shared Objects on Macintosh" - the first 20-30 minutes of the session was spent explaining key differences between these technologies and looking at how to pick which one to use for the specific job at hand. Almost by definition, DLL architectures need to have some knowledge of code internals and runtime "stuff". (SOM avoids many of these problems, but requires you to describe things first in an IDL). During the design and implementation of ASLM, when it came time to "know things and stuff", ASLM engineers looked at MPW's behavior as a reference model. Whether this is good or bad probably depends on what you think about MPW (which is also not the point of this thread). What is important to know, however, is that other compiler/linker developers have made choices, for their own very good and important reasons, to do "things" and store "stuff" differently than MPW does. As a result, today ASLM is straightforward to use with MPW, but difficult or even impossible to use with other compiler/linker tools such as the MetroWerks or Symantec environments. This is an issue of concern for all ASLM developers. Based on what I've been able to understand about this, I believe that there are five key things that must be true to state that "Compiler XXXX supports ASLM" or conversely, that "ASLM supports Compiler XXXX". And there are four different levels of interoperability possible. Level One Compatiblity - -------------------- At this level, I can build C or Pascal language programs that use the services of ASLM and load ASLM shared libaries. The C or Pascal language programs can be built with the compiler/linker of my choice. The shared libraries must be built with MPW, or with a compiler/linker that conforms to all of MPW's "stuff". (A MetroWerks C or Pascal app could use ASLM to load and share a MPW shared library). To reach Level One Compatibility, 3 things must be true: ¥ the Compiler/Linker chosen must be able to import the 'LibraryMgr.o' file supplied in the ASLM developer kit. ¥ the Compiler/Linker chosen and ASLM must agree on data representation issues such as insertion of padding bytes, struct alignment, etc. This agreement could come because the compiler handles these things the same way as does MPW (and thus conforms to ASLM's expectation), or possibly because the compiler offers a switch to conform to MPW conventions as an option. By itself, having ASLM offer a switch to conform to the compiler's expectations would not be sufficient to achieve this level of compatibility (I don't think), because the shared libaries would have been built with MPW and thus there would potentially be disagreement on this fundamental issue. ¥ the Compiler/Linker chosen and ASLM must agree on calling conventions; Is it going to be C for C, Pascal for Pascal? Pascal for everything? Again, this agreement could come because the compiler handles these things the same way as does MPW (and thus conforms to ASLM's expectation), or because the compiler offers a switch to conform to MPW conventions as an option. By itself, having ASLM offer a switch to conform to the compiler's expectations would not be sufficient to achieve this level of compatibility (I don't think), because the shared libaries would have been built with MPW and thus there would potentially be disagreement on this fundamental issue. Level Two Compatibility - --------------------- At this level, I can also build C++ programs that use the services of ASLM and load ASLM shared libaries. The C++ programs can be built with the compiler/linker of my choice. The shared libraries must be built with MPW, or with a compiler/linker that conforms to all of MPW's "stuff". (A MetroWerks C++ app could use ASLM to load and share a MPW shared library). To reach Level Two Compatibility, all three conditions from Level One must be satisfied. In addition, the following condition must also be true: ¥ the Compiler/Linker chosen and ASLM must agree on the V-table format in use. This agreement could come because the compiler handles these things the same way as does MPW (and thus conforms to ASLM's expectation), or because the compiler offers a switch to conform to MPW conventions. By itself, having ASLM offer a switch to conform to the compiler's expectations would not be sufficient to achieve this level of compatibility (I don't think), because the shared libaries would have been built with MPW and thus there would potentially be disagreement on this fundamental issue. Level Three Compatibility - ----------------------- At this level, I can also build shared libraries that can be loaded by ASLM upon direction from a client application. The client application and the shared libaries can be built with THE SINGLE compiler/linker of my choice. (A MetroWerks C, Pascal, or C++ application could use ASLM to load a MetroWerks shared library). To reach Level Three Compatibility, all four conditions from Level One and Level Two must be satisfied. In addition, the following condition must also be true: ¥ the Compiler/Linker chosen and ASLM must agree on the format of the object file. This agreement could come because the compiler handles these things the same way as does MPW (and thus conforms to ASLM's expectation), or because the compiler offers a switch to conform to MPW conventions, _or_ by having an ASLM switch that directs ASLM to conform to the compiler's expectations for "stuff". Level Four Compatibility - ---------------------- At this level I can build C, Pascal or C++ client applications, as well as shared libraries that can be loaded by ASLM upon direction from a client application. The client application and the shared libaries can be built with a MIX-AND-MATCH set of compilers/linkers of my choice. Libraries, both procedural and object-oriented, from multiple compilers could be dynamically loaded and shared. (A MetroWerks main could load a shared library that had been built with Symantec tools, for example). To reach Level Four Compatibility, all five conditions from Level One through Level Three must be satisfied. In addition, the following condition must also be true: ¥ ALL Compilers/Linkers and ASLM must agree on ALL the "stuff" outlined above. This agreement, I believe, could only come through an industry or defacto standard representation and format for data, calling conventions, V-table formats, and object file formats. To my knowledge, no such single format agreement, spanning MPW, MetroWerks, and Symantec tools, exists (I'd love to be wrong on this). - ---------------------- I really appreciate the support for and interest in ASLM by applications and tool developers such as the great folks at MetroWerks and Symantec. I'm interested in working out multi-tool support for ASLM, and am willing to seriously investigate changes to ASLM if there is a real possibility of getting to Level Four compatibility! Comments and corrections are welcome. But please, no technical flames. I'm only the marketing guy. ;) Garry "also the ASLM guy" Hornbuckle - --------------------------------------------------------------------- Garry Hornbuckle Product Manager, Communications & Collaboration - --------------------------------------------------------------------- "If I told you that I | email garryh@seeding.apple.com spoke only for myself | applelink HORNBUCKLE1 would you believe me?" | fax (408) 974-1211 - --------------------------------------------------------------------- --------------------------- >From jc@vivitech.com (John Cooper) Subject: Symantec at WWDC (Was: Symantec vs. Metrowerks? What to do?) Date: Sun, 22 May 1994 13:55:55 GMT Organization: Vivid Technologies Inc. In article <2ren5c$f12@news.delphi.com> thundero@news.delphi.com (THUNDERONE@DELPHI.COM) writes: >> A couple of more things. First, today, Symantec has announced some >> new tools -- a subscription CD that has development versions of >> compilers and such on it. >Hehehe... I wonder where they got *that* idea. But are Symantec's >prereleases as stable as Metrowerks? Can you post some more details, >or at least the month of the MacTech issue reviewing this CD? Symantec >folks, you guys want to post some details? Phil? Tom? I heard from a friend who attended WWDC that Symantec was boo'ed and hissed at by a room full of developers during a seminar. Such a reception is usually reserved for Microsoft alone... This same friend also characterized Symantec's tools announcements as mostly: "We'll have that too, someday..." I guess developers weren't too impressed with Symantec this year. Can anyone else who attended offer their observations/opinions/insights? -John +--------------------------+------------------------------------------+ | John R. Cooper | Internet: jc@vivitech.com, | | Vivid Technologies, Inc. | jcooper@world.std.com | | Waltham, MA 02154 | AOL: JRCooper (jrcooper@aol.com) | +--------------------------+------------------------------------------+ | "God split himself into a myriad parts that he might have friends." | | This may not be true, but it sounds good and is no sillier than any | | other theology. | | -- Long's Notes -- | +---------------------------------------------------------------------+ +++++++++++++++++++++++++++ >From mikel@intercon.com (Michael W. Wellman) Date: Mon, 23 May 1994 13:38:57 -0500 Organization: InterCon Systems Corp., Herndon, VA, USA In article <1994May22.135555.5162@vivitech.com>, jc@vivitech.com (John Cooper) writes: > I heard from a friend who attended WWDC that Symantec was boo'ed and > hissed at by a room full of developers during a seminar. Such a > reception is usually reserved for Microsoft alone... > > This same friend also characterized Symantec's tools announcements > as mostly: "We'll have that too, someday..." I guess developers > weren't too impressed with Symantec this year. > > Can anyone else who attended offer their observations/opinions/ > insights? Symantec was repeatedly hissed at WWDC. Essentially, every time Apple mentioned their respective names during the "Developer Tools State of the Union", Symantec was hissed and Metrowerks was applauded. When it came time to do their presentations, Metrowerks blew everyone away. Their demo consisted of their compiling the 68k version of Metrowerks, the PowerPC version of Metrowerks, and MacApp 3.1; some 1.4 million lines of code in some 11 minutes (in fact, the talking portion of the presentation finished first so they stopped the compile before it all finished, but they were only a few files from the end of MacApp). This was followed by testimonials from people from Adobe, Apple, Claris, and other companies. Summary of the testimonials: Metrowerks not only cures cancer, it causes world peace. By the time Symantec took the stage, no one was booing anymore simply because everyone felt sorry for them. They decided not to compile, not to show the debugger, and when they went to show some of their "cool" stuff, it repeatedly crashed. To be fair, Symantec had added some nifty features to both their 7.0.1 release and their next generation environment. You can finally open a file without a project being open; you can open multiple projects; projects can be nested nicely in the project window and double-clicking them opens another project window; they support descending sub-projects and automatically rebuilding them if necessary; they've got multiple-paned windows; etc. The consensus seemed to be too little too late. Personally, three of the five people I was with left immediately after the Metrowerks demo to buy a copy of Metrowerks and see if we could get some things compiled before dinner... ;-) I'm personally disappointed that both Metrowerks and Symantec seem pretty dedicated to not supporting Apple's Shared Library Manager since you can't use Open Transport without such support. mikel +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 23 May 94 23:10:26 GMT Organization: SRI International, Menlo Park, CA In article <9405231338.AA57725@mikel.intercon.com> mikel@intercon.com (Michael W. Wellman) writes: >I'm personally disappointed that both Metrowerks and Symantec seem pretty >dedicated to not supporting Apple's Shared Library Manager since you can't >use Open Transport without such support. Or that the OpenTransport team decided to use ASLM. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 24 May 1994 06:17:50 GMT Organization: The Royal Institute of Technology >>I'm personally disappointed that both Metrowerks and Symantec seem pretty >>dedicated to not supporting Apple's Shared Library Manager since you can't >>use Open Transport without such support. >Or that the OpenTransport team decided to use ASLM. Won't ASLM come on top of the CFM? And both MW and SC will of course support the CFM. The only thing left is making the name mangling conform to CFront standards. Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- "From now on I will re-label the EQ on the deck as Fizz and Wobble instead of HF and LF." +++++++++++++++++++++++++++ >From Chris Hanson Date: Mon, 23 May 94 22:53:26 -0600 Organization: Green Dragon Creations, Inc. In article <9405231338.AA57725@mikel.intercon.com>, Michael W. Wellman writes: > I'm personally disappointed that both Metrowerks and Symantec seem pretty > dedicated to not supporting Apple's Shared Library Manager since you can't > use Open Transport without such support. I think it's more Apple's fault, actually. Shared Library Manager is designed to work with MPW C++ (which is CFront 2.something, I think). This is because it explicitly supports only C++, and relies on the structure of MPW's virtual tables and the way MPW munges method names. Of course, since Apple has committed to SOM I think they'd be stupid not to support Open Transport on it also. My bet is that they will; until SOM support is formally integrated into the OS, we'll probably rely on ASLM for such matters. TTFN, Chris +++++++++++++++++++++++++++ >From mikel@intercon.com (Michael W. Wellman) Date: Tue, 24 May 1994 09:37:02 -0500 Organization: InterCon Systems Corp., Herndon, VA, USA I wrote: > > I'm personally disappointed that both Metrowerks and Symantec > > seem pretty dedicated to not supporting Apple's Shared Library > > Manager since you can't use Open Transport without such support. Chris Hanson wrote: > I think it's more Apple's fault, actually. Shared Library Manager is > designed to work with MPW C++ (which is CFront 2.something, I > think). This is because it explicitly supports only C++, and relies > on the structure of MPW's virtual tables and the way MPW munges > method names. Of course, since Apple has committed to SOM I think > they'd be stupid not to support Open Transport on it also. My bet is > that they will; until SOM support is formally integrated into the > OS, we'll probably rely on ASLM for such matters. I vaguely recall something about SOM not being capable of dealing with issues such as interrupts (you pay some prices for platform independence). If this memory is correct, it'd be very hard to build a networking structure on top of it. Also; in Apple's defense (or, more directly, in the Open Transport team's defense), I don't believe SOM was available as an option when ASLM was implemented. Both Metrowerks and Symantec stated that it was the vtable dependencies that made them not want to do the work, that they've spent a lot of time optimizing their compilers to generate more efficient vtables, and that they didn't want to spend still more time making them less efficient. All of the issues make sense; but it's inconvenient having to give up Metrowerks because of this (clearly, if Open Transport needs ASLM, I'm not giving up ASLM). mikel +++++++++++++++++++++++++++ >From woody@alumni.caltech.edu (William Edward Woody) Date: 24 May 1994 18:08:55 GMT Organization: California Institute of Technology, Alumni Association Michael W. Wellman wrote: >I'm personally disappointed that both Metrowerks and Symantec seem pretty >dedicated to not supporting Apple's Shared Library Manager since you can't >use Open Transport without such support. Call me stupid (having zero experience with ASLM), but on my E.T.O. #14 disk there's this directory (E.T.O.:Tools - Objects:Apple Shared Libary Manager:ASLM 1.1.GM:ASLM Symantec Support) containing stuff which reportedly allow you to develop and use ASLM with both Symantec C++ for MPW and Symantec C++ for Macintosh v6.0.1. - Bill -- "A secret face--a touch of grace William Edward Woody A man must learn to give a little space woody@alumni.cco.caltech.edu A peaceful state--a submissive trait A man must learn to gently dominate" -- Rush, "Animate" +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Tue, 24 May 1994 21:11:09 GMT Organization: The World Public Access UNIX, Brookline, MA mikel@intercon.com (Michael W. Wellman) writes: >Both Metrowerks and Symantec stated that it was the vtable dependencies that >made them not want to do the work, that they've spent a lot of time >optimizing their compilers to generate more efficient vtables, and that they >didn't want to spend still more time making them less efficient. In order to support ASLM, every aspect of our C++ implementation would need to be identical to MPW cfront (on 68K) and PPCC (on PowerPC). This gives us very little latitude in improving calling conventions, vtables formats, name mangling, etc. all to support an interface which makes up at most 1% of your program. Seems like a heavy price to pay. (Which is not to say our current implementation is more efficient at the moment, but we'd certainly like it to continue optimizing it) Furthermore, we'd need to generate MPW .o files on 68K and XCOFF files on PowerPC so that the ASLM tools could do their pre- and post-processing. This would require again a substantial amount of work which is better spent improving our code generation, implementing templates, etc. SOM solves many of these issues because it reduces the C++ interface to a C interface, and it is much easier to be compatible with that (we already are on PowerPC, will be soon on 68K) >All of the issues make sense; but it's inconvenient having to give up >Metrowerks because of this (clearly, if Open Transport needs ASLM, I'm not >giving up ASLM). Take this up with the Open Transport engineers. It was a shortsighted decision to use a technology supported only by Apple's tools. I can't believe that it was impossible to implement the necessary functionality without component C++ objects in ASLM shared libs. We are working closely with Apple to support SOM and CFM (PowerPC and 68K). -- John McEnerney, Metrowerks PowerPC Product Architect +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 24 May 1994 16:07:01 -0700 Organization: SRI International, Menlo Park, CA In article johnmce@world.std.com (John McEnerney) writes: >Take this up with the Open Transport engineers. It was a shortsighted I did and he wasn't very happy about it. I guess I touched a raw nerve but Garry Honbukle was very defensive about it. Oh well, looks like I won't be doing any opentransport stuff anytime soon. Good thing they are not going to break the old API. >We are working closely with Apple to support SOM and CFM (PowerPC and 68K). I agree with John. It seem like a much better way to go. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Wed, 25 May 1994 01:52:08 GMT Organization: Adobe Systems Incorporated Jon W tte writes > Won't ASLM come on top of the CFM? And both MW and SC will of course > support the CFM. The only thing left is making the name mangling > conform to CFront standards. Does ASLM depend on vtable layout? Perhaps the real answer is to standardize the whole C++ runtime to such a level that objects created by different compilers can be linked together. (What? Don't make you laugh so hard? MY apologies :-)) -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Never let a "final candidate" subscript get above the age of consent. +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Wed, 25 May 1994 07:06:07 GMT Organization: The World Public Access UNIX, Brookline, MA zstern@adobe.com (Zalman Stern) writes: >Does ASLM depend on vtable layout? Perhaps the real answer is to standardize >the whole C++ runtime to such a level that objects created by different >compilers can be linked together. (What? Don't make you laugh so hard? MY >apologies :-)) While at Symantec I spent some time looking into all of the issues involved in supporting ASLM in the THINK compilers. I recall that ASLM exports an OOP interface to the many worthwhile features that it provides. This means that if you need to use any of these features, the code on the client side had better have the same naming conventions, vtable formats, and calling sequences as the code in the ASLM library. There are other problems, such as tools which process the .o files output from the MPW compiler, though these may go away once CFM is universally supported. However, the issue of compatible conventions doesn't go away. If a library exports an OOP interface, via ASLM or CFM, it would require that all compilers use the same conventions. SOM works around this by generating C++ wrappers to a C interface--your source code is in C++, but by the time a vtable is constructed or a virtual function is called, it has been reduced to simple C data structures and calling conventions. I admit to never having looked into the exact requirements of Open Transport. I'll try to do some reading on it to see if a solution specific to Open Transport is possible. -- John McEnerney, Metrowerks PowerPC Product Architect +++++++++++++++++++++++++++ >From lambert_l@measurex.com (Leon Lambert) Date: Wed, 25 May 1994 19:16:13 GMT Organization: measurex I'd like to thank John McEnerney from Metrowerks for taking an interest in this discussion. I haven't noticed Symantec even talking about it. Let's all just get along :) +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 26 May 1994 17:56:45 GMT Organization: The Royal Institute of Technology >> I'm personally disappointed that both Metrowerks and Symantec seem pretty >> dedicated to not supporting Apple's Shared Library Manager... >Can you expand on this? What stands in the way of using Metrowerks to >do ASLM work? (Particular language features?). ASLM relies on CFronts name mangling and vtable formats. Case closed. :-) >meantime I'd like to get some small OpenDoc parts built and the only >compiler I have here is CodeWarrior. (I've also own the current rev of No Can Do unless you a) replace ASLM or b) wait for the CFM/SOM version due Any Year Now. -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- This sig is less than 3 lines: Improve the UseNet S/N ratio! +++++++++++++++++++++++++++ >From peter@ncrpda.curtin.edu.au (Peter N Lewis) Date: 27 May 1994 07:42:43 +0800 Organization: NCRPDA, Curtin University johnmce@world.std.com (John McEnerney) writes: >zstern@adobe.com (Zalman Stern) writes: >I admit to never having looked into the exact requirements of Open >Transport. I'll try to do some reading on it to see if a solution >specific to Open Transport is possible. Garry says that SOM can't be used for Open Transport. I don't know why, but I do know that one of thse has to happen: - Metrowerks supports ASLM in their Pascal compiler (seems quite unlikely). - Symantec supports ASLM in THINK Pascal (fat chance!) - Open Transport moves to SOM (Garry says this is impossible) - Dylan supportsd ASLM and I move to it. Or I could just find a new area on the Mac to work on.... Peter. -- I'm at a conference (WWDC) and on holiday until June 1, so my messages will be short, delayed, imprecise, and less helpful than usual. Sorry! Peter N Lewis Ph: +61 9 368 2055 +++++++++++++++++++++++++++ >From phixus@netcom.com (Chris DeSalvo) Date: Sat, 28 May 1994 06:43:16 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Back the original thread: No, Symantec wasn't booed and hissed that badly. There was a little, but it wasn't TOO much. Yes, their TCL 2.0 Demo (which was very simple) crashed. But so did the first demo of OpenDoc during the opening Keynote address. In Symantec's favor: They threw the most awesome party of the convention! It was at Gordon Biersch, a local bar/brewery. The fresh-brewed beer and the food were all awesome. In regards to ASLM and it's dependency on CFront conventions: I just read today that Apple has made an agreement with Symantec to do a technology trade and get their compiler front-end, abandoning the CFront stuff in the process. Anyone wanna venture a speculation of what this means for future development? Also, I do recal in one of the WWDC sessions Apple saying something to the effect that althrough a lot of the libraries for the new technologies was OO-oriented, you didn't have to use an OOPL to utilize them. Anyone recall this, or was I too hung-over? L8R Chris -- +-----------------------------------------------------------------+ | phixus@netcom.com | Macintosh: Changing the world, | | Chris De Salvo | one person at a time! | | Professional Mac Geek | ----------------------------- | | for MacPlay, Inc. | (I wish they'd hurry up!) | +-----------------------------------------------------------------+ Any opinions expressed, or implied, are my own! They should not be considered representative of the opinions or policies of my employer, MacPlay, a division of Interplay Productions, Inc. +++++++++++++++++++++++++++ >From somogyi@ziff.com (Stephan Somogyi) Date: Mon, 30 May 1994 20:37:18 GMT Organization: Digital Media In article <2s3c5j$a03@ncrpda.curtin.edu.au>, peter@ncrpda.curtin.edu.au (Peter N Lewis) wrote: > Garry says that SOM can't be used for Open Transport. I don't know why, > but I do know that one of thse has to happen: If memory serves, the reasons are that SOM isn't interrupt-safe and the overhead incurred by SOM makes it unsuitable for time-critical code such as a protocol stack. ____________________________________________________________________________ Stephan Somogyi Vorsprung durch Technik Digital Media +++++++++++++++++++++++++++ >From somogyi@ziff.com (Stephan Somogyi) Date: Mon, 30 May 1994 20:45:16 GMT Organization: Digital Media In article <9405240937.AA02456@mikel.intercon.com>, mikel@intercon.com (Michael W. Wellman) wrote: > All of the issues make sense; but it's inconvenient having to give up > Metrowerks because of this (clearly, if Open Transport needs ASLM, I'm > not giving up ASLM). After talking to several people at WWDC about this, I'm not convinced that things are quite this bleak. OpenTransport will have a C-based procedural interface that one could (theoretically -- I haven't looked into this yet myself) write one's own C++ wrappers around. However, I don't know whether there are any penalties for using the C-based interfaces rather than the C++ interfaces. To the best of my knowledge, the issues surrounding support of ASLM (and the resultant requirements for compatible name mangling and vtable formats) are only relevant if one wants to use OpenTransport's C++ interfaces. ____________________________________________________________________________ Stephan Somogyi Vorsprung durch Technik Digital Media +++++++++++++++++++++++++++ >From amanda@intercon.com (Amanda Walker) Date: Thu, 2 Jun 1994 15:48:32 -0500 Organization: InterCon Systems Corporation, Herndon, VA USA somogyi@ziff.com (Stephan Somogyi) writes: > OpenTransport will have a C-based procedural interface that one > could (theoretically -- I haven't looked into this yet myself) write > one's own C++ wrappers around. However, I don't know whether there are > any penalties for using the C-based interfaces rather than the > C++ interfaces. The C++ class is, in fact, simply a wrapper around the C interface, as far as I can tell. > To the best of my knowledge, the issues surrounding support of ASLM > (and the resultant requirements for compatible name mangling and > vtable formats) are only relevant if one wants to use OpenTransport's > C++ interfaces. You still need at least minimal ASLM support in order to use the C API, since it's an ASLM function set, not a statically linked library. Also, the LibraryManager.o library needs to have its vtables set up and constructors called, which necessitates at least a simulacrum of the MPW C++ initialization code. The basic problem is that the ASLM is a hack (albeit a very clever hack). It will thus require a hack to access it from Code Warrior. The only question is how twisted such a hack will turn out to be. Also note that this is only a big problem on the 68K side. The PPC ASLM is built on top of CFM, which should help a lot. Unfortunately, Open Transport seeds have been 68K-only builds so far. None of this is intractable by any means. It's just annoying :). Amanda Walker InterCon Systems Corporation +++++++++++++++++++++++++++ >From seaquest@netcom.com (Pete Mackie) Date: Sat, 4 Jun 1994 15:52:56 GMT Organization: Seaquest Software In Article , somogyi@ziff.com (Stephan Somogyi) wrote: >In article <2s3c5j$a03@ncrpda.curtin.edu.au>, peter@ncrpda.curtin.edu.au >(Peter N Lewis) wrote: > >> Garry says that SOM can't be used for Open Transport. I don't know why, >> but I do know that one of thse has to happen: > >If memory serves, the reasons are that SOM isn't interrupt-safe and the >overhead incurred by SOM makes it unsuitable for time-critical code such >as a protocol stack. > I also heard that SOM isn't interrupt-safe at WWDC therefore cannot be used for Open Transport. However, Apple states that my not always be true. See Apple's DDL Statement of Direction following. This may help you, or confuse you even more. ;-) ========================================== Macintosh Dynamic Linked Libraries (DLLs) ========================================== ETO #14 (March '1994) Update Apple has developed a complete technology solution for shared code, shared objects, and dynamic linked libraries (DLLs) on the Macintosh. Parts of this solution are available today, with additional parts becoming available in the coming months. There are three key components to Macintosh DLL strategy: o Apple's Shared Library Manager (ASLM), o Apple's Code Fragment Manager (CFM), and o IBM's System Object Model (SOM). Here is a brief summary of ASLM, CFM, and SOM ... ASLM - ---------- Apple Shared Library Manager is the first component of Apple's DLL solution to be available, and is an integral part of our overall DLL offering. ASLM supports shared code libraries for both procedural and object oriented development efforts. A number of Apple products have already been based on ASLM, including MacSNMP and the GeoPort communications pod technology. Third parties such as Microsoft (OLE for Macintosh), Novell (AppWare), and Aldus have also adopted ASLM to support their DLL needs. In the future, additonal functionality will be added to the Macintosh operating system as ASLM libraries, including our next generation networking, the Open Transport Communications Architecture. ASLM v1.1.1 is the currently shipping release. ASLM v2.0 is under development, to provide support for native code shared libraries on Power Macintosh (An alpha release is available on this ETO). ASLM 2.x sits on top of (is based on) the Code Fragment Manager. This work is expected to produce final product in 2Q CY94. As CFM becomes available on 68K Macintosh (see below), ASLM version 2.1 will support CFM on 68K as well, while continuing to support current 68K-style shared libraries. Thus, ASLM v2.x will provide compatibility for ASLM v1.1 and v1.1.1 applications. ASLM adds higher-level object-oriented capabilities to the environment that are not a part of the Code Fragment Manager itself. ASLM is the technology of choice when you: o need DLLs on 68K today ... ASLM is shipping o want simplicity and elegance with C++ o want a simple but powerful extension mechanism using C, Pascal, or ASM o have performance sensitive (i.e., interrupt time) needs like networking o want run-time transparent dynamic loading and unloading of code o DON'T need transparent access to per-context global data o DON'T need to solve the "fragile base class" problem for C++ CFM - ---------- As a second key step in our DLL strategy, Apple has developed a new foundation layer for dynamic linking on the Macintosh known as the Code Fragment Manager (CFM). CFM will be a core part of System Software on the PowerPC Macintosh. CFM is also being developed for the Macintosh on 68K. This work is expected to produce final product in 3Q CY94. The Code Fragment Manager provides code sharing and dynamic linking, with features supporting per-context globals. CFM will be fully supported by development tools on Macintosh. CFM is the best bet when your application: o runs on PowerPC Macintosh first, and 68K Macintosh later o needs only basic dynamic loading and unloading of shared code o needs to reduce system overhead to the minimum amount o needs transparent access to per-context global data o DOES NOT need system-level OOP support SOM - ---------- Apple is in the process of licensing and porting IBM's System's Object Model (SOM) technology to Macintosh. SOM is a multi-platform standard providing for system-level sharable objects in a language-neutral way. SOM also solves the "fragile base class" problem, avoiding the need for client libraries to be recompiled when the base class they inherit from is in a different library and is changed. To offer these benefits (multi-platform support and fragile base-class resolution) SOM requires the use of an IDL as a first step in the development process. SOM runs on top of CFM, and thus will become available on both 68K and PowerPC Macintosh. SOM is a foundation technology for OpenDoc. Integration - ---------- SOM and ASLM will both live in a CFM run-time environment, and will both be available on both 68K and PowerPC Macintosh. Thus there will be no impediment to co-existence of ASLM and SOM, or to applications that use both ASLM and SOM. In fact, a SOM class could easily call an ASLM class or vice-versa. Over time, some of the functionality provided by ASLM may be supplanted by SOM. However, ASLM APIs will be preserved. As a result, applications written to the ASLM API may have some functionality transparently migrated to SOM in the future. ___________________________________________________________________ Pete Mackie | Internet: seaquest@netcom.com Seaquest Software | AppleLink: D0937 Portland, Oregon USA | America Online: Seaquest1 Voice: (503) 531-0252 | eWorld: Seaquest Fax: (503) 629-8442 | _____________________________|_____________________________________ --------------------------- >From rkwee@ee.pdx.edu (Roland Kwee) Subject: [Q] Finding out if volume is locked Date: 2 Jun 1994 19:13:15 -0700 Organization: (none) How do I quickly check if the volume is locked? New Inside Mac, Files, p2-8 says I should check that before opening a file for write access, because the file open call would return OK even on locked volumes. They recommend calling PBHGetVInvo() (what a user-friendly system...) which is described on p. 2-144, but I can't find the description of the volume attributes ioVAtrb. Does anybody know? Thanks, Roland Kwee (please send email directly to: RolandKwee@ACM.org) +++++++++++++++++++++++++++ >From mclow@coyote.csusm.edu (Marshall Clow) Date: 2 Jun 1994 19:26:29 -0700 Organization: California State University San Marcos Roland Kwee (rkwee@ee.pdx.edu) wrote: >How do I quickly check if the volume is locked? New Inside Mac, Files, >p2-8 says I should check that before opening a file for write access, >because the file open call would return OK even on locked volumes. >They recommend calling PBHGetVInvo() (what a user-friendly system...) >which is described on p. 2-144, but I can't find the description >of the volume attributes ioVAtrb. >Does anybody know? Here's my routine: Boolean VIsLocked ( short vRefNum ) { #define softLockBit 0x8000 #define hardLockBit 0x0080 OSErr err = noErr; HParamBlockRec pb; Str255 vName; if ( vRefNum == kOnSystemDisk ) vRefNum = FindSystemVolume (); vName [ 0 ] = '\0'; pb.volumeParam.ioCompletion = nil; pb.volumeParam.ioNamePtr = vName; pb.volumeParam.ioVRefNum = vRefNum; pb.volumeParam.ioVolIndex = 0; err = PBHGetVInfoSync ( &pb ); AssertStr ( err == noErr, "\pPBHGetVInfoSync in VIsLocked" ); return ( pb.volumeParam.ioVAtrb & ( softLockBit | hardLockBit )) != 0; } Marshall Clow Aladdin Systems mclow@san_marcos.csusm.edu +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 4 Jun 1994 23:28:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <2sm3jr$cjn@cruella.ee.pdx.edu>, rkwee@ee.pdx.edu (Roland Kwee) writes: >How do I quickly check if the volume is locked? New Inside Mac, Files, >p2-8 says I should check that before opening a file for write access, >because the file open call would return OK even on locked volumes. >They recommend calling PBHGetVInvo() (what a user-friendly system...) >which is described on p. 2-144, but I can't find the description >of the volume attributes ioVAtrb. >Does anybody know? Funny you should ask. I added CheckVolLock to MoreFiles (the DTS File Manager sample) this afternoon. Here's the prototype, documentation, and function. The only code not included here is the pcpy function which I'm sure you can come up with (or grab it from MoreFiles). /******************************************************************** *********/ pascal OSErr CheckVolLock(StringPtr pathname, short vRefNum); /* Use CheckVolLock to determine if a volume is locked - either by hardware or by software. If CheckVolLock returns noErr, then the volume is not locked. pathName input: Pointer to a full pathname or nil. If you pass in a partial pathname, it is ignored. A full pathname to a volume must end with a colon character (:). vRefNum input: Volume specification (volume reference number, working directory number, drive number, or 0). */ /******************************************************************** *********/ pascal OSErr CheckVolLock(StringPtr pathname, short vRefNum) { HParamBlockRec pb; Str255 tempPathname; OSErr error; pb.volumeParam.ioVRefNum = vRefNum; if (pathname == nil) { pb.volumeParam.ioNamePtr = nil; pb.volumeParam.ioVolIndex = 0; /* use ioVRefNum only */ } else { pcpy((StringPtr)tempPathname, pathname); /* make a copy of the string and */ pb.volumeParam.ioNamePtr = (StringPtr)tempPathname; /* use the copy so original isn't trashed */ pb.volumeParam.ioVolIndex = -1; /* use ioNamePtr/ioVRefNum combination */ } error = PBHGetVInfoSync(&pb); if ( error == noErr ) { if ( (pb.volumeParam.ioVAtrb & 0x0080) != 0 ) error = wPrErr; /* volume locked by hardware */ else if ( (pb.volumeParam.ioVAtrb & 0x8000) != 0 ) error = vLckdErr; /* volume locked by software */ } return (error); } /******************************************************************** *********/ - Jim Luther --------------------------- End of C.S.M.P. Digest **********************