ftp.mactech.com 2010/ftp.mactech.com.tar/ftp.mactech.com/csmpdigest/csmp-digest-v3-053

Text File | 2010-09-21 | 82KB | 2,282 lines

Received-Date: Mon, 5 Sep 1994 15:28:31 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-053
To: [e-mail]
Date: Mon, 5 Sep 1994 15:28:25 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 58

--------------------
Archive.sit    2K
Archive.sit    2K
--------------------

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
([e-mail]).

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 [e-mail] 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 [e-mail]
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
[e-mail]. 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 [e-mail] ( 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.

<Picard> "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?"

<Geordi> "Yes, Captain.  In fact, we found the answer by
searching through our archives on late twentieth-century
computing technology."

<Geordi presses a key, and a logo appears on the computer
screen.>

<Riker looks puzzled.> "What the hell is 'Microsoft'?"

<Data turns to answer.> "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."

<Picard> "But the Borg have the ability to adapt.  Won't
they alter their processing systems to increase their storage
capacity?"

<Data> "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."

<Picard> "Excellent work.  This is even better than that
'unsolvable geometric shape' idea."

<. . . 15 minutes later . . .>

<Data> "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.'"

<Geordi> "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."

<Picard> "Data, scan the history books again and determine
if there is something we have missed."

<Data> "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.'"

<Riker>  "Captain, we have no choice.  Requesting
permission to begin emergency escape sequence 3F . . ."

<Geordi, excited>  "Wait, Captain, I just detected that their
CPU capacity has suddenly dropped to 0%!"

<Picard> "Data, what do your scanners show?"

<Data> "Apparently the Borg have found the internal
'Windows' module named 'solitaire' and it has used up all
the CPU capacity."

<Picard> "Let's wait and see how long this 'solitaire' can
reduce their functionality."

<. . . Two hours pass . . .>

<Riker> "Geordi, what's the status of the Borg?"

<Geordi> "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.'"

<Picard> "How much time will that buy us?"

<Data> "Current Borg solution rates allow me to predict an
interest time span of 6 more hours."

<Geordi> "Captain, another vessel has entered our sector."

<Picard> "Identify."

<Data> "It appears to have markings similar to the
'Microsoft' logo."

<Over the speakers> "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."

<Data> "The alien ship has just opened its forward hatches
and released thousands of humanoid shaped objects."

<Picard> "Magnify forward viewer on the alien craft."

<Riker> "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?!"

<Data> "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."

<Riker and Picard together horrified> "Lawyers!!"

<Geordi> "It can't be.  All the lawyers were rounded up and
sent hurtling into the sun in 2017 during the great awaken-
ing."

<Data> "True, but apparently some must have survived."

<Riker> "They have surrounded the Borg ship and are
covering it with all types of papers."

<Data> "I believe that is known in ancient vernacular as 'red
tape.'  It often proves fatal.

<Riker> "They're tearing the Borg to pieces!"

<Picard> "Turn off the monitors.  I can't stand to watch.  Not
even the Borg deserve that."



  Disclaimer: Just my opinion.
                                    _/   _/  _/  _/_/_/   _/   _/
     Interet: [e-mail]        _/_/ _/  _/  _/   _/  _/_/_/
      eWorld: nick                _/ _/_/  _/  _/       _/ _/
         CIS: 71232,766          _/   _/  _/   _/_/_/  _/   _/

           "Science is nothing but perception" - Plato

---------------------------

>From [e-mail] (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: [e-mail]      |                              |
+==============================|==============================+

+++++++++++++++++++++++++++

>From [e-mail] (D.A. McLeod)
Date: 22 Aug 1994 13:32:42 GMT
Organization: Health Canada

Hartmut Kocher US/ESA 60/1L/2? #5629 ([e-mail]) 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 [e-mail] (Michael Engelhart)
Date: 22 Aug 1994 15:38:09 GMT
Organization: Apple Travel

In article <[e-mail]>,
[e-mail] (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: [e-mail]      |                              |
> +==============================|==============================+


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 [e-mail] (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                       [e-mail]
Emerald Intelligence / University of Michigan

+++++++++++++++++++++++++++

>From [e-mail] (MW Ron)
Date: 19 Aug 1994 19:44:06 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <333aak$[e-mail]>, [e-mail]
(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
[e-mail]
Metrowerks Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Matthias Neeracher)
Date: 19 Aug 1994 23:19:32 GMT
Organization: Swiss Federal Institute of Technology (ETHZ)

[e-mail] (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 <[e-mail]> 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 [e-mail] (Pete Gontier)
Date: Fri, 19 Aug 1994 20:17:34 -0800
Organization: Integer Poet Software

In article <333aak$[e-mail]>, [e-mail]
(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 // [e-mail]

 "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." -- [e-mail], in Wired 2.09 p62

+++++++++++++++++++++++++++

>From [e-mail] (MW Ron)
Date: 20 Aug 1994 12:20:01 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail]
(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
[e-mail]
Metrowerks Inc.

#include <iostream>

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 [e-mail] (Harold Ekstrom)
Date: Sat, 20 Aug 1994 20:45:15 -0800
Organization: Ag Group

In article <333g46$[e-mail]>, [e-mail] (MW Ron) wrote:

> In article <333aak$[e-mail]>, [e-mail]
> (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
> [e-mail]
> 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
[e-mail]
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 [e-mail] (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:    <pad>
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 <pad> 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 <[e-mail]>, [e-mail] (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 [e-mail] (Denizen of the Deep)
Date: 17 Aug 1994 16:22:16 GMT
Organization: Computer Science Department, Stanford University.

In article <[e-mail]>,
Marshall Clow <mclow@san_marcos.csusm.edu> 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 [e-mail] (Lars Farm)
Date: Fri, 19 Aug 1994 10:08:12 +0100
Organization: Mid Sweden University

In article <32tdfo$[e-mail]>, [e-mail]
(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

--
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail] (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 <[e-mail]>
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: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Sat, 20 Aug 1994 23:05:30 -0700
Organization: Infinity Systems

In article <[e-mail]>, redial <[e-mail]> 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 [e-mail]___//
  //    //      Infinity Systems                                  //
 //    //  //  Redmond, Washington                               //
//    //////____________________________________________________//

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Sun, 21 Aug 1994 13:28:06 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
redial <[e-mail]> 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 ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
    Not speaking for IBM.


---------------------------

>From Felix Ungman <[e-mail]>
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 <DebugNew.h>
#define new NEW

Works great in most cases.

+++++++++++++++++++++++++++

>From [e-mail] (Dan Podwall)
Date: Mon, 22 Aug 1994 15:26:57 GMT
Organization: Metrowerks, Inc.

Felix Ungman ([e-mail]) 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 [e-mail] (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 <[e-mail]> - Macintosh TCP fingerpainter

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Sun, 21 Aug 1994 15:00:50 -0500
Organization: One Step Beyond

[e-mail] (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          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (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
--
[e-mail]   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 [e-mail] (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 [e-mail] (Dana Cartwright 3rd)
Date: 3 Aug 1994 12:23:13 GMT
Organization: Syracuse University, Syracuse NY, USA

Ola Montan ([e-mail]) 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 [e-mail] (John Nagle)
Date: Wed, 3 Aug 1994 16:38:21 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (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 [e-mail] (Jon W{tte)
Date: Wed, 03 Aug 1994 19:35:33 +0200
Organization: Royal Institute of Something or other

In article <31o27h$[e-mail]>,
 [e-mail] (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 [e-mail] (Brian L. Matthews)
Date: 3 Aug 1994 17:28:09 GMT
Organization: Northwest Nexus Inc.

In article <[e-mail]>,
Ola Montan <[e-mail]> 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 [e-mail] (William Edward Woody)
Date: 3 Aug 1994 20:32:35 GMT
Organization: California Institute of Technology, Alumni Association

In article <[e-mail]>,
Ola Montan <[e-mail]> 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:
  [e-mail]             | "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 [e-mail] (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... <grin>


+++++++++++++++++++++++++++

>From [e-mail] (Preston Marshall)
Date: 3 Aug 1994 18:09:24 GMT
Organization: Vanguard Research, Inc.

> Ola Montan ([e-mail]) 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           -       [e-mail]        |
|     Vanguard Research, Inc.    -                                |
|     10306 Eaton Pl.            -       The opinions are mine,   |
|     Farifax, Va 22111          -       my employer doesn't care |
___________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Thu, 04 Aug 1994 11:00:59 +0200
Organization: Royal Institute of Something or other

In article <31out3$[e-mail]>,
 [e-mail] (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 [e-mail] (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
_/_/_/_/   [e-mail]                          -
How can one expect to program without buying a single IM?

+++++++++++++++++++++++++++

>From Jeff Abrahamson <[e-mail]>
Date: Thu, 04 Aug 94 10:20:40 -0500
Organization: Purple


In article <31ok39$[e-mail]>, 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 [e-mail] (Kevin R. Boyce)
Date: Thu, 04 Aug 1994 13:24:23 -0400
Organization: NASA/GSFC

In article <[e-mail]>,
 clio![e-mail] wrote:

>In article <31ok39$[e-mail]>, 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      [e-mail]
Goodbye Clipper chip, hello asteroid Zappa.  Is this a great country or what?

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Thu, 4 Aug 1994 19:08:29 GMT
Organization: PRZ TU-Berlin

[e-mail] (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
[e-mail]   | Modernen hoerten, was wuerden sie tun, was
Process Control Center      | wuerden sie sagen!
Technical University Berlin |               -- Jacobus von Luettich (ca. 1330)

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 3 Aug 1994 20:34:58 GMT
Organization: Apple Computer

Jon W{tte, [e-mail] 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                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 4 Aug 1994 20:34:16 GMT
Organization: Apple Computer

Jeff Abrahamson, [e-mail] 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                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Fri, 5 Aug 1994 09:25:45 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
joe zobkiw <[e-mail]> 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                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Fri, 5 Aug 1994 09:40:14 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Ari I Halberstadt <[e-mail]> 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                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Aaron Giles)
Date: Fri, 05 Aug 1994 13:36:13 -0400
Organization: Cornell University Medical College

In article <[e-mail]>, Jens Alfke
<[e-mail]> wrote:

> Jon W{tte, [e-mail] 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 ([e-mail])
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 [e-mail] (Pete Gontier)
Date: Fri, 05 Aug 1994 11:02:43 -0800
Organization: Integer Poet Software

In article <[e-mail]>,
[e-mail] (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 // [e-mail]

 "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 [e-mail] (Bill Hofmann)
Date: Fri, 5 Aug 1994 18:04:16 GMT
Organization: Fresh Software

In article <[e-mail]>, [e-mail] (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                                   [e-mail]
Fresh Software and Instructional Design        voice: [phone]
1640 San Pablo Ave #C, Berkeley CA 94702 USA   fax:   [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Bill Hofmann)
Date: Fri, 5 Aug 1994 18:16:35 GMT
Organization: Fresh Software

In article <[e-mail]>, [e-mail] (John Nagle) wrote:
> [e-mail] (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                                   [e-mail]
Fresh Software and Instructional Design        voice: [phone]
1640 San Pablo Ave #C, Berkeley CA 94702 USA   fax:   [phone]

+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail] (Mason Bliss)
Date: Wed, 10 Aug 1994 02:41:11 GMT
Organization: University of Massachusetts Dartmouth

In <[e-mail]> [e-mail] (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  -  [e-mail]  -  [e-mail]
 "What diabolical chicken stepped on your forehead and sat on your chin?"

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 09 Aug 1994 20:19:53 -0800
Organization: Integer Poet Software

In article <[e-mail]>, [e-mail] (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 // [e-mail]

 "I am Homer of Borg! Prepare to be... Ooooooo! Donuts!"

+++++++++++++++++++++++++++

>From [e-mail] (Alexander M. Rosenberg)
Date: Wed, 10 Aug 1994 19:06:51 GMT
Organization: Hackers Anonymous

In article <[e-mail]>, [e-mail]
(Pete Gontier) wrote:

> In article <[e-mail]>, [e-mail] (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: [e-mail]      - Yoyodyne    -
-  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr        - Propulsion  -
-  Palo Alto, CA 94301     -                                - Systems     -
-  [phone]          - Nobody is my employer so       - :-)         -
-  [phone]          - nobody cares what I say.       -             -

+++++++++++++++++++++++++++

>From [e-mail] (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 <[e-mail]> [e-mail] (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 [e-mail] (Ingemar Ragnemalm)
Date: 19 Aug 1994 21:27:13 GMT
Organization: (none)

[e-mail] (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: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (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$[e-mail]>, [e-mail] (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!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (Marc T. Kaufman)
Date: 22 Aug 1994 03:08:30 GMT
Organization: Computer Science Department, Stanford University.

In article <[e-mail]>,
Quinn "The Eskimo!" <[e-mail]> wrote:
>In article <33383h$[e-mail]>, [e-mail] (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 [e-mail] (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...)



--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

"TextEdit does everything right."
    ã Jon W{tte


+++++++++++++++++++++++++++

>From [e-mail] (Tom Emerson)
Date: Sat, 20 Aug 1994 17:15:43 -0800
Organization: Symantec Development Tools Group

In article <[e-mail]>, [e-mail] (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
                          [e-mail]
  "I dreamed I had to take a test, in a Dairy Queen, on another planet."

+++++++++++++++++++++++++++

>From [e-mail] (Steve Poole)
Date: Mon, 22 Aug 1994 10:59:25 -0800
Organization: Walker Richer & Quinn

In article <tree-2008941715430001@155.64.60.21>, [e-mail]
(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: [e-mail]  -  AOL: Spoole  -  INTEL 80x86: Just say NOP -
- "Nurse! Do let's pretend that I'm a hungry hyaena, and you're a bone!" -
- ------------------------------------------------------------------------

---------------------------

>From [e-mail] (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




--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
    Not speaking for the Microsoft Corporation.


---------------------------

>From [e-mail] (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:  [e-mail] | AOL: emmayche
      Macophile     |  Serious Disney enthusiast  | CIS: 75130,1434

+++++++++++++++++++++++++++

>From [e-mail] (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$[e-mail]>, [e-mail] (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!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

>From [e-mail] (RadixInc)
Date: 12 Aug 1994 01:42:00 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <32eg6h$[e-mail]>, [e-mail] (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 [e-mail] (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                                    [e-mail]
Santa Cruz, California, USA

---------------------------

>From [e-mail] (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: [e-mail]
==============================

---------------------------

End of C.S.M.P. Digest
**********************