From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-053 Date: Mon, 5 Sep 1994 15:28:25 +0200 (MET DST) C.S.M.P. Digest Mon, 05 Sep 94 Volume 3 : Issue 53 Today's Topics: A real funny story AppleScript: event times out C++ Virtual Destructor Q Enum size -- what's the LCD? Followup on 'Safe Save' problem - still ticking! MW DebugNew Tip Scrollbars in Dialogs? Should new programs still be System 6 compatible? The System 7.5 Think Debugger Bug - and fix! Think Debugger & INIT source code [Q] How to do non-bypassable INIT? malloc problem in CW-4 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 nick+@pitt.edu ( nick.c ) Subject: A real funny story Date: Fri, 19 Aug 94 21:40:04 GMT Organization: The Pitt, Chemistry Folks: A friend of mine just sent me this, personally I think it's hilarious (so long as you don't work for MS :-). Enjoy, - -- "Star Trek Lost Episodes" transcript. "Mr. LaForge, have you had any success with your attempts at finding a weakness with the Borg? And Mr. Data, have you been able to access their command pathways?" "Yes, Captain. In fact, we found the answer by searching through our archives on late twentieth-century computing technology." "What the hell is 'Microsoft'?" "Allow me to explain. We will send this program, for some reason called 'Windows,' through the Borg command pathways. Once inside their root com- mand unit, it will begin consuming system resources at an unstoppable rate." "But the Borg have the ability to adapt. Won't they alter their processing systems to increase their storage capacity?" "Yes, Captain. But when 'Windows' detects this, it will create a new version of itself called an 'upgrade.' The use of resources increases exponentially with each iteration. The Borg will not be able to adapt quickly enough. Eventually all of their processing ability will be taken over and none will be available for their normal operational functions." "Excellent work. This is even better than that 'unsolvable geometric shape' idea." <. . . 15 minutes later . . .> "Captain, we have successfully installed the 'Windows' in the command unit and, as expected, it immediately consumed 85% of all resources. We, however, have not received any confirmation of the expected 'upgrade.'" "Our scanners have picked up an increase in Borg storage and CPU capacity to compensate, but we still have no indication of an 'upgrade' to compensate for their increase." "Data, scan the history books again and determine if there is something we have missed." "Sir, I believe there is a reason for the failure in the 'upgrade.' Apparently the Borg have circumvented that part of the plan by not sending in their 'registration cards.'" "Captain, we have no choice. Requesting permission to begin emergency escape sequence 3F . . ." "Wait, Captain, I just detected that their CPU capacity has suddenly dropped to 0%!" "Data, what do your scanners show?" "Apparently the Borg have found the internal 'Windows' module named 'solitaire' and it has used up all the CPU capacity." "Let's wait and see how long this 'solitaire' can reduce their functionality." <. . . Two hours pass . . .> "Geordi, what's the status of the Borg?" "As expected the Borg are attempting to re- engineer to compensate for increased CPU and storage demands, but each time they successfully increase resources I have set up our closest deep space monitor beacon to transmit more 'Windows' modules from something called the 'Microsoft fun-pack.'" "How much time will that buy us?" "Current Borg solution rates allow me to predict an interest time span of 6 more hours." "Captain, another vessel has entered our sector." "Identify." "It appears to have markings similar to the 'Microsoft' logo." "THIS IS ADMIRAL BILL GATES OF THE MICROSOFT FLAGSHIP MONOPOLY. WE HAVE POSITIVE CONFIRMATION OF UN- REGISTERED SOFTWARE IN THIS SECTOR. SURRENDER ALL ASSETS AND WE CAN AVOID ANY TROUBLE. YOU HAVE TEN SECONDS." "The alien ship has just opened its forward hatches and released thousands of humanoid shaped objects." "Magnify forward viewer on the alien craft." "Good God Captain! Those are humans floating straight toward the Borg ship with no life support suits! How can they survive the tortures of deep space?!" "I do not believe that those are humans sir; if you will look closer, I believe you will see that they are carrying something recognized in the twenty-first century as doe-skin leather briefcases, and wearing Armani suits." "Lawyers!!" "It can't be. All the lawyers were rounded up and sent hurtling into the sun in 2017 during the great awaken- ing." "True, but apparently some must have survived." "They have surrounded the Borg ship and are covering it with all types of papers." "I believe that is known in ancient vernacular as 'red tape.' It often proves fatal. "They're tearing the Borg to pieces!" "Turn off the monitors. I can't stand to watch. Not even the Borg deserve that." Disclaimer: Just my opinion. _/ _/ _/ _/_/_/ _/ _/ Interet: nick@pitt.edu _/_/ _/ _/ _/ _/ _/_/_/ eWorld: nick _/ _/_/ _/ _/ _/ _/ CIS: 71232,766 _/ _/ _/ _/_/_/ _/ _/ "Science is nothing but perception" - Plato --------------------------- >From kocher@lts.sel.alcatel.de (Hartmut Kocher US/ESA 60/1L/2? #5629) Subject: AppleScript: event times out Date: Mon, 22 Aug 94 08:33:35 GMT Organization: SEL-Alcatel LTS Dept. US/ES I've written a small AppleScript, that copies a few folders around using the scriptable Finder. My problem is that if one of these folders holds many files, the reply from the Finder takes too long and the reply times out (aborting the script :-( ). How can I set the timeout value, so my script is willing to wait longer fro a reply? Thanks for your suggestions. -- +==============================|==============================+ | Hartmut Kocher | | | Technical Consultant | All opinions expressed here | | Rational GmbH | are my own. | | Rosenstrasse 7 | | | 82049 Pullach im Isartal | I know you guessed it, | | Germany | but it keeps my lawyer happy.| | Email: hwk@rational.com | | +==============================|==============================+ +++++++++++++++++++++++++++ >From dmcleod@hpb.hwc.ca (D.A. McLeod) Date: 22 Aug 1994 13:32:42 GMT Organization: Health Canada Hartmut Kocher US/ESA 60/1L/2? #5629 (kocher@lts.sel.alcatel.de) wrote: : How can I set the timeout value, so my script is willing to wait : longer fro a reply? with timeout of #### seconds . . . end timeout +++++++++++++++++++++++++++ >From engelhar@bga.com (Michael Engelhart) Date: 22 Aug 1994 15:38:09 GMT Organization: Apple Travel In article <1994Aug22.083335.25853@lts.sel.alcatel.de>, kocher@lts.sel.alcatel.de (Hartmut Kocher US/ESA 60/1L/2? #5629) wrote: > I've written a small AppleScript, that copies a few folders around > using the scriptable Finder. My problem is that if one of these folders > holds many files, the reply from the Finder takes too long and the > reply times out (aborting the script :-( ). > > How can I set the timeout value, so my script is willing to wait > longer fro a reply? > > Thanks for your suggestions. > > -- > +==============================|==============================+ > | Hartmut Kocher | | > | Technical Consultant | All opinions expressed here | > | Rational GmbH | are my own. | > | Rosenstrasse 7 | | > | 82049 Pullach im Isartal | I know you guessed it, | > | Germany | but it keeps my lawyer happy.| > | Email: hwk@rational.com | | > +==============================|==============================+ Hartmut, simply enclose your routine with the following: with timeout of 400 seconds --use any value you want, the default is 120 seconds your routine end timeout Mike --------------------------- >From jpek@umich.edu (Jeff Pek) Subject: C++ Virtual Destructor Q Date: 19 Aug 1994 22:05:08 GMT Organization: U of Mich (MBA) I wonder if someone could clear the air around our office about why virtual destructors should or should not be used. Specifically, I'm interested in Metrowerks' compiler's implementation. 1) Why would I want to/need to declare a destructor virtual? 2) What happens if I don't? Thanks very much! Jeff - ------------------------------------------- Jeff Pek jpek@umich.edu Emerald Intelligence / University of Michigan +++++++++++++++++++++++++++ >From mwron@aol.com (MW Ron) Date: 19 Aug 1994 19:44:06 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <333aak$fj8@lastactionhero.rs.itd.umich.edu>, jpek@umich.edu (Jeff Pek) writes: >>1) Why would I want to/need to declare a destructor virtual? >>2) What happens if I don't? 1) You need to declare a virtual destructor when you have a base class, its destructor is different than the derived classes destructor, and objects are deleted via pointer or refernce to base class. ( a good habit, declare it for all base classes ) 2) if you don't, you will not guarantee all objects will be deleted when an object is deleted, if it is accessed as a base class poiter. Scott Meyers in Effective C++ explains this quite well. Ron Liechty RonL@metrowerks.com Metrowerks Inc. +++++++++++++++++++++++++++ >From neeri@iis.ee.ethz.ch (Matthias Neeracher) Date: 19 Aug 1994 23:19:32 GMT Organization: Swiss Federal Institute of Technology (ETHZ) jpek@umich.edu (Jeff Pek) writes: >I wonder if someone could clear the air around our office about why >virtual destructors should or should not be used. Specifically, I'm >interested in Metrowerks' compiler's implementation. >1) Why would I want to/need to declare a destructor virtual? As a rule of thumb, as soon as you have a virtual function for a class, you should also have a virtual destruction. >2) What happens if I don't? As an example, take: class A ... class B : public A ... A * pa = new B; delete pa; Unless A has a virtual destructor, no destructor for B will be executed on the object pointed to by pa, which is would often be desirable. Matthias - --- Matthias Neeracher http://err.ethz.ch/members/neeri.html "There once was an Age of Reason, but we've progressed beyond it." -- Ayn Rand, _Atlas Shrugged_ +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Fri, 19 Aug 1994 20:17:34 -0800 Organization: Integer Poet Software In article <333aak$fj8@lastactionhero.rs.itd.umich.edu>, jpek@umich.edu (Jeff Pek) wrote: > 1) Why would I want to/need to declare a (C++) destructor virtual? > 2) What happens if I don't? The Annotated C++ Reference Manual (commonly known as "the ARM"), Ellis and Stroustup, ISBN, 0-201-51459-1, chapter 12.4 (page 276 in my printing). And a note to aid in your reading: non-virtual destructors are the exception (no pun intended), not the rule. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Even during a particularly harsh (Colorado) winter... many of the 300 families in the VCTV (movies-on-demand) trial continued to go to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62 +++++++++++++++++++++++++++ >From mwron@aol.com (MW Ron) Date: 20 Aug 1994 12:20:01 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , gurgle@dnai.com (Pete Gontier) writes: Here is a short example of a virtual destructor in use. remove the virtual keyword and you will see that only the base class's destructor is called. Ron Liechty RonL@metrowerks.com Metrowerks Inc. #include class base { public: int *a; protected: base() { a = new int(1);} public: virtual ~base() { cout << "deleteting base "; delete a;}; }; class base2 : public base { public: int *b; protected: base2() { b = new int(1);} public: virtual ~base2() { cout << "deleteting base2 "; delete b;}; }; class d : public base2 { public : int *c; public: d() { c = new int(3);} ~d() { cout << "deleteting d "; delete c;}; }; main() { base *bPtr = new d; delete bPtr; cout << "enter a char " ; cin.get(); return 0; } +++++++++++++++++++++++++++ >From ekstrom@aggroup.com (Harold Ekstrom) Date: Sat, 20 Aug 1994 20:45:15 -0800 Organization: Ag Group In article <333g46$hu5@search01.news.aol.com>, mwron@aol.com (MW Ron) wrote: > In article <333aak$fj8@lastactionhero.rs.itd.umich.edu>, jpek@umich.edu > (Jeff Pek) writes: > > >>1) Why would I want to/need to declare a destructor virtual? > >>2) What happens if I don't? > > 1) You need to declare a virtual destructor when you have a base class, > its destructor is different than the derived classes destructor, and > objects are deleted via pointer or refernce to base class. ( a good habit, > declare it for all base classes ) > > 2) if you don't, you will not guarantee all objects will be deleted when > an object is deleted, if it is accessed as a base class poiter. > > Scott Meyers in Effective C++ explains this quite well. > > Ron Liechty > RonL@metrowerks.com > Metrowerks Inc. Another good source of answers for this and other common C++ questions is the C++FAQ (rtfm.mit.edu). It was one of the first things I read when learning C++. harold - ------------------------------------------------------------ Harold Ekstrom ekstrom@aggroup.com ag group, inc. 2540 camino diablo, suite 200 walnut creek, ca 94596 510-937-7900 voice 510-937-2479 fax 510-937-6704 ara ftp.aggroup.com anonymous ftp --------------------------- >From afrancke@netcom.com (Andrew Francke) Subject: Enum size -- what's the LCD? Date: Wed, 17 Aug 1994 02:54:56 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) If I'm not mistaken, the lowest common denominator for enum size is that presented by MPW 68k C -- variable 1, 2, or 4 bytes. Other Mac C and C++ compilers support the ANSI definition, sizeof(enum) == sizeof(int), but not MPW C. All Mac compilers support variable enum size just like MPW C. Is this strictly correct? Now, examine the following code: typedef enum { a=255 } one_byte_enum_t; typedef enum { b=65000 } two_byte_enum_t; typedef enum { c=1000000 } three_byte_enum_t; #if defined (powerc) || defined (__power) #pragma align=mac68k #endif struct test1 { one_byte_enum_t mem1; two_byte_enum_t mem2; three_byte_enum_t mem3; }; #if defined (powerc) || defined (__powerc) #pragma align reset // or whatever it is #endif The $10,000,000 question -- do these structures lay out on every Mac C compiler in this way: Offset Byte from Contents &test 1: - --------- -------- 0x00000000: mem1 0x00000001: 0x00000002: mem2 0x00000003: mem2 0x00000004: mem3 0x00000005: mem3 0x00000006: mem3 0x00000007: mem3 How about stack alignment? If I declare a function: void foo ( one_byte_enum a, two_byte_enum b, three_byte_enum c ); ...what will the stack look like? Will it be the same for all Mac C/C++ compilers? Example stack: 1 2 3 4 5 6 7 8 SP-0x8: c c c c b b a SP: (Sorry if this last example isn't that clear -- the stack is being displayed in hi-lo, left to right order, assuming that all parameters have been pushed and we're about to JSR to foo) Thanks in advance for your insight. Andy Francke +++++++++++++++++++++++++++ >From mclow@san_marcos.csusm.edu (Marshall Clow) Date: Wed, 17 Aug 1994 00:53:32 -0800 Organization: Aladdin Systems In article , afrancke@netcom.com (Andrew Francke) wrote: > If I'm not mistaken, the lowest common denominator for enum size is > that presented by MPW 68k C -- variable 1, 2, or 4 bytes. Other Mac C > and C++ compilers support the ANSI definition, sizeof(enum) == > sizeof(int), but not MPW C. All Mac compilers support variable enum > size just like MPW C. > > Is this strictly correct? > No. It's wrong in several areas. > [ code deleted ] > > The $10,000,000 question -- do these structures lay out on every Mac > C compiler in this way: > [ more code deleted ] No. Different compilers allocated sizes for enums differently. I believe that the following is true: 1) MPW C (68K) -- enums are 4 bytes 2) Think C (68K) -- enums are 1, 2, or 4 bytes (based on values) except if the "Enums are always ints" preference is checked, in which case they are 2 or 4 bytes depending on how big your ints are. 3) Metrowerks C (68K) -- same as Think C (68K). 4) Metrowerks C (PPC) -- enums are 1, 2, or 4 bytes (based on values) except if the "Enums are always ints" preference is checked, in which case they are 4 bytes. 5) PPCC (Apple's MPW based PPC compiler) -- I don't know. 6) Apple's new PPC C compiler (Beta on ETO #15) -- I don't know 7) Motorola C (PPC) -- I don't know 8) Absoft C (PPC) -- I don't know [ I'm sure I forgot someone. ] The ANSI spec (from memory, so don't flame me for wordage) says that enums must be "compatible with integer type". The rest is up to the compiler writer. This is one of the non-portable aspects of C. -- Marshall -- Marshall Clow Aladdin Systems mclow@san_marcos.csusm.edu +++++++++++++++++++++++++++ >From becker@Xenon.Stanford.EDU (Denizen of the Deep) Date: 17 Aug 1994 16:22:16 GMT Organization: Computer Science Department, Stanford University. In article , Marshall Clow wrote: > >The ANSI spec (from memory, so don't flame me for wordage) says that enums >must be "compatible with integer type". The rest is up to the compiler >writer. > >This is one of the non-portable aspects of C. > >-- Marshall > >From K&R II, A8.4: The identifiers in an enumerator list are declared as constants of type int... So there you have it. In strict ANSI C, enums should take up the same space as an int on the machine (i.e. 2 or 4 bytes, depending on your settings and/or compiler). It's only non-portable in the sense that different compilers may have different sizes for int; however once the choice of int size is made, there is no latitude for choosing how to deal with enums. -Jon +++++++++++++++++++++++++++ >From Lars.Farm@nts.mh.se (Lars Farm) Date: Fri, 19 Aug 1994 10:08:12 +0100 Organization: Mid Sweden University In article <32tdfo$gn2@Times.Stanford.EDU>, becker@Xenon.Stanford.EDU (Denizen of the Deep) wrote: > From K&R II, A8.4: > The identifiers in an enumerator list are declared as constants > of type int... > > So there you have it. In strict ANSI C, enums should take up the same > space as an int on the machine (i.e. 2 or 4 bytes, depending on your In C perhaps, but not so in C++. enum is not int. An enum can be initialized by a constant expression of integral type. An enum will silently be converted to an int where an int is expected (|, &, + ...) but an int will not silently be converted to an enum, because nothing says it will fit in the space allocated for the enum. Cast needed. An enum is required to have room for "...the nearest larger binary power minus 1 and down to 0...". So enum { false,true } is only required to allocate one bit for the value. [ARM - ANSI/ISO resolutions r.7.2]. Realistically this means that an enum will be allocated 1, 2 or 4 bytes depending on enumerated constants and whatever the compilers author sees reasonable. In any event the space allocated to an enum may be smaller than what is needed for an int provided it has room for any of the enum constants. Lars -- Lars.Farm@nts.mh.se +++++++++++++++++++++++++++ >From phils@bedford.symantec.com (Phil Shapiro) Date: Fri, 19 Aug 1994 12:36:51 -0400 Organization: Symantec Corp. | No. Different compilers allocated sizes for enums differently. I believe | that the following is true: Only slightly off, with respect to "enums are always ints", see below*. | 1) MPW C (68K) -- enums are 4 bytes | | 2) Think C (68K) -- enums are 1, 2, or 4 bytes (based on values) except if | the "Enums are always ints" preference is checked, in which case they are | 2 or 4 bytes depending on how big your ints are. | | 3) Metrowerks C (68K) -- same as Think C (68K). | | 4) Metrowerks C (PPC) -- enums are 1, 2, or 4 bytes (based on values) | except if the "Enums are always ints" preference is checked, in which case | they are 4 bytes. | | 5) PPCC (Apple's MPW based PPC compiler) -- I don't know. | 6) Apple's new PPC C compiler (Beta on ETO #15) -- I don't know | 7) Motorola C (PPC) -- I don't know | 8) Absoft C (PPC) -- I don't know 9) Symantec C/C++ -- enums are 1, 2, or 4 bytes based on values. If enums are always ints is checked, then they are 4 bytes. The rules are the same for both the 68k and PowerPC compilers. Apple's new PPC C++ compiler (aka MrC) should be the same as Symantec C++, since they share compiler front ends. (*) In ANSI C, enums are the same size as int, provided that the value that they contain can be represented in an int. So when you use the "enums are always ints" option, you're really saying that they're at least as big as an int. They can be bigger, or unsigned (or both), depending on the value that they contain. The main thing is that you shouldn't depend on the size of an enum. If you plan to do I/O with an enum, cast it to a known (portable) type first. -phil +++++++++++++++++++++++++++ >From afrancke@netcom.com (Andrew Francke) Date: Fri, 19 Aug 1994 21:16:29 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) > The main thing is that you shouldn't depend on the size of an enum. If > you plan to do I/O with an enum, cast it to a known (portable) type first. > -phil I'm afraid this is a moot point in my case. I've already got a sizable amount of ASN.1-compiler-generated C source with enums a'plenty in struture declarations. I'll state my question again: GIVEN THE RIGHT SET OF COMPILER OPTIONS, is not the LCD of enum sizes the 1-2-4 packing scheme? I yet labor under the impression that MPW C doesn't even support "enums are ints" as an option. --------------------------- >From redial Subject: Followup on 'Safe Save' problem - still ticking! Date: Sat, 20 Aug 1994 21:46:44 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Netters - Thanks to all who attempted to help with my 'Safe save' problem. It did indeed look as tho closing the temporary file after the FSpExchangeFiles swap would solve the problem of the 'File Busy' error message when I attempted to delete the temporary file. Unfortunately :-( it didn't. Here's a summary of my Safe Save procedure, which follows the example in Think C Reference 2.0. I call StandardPutFile to get the user's input re the new file. If the reply is good and we're not replacing an existing file, I call FSpCreate. (According to IM:Files this creates a file with both forks, only they're both empty.) I then call FSpCreateResFile to open the resource fork, and proceed to copy a string resource for the 'Application missing' error message ('STR ' ID -16396) from my application's resources into the new file. I then close the resouce fork with an FSClose. Next, I open the data fork using FSpOpenDF. If no errors occur, I proceed to create a temporary file, open its data fork, write the data into it, close it, exchange its data with the real file, and then delete the temporary file. It's at this point I get my first sign of trouble: OSErr -47, aka 'File busy.' My snooping has revealed the following points of information. 1) When I attempt to open the newly created document file with ResEdit, I'm told it doesn't have a resource fork. 2) It does contain the appropriate data in its data fork. And 3) if I reboot the computer, the temporary file shows up in the trashcan in a folder labled 'Rescued items.' >From this, is it obvious to anyone as to what I'm doing wrong? Any suggestions on what debugging steps I should take would be greatly appreciated. TIA. Ron Goebel | Internet: redial@netcom.com +++++++++++++++++++++++++++ >From tgaul@halcyon.com (Troy Gaul) Date: Sat, 20 Aug 1994 23:05:30 -0700 Organization: Infinity Systems In article , redial wrote: > Here's a summary of my Safe Save procedure, which follows the example in > Think C Reference 2.0. I call StandardPutFile to get the user's input re > the new file. If the reply is good and we're not replacing an existing > file, I call FSpCreate. (According to IM:Files this creates a file with > both forks, only they're both empty.) I then call FSpCreateResFile to > open > the resource fork, and proceed to copy a string resource for the > 'Application missing' error message ('STR ' ID -16396) from my > application's resources into the new file. I then close the resouce fork > with an FSClose. Next, I open the data fork using FSpOpenDF. If no > errors > occur, I proceed to create a temporary file, open its data fork, write the > data into it, close it, exchange its data with the real file, and then > delete the temporary file. It's at this point I get my first sign of > trouble: OSErr -47, aka 'File busy.' First, it sounds like you're putting the resources into the 'real' file, and then putting the data into the 'temp' file's data fork, and then doing a swap on them. This isn't what you want to do. The call FSpExchangeFiles doesn't swap the data fork from one file to another, it swaps the directory information for the two files. This means that both the data and resource forks are swapped. Note, though, that this call does not swap the Finder information (like Modification Dates) for the files (or the locations in the file system, i.e. the file named 'Temp File' is still in the Temporary Items Folder). Next, once you have exchanged the files, I _think_ that the refnums you have for the files are also considered 'swapped' (it's been a while since I've done this, and I don't have the source code I produced anymore, but a quick glance into the Think Reference seemed to indicate that). This means if you have the variables 'realFileRefnum' and 'tempFileRefnum', which point where their names imply before the swap, after the swap, they point to the opposite files in the files system. So, by closing tempFileRefnum, you're really closing the 'real' file, and when you try to delete the file with tempFileFSSpec, the 'temp' file hasn't been closed, and you'd get that error. (Note that although the refnums are backward, the FSSpecs still point to the files that their names would imply, because these files are still in the same locations in the file system, just their contents have been swapped.) > My snooping has revealed the following points of information. > 1) When I > attempt to open the newly created document file with ResEdit, I'm told it > doesn't have a resource fork. That's because you never added a resource fork to the temp file (where you should have), you added it to the intended destination file (where it was then swapped into the temp file, the one you find in the Rescued Items folder). > 2) It does contain the appropriate data in > its data fork. And That's because the swap did in fact occur. > 3) if I reboot the computer, the temporary file shows > up in the trashcan in a folder labled 'Rescued items.' Anything in the temporary folder upon restart will be put into a folder by that name in the Trash automatically. This is indicative of the fact that the temp file was never deleted (as your error message indicated). Hope this helps. _troy //////// //////___Troy Gaul____________________tgaul@halcyon.com___// // // Infinity Systems // // // // Redmond, Washington // // //////____________________________________________________// +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Sun, 21 Aug 1994 13:28:06 +0200 Organization: Royal Institute of Something or other In article , redial wrote: >Thanks to all who attempted to help with my 'Safe save' problem. It did >indeed look as tho closing the temporary file after the FSpExchangeFiles >swap would solve the problem of the 'File Busy' error message when I >attempted to delete the temporary file. Unfortunately :-( it didn't. That's because when you call FSpExchangeFiles, the open file reference still points into the data you're writing; i e the fRefNum now points into the "real" file and not the "temp" file which now contains the old data. You have to close the _old_ file! /* * Add error checking to taste * This assumes you're passing the address of your currently- * open file's fRefNum, and the FSSpec for it, and that there * is indeed a currently-open file. */ void SafeSave ( short * oldRefNum , const FSSpec * fileLocation ) { FSSpec tempSpec ; short tempRef = 0 ; FInfo fi ; FSpGetFInfo ( fileLocation , & fi ) ; MakeTempSpec ( & tempSpec ) ; FSpCreate ( & tempSpec , 'trsh' , 'trsh' , smSystemScript ) ; FSpOpenDF ( & tempSpec , fsRdWrPerm , & tempRef ) ; WriteDataToFile ( tempRef ) ; FSpExchangeFiles ( fileLocation , & tempSpec ) ; FSpSetFInfo ( fileLocation , & fi ) ; FSClose ( * oldRefNum ) ; * oldRefNum = tempRef ; FSpDelete ( & tempSpec ) ; } -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Not speaking for IBM. --------------------------- >From Felix Ungman Subject: MW DebugNew Tip Date: 22 Aug 94 14:06:13 +0000 Organization: (none) I want to thank MW for the DebugNew module! Even though my code was pretty well tested, I tracked down 5 memory leaks after only 15 minutes of testing! The only unneccecary flaw is that it violates the first rule of tools: Never, ever, increase the work of the user. Instead of making your code look like a mess of NEW macros (NEW is defined as "#define NEW new(__FILE__, __LINE__)") you can simply overide operator new with "#define new new(__FILE__, __LIN= E__)" Or if you don't want to edit the DebugNew.h file: #include #define new NEW Works great in most cases. +++++++++++++++++++++++++++ >From dpodwall@world.std.com (Dan Podwall) Date: Mon, 22 Aug 1994 15:26:57 GMT Organization: Metrowerks, Inc. Felix Ungman (felix@hu.se) wrote: : Instead of making your code look like a mess of NEW macros : (NEW is defined as "#define NEW new(__FILE__, __LINE__)") : you can simply overide operator new with "#define new new(__FILE__, __LIN= : E__)" There reason it isn't done that way is because it would break the array form of operator new, e.g. char* p = new char[10]; You can't currently override the array operator new. I agree that if you don't need the array version then your modification is handy. Dan Podwall Metrowerks, Inc. --------------------------- >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Subject: Scrollbars in Dialogs? Date: Sun, 21 Aug 1994 18:51:33 +0800 Organization: NCRPDA, Curtin University Hi All, Simple question, how do you do scroll bars as dialog items? I can set up the CNTL resource and then make a control item in the dialog, and the scontrol appears, and the dialog manager does all the tracking for it (tracks the clicks on the arrows and highlights them, and drags the thumb around). But the clicks on the arrows don't seem to change the value of the control. Do I have to install some sort of proc to track them? It can't be that hard, but I checked another program and it used a user item and created it's own control, so maybe it is? Peter. -- Peter N Lewis - Macintosh TCP fingerpainter +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Sun, 21 Aug 1994 15:00:50 -0500 Organization: One Step Beyond peter.lewis@info.curtin.edu.au (Peter N Lewis) wrote: ) Simple question, how do you do scroll bars as dialog items? I can set up ) the CNTL resource and then make a control item in the dialog, and the ) scontrol appears, and the dialog manager does all the tracking for it I put a user item over (under?) the scroll bar item to catch clicks before they get to the scroll bar itself. This way, you can still use ResEdit (or whatever) to edit your dialog. And, yeah, you have to manually track the the arrows using a callback. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From tclement@hmc.edu (Todd Clements) Date: 22 Aug 1994 02:22:22 GMT Organization: Harvey Mudd College, Claremont CA USA Check out DialogBits on ftp.apple.com (I think in the snippets directory)... it's in C, but I'm sure you can figure it out. =) Todd -- tclement@hmc.edu Todd Clements - Chem nerd at Harvey Mudd College "In the beginning, there was nothing. And God said, 'Let there be LIGHT!' And there was still nothing; but now you could see it." --------------------------- >From Ola.Montan@malmo.trab.se (Ola Montan) Subject: Should new programs still be System 6 compatible? Date: Wed, 3 Aug 1994 11:32:14 GMT Organization: Telia Research AB I'm writing new programs for the Macintosh and I wonder: - Is it OK today to assume that the user have System 7.0 or later, or do I have to make it possible to run the program on System 6 or even System 5? - If I have to be able to run on System 6, what do I have to think about? All "compatiblity guidelines" tells about what to think about to run in System 7. / Ola Montán +++++++++++++++++++++++++++ >From decartwr@newstand.syr.edu (Dana Cartwright 3rd) Date: 3 Aug 1994 12:23:13 GMT Organization: Syracuse University, Syracuse NY, USA Ola Montan (Ola.Montan@malmo.trab.se) wrote: : I'm writing new programs for the Macintosh and I wonder: : - Is it OK today to assume that the user have System 7.0 or later, or do : I have to make it possible to run the program on System 6 or even System : 5? I'll add two more questions to your list: 68000 compatibility, and older versions of QuickDraw. I keep an "old" SE around and run my software on it, but I'm darned if I know why. Preserving compability with these older systems is less and less attractive (to the developer, at any rate!). Development goes forward (in my case) on a 68040. If you use floating windows (like Dean Yu's), you'll find they work differently on older ROM's (at least, I suspect it's code in the ROM's that's the difference, but that's just a guess on my part). +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Wed, 3 Aug 1994 16:38:21 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Ola.Montan@malmo.trab.se (Ola Montan) writes: >I'm writing new programs for the Macintosh and I wonder: >- Is it OK today to assume that the user have System 7.0 or later, or do >I have to make it possible to run the program on System 6 or even System >5? Unless your application is for the educational or game market, forget System 6. John Nagle +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Wed, 03 Aug 1994 19:35:33 +0200 Organization: Royal Institute of Something or other In article <31o27h$8q8@newstand.syr.edu>, decartwr@newstand.syr.edu (Dana Cartwright 3rd) wrote: >: - Is it OK today to assume that the user have System 7.0 or later, or do >: I have to make it possible to run the program on System 6 or even System >: 5? >I'll add two more questions to your list: 68000 compatibility, and >older versions of QuickDraw. I keep an "old" SE around and run my This is covered in the FAQ (the Total Authority Document :-) Anyway, there seems to be two ways you can go: 1) Does your app require color, or AppleEvents, or QuickTime, or more than 1 MB of memory (for itself)? Or does it require more than one process running at once? Go for System 7 only. 2) Is your application in the "typical application" cathegory; word processing, telecommunications, ... People who bought their computers four years ago probably bought what they need already. Go with System 7. 3) So you're writing a novelty application which will work well on small screens, in black/white, in a small memory footprint. Here, you might still sell into a bigger market if you work with System 6 as well. However, for the majority of applications, it's just not worth it. As an example, here is what I _demand_ to run in my newer apps: - New File Manager (soon to be renamed the Old New File Manager :-) - 32-bit QuickDraw - 68020 or better - AppleEvents Of course I test for these individually, but on failure, I tell users to upgrade to System 7 (or their computer, if the CPU test fails) However, some things should NOT be demanded. That Virtual Memory be off is an _evil_ thing, especially on PowerPCs where system performance is BETTER with VM on, as long as your swap file just covers your RAM and another meg or two. Cheers, / h+ -- Jon Wätte Hagagatan 1 113 48 Stockholm Sweden +++++++++++++++++++++++++++ >From blm@chinook.halcyon.com (Brian L. Matthews) Date: 3 Aug 1994 17:28:09 GMT Organization: Northwest Nexus Inc. In article <1994Aug3.113214.15566@malmo.trab.se>, Ola Montan wrote: |- Is it OK today to assume that the user have System 7.0 or later, or do |I have to make it possible to run the program on System 6 or even System |5? In my opinion, don't worry about anything earlier than System 6. If your target market is higher end users (who probably have newer machines which don't even run System 6), don't worry about System 6. If your target is lower end users (who can't necessarily afford to upgrade to the new machines or have the hardware to run System 7), you need to worry about System 6. However, whatever you assume about the target machine, make sure your software tests your assumptions at run time and reacts gracefully if they're wrong. So if your software requires System 7, test for that, and if you're not running on System 7 or later, present an alert stating you need System 7, then exit (and of course the code that does this needs to run on System 6, and is simple enough it can probably run on earlier systems as well). Similarly for things like processor (68000 vs. 68020 vs. PowerPC), Color Quickdraw, DSP, etc. Brian +++++++++++++++++++++++++++ >From woody@alumni.caltech.edu (William Edward Woody) Date: 3 Aug 1994 20:32:35 GMT Organization: California Institute of Technology, Alumni Association In article <1994Aug3.113214.15566@malmo.trab.se>, Ola Montan wrote: >I'm writing new programs for the Macintosh and I wonder: > >- Is it OK today to assume that the user have System 7.0 or later, or do >I have to make it possible to run the program on System 6 or even System >5? According to some information I got from Apple in one of their developer's mailings, most users are running under System 7. But 'most' means > 50%; not everyone has upgraded yet. It's reasonable to support System 6.0.7 as well as System 7. >- If I have to be able to run on System 6, what do I have to think about? >All "compatiblity guidelines" tells about what to think about to run in >System 7. What I check for in my standard initialization loop in the library I tend to use for all applications are: o Is AppleEvents available? (If they are, I install my Apple Events handler. If they are not, I use CountAppFiles() and GetAppFiles() to get the files which my application was run with.) o Is Color Quickdraw available? (For applications which use color. For applications which use 32 bit color, I also check the features which are available through the gestaltQuickdrawFeatures selector. o Are FSSpec-selectors available? (This sets a global flag. Anytime I want to open a file, I use the FSpOpenDF() call if the flag is set, and HOpen() call if it's clear. One of the cheats I use is to use the fields of the FSSpec data structure to store the Volume RefNum, Directory ID, and file name of the file I'm working with if that flag is clear. Though Apple says not to initialize the fields of a FSSpec by hand, I interpret that as meaning that if FSSpecs are supported by the OS, then you should use FSMakeFSSpec(). Otherwise, an FSSpec is simply 70 bytes of storage that's up for grabs.) All of the System 7 compatability guidelines (be 32 bit clean, work well with MultiFinder, etc., etc., etc.) are just generally good hygene. And getting into the habit of checking with Gestalt for a particular feature is algo just good hygene. I hope this helps. - Bill -- - William Edward Woody | Disclamer: woody@alumni.cco.caltech.edu | "He who knows does not speak; - In Phase Consulting | He who speaks does not know." 337 West California #4; Glendale, CA 91203 | - Lao Tzu +++++++++++++++++++++++++++ >From lbotez@picard.cs.wisc.edu (Lynda Botez) Date: 3 Aug 1994 21:04:49 GMT Organization: U of Wisconsin CS Dept Excuse me, but do you really tell your users to "upgrade their computer?" haha... "Your computer sucks; get a "real" computer..." Sorry, that just cracks me up... +++++++++++++++++++++++++++ >From marshall@cais.com (Preston Marshall) Date: 3 Aug 1994 18:09:24 GMT Organization: Vanguard Research, Inc. > Ola Montan (Ola.Montan@malmo.trab.se) wrote: > : I'm writing new programs for the Macintosh and I wonder: > > : - Is it OK today to assume that the user have System 7.0 or later, or do > : I have to make it possible to run the program on System 6 or even System > : 5? > I sent E-mail to Apple developer services once suggesting that they periodically publish their estimates as to "what was out there" in terms of systems and OS's. They must have a guess as to how many plusses, SE's or even IIfx's are stil active and being used. I would like to know what I loose when I decide to make a feature mandatory. The problem is going to come up again when 7.5 gets established. -- ___________________________________________________________________ | Preston Marshall - marshall@cais.com | | Vanguard Research, Inc. - | | 10306 Eaton Pl. - The opinions are mine, | | Farifax, Va 22111 - my employer doesn't care | ___________________________________________________________________ +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Thu, 04 Aug 1994 11:00:59 +0200 Organization: Royal Institute of Something or other In article <31out3$lme@gap.cco.caltech.edu>, woody@alumni.caltech.edu (William Edward Woody) wrote: >According to some information I got from Apple in one of their >developer's mailings, most users are running under System 7. >But 'most' means > 50%; not everyone has upgraded yet. It's >reasonable to support System 6.0.7 as well as System 7. A year ago, the 50% limit was already passed. Since then, Apple has sold several million more computers, all of them with 68030s, color quickdraw enabled, and running System 7. People seem to be still living in the pre-1991 world of "lots" of 68000 macs. Face it: the way Apples sales have been taking off the last few years, 68000 and System 6 is a CLEAR minority, and since those computers are at least three years old, they probably don't buy much software anymore. The exception is of course the lower educational market; nobody ever spends enough money on educating the coming generation. Cheers, / h+ -- Jon Wätte Hagagatan 1 113 48 Stockholm Sweden +++++++++++++++++++++++++++ >From zobkiw@datawatch.com (joe zobkiw) Date: Thu, 4 Aug 1994 15:13:35 GMT Organization: Datawatch Corporation Even if your app doesn't REQUIRE AppleEvents, PPCToolbox, QuickTime, etc. I would say don't waste your time supporting System 6. I am currently working on a commercial project that must support System 6 and it stinks. You can't use the cool icon utilities, can't use the new standard file routines, can't tail patch safely, can't depend on color QuickDraw, can't use the the nice auto-positioning features of the Window Manager. Supporting System 6 consists of carrying a lot of extra baggage - in the form of code. Ever date someone who has a lot of extra emotional baggage? It's a _very_ similar experience! ___________________________________________________________ _/_/_/_/ Joe Zobkiw ,,, _/ Senior Software Engineer - - _/ Datawatch Corporation L _/_/_/_/ zobkiw@datawatch.com - How can one expect to program without buying a single IM? +++++++++++++++++++++++++++ >From Jeff Abrahamson Date: Thu, 04 Aug 94 10:20:40 -0500 Organization: Purple In article <31ok39$sth@nwfocus.wa.com>, Brian L. Matthews writes: > However, whatever you assume about the target machine, make sure your > software tests your assumptions at run time and reacts gracefully if they're > wrong. I agree. However, some problems arise: - I compile for a 68020, but the user has but a 68000. Unless I'm using MPW, I don't know how to compile just a single segment for 68000 and the rest for 68020. - I compile for 68881, but the user doesn't have a 68881. Same problem as above. Note that PPC's crash when you make 68881 calls, so it's not just a low-end-only problem. Standard Disclaimer: Of course, these may be easily solved problems to which I simply don't know the answers. -Jeff Abrahamson PDI +++++++++++++++++++++++++++ >From Kevin.R.Boyce@gsfc.nasa.gov (Kevin R. Boyce) Date: Thu, 04 Aug 1994 13:24:23 -0400 Organization: NASA/GSFC In article <94080410204000115@purple.com>, clio!jeff@vu-vlsi.ee.vill.edu wrote: >In article <31ok39$sth@nwfocus.wa.com>, Brian L. Matthews writes: > >> However, whatever you assume about the target machine, make sure your >> software tests your assumptions at run time and reacts gracefully if they're >> wrong. > >I agree. However, some problems arise: > >- I compile for a 68020, but the user has but a 68000. Unless I'm using >MPW, I don't know how to compile just a single segment for 68000 and the >rest for 68020. Metrowerks I don't know from (yet), but for Think C: #pragma options( mc68020, mc68881 ) to turn them on, #pragma options( !mc68020, !mc68881 ) to turn them off. See pp. 322ff in the TC6 manual. BTW, it would be nice if you used shorter lines in your posts. Newswatcher couldn't clean it up; I had to shlep all the way over to BBEdit. :-) -- Kevin Kevin.R.Boyce@gsfc.nasa.gov Goodbye Clipper chip, hello asteroid Zappa. Is this a great country or what? +++++++++++++++++++++++++++ >From pcastine@jake.prz.tu-berlin.de (Peter Castine) Date: Thu, 4 Aug 1994 19:08:29 GMT Organization: PRZ TU-Berlin marshall@cais.com (Preston Marshall) writes: > >I sent E-mail to Apple developer services once suggesting that they >periodically publish their estimates as to "what was out there" in terms >of systems and OS's. They must have a guess as to how many plusses, SE's >or even IIfx's are stil active and being used. > If you're a registered developer, you get Apple Direct. They have published figures from time to time Re: numbers of various Machines and OS Versions out there in userland. Sorry, don't have one here to quote off hand. -- Peter Castine | Oh, wenn jene alten, musikkundigen Gelehrten die pcastine@prz.tu-berlin.de | Modernen hoerten, was wuerden sie tun, was Process Control Center | wuerden sie sagen! Technical University Berlin | -- Jacobus von Luettich (ca. 1330) +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 3 Aug 1994 20:34:58 GMT Organization: Apple Computer Jon W{tte, h+@nada.kth.se writes: > However, some things should NOT be demanded. That Virtual Memory be > off is an _evil_ thing, especially on PowerPCs where system > performance is BETTER with VM on, as long as your swap file just > covers your RAM and another meg or two. Is that true for you? I turned VM on on my 7100 and gave it 1 more MB than I have physical RAM, and still it made my CodeWarrior compiles a lot slower. (During compilation, after every few files I could hear my disk doing a lot of VM thrashing...) It was something like a 20% performance penalty, although I didn't time it. I believe the problem is that since part of the physical RAM is being used to store code, it's not available for heaps, so there's really much greater than 1MB difference between the virtual and physical memory available for heap zones. It's a shame ... guess I'll have to wait until Copland for good VM. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 4 Aug 1994 20:34:16 GMT Organization: Apple Computer Jeff Abrahamson, Jeff@purple.com writes: > - I compile for a 68020, but the user has but a 68000. Unless I'm using MPW, I > don't know how to > compile just a single segment for 68000 and the rest for 68020. In C/C++, you do this with #pragma statements. Check your development system's manual; THINK and CodeWarrior do this differently but both of them let you change most of the compile settings via pragmas. I believe Pascal has similar stuff. > - I compile for 68881, but the user doesn't have a 68881. Same problem as > above. Note that PPC's > crash when you make 68881 calls, so it's not just a low-end-only problem. Again, there are pragmas to turn 881 codegen on and off. If you want to run with or without an 881 but take advantage of it if it exists, the best thing is probably to include two versions of your core math-intensive routines, one compiled for 881 and one not. (You can put the two versions in different segments, so only one will ever get loaded.) Then call Gestalt at startup to check whether you have an 881, and call one routine or the other depending. Or if you're megaconcerned about efficiency, at startup set up some procptrs to point to one or the other set of routines, and then call the routines through the procptrs. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Fri, 5 Aug 1994 09:25:45 GMT Organization: The World Public Access UNIX, Brookline, MA In article , joe zobkiw wrote: >Even if your app doesn't REQUIRE AppleEvents, PPCToolbox, QuickTime, etc. >I would say don't waste your time supporting System 6. I am currently >working on a commercial project that must support System 6 and it stinks. >You can't use the cool icon utilities, can't use the new standard file >routines, can't tail patch safely, can't depend on color QuickDraw, can't >use the the nice auto-positioning features of the Window Manager. I don't think tail patching was fully authorized with sys-7.0. I think the PowerPC sys software was the first to allow tail-patching for all patchable traps, and that was due to the way the MMM (mixed-mode mangler) calls patches. Color QuickDraw is only supported on CPUs 68K and greater, and was supported in systems prior to 7.0 on appropriate hardware. >How can one expect to program without buying a single IM? Buy all of them on the forthcoming CD :-) Regular $100, but if you preorder, then it's only $80. You're not charged till it ships, and they'll call to confirm that you still want it. MacWorld show special, but Addison-Wesley might extend this beyond the show. I think having all of NIM on a CD is essential. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Fri, 5 Aug 1994 09:40:14 GMT Organization: The World Public Access UNIX, Brookline, MA In article , Ari I Halberstadt wrote: >Color QuickDraw is only supported on CPUs 68K and greater, and was >supported in systems prior to 7.0 on appropriate hardware. Ack, I didn't mean 68K or greater, I meant 68020 and later CPUs. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From giles@med.cornell.edu (Aaron Giles) Date: Fri, 05 Aug 1994 13:36:13 -0400 Organization: Cornell University Medical College In article <1994Aug3.203458.22623@gallant.apple.com>, Jens Alfke wrote: > Jon W{tte, h+@nada.kth.se writes: > > However, some things should NOT be demanded. That Virtual Memory be > > off is an _evil_ thing, especially on PowerPCs where system > > performance is BETTER with VM on, as long as your swap file just > > covers your RAM and another meg or two. > > Is that true for you? I turned VM on on my 7100 and gave it 1 more MB than I > have physical RAM, and still it made my CodeWarrior compiles a lot slower. > (During compilation, after every few files I could hear my disk doing a lot > of VM thrashing...) It was something like a 20% performance penalty, although > I didn't time it. I think CW uses temporary memory during compiles, which will cause thrashing in the system heap, where your extra 1MB is probably hanging out. I really really wish Apple would let you set your VM to exactly your system memory, so that you can get file mapping without fear of trashing in the extra 1MB. I tried hacking the system file to set VM down to exactly equal to my physical memory, but it wasn't too happy after that. :-) Aaron -- Aaron Giles (giles@med.cornell.edu) Power Macintosh Developer, Cornell University Medical College JPEGView home page: http://www.med.cornell.edu/jpegview.html JPEGView FTP site: ftp://ftp.med.cornell.edu/pub/aarong/jpegview/ +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Fri, 05 Aug 1994 11:02:43 -0800 Organization: Integer Poet Software In article , zobkiw@datawatch.com (joe zobkiw) wrote: > I am currently working on a commercial project that must support System 6 > and it stinks... You can't ... depend on color QuickDraw... You can't depend on Color QuickDraw even under System 7. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Clear-cutting removes all trees... to create new habitats for wildlife. P&G uses this economically and environmentally sound method because it most closely mimics nature's own processes. Clear-cutting also opens the floor to sunshine, thus stimulating growth and providing food for animals." -- Procter & Gamble's "Decision Earth" free school curriculum +++++++++++++++++++++++++++ >From wdh@netcom.com (Bill Hofmann) Date: Fri, 5 Aug 1994 18:04:16 GMT Organization: Fresh Software In article , ari@world.std.com (Ari I Halberstadt) wrote: > I don't think tail patching was fully authorized with sys-7.0. I think > the PowerPC sys software was the first to allow tail-patching for all > patchable traps, and that was due to the way the MMM (mixed-mode > mangler) calls patches. Recent threads have discussed that tail patching has been legit with a few exceptions (FrontWindow(), apparently, who knows why?) since system 7, because of the revised way come-from patches are done by system software. -Bill -- Bill Hofmann wdh@netcom.com Fresh Software and Instructional Design voice: +1 510 524 0852 1640 San Pablo Ave #C, Berkeley CA 94702 USA fax: +1 510 524 0853 +++++++++++++++++++++++++++ >From wdh@netcom.com (Bill Hofmann) Date: Fri, 5 Aug 1994 18:16:35 GMT Organization: Fresh Software In article , nagle@netcom.com (John Nagle) wrote: > Ola.Montan@malmo.trab.se (Ola Montan) writes: > >I'm writing new programs for the Macintosh and I wonder: > >- Is it OK today to assume that the user have System 7.0 or later, or do > >I have to make it possible to run the program on System 6 or even System > >5? > Unless your application is for the educational or game market, > forget System 6. I agree: this is the "proper" approach--evaluate your target market, and decide based on this. So for instance, if you're targeting PowerBooks, you can ignore sys 6 (unless you're worried about the transitional Kanji sys 6 that lots of people in Japan were running prior to system 7.1). Probably at this point, you could ignore system 6 (maybe even 7.0) for mass market if you're targeting the Performa market. Don't forget to factor in development time: 50% may be running 7.5 by the time you finish :-(. Also, where you *don't* have to assume system 7, don't. You can and should use FSSpec's, and the MakeFSSpec call has glue for pre-7 systems. You can wrap portions that are different in 6 vs 7 (HOpen vs FSpOpenDF: who names these things?) in a common routine that has consistent calling conventions to maintain maximum compatibility. Other areas like the script manager are so different from release to release of system software that one could be forgiven for requiring not just 7.0 but 7.1 (the basis of NIM, after all). Obviously if you're writing a program to do collaboration, you can require 7.1 Pro, or if you're writing a GX Print Utility, you can require GX, so that gives you license to require all kindsa things. I would still test on 68000 Macs, but more as an afterthought. I've still got a Classic at home and an SE with a jet engine fan in the office collecting dust, and occasionally give things a try on there. -Bill -- Bill Hofmann wdh@netcom.com Fresh Software and Instructional Design voice: +1 510 524 0852 1640 San Pablo Ave #C, Berkeley CA 94702 USA fax: +1 510 524 0853 +++++++++++++++++++++++++++ >From qsi@cnh.wlink.nl (Peter Kocourek) Date: 07 Aug 94 16:54:24 +0200 Organization: Care Net Holland Bill Hofmann wrote in a message on 05 Aug 94: BH> Probably at this point, you could ignore system 6 (maybe even BH> 7.0) for mass market if you're targeting the Performa market. BH> Don't forget to factor in development time: 50% may be running BH> 7.5 by the time you finish :-(. Considering Apple's idiotic pricing of 7.5, I don't think you should be too worried about many users running it. :-/ YHS:QSI! +++++++++++++++++++++++++++ >From mason@cis.umassd.edu (Mason Bliss) Date: Wed, 10 Aug 1994 02:41:11 GMT Organization: University of Massachusetts Dartmouth In <80b_9408080302@cnh.wlink.nl> qsi@cnh.wlink.nl (Peter Kocourek) writes: >Considering Apple's idiotic pricing of 7.5, I don't think you should be too >worried about many users running it. :-/ Heh. Oh, come on! I *want* to go out and spend big bucks so that my system disks will install all the stuff I've FTPed *for* me. I may be missing something, but it doesn't look like 7.5 has anything terribly significant in it. It looks more akin to the jump from 7.0 to 7.5, where we could spend all kinds of money to have a fonts folder. My preference is this: Write for 7.0. Don't go out of your way to make things incompatible with System 6. If you can be compatible with System 6, great, but if not, don't worry about it. -- Mason L. Bliss - mason@acheron.middleboro.ma.us - mason@cis.umassd.edu "What diabolical chicken stepped on your forehead and sat on your chin?" +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Tue, 09 Aug 1994 20:19:53 -0800 Organization: Integer Poet Software In article , ari@world.std.com (Ari I Halberstadt) wrote: > I don't think tail patching was fully authorized with sys-7.0. Yes, it was, other than FrontWindow or FindWindow or some other call that starts with 'F' and ends with 'Window'. :-) I'd be surprised if there were an official Apple document with a specific announcement, but Apple employees, indeed, Blue Meanies, have posted repeatedly here that this is the case. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "I am Homer of Borg! Prepare to be... Ooooooo! Donuts!" +++++++++++++++++++++++++++ >From alexr@apple.com (Alexander M. Rosenberg) Date: Wed, 10 Aug 1994 19:06:51 GMT Organization: Hackers Anonymous In article , gurgle@dnai.com (Pete Gontier) wrote: > In article , ari@world.std.com (Ari I > Halberstadt) wrote: > > > I don't think tail patching was fully authorized with sys-7.0. > > Yes, it was, other than FrontWindow or FindWindow or some other call that > starts with 'F' and ends with 'Window'. :-) I'd be surprised if there were > an official Apple document with a specific announcement, but Apple > employees, indeed, Blue Meanies, have posted repeatedly here that this is > the case. And I believe that Inside Mac: Operating System Utilities even states this. - ------------------------------------------------------------------------- - Alexander M. Rosenberg - INTERNET: alexr@apple.com - Yoyodyne - - 330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr - Propulsion - - Palo Alto, CA 94301 - - Systems - - (415) 329-8463 - Nobody is my employer so - :-) - - (408) 974-3110 - nobody cares what I say. - - +++++++++++++++++++++++++++ >From qsi@cnh.wlink.nl (Peter Kocourek) Date: 11 Aug 94 15:37:07 +0200 Organization: Care Net Holland Mason Bliss wrote in a message on 10 Aug 94: MB> In <80b_9408080302@cnh.wlink.nl> qsi@cnh.wlink.nl (Peter Kocourek) MB> writes: >Considering Apple's idiotic pricing of 7.5, I don't think you should be too >worried about many users running it. :-/ MB> Heh. Oh, come on! I *want* to go out and spend big bucks so MB> that my system disks will install all the stuff I've FTPed MB> *for* me. MB> I may be missing something, but it doesn't look like 7.5 has MB> anything terribly significant in it. It looks more akin to MB> the jump from 7.0 to 7.5, where we could spend all kinds of MB> money to have a fonts folder. This is not entirely fair: System 7.5 does come with QuickDraw GX and PowerTalk. Some people will find these enhancements valuable, although personally, I probably won't be using either of them. The question is, whether the $140 Apple wants to charge for the update is reasonable. I don't happen to think so, even if I had a use for GX. It is clear that GX is a substantial achievement, and its development cost Apple a lot of money. I also understand that Apple wants to offset the developments costs. However, I don't this is the best way of going about it. The ultimate success of new technologies will be determined by how widely they are adopted by users and developers. Developers are less likely to support Apple's cool new technologies, if the installed user base is small. I think the $140 (or $99 street) would be more reasonable for a more substantial upgrade, like Copland. MB> My preference is this: Write for 7.0. Don't go out of your MB> way to make things incompatible with System 6. If you can be MB> compatible with System 6, great, but if not, don't worry about MB> it. I don't support System 6 any longer in new programs I write. Maintaining older programs, I keep the System 6 stuff in. As for supporting post-7.0 features, I implement them based on how much work it is, and how much demand there is for them. YHS:QSI! +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: 19 Aug 1994 21:27:13 GMT Organization: (none) Ola.Montan@malmo.trab.se (Ola Montan) writes: >I'm writing new programs for the Macintosh and I wonder: >- Is it OK today to assume that the user have System 7.0 or later, or do >I have to make it possible to run the program on System 6 or even System 5? Forget System 5. If you can make your program run on it, well, good, but that is like paiting the back of the drawers - you know you did a great job, but few will care. System 6.0.7 is the lowest system that is interesting to support. If you should, depends on the users. Many low-end users use System 6, especially those on slow Macs like MacPlus, or Macs with little memory. Extreme case of needing System 6: Networked games! If you make a networked game, try to support both System 6 and non-color-QuickDraw. Many long-time Mac users have two Macs, and one of them might be an old Plus or SE. If your program is color only, there is a smaller population who will want System 6. Not none at all, but making it work in b/w (esp non-color QD) is more important. And, as someone noted, if you make high-end applications, where most of your users use new, high-end Macs, well, who will notice? >- If I have to be able to run on System 6, what do I have to think about? >All "compatiblity guidelines" tells about what to think about to run in >System 7. Only use stuff described in IM 1-5. GWorlds can be demanded, at least from color users, since they can install it under sys 6. If you can't run System 6 yourself, you better find someone who do, or you'll never know. -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Sun, 21 Aug 1994 15:26:10 +0800 Organization: Department of Computer Science, The University of Western Australia In article <33383h$cm0@newsy.ifm.liu.se>, ingemar@lysator.liu.se (Ingemar Ragnemalm) wrote: >System 6.0.7 is the lowest system that is interesting to support. I disagree. 6.0.5 has most of the features of 6.0.7 (specifically _Gestalt) but is a lot more reliable on machines that don't need 6.0.7 (ie LC, IIsi). If you're going to support System 6 you should support back to 6.0.5! -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From kaufman@Xenon.Stanford.EDU (Marc T. Kaufman) Date: 22 Aug 1994 03:08:30 GMT Organization: Computer Science Department, Stanford University. In article , Quinn "The Eskimo!" wrote: >In article <33383h$cm0@newsy.ifm.liu.se>, ingemar@lysator.liu.se (Ingemar >Ragnemalm) wrote: ->System 6.0.7 is the lowest system that is interesting to support. >I disagree. 6.0.5 has most of the features of 6.0.7 (specifically >_Gestalt) but is a lot more reliable on machines that don't need 6.0.7 (ie >LC, IIsi). If you're going to support System 6 you should support back to >6.0.5! I have one customer who is running 6.0.3, because he likes the Quickdraw bug that caused hairlines not to fatten when copied to a larger bitmap. He needed that feature to create hairline targets on 35mm slides. I think we can agree not to go back to 4.x, though, can't we? Marc --------------------------- >From h+@nada.kth.se (Jon W{tte) Subject: The System 7.5 Think Debugger Bug - and fix! Date: Fri, 19 Aug 1994 22:27:29 +0200 Organization: Royal Institute of Something or other As you may now be aware of, there is a bug in Think Debugger and/or System 7.5 that makes the debugger freeze on startup for several kinds of projects. It worked in 7.5b5, but not now. Everyone at apple says that nothing changed in the Process Manager between them. The bug, however, DOES depend on Think Debugger calling GetNextEvent in a tight loop, waiting for an app4Evt that doesn't get there. This INIT, when installed, patches GetNextEvent to call WaitNextEvent and give 6 in background time, which makes the debugger work once again. Since WaitNextEvent calls GetNextEvent internally, AND process switched happen during WaitNextEvent calls, I have a nice re-entrancy problem which I solve with a linked list of A5 values in the system heap. This list is NOT cleaned up, and consists of nonrelocatable blocks, so use with care! (it doesn't crash, though) Source included Enjoy, / h+ (Pardon the binary posting on this group, but it's SOOO small, important and relevant...) (This file must be converted with BinHex 4.0) :#d&bBfKTGQ8ZFfPd!&0*9%46593K!*!%"Ld!N!6D4P0*9#%!!J!!"Leb6'&e!J# 3""B!!!d!$8G145dq9dj&)%P1596H@!!@plS!N!1!!*!%!H6TS19H!*!8!EX!N!6 rN!4*6NP89dj&)3%!URT2MUTkL[S!!!(q!*!'!68!N!6D+J#3#%Q%%3!)(2b83a! V!94,T9i#L+fB8,L`SeBec9BMfcTU5@aFfq5N'Xel*#IKpXRY3aiR%MR6jb"3cN[ VpVYM@1FpXK8b`kN8kqYjTkpR9Pp8UlfE*-a0NYj*NYj*NZ+bNkT-8Z8QDPY(,BR 9DRAMGeT-b@l"hV'%0p@-)b[Ac$eqleT0aaFq[NhV0q'iFU-6hS3m@RpIfq3XKrF DhlA'Pk2epl9eP&diN!"m#h'DVQlC[hUY#`(9c0fYFiZDN!#rCNh)efi)j'aer,L q,AT!3Fc"dbVJ-+(c#e!`q4BRZdTR-kjd'*0D[&cJJQFJ0M8@YqmlY9B9b*h`$14 1cUUC1eV`q0,PqT3EAGB2X3P23qiS*'I0ZkE'V,4UmfqBG(`pFH0B4k&31rXHQ5E #+)$!c&5AFm@+Fk56!!!0$3CYB@PZ,Q1H3*U))!(FhPJ!&[Hk!*!$J!#3"!(NkD$ 3+!#3%4B!N!MrN!4849K85d&)6!%!UE8-1+TkLQ-!!!&q!!!(rJ#3!pN!!!-T#dX dl`#3"U1-%3!)(!`k"&(aqD"SC3Dj+c,)Gr&*N!#EjkQCUfDqj!N`2E!RVJka160 )K2P5-Ma1Q*E8-p3aS9dR"-Tjc!!hCRhNXYj[RCf[)8#Z'8lVA9eZ9Y0MG`)RUA0 UTiF,MNVZRCb9h"fJh91SK,2%M*P,j*3,PHYbqr13!!m(FH$@jk&SF+I#plbE2@0 HYY[*cY(CFXMNHFZaMc+a,aY%"DqI-j,#2pJUrJ5)KDS3imQ)D3E1KA$T(Rc#X&e SpSk)jV0Z#4lDpX+0qcN+G66`"i*G(8f-Q6,c+TlBYU!&#Nlaj!%)-S$*86*BMl# 9VH%[XZBP-m))ME!RE%#1f4(k%8TQ+`&B2H$e2(S!UdB"2ZS64LK"!#0)BJ6p#!$ ZqQa!9RD%(AP+RKdjCNH'M)`B33)$)!m!0,$fpq&c-"KdiBe-iH+6-FMBAT+')Sm 3(Vmlqf!5SG[aNjAS,8kP@PJ0Lj&(U+!"6ID4H9a2i50,dX3--jQNjK%lmV`SE-r !Rr2"H1bjG`62FC42*UJBmcb"()jVbaEh594j"Th$b[-83hQ$kK92)i&N-DAIYJ$ ZYaifH,qj-Kd-1R93`m2i&,A-98M&PVBcf,-q3DF9qBA4DbVJ)NNM1G1V*2eZVdV b%XfjP1*FmHaT&#R8eXGe*d8dA0QhH,"TTm'$jV,RM*X`hVVCZ[q@dZ[fUe,1[T@ LM'EX5e$i`q+kKlkrl)'k2m'jHA'$UIP(apVr0ajEZadIplhm"131ff93!3hZ0`[ "j64c[e8JK9b)"A#ic%PT**JBJD*X@#hT@pGcMar*8jRCHNCD`A%BBhJej&P'!U- 0q8DfMe'+T+81KLC@-Tr%+cS#JXQh3lLE4T,SI(30Hjd@lpH'rKbY[$"aCB3b@d$ '&CqL3@8C,U2iml#f)PP'"2Rc([f%3T&q0m'(2BHScA6"N`fPCAJAajm(IY93QE6 MK)ip'mdD8DHe[PIV,FC9JU,BLPE'eSJ3HhGMp!0kaJL*LN23XF`*G)2D3$*fi&X C&l3*d3*LVX'QaJMSf##+D!,D&#!aPE0#Nk[8'Bm&Rd#5%Y0!p`c0LEYpk*!!+KH PdP-G4c!5-V`#E93H8J#N*B'8'LcZ*AYmGCXNi3IPKr0ZG*UXVZlAq*4m8)Iad2# 43!Z#N!!bXqMBq5R`X!1%eh#XF**SLPlZd`BJ1qrK0+2rVYhf&MqSA-Fb6k1Y*3m +iND+dYZmM#eG(,EP@Kbk+'i"E9(&Yh0femkkMcpPIldG5`9G')'p,pCA6S"9JK1 F[6IUE+'I83QV($E$Jqq(65diD"%1MU#b`'TXV!&0FjRDe9PMk"LJ*QL"f@kmGYV YXEH8HVIXPV%EQ84XbQP5'XbcRqjJ[fAr!3#3!dbQ!!!: -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden "TextEdit does everything right." ‹ Jon W{tte +++++++++++++++++++++++++++ >From tree@bedford.symantec.com (Tom Emerson) Date: Sat, 20 Aug 1994 17:15:43 -0800 Organization: Symantec Development Tools Group In article <9668AA7AE251.45173@klkmac004.nada.kth.se>, h+@nada.kth.se (Jon W{tte) wrote: > As you may now be aware of, there is a bug in Think Debugger > and/or System 7.5 that makes the debugger freeze on startup for > several kinds of projects. > > It worked in 7.5b5, but not now. Everyone at apple says that > nothing changed in the Process Manager between them. The bug, > however, DOES depend on Think Debugger calling GetNextEvent in > a tight loop, waiting for an app4Evt that doesn't get there. Some background on this: the TPM/THINK Debugger IAC worked through 7.5b6. >From that point on some change in the new system software broke the communications mechanism. The problem only occurs for some projects (one commonality is the number of static constructors it contains - we haven't seen it with large C applications), and we have yet to determine the exact circumstances that cause the problem to appear or what changed in the System software to hose it. We've talked to the engineer responsible for the Process Manager in 7.5 and he doesn't know what changed either, so this is a mystery. The loop that waits on app4Evt's and updateEvts appears in both the TPM and Debugger --- which one you hang in depends on who initiated the communication. > This INIT, when installed, patches GetNextEvent to call > WaitNextEvent and give 6 in background time, which makes the > debugger work once again. Since WaitNextEvent calls [snip] This is the fix that we will probably make, though we need to QA more before releasing it, and it would be nice to know what actually changed in the System to bring about the problem. -tre -- Tom Emerson Software Engineer Development Tools Group Symantec Corporation tree@bedford.symantec.com "I dreamed I had to take a test, in a Dairy Queen, on another planet." +++++++++++++++++++++++++++ >From stevep@wrq.com (Steve Poole) Date: Mon, 22 Aug 1994 10:59:25 -0800 Organization: Walker Richer & Quinn In article , tree@bedford.symantec.com (Tom Emerson) wrote: > communications mechanism. The problem only occurs for some projects (one > commonality is the number of static constructors it contains - we haven't > seen it with large C applications), and we have yet to determine the exact I've seen it with large C apps, Tom. Steve - ------------------------------------------------------------------------ - Internet: stevep@wrq.com - AOL: Spoole - INTEL 80x86: Just say NOP - - "Nurse! Do let's pretend that I'm a hungry hyaena, and you're a bone!" - - ------------------------------------------------------------------------ --------------------------- >From h+@nada.kth.se (Jon W{tte) Subject: Think Debugger & INIT source code Date: Sun, 21 Aug 1994 16:52:25 +0200 Organization: Royal Institute of Something or other The INIT I sent out a day ago to fix the System 7.5 bug when using the Think Debugger _did_ fix the problem, but it didn't do it by behaving as advertized. This is because I patched InitWindows, and from that patch patched GetNextEvent to instead call WaitNextEvent with a sleep time of 6, and added some application referencing stuff in a linked list to kkeep track of re-entry. Well, using the patch I did, calling WaitNextEvent would actually result in WaitNextEvent being called twice; once with whatever sleep time was passed to it, and once through my path before it came down to GetNextEvent. Not good. HOWEVER - it turns out that the Process Mangler patches out InitWindows so other apps don't get to it, just like with WaitNextEvent and GetNextEvent (which was why I laid the basic patch there initially...) with the exception of the Finder, which calls InitWindows before this patching is done. Straaaange! Now, my patch hangs off InitDialogs, which, as it turns out, is a much better place to hang - cheaper brews, cooler people, and not getting patched-out by the Process Mangler. Yet, anyway :-) Another complication was that I only used one location to save the old WaitNextEvent globally. Since some apps patch WaitNextEvent themselves, BEFORE they call InitDialogs, this was a bad thing (projects running under the Think Debugger come to mind...) Now I only patch if the saved address is 0, or the address I get from WNE is the same as the saved address, which it turns out to be for the vast majority of applications; even for the Finder (It's surprising that the Finder does ANYTHING like we mortals :-) Anyway, now this INIT behaves as advertized, and can also serve as example code of how to write a skanky INIT that gets at the WaitNextEvent mechanism and circumvents the Process Manager. In pure inline assembly, no less. Code review invited. Cheers, / h+ Jon W{tte (This file must be converted with BinHex 4.0) :#d&bBfKTGQ8ZFfPd!&0*9%46593K!*!%"ed!N!5#B&0*9#%!!J!!"eeb6'&e!J# 3""B!!!d!$8G145dq9dj&)%P15944H!!-rCS!N!1!!*!%!@GFS-Ne!*!8!Nm!N!6 rN!4*6NP89dj&)3%!URT2MUTp-jX!!!+L!*!'!FN!N!55J3#3#'Kf%3!)!$cY(-i 3HMf8I2+'Y30lpJ9d8memb4-m6aDXlVL(QSpb10pZ9)ZiYXP*0CVh5%l#lC2EKcc J!FfC2NIhB%h'pI5lBeMR2E)9lLK!DGQpC(qlL8q-[R9LcFU[p'fAmHUEXeG3c3U EI,XjE-Kh%Z4ZPr%Dc(ElMAY,6khjM&E4Fdr$,cFHd@J&*Ve@1f#DFH4dF&CG[fG UlTV1$204`9%1jH0pmDA(acGU9"HR9@[*5*Mi"XSdAbD0Db-S(8`%,HZNR$NRE%C E+T2T%*NdL$+*Sd5QT&'"(52c(dpi8mdiXR,0h12hVY9dr&E(YfRp*[3Y0cVK6FL MpIHe6FkUeA4FAq1VlV"ADZcTYrE2Cra9f[HqYNj+Vh%A[Z-ZeElhYA88#3H5EjP r@kd!LE8Z"15drkEf-he*KjEp+fM2fXiYDN+HQM@G%aU!R+f1(pHh43r)KcPi1Vm !qC*[D49`8Zr4UB`Ik6!QYALj`!A23'aU,'lIGfUY+T!!1q%Cb*fF960h00raTF[ e+6HkV"pL%jk'h&&)cTVr(i(l5Hc'r4b&3PG!JkM)G!)Nr@pJ(MmJTI#Xd6LM,63 DZkdQJ"$FhfGD,ZG2ScJrNNN0$3CYB@PZ,Q1H3)%jZJ&I8AJ!$2fD!*!$J!#3"!& RA+"TR!#3%4B!N!MrN!4849K85d&)6!%!URdcEkTp-fF!!!&q!!!+P`#3!r8!!!1 T,)-c)J#3"YHF%3!)(!`k"&(*(%4&TL-!A!I6d!421k102PIY$"*K[K32H##8e$2 8-D'GcSfqSVL2A0DlBd3G$T!!j`#RpDj(MmG-63UGSLE9fUQ@6ph9EU)Sm0LifMj ecqA6plhPYP'1jl&,TcpAkjCYEVP3$l@pN!!261C66ZC6*[2a)&-2G'MC(kDA[QF ki&Sq+0aZiLfMRKKekbQ3!0[a2q(iRp$qIhLmdr1PTUP$NhXRCb9h9kqdHkT-`h, -'83&VjmcNZ+XmX-R3#a8K4K24N`cm%&46lS(CqrS5Xj'meQh"2H6f)hl13Te02! (JPdG6BbCST3*qiXql5`!N!-,6PIb!!3C`13S'Da(q0U&lmMDQCb5!H@%Hi32b&2 ##AYbP-a@!T!!!Dmq1i"9B`!Ip5+--))!6T!!a!Rk%3$FjDef[FF)Ir,m#$r+M9" 1"T`F*b01KTa-q%T@!U"RMhrf$(iBc@B6q&C9F2fpYFMBNTF9p'(!hV-H0dYicmU UY20DPCApR&hdHTNi@8'bjV2&SZGr&r!FdbE2862@kdRNF0P*$RP#4e&c0$k2QLp 4U"[8Ar-UNdJ55hSpNF#6iA'I6`GEdGPXh"QeA"3[dDK'#i)9C&G`j(5Qk6",@U& [#-$cNNZ9Qkf6kH3X1[N+l@ZPj'[0kbqb6+0a1TkGNYPm+crNScXkI6iDE$MAh)V LAXhKrJI+f@3DSEck%BUfKV'$8AM+iTE$q9QbiA$05hZ&Dr[L"L[lEccZ$,3"XFC 52R`iHVd8hm&PTZD'hq"m9EPiLf8GlYZ)T"8kLBTU`U0e+PY&`[XBZJF'$l&l`[e lm)M'$Ni(*1Dk-dKKq5p11rdrdT6rP5DRXPAm-dhh#!iGpSReheNL()l'ce@l-Hl J*J(ZQfAYAk0"M9c+@q$`TU&,Um!@#'6PVPmC)a)e&`J,T5'A+Z@5VJTZLVRPU@` c3IJN*1c3DI[M(IAplAdTEdj$CAqdP4S0Pk*!mAE1khUEY"%&-e$f+I*FDfl-X5f dD[)#&T,R[rE`EqQ*3"j32Si)1Up8lFVLJ-eee!Ub6Id)5Z8mN!!k8(9'pJZ24%b 6[S1MmC!!6cY&)Z(1@a&23kMkPS+Jq4)YDPHG`8Ub2ZqNk+bQB#6Vd,SNE#3L085 jp*dT08RZab80KDLfh`Q"KhHBV%9N&Vb2rCf2Q-YM%'K*GTREKF+Rhe&`RVSkqj, NYFqkLcF8U"fYq#1)C88YYN)`9!NPr99Hl2VUaE&2p#p,iV%2+&JacQ!+e9#$@M4 NF1%0ZM-ZU@bc@k$D")F5-k$P69NNhbGNJ(!%CBffd5dCMj%SC3R3Z+HHpKm#N!! BYe8Gl`R("D45LEGJV'i%'D"TF!%9%@`r(T!!CRp#h3(m0$ailIji`$TdRcSXj+1 VIKF%U96YmKLA&J8L,#f0H@R)qUkGBi$F0QZhek3GAkG4GD'D+VZAj+-`cM5jGhi CfkMXjL4e'&Ra4HT!YFpHf8rr(BmRf"mrT)3,QR+LYEPCU#1-"Uj`pCh9Vfk0Vk- GpqRJXjqqJA3(Td0+J`p3i"HlaJP3[l[ek,J4cUl@&NdPBQYN#Je9!kI@rF!qX2m "clB!!!: -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Not speaking for the Microsoft Corporation. --------------------------- >From emmayche@apple.com (Mark Hartman) Subject: [Q] How to do non-bypassable INIT? Date: 11 Aug 1994 17:36:33 -0700 Organization: Apple Computer Inc, Cupertino, CA For security reasons, I need to have an INIT loaded/run at startup whether or not the Shift key is held down. I know that some of the Apple-supplied goodies do this; does anyone know what the rules are for what gets loaded anyway if Shift is held down? -- ======================================================================= The above is not guaranteed to be the opinions of anyone in particular. ======================================================================= Mark Hartman, N6BMO | E-mail: emmayche@apple.com | AOL: emmayche Macophile | Serious Disney enthusiast | CIS: 75130,1434 +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Fri, 12 Aug 1994 10:55:34 +0800 Organization: Department of Computer Science, The University of Western Australia In article <32eg6h$edh@apple.com>, emmayche@apple.com (Mark Hartman) wrote: >For security reasons, I need to have an INIT loaded/run at startup whether or >not the Shift key is held down. I know that some of the Apple-supplied >goodies do this; does anyone know what the rules are for what gets loaded >anyway if Shift is held down? The only one I know of is System 7 Tuner, which installs an INIT in the system file that specifically opens, load and runs the tuna regardless of whether the shift key is down. Another possible solution is to disable the shift key by deleting the 'dbex' resource in the system file. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From radixinc@aol.com (RadixInc) Date: 12 Aug 1994 01:42:00 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <32eg6h$edh@apple.com>, emmayche@apple.com (Mark Hartman) writes: "For security reasons, I need to have an INIT loaded/run at startup whether or not the Shift key is held down. I know that some of the Apple-supplied goodies do this; does anyone know what the rules are for what gets loaded anyway if Shift is held down?" There is a new INIT type that is loaded regardless of the shift key. Look at one of the ones that always loads. I think the file type needs to be 'scri', and other than that it's the same (INIT resource, etc.). I haven't tested this though, so check it out yourself. I hope you aren't writing a virus or something obnoxious... Gregory Jorgensen Radix Consulting Inc. +++++++++++++++++++++++++++ >From dlb@netcom.com (David Beauchesne) Date: Fri, 19 Aug 1994 02:52:08 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) > There is a new INIT type that is loaded regardless of the shift key. Look > at one of the ones that always loads. I think the file type needs to be > 'scri', and other than that it's the same (INIT resource, etc.). I haven't > tested this though, so check it out yourself. This is correct. Type 'scri' is used by Apple to load different scripts (languages). They are treated, (and coded), just like 'INIT's, but their loading cannot be stopped with the shift key. -- David L. Beauchesne dlb@netcom.com Santa Cruz, California, USA --------------------------- >From khurram@bga.com (Khurram Qureshi) Subject: malloc problem in CW-4 Date: 21 Aug 1994 15:49:55 -0500 Organization: Real/Time Communications - Bob Gustwick and Associates There is a problem with malloc/realloc problem which exists in CW/4. Typically this surfaces when performing continuous memory allocations (inside a for loop for example). This will be fixed as soon as possible. Thanks. ============================== Khurram Qureshi Metrowerks Technical Support e-mail: khurram@bga.com ============================== --------------------------- End of C.S.M.P. Digest **********************