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

Text File | 2010-09-21 | 139KB | 3,817 lines

Received-Date: Thu, 1 Sep 1994 14:34:02 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-052
To: [e-mail]
Date: Thu, 1 Sep 1994 14:33:55 +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: 57

C.S.M.P. Digest             Thu, 01 Sep 94       Volume 3 : Issue 52

Today's Topics:

        A Note for SC++ newbies
        Adobe Photoshop Plug-ins.
        Advanced QuickTime 1.6.1 Question
        AppleEvents during ModalDialog?
        Background always app that cannot be switched to by user?
        Book recommendations for new Mac programmer?
        CodeWarrior WWW Support Service
        Control Strip docs?
        Copying graphics without QuickDraw: custom blitting code
        Debugging on PowerMacs
        Guide for writing programs for both PowerPC and 680x0? etc...
        HFSDispatch Trap. Success
        MPW PPCC funnies ...
        Opening the Apple CD ROM Tray.
        PPC CDK User Comments
        Problem with FSRead-WriteNoCache
        Talking to the network (TCP) -- how?
        What fonts are always available?
        [Q] Universal Headers
        best c++ book...
        testing if a sound is done



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] (Pete Figliozzi)
Subject: A Note for SC++ newbies
Date: 31 Jul 94 12:45:01 -0400
Organization: The Ohio State University, Department of Physics


I would like to point something out to SC++ newcomers:

If your source filename ends with .c, it gets compiled with the regular C
compilier.  If you turn "Think C Object Extensions" on, then your .c source
file can use all of the old Think C almost-C++ stuff.

If your source filename ends with .cp or .cpp, it gets compiled with the
real C++ compiler.

In other words, if all of the sudden the compiler is choking on "class xxx"
statements, make sure the source file has the .cp or .cpp extension.  This
just about drove me out of my mind yesterday, until I finally figured out what
the problem was!

Pete

[e-mail]


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

>From [e-mail] (Ed Estes)
Subject: Adobe Photoshop Plug-ins.
Date: 15 Aug 1994 14:01:06 -0500
Organization: (none)

Greetings.

I am interested in writing a few plug-ins for Adobe Photoshop.  Where might I
find the appropriate docs/hooks in order to do so?  I see that Adobe has an
"Adobe Developer's Association" and I'm hoping I don't have to join in order
to get this information.  I spent close to an hour navigating through their
voice-mail and never found the answers I needed.  The FAX I received
regarding the ADA seemed to be geared more towards font developers and people
who need serious phone support.  We've got several copies of Photoshop here
at the office and I'd just like to write a few simple things to help the
designers.  I don't need any support or advance technical docs, so I'm hoping
I won't have to pay the $195+ to join ADA.  We've already spent thousands on
the software and joining it would be an overkill for my purposes.

TAI for your input.

--Ed


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

>From [e-mail] (halstej)
Date: 15 Aug 1994 22:09:46 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Ed Estes) writes:
> I am interested in writing a few plug-ins for Adobe Photoshop.  Where might I
> find the appropriate docs/hooks in order to do so?  I see that Adobe has an

I found this the other day at Info-Mac.  It WASN'T in the developers
directory, believe it or not.  Here's the whole path:

sumex-aim.stanford.edu   /info-mac/Graphic/util/photoshop-kit.hqx

Hope that fixes you up.

-Jerry


p.s. Public praise to Peter Lewis for Anarchie: this is an awesome
program!
     (including the drag manager support in the latest version)

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

>From [e-mail] (MacneilS)
Subject: Advanced QuickTime 1.6.1 Question
Date: 29 Jul 1994 22:48:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

I don't know how advanced you have to be to answer this question, but I've
been RTFMing QuickTime Components and Tech Notes for the answer and still
haven't found it. Here it goes: Does anybody know how I can access the
CopyBits() like function embedded in QuickTime? I've heard that QuickTim
uses it's own version for speed's sake. Also would the dithering  be a
part of that function? You see: I'm making a game that I want to work in
both 16 grays as well as 256 colors. CopyBits()ing from the 8-Bit GWorld
to the 4-Bit window is just too slow (especially if I use ditherCopy
instead of srcCopy). And it would take too long to re-write the offscreen
blitting code to support 4-Bit (not even mentioning that I would have to
convert all of the icl8's to 4-Bit when the application is launched
[either that or waste disk space]).

Any help would be appreciated.

Take Care,
[e-mail], The Syzygy Cult


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

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 2 Aug 94 17:41:29 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <31cf12$[e-mail]>, [e-mail] (MacneilS) writes:
> I don't know how advanced you have to be to answer this question, but I've
> been RTFMing QuickTime Components and Tech Notes for the answer and still
> haven't found it. Here it goes: Does anybody know how I can access the
> CopyBits() like function embedded in QuickTime? I've heard that QuickTim
> uses it's own version for speed's sake. Also would the dithering  be a
> part of that function?

Ah, you want to use "fast dithering". Yes, this is possible. The easiest way
is to call the "None" codec. Basically all that does is convert between
different bit depths, including doing fast dithering.

You have to set up to invoke the codec via a DecompressImage call. This needs
a pointer to the "compressed" data; pass a 32-bit-clean pointer to your
offscreen pixels. It also wants a handle to an ImageDescription record: you
need to fake one. One important thing to remember is that the width field
of the ImageDescription needs to be computed from the rowBytes field of your
PixMap, not the bounds width; this is because the "compressed" pixels are
assumed not to have any rowBytes padding.

Here's some example code I wrote a while ago to deal with all this. I must
admit I didn't test all the cases to make sure they work, so you might want
to use this with care. The code takes SrcBits as a pointer to a BitMap, only
it might be a part of a PixMap or CGrafPort (as with CopyBits):

    SrcPix := NIL; (* default *)
    SrcPixMap := NIL; (* ditto *)
    IF BitTestPtr(7, ADR(SrcBits^.rowBytes)) THEN
    IF BitTestPtr(6, ADR(SrcBits^.rowBytes)) THEN
      (* it's a CGrafPort *)
        SrcPixMap := CAST(PixMapHandle, SrcBits^.baseAddr);
        SrcPix := SrcPixMap^; (* for SrcWidth calculation *)
        PixData := GetPixBaseAddr(SrcPixMap);
        SrcRect := SrcPixMap^^.bounds (* default *)
    ELSE
      (* pointer into pixmap -- should I try using GetPixBaseAddr here too? *)
        SrcPix := CAST(PixMapPtr, SrcBits);
        PixData := SrcPix^.baseAddr;
        SrcRect := SrcPix^.bounds (* default *)
    END (*IF*);
    SrcWidth := BAndWS(SrcPix^.rowBytes, 03FFFH) * 8 DIV SrcPix^.pixelSize
    ELSE
      (* b&w bitmap *)
    PixData := SrcBits^.baseAddr;
    SrcRect := SrcBits^.bounds; (* default *)
    SrcWidth := SrcBits^.rowBytes * 8
    END (*IF*);
    SrcOrigin := SrcRect.topLeft;
    Desc := NewHandleClear(SIZE(ImageDescription));
    Desc^^.idSize := SIZE(ImageDescription);
    Desc^^.cType := 072617720H (* 'raw ' *);
    Desc^^.resvd1 := 0;
    Desc^^.resvd2 := 0;
    Desc^^.dataRefIndex := 0;
    Desc^^.version := 0;
    Desc^^.revisionLevel := 0;
    Desc^^.vendor := 0;
    Desc^^.temporalQuality := ImageCompression.codecMinQuality;
    Desc^^.spatialQuality := ImageCompression.codecNormalQuality;
    Desc^^.width := SrcWidth;
    Desc^^.height := SrcRect.bottom - SrcRect.top;
    Desc^^.hRes := 000480000H;
    Desc^^.vRes := 000480000H;
    Desc^^.dataSize := 0;
    Desc^^.frameCount := 1;
  (* Desc^^.name -- skip *)
    IF SrcPixMap <> NIL THEN
    SrcPix := SrcPixMap^ (* refresh pointer *)
    END (*IF*);
    IF SrcPix = NIL THEN
      (* b&w bitmap *)
    Desc^^.depth := 1;
    Desc^^.clutID := 1
    ELSE
    CASE SrcPix^.pixelSize OF
    | 1, 2, 4, 8:
        Desc^^.depth := SrcPix^.pixelSize;
        IF (SrcPix^.pmTable^^.ctSeed > 0) AND (SrcPix^.pmTable^^.ctSeed < 128) THEN
          (* standard CLUT *)
        Desc^^.clutID := SrcPix^.pmTable^^.ctSeed;
        IF (SrcPix^.pmTable^^.ctSeed > 32) AND (SrcPix^.pmTable^^.ctSeed < 64) THEN
          (* greyscale image *)
            Desc^^.depth := Desc^^.depth + 32
        END (*IF*)
        ELSE
          (* custom CLUT *)
        Err := SetImageDescriptionCTable(Desc, SrcPix^.pmTable);
        IF Err <> noErr THEN
            Debugger
        END (*IF*)
        END (*IF*)
    | 16, 32:
        Desc^^.depth := SrcPix^.pixelSize;
        Desc^^.clutID := -1
    END (*CASE*)
    END (*IF*);

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

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

>From [e-mail] (Bob Bradley)
Subject: AppleEvents during ModalDialog?
Date: Mon, 25 Jul 1994 06:46:28 -0800
Organization: SS Software Inc.

How are AppleEvent handles while a ModalDialog is up? Are they queued
until the dialog is gone or are they just ignored and forgotten?

I've looked at the NewsWatcher source and with it's MyMovableModalDialog
routine, it just masks out AppleEvents. Is this what ModalDialog does?

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

>From [e-mail] (Bob Bradley)
Date: Mon, 25 Jul 1994 15:26:00 -0800
Organization: SS Software Inc.

In article <[e-mail]>, [e-mail] (Jon
Wdtte) wrote:

> You can't mask AppleEvents; when you call WaitNextEvent, you
> can receive AppleEvents. You have to write a ModalFilterProc that
> is prepared to handle AppleEvents.

This is what is in the NewsWatcher Source:

WaitNextEvent(everyEvent & ~highLevelEventMask, &ev, 0, nil);

Is this not masking out high level events (AppleEvents)? I'm not being
sarcastic, I've honestly never seen the ~ character used and don't know
what it does. I just thought, by the way it was used above that it masked
out high level events.

The problem for me with writing support for AppleEvents in my Filter Proc
is that when I get an OpenDocument AppleEvent, I put up a ModalDialog for
the user to setup the operation on the file and if someone was sending me
OpenDocument AppleEvents while that a dialog was up, I'd get ModalDialogs
popping up on top of each other.

The only way I can think of getting around this is to queue AppleEvents
similar to how DragonSmith queues them.

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

>From [e-mail] (bgsuvax)
Date: 26 Jul 1994 13:20:44 GMT
Organization: Bowling Green State University

[e-mail] (Jon Wdtte) writes:
> In article <[e-mail]>,
>  [e-mail] (Bob Bradley) wrote:
>
>>I've looked at the NewsWatcher source and with it's MyMovableModalDialog
>>routine, it just masks out AppleEvents. Is this what ModalDialog does?
>
> You can't mask AppleEvents; when you call WaitNextEvent, you
> can receive AppleEvents. You have to write a ModalFilterProc that
> is prepared to handle AppleEvents.

  Hmm, I haven't given this much thought before.  Would it be
simpler to have the modal filter proc re-post the event so the
main event loop can handle it later?

Dave

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>

             *THE* alt.sources.mac supporter!


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

>From [e-mail] (Daniel Azuma)
Date: Tue, 26 Jul 1994 07:37:32 -0700
Organization: California Institute of Technology

[e-mail] (Bob Bradley) wrote:

> How are AppleEvent handles while a ModalDialog is up? Are they queued
> until the dialog is gone or are they just ignored and forgotten?

Even if, as Jon Watte says, you can't mask out AppleEvents, I think you
can keep them there in the queue by just NOT calling AcceptHighLevelEvent
or AEProcessAppleEvent.

[e-mail] (bgsuvax) wrote:

>   Hmm, I haven't given this much thought before.  Would it be
> simpler to have the modal filter proc re-post the event so the
> main event loop can handle it later?

I'd suspect that isn't such a good idea, seeing that the AppleEvent
manager automatically dispatches AppleEvents you send to yourself, without
putting them through the event queue. You'd have to disable that
mechanism, or manually try to send them as high-level events (which is
hairy).

--Dan

- ----------------------------------------------------------------
  Daniel Azuma            | "Rejoice in the Lord always; again I
  Caltech                 |  will say, Rejoice..."
  [e-mail]  |              --Philippians 4:4
- ----------------------------------------------------------------

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

>From Jens Alfke <[e-mail]>
Date: Tue, 26 Jul 1994 21:05:24 GMT
Organization: Apple Computer

Bob Bradley, [e-mail] writes:
> The problem for me with writing support for AppleEvents in my Filter Proc
> is that when I get an OpenDocument AppleEvent, I put up a ModalDialog for
> the user to setup the operation on the file and if someone was sending me
> OpenDocument AppleEvents while that a dialog was up, I'd get ModalDialogs
> popping up on top of each other.

(1) You should allow the parameters to opening the file to be specified in
the Apple event as optional parameters, so that the entire action can be
driven by a script without user interaction.

(2) If handling an Apple event requires user interaction like a dialog, and
this can't be done (like because another dialog is up) your AE handler should
return the error code errAENoInteractionAllowed (I'm not sure about the exact
spelling; look in <AppleEvents.h>.)

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

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

>From [e-mail] (Quinn "The Eskimo!")
Date: Wed, 27 Jul 1994 11:33:46 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, [e-mail] (Jon
Wdtte) wrote:

>You can't mask AppleEvents; when you call WaitNextEvent, you
>can receive AppleEvents. You have to write a ModalFilterProc that
>is prepared to handle AppleEvents.

Or don't use ModalDialog.  The best way to do this is to bring up the
dialog as the front window and then return to your application's main
event loop, which detects the modal front window and refuses to activate
any other windows.  This is the way MacApp and TCL do it.

btw The number of applications that *actually* support AppleEvents while
modal dialogs are up is vanishingly small ):
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

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

>From [e-mail] (Jonas Wallden)
Date: 27 Jul 1994 08:55:08 GMT
Organization: (none)

[e-mail] (Quinn "The Eskimo!") writes:

>btw The number of applications that *actually* support AppleEvents while
>modal dialogs are up is vanishingly small ):

Hehe. I've written one (PowerScan), but can you say Thread Manager... It is
possible to open e.g. the Preferences dialog, switch to the Finder, and drag &
drop a folder/volume to the application icon!

-- Jonas Wallden
--
-- Jonas Wallden -- Internet: [e-mail] -- AppleLink: sw1369 --

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

>From [e-mail] (Quinn "The Eskimo!")
Date: Thu, 28 Jul 1994 10:40:42 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <3157dc$[e-mail]>, [e-mail] (Jonas
Wallden) wrote:

>[e-mail] (Quinn "The Eskimo!") writes:
>
>>btw The number of applications that *actually* support AppleEvents while
>>modal dialogs are up is vanishingly small ):
>
>Hehe. I've written one (PowerScan), but can you say Thread Manager...

Well my officemate has written one too but it doesn't need threads to do it!
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  My fully scriptable, recordable and attachable application is better
  than your fully scriptable, recordable and attachable application.
  [na na na-na na!]

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

>From [e-mail] (Bob Bradley)
Date: Sat, 30 Jul 1994 16:44:39 -0800
Organization: SS Software Inc.

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

> (1) You should allow the parameters to opening the file to be specified in
> the Apple event as optional parameters, so that the entire action can be
> driven by a script without user interaction.

I'm not sure if the action should actually be done like an Open event or
not. I do it now but, what my app does is rename files and my end goal
would to make the application almost totally driven by scripts (no app
interaction by the user at all) but, I'm not sure if I should create a new
type of AppleEvent (RenameEvent?) or just use the standard OpenDocument
event with special parameters. What do you think?

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

>From [e-mail] (Gavin Picknell)
Subject: Background always app that cannot be switched to by user?
Date: 11 Aug 1994 00:29:37 GMT
Organization: University of Auckland

Is there anyway to code an app under system 7 so that it does not appear in
the finders "switch to menu", doesnt appear in the "about this macintosh"
dialouge, and just sits in the background doing it's own thing
whenever it gets time passed to it?

Assuming of course that its already been set up with no user interface and
knows what it should be doing and requires no interaction.

Cheers.

[e-mail]

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

>From [e-mail] (Robert Mah)
Date: Thu, 11 Aug 1994 03:59:59 -0500
Organization: One Step Beyond

[e-mail] (Gavin Picknell) wrote:

) Is there anyway to code an app under system 7 so that it does not appear in
) the finders "switch to menu", doesnt appear in the "about this macintosh"
) dialouge, and just sits in the background doing it's own thing
) whenever it gets time passed to it?
)
) Assuming of course that its already been set up with no user interface and
) knows what it should be doing and requires no interaction.


Basically, all you want to do is minimal toolbox initialization (just
_InitGraf and maybe _InitFonts) and then go to your event loop.

In your event loop, since you have no user interface, and the app can't be
switched in/out, the only events you have to handle are kHighLevelEvent's
and idle events.  Simply dispatch on the AppleEvents as they come in to do
your stuff.

Don't forget to set the "background only" bit in the 'SIZE' resource and
change the file type to 'appe' if you want it to behave like an extension
from the user's point of view.

The code is rather simple...

void main()
{
    EventRecord evt;

    InitGraf( &qd.thePort );
    InstallAppleEvents();       // install 'oapp', 'quit' and
                                // dummy 'odoc'/'pdoc' handlers
    DoOtherInits();

    while( ! gAllDone ){
        WaitNextEvent( everyEvent, &evt, sleepTime, NULL );
        if( evt.what == kHighLevelEvent )
            AEProcessAppleEvent( &evt );
        else
            DoIdle();
    }
    ExitToShell();
}


Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

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

>From [e-mail] (Jim Sokoloff)
Date: Thu, 11 Aug 1994 12:57:45 GMT
Organization: MV Communications, Inc.

In article <32brdh$[e-mail]>,
Gavin Picknell <[e-mail]> wrote:
>Is there anyway to code an app under system 7 so that it does not appear in
>the finders "switch to menu", doesnt appear in the "about this macintosh"
>dialouge, and just sits in the background doing it's own thing
>whenever it gets time passed to it?
>
>Assuming of course that its already been set up with no user interface and
>knows what it should be doing and requires no interaction.
>
>Cheers.
>
>[e-mail]

Sure there is. In the SIZE resource, set the background only bit.
I used to think that you had to change the file type to appe, but I
don't think that is necessary...

- -Jim


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

>From Matt Slot <[e-mail]>
Date: 11 Aug 1994 04:19:04 GMT
Organization: University of Michigan

Gavin Picknell, [e-mail] writes:
 > Is there anyway to code an app under system 7 so that it does not appear in
 > the finders "switch to menu", doesnt appear in the "about this macintosh"
 > dialouge, and just sits in the background doing it's own thing
 > whenever it gets time passed to it?

You need to set the "Background Only" bit in your app's SIZE flags
(typically the same place you set Type/Creator/MemSize). Such "programs"
have File Type of "appe", not "APPL" -- and is treated as an extension.
This will keep your program from being switch to, out of the Applications
menu, but not out of the "About the Finder" and other memory utils.

Matt

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

>From [e-mail] (Mats Bredell)
Date: Sat, 13 Aug 1994 20:38:22 +0200
Organization: UDAC

In article <32c8ro$[e-mail]>, Matt Slot
<[e-mail]> wrote:

> Gavin Picknell, [e-mail] writes:
>  > Is there anyway to code an app under system 7 so that it does not appear in
>  > the finders "switch to menu", doesnt appear in the "about this macintosh"
>  > dialouge, and just sits in the background doing it's own thing
>  > whenever it gets time passed to it?
>
> You need to set the "Background Only" bit in your app's SIZE flags
> (typically the same place you set Type/Creator/MemSize). Such "programs"
> have File Type of "appe", not "APPL" -- and is treated as an extension.
> This will keep your program from being switch to, out of the Applications
> menu, but not out of the "About the Finder" and other memory utils.

They can also have type "APPL", which makes it possible to start them by
double clicking by the user. It still doesn't have any user interface, so
the application will simply "disappear" into the system which might
confuse the user. "appe" is useful if the application should always be run
at startup, while "APPL" can be used if the user is supposed to start the
background application.

/Mats

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

>From [e-mail] (Matt Kimmel)
Subject: Book recommendations for new Mac programmer?
Date: 15 Aug 1994 14:54:47 GMT
Organization: University of Massachusetts, Amherst MA


Hi,

I just bought a Mac system and a copy of Metrowerks CodeWarrior, and I'd
like to start to learn how to write Mac apps in C and/or C++.  Can anybody
recommend a good book to get me started?  I am very familiar with C and
C++ and with other GUIs; however, I have no experience with the Mac toolbox
or with CodeWarrior.

Any recommendations would be most appreciated.

Thanks!
-Matt
--
Matt Kimmel                                   Associate Software Specialist
Department of Computer Science, LGRC A313             Phone: [phone]
University of Massachusetts                             Fax: [phone]
Amherst, MA  01003                              E-mail: [e-mail]

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

>From [e-mail] ( nick.c )
Date: Mon, 15 Aug 94 15:15:29 GMT
Organization: The Pitt, Chemistry

In Article <32nvjn$[e-mail]>, [e-mail] (Matt
Kimmel) wrote:

>I just bought a Mac system and a copy of Metrowerks CodeWarrior, and I'd
>like to start to learn how to write Mac apps in C and/or C++.  Can anybody
>recommend a good book to get me started?  I am very familiar with C and
>C++ and with other GUIs; however, I have no experience with the Mac toolbox
>or with CodeWarrior.


    Here's a list I keep on my HD, take all comments with a grain of
      salt, luck.



Books on Mac Programming
~~~~~~~~~~~~~~~~~~~~~~~~

Learning the Language (C/C++)
=============================

    _Learn C on the Macintosh_ by Dave Mark
      Addison Wesley Publishing

      A good introduction to the C language, includes a limited
      version of Think C 5.0.  Does not cover the toolbox, but
      then you shouldn't be worrying about the toolbox till you
      understand the language

    _Learn C++ on the Macintosh_ by Dave Mark
      Addison Wesley Publishing, 1993 ISBN: 0-201-62204-1

      An introduction to C++, best if you already understand C.
      I'd consider this an unofficial "part 2" to Dave's Learn C
      book.  Includes a limited version of Symantec C++ 6.0.

    _The C Programming Language_ 2nd ed. by Brian Kernighan
      and Dennis Ritchie, Prentice Hall, 1988 ISBN: 0-13-110362-8

      The definitive reference for the C language.  A must have.

    _The C++ Programming Language_ 2nd ed., by Bjarne Stroustrup
      Addison Wesley Publishing, 1991 ISBN: 0-201-53992-6

      As close to a definitive reference for the C++ language as
      exists.  Very important reference, but reads like stereo
      instructions.  Should not be considered an introduction.

Learning the Toolbox
====================

    _Macintosh Programming Techniques_ by Dan Parks Sydow
      M&T Books, 1994 ISBN: 1-55828-326-9

      One of the best introductions to macintosh programming.
      Introduces windows, menus, etc.  Assumes a working knowledge
      of C.  Includes a floppy with all example source code, and
      an electronic tutorial.

    _Macintosh Programming Primer_ by Dave Marks

      Volumes one and two.  A good introduction to macintosh programming,
      and what I started with.  Some folks argue it's a little out of
      date, but I'd still recommend it to anyone starting out.

Learning an Environment
=======================

    _Symantec C++ for the Macintosh: The Basics_ by John May
      & Judy Whittle, M&T Books, 1993 ISBN: 1-55828-276-9

      A good introduction to Symantec's C++ environment, one of the
      best programming environment's for the mac (IMHO).  Reintroduces
      basic C++ concepts and the environment in detail.  Includes
      example source code on enclosed floppy disk.

    _Power Macintosh Programming Starter Kit_ by Tom Thompson
      Hayden Books, 1994 ISBN: 1-56830-091-3

      A good introduction to MetroWerk's CodeWarrior, the other best
      programming environment for the mac, the only one to use if you're
      building PPC code, and my current favorite.  The enclosed CD
      has a limited version of CodeWarrior (you can only work on
      the projects included in the disc - can't create new ones),
      and example code.  Covers a lot of toolbox issues that are
      not explored in other introductory books and the PPC architecture
      in detail.  Assumes working knowledge of C, and the toolbox.



     Interet: [e-mail]         _/   _/  _/  _/_/_/   _/   _/
      eWorld: nick                 _/_/ _/  _/  _/   _/  _/_/_/
         CIS: 71232,766           _/ _/_/  _/  _/       _/ _/
                                 _/   _/  _/   _/_/_/  _/   _/

           "Science is nothing but perception" - Plato


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

>From [e-mail] (Fairgate Technologies)
Subject: CodeWarrior WWW Support Service
Date: 5 Aug 1994 14:26:22 -0500
Organization: Fairgate Technologies

Fairgate Technologies (FT) is pleased to announce the availability of
its WWW server at http://www.iquest.com/~fairgate.

FT specializes in custom software & documentation for the Macintosh.
Because of all the help and useful information we've gotten from the
'net over the years, we're offering our WWW server as a free resource
to the net.community of Macintosh developers.

The server contains useful information for the Macintosh developer,
including the official Metrowerks CodeWarrior WWW support area and an
archive of user-contributed PowerPlant classes. We will be continuing
to expand and improve the server over the next several months, so we
encourage you to visit often and to make suggestions via the provided
suggestion boxes.

Send specific comments or questions to the FT Webmaster at
"[e-mail]". We hope you enjoy our service!

-Paul Robichaux
 Fairgate Technologies

--
Paul Robichaux       Fairgate Technologies         [e-mail]
      Fairgate Technologies does custom Mac development.
    Visit our WWW page at http://www.iquest.com/~fairgate.

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

>From [e-mail]
Subject: Control Strip docs?
Date: Fri, 29 Jul 1994 22:02:09 GMT
Organization: Loughborough University, UK.

Hi there! Does anyone know where documentation about writing control
strip modules for the powerbooks can be found?

Thanks,
       Julian.

[e-mail]


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

>From [e-mail] (Robert Mah)
Date: 30 Jul 1994 19:12:46 GMT
Organization: One Step Beyond

[e-mail] (J.C.Highfield) wrote:

) Hi there! Does anyone know where documentation about writing control
) strip modules for the powerbooks can be found?

It's included as a chapter in the developer's note about the Powerbook
500 series.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

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

>From [e-mail] (bgsuvax)
Date: 30 Jul 1994 20:45:53 GMT
Organization: Bowling Green State University

[e-mail] writes:
> Hi there! Does anyone know where documentation about writing control
> strip modules for the powerbooks can be found?
>
> Thanks,
>        Julian.
>
> [e-mail]
>

  The header files for doing so can be found in the alt.sources.mac
archive at ftpbio.bgsu.edu (129.1.252.66) in the
/ftp/pub/alt.sources.mac/snippets-v02/controlstrip.h.

Dave

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>

             *THE* alt.sources.mac supporter!

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

>From Tony Andreoli <Tony_Andreoli_-_CTA@CL_C21SMTP_GW.CHINALAKE.NAVY.MIL>
Date: Mon, 1 Aug 1994 01:49:23 GMT
Organization: Naval Air Warfare Center - Weapons Division

In article <[e-mail]> , [e-mail] writes:
>Hi there! Does anyone know where documentation about writing control
>strip modules for the powerbooks can be found?
>
>Thanks,

Look on the June (I think) Developers References CD.  It's in the PB 5xx
documentation.

Tony Andreoli

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

>From [e-mail] (Alex Metcalf)
Subject: Copying graphics without QuickDraw: custom blitting code
Date: Thu, 4 Aug 1994 12:40:19 GMT
Organization: Best Before Yesterday


        Due to further requests from a number of people, here again is
some code for copying graphics without QuickDraw. It's really intended for
all those people writing arcade games: 90 percent of programmers will do
fine using CopyBits and CopyMask in their software.

        If you have any questions or comments on the code, feel free to
get in touch!


        Alex

--
Alex Metcalf, Best Before Yesterday
Mac programmer in C, C++, HyperTalk, assembler
Juggler, 3-ball tricks

Internet:          [e-mail]
Fax (UK):          (0570) 45636
Fax (US / Canada): 011 44 570 45636



Custom graphics blitting code
- ---------------------------

   This code is a modification on the code from my new arcade game,
Maniac 2. It is possible to make the code even faster (especially if you
are only copying one size of rectangle), but it works well (and fast) as
a cheap alternative to CopyBits. With this and similar routines
in my game, I get an increase of up to 500 percent over CopyBits and
CopyMask, mainly because the code does far less checking than CopyBits does.

   Note that this code may actually draw to the screen when the
electron beam is half way down the screen. So, the top half of
your graphic may appear slightly after the bottom half. You
need to read up on the Vertical Retrace manager and SlotVInstall if you
want to "sync" your animation with the electron beam of the screen.

   The code copies a rectangle from an offscreen graphics world onto the
screen. The following assumptions are made:

o   You're in 32-bit addressing mode
o   The monitor is in 8-bit (256 colours/grays); 1 byte per pixel
o   The cursor is hidden
o   The source and destination rectangles are the same size
o   The GWorld and the screen are using the same colour table
o   The rectangles don't go off the screen or off the GWorld
o   The rectangles are in coordinates which are local to the screen
        (i.e. top left of screen is 0,0)

   There are four globals used:

o   gWorldPixMapBase is the base address of the graphics world pix map.
You use GetGWorldPixMap to get the pix map, and then you use
GetPixBaseAddr to get the base address.

o   gScreenPixMapBase is the pix map base address of the screen.
You get the pix map from the GDHandle of the screen you're using. Then
you use GetPixBaseAddr.

    If you're using the main monitor, you can get the GDHandle for that
monitor by using GetMainDevice ().

o   gWorldRowByteCount is the rowBytes for the graphics world. You get
it like this:

gWorldRowByteCount = (0x7FFF & (**tWorldPixMap).rowBytes);

o   gScreenRowByteCount is the rowBytes for the screen. You get it like
this:

gScreenRowByteCount = (0x7FFF & (**tScreenPixMap).rowBytes);


   I hope the code is useful to someone: you might try using the code,
but it's much better if you read through and understand what's happening,
and then use parts of it in your own game, animation app, or whatever.

   If you don't know how to read assembler, an excellent start is this
book:

How to Write Macintosh Software
by Scott Knaster
Published by Addison Wesley
ISBN 0-201-60805-7

   Have fun!



   Alex Metcalf
   [e-mail]


void RectCopy (Rect tSourceRect, Rect tDestRect)
{
        asm
        {
                movem.l a0-a1/d0-d7, -(sp);

                move.l  gWorldPixMapBase, D0;
                move.w  tSourceRect.top, D1;
                ext.l   D1;
                mulu.l  gWorldRowByteCount, D1;
                add.l   D1, D0;
                move.w  tSourceRect.left, D1;
                ext.l   D1;
                add.l   D1, D0;
                move.l  D0, A0;     // A0 is the source

                move.l  gScreenPixMapBase, D0;
                move.w  tDestRect.top, D1;
                ext.l   D1;
                mulu.l  gScreenRowByteCount, D1;
                add.l   D1, D0;
                move.w  tDestRect.left, D1;
                ext.l   D1;
                add.l   D1, D0;
                move.l  D0, A1;     // A1 is the destination

                move.w  tSourceRect.right, D6;
                move.w  tSourceRect.left, D0;
                sub.w   D0, D6;
                ext.l   D6;         // D6 is the width of rect to copy

                move.l  gWorldRowByteCount, D2;
                sub.l   D6, D2;     // D2 is the source row offset

                move.l  gScreenRowByteCount, D3;
                sub.l   D6, D3;     // D3 is the destination row offset

                move.w  tSourceRect.bottom, D4;
                move.w  tSourceRect.top, D0;
                sub.w   D0, D4;
                ext.l   D4;
                subq.l  #1, D4;     // D4 is number of rows to copy

                moveq.l #4, D5;

                tst.l   D4;
                ble.s   @6;

                move.l D6, D0;
                divs.l D5, D0;
                move.l D5, D7;
                mulu.l D0, D7;
                move.l D6, D1;
                sub.l  D7, D1;
                subq.l #1, D0;
                subq.l #1, D1;
                move.l D0, D6;
                move.l D1, D7;

                @1;
                tst.l D0;
                blt.s @3;

                @2;
                move.l (a0)+, (a1)+;
                dbra d0,@2;

                @3;
                tst.l D1;
                blt.s @5;

                @4;
                move.b (a0)+, (a1)+;
                dbra d1,@4;

                @5;
                adda.l D2, A0;
                adda.l D3, A1;
                move.l D6, D0;
                move.l D7, D1;
                dbra d4,@1;

                @6;
                movem.l (sp)+, a0-a1/d0-d7;
        }
}

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

>From [e-mail] (David Wareing)
Date: 18 Aug 94 14:32:24 GMT
Organization: Apanix Public Access Unix, [phone] (5 lines)

[e-mail] (Alex Metcalf) writes:

>        Due to further requests from a number of people, here again is
>some code for copying graphics without QuickDraw. It's really intended for
>all those people writing arcade games: 90 percent of programmers will do
>fine using CopyBits and CopyMask in their software.

Excellent. Well done Alex.

--
David Wareing
Adelaide, South Australia         [e-mail]
- ------------------------------------------------------------
Freelance Macintosh Games & Multimedia Programming

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

>From [e-mail] (Bill Lipa)
Subject: Debugging on PowerMacs
Date: 1 Aug 1994 21:11:14 GMT
Organization: Center for Advanced Medical Informatics at Stanford


What methods are people using to do low-level debugging on PowerMacs?
By low-level, I mean tracking down problems in apps that are running outside
of a source-code debugging environment like Metrowerks.

On 68K Macs, Macsbug made it easy to figure out where things were hanging
and crashing by using the sc7 and sc6 commands, for example. Is there any
equivalent on PowerMacs?

You can use Macsbug on PowerMacs but, as I understand it, only to debug
emulated code. I need to debug native code.

Bill


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

>From mclow@san_marcos.csusm.edu (Marshall Clow)
Date: Mon, 01 Aug 1994 21:17:38 -0800
Organization: Aladdin Systems

In article <31jodi$[e-mail]>, [e-mail] (Bill
Lipa) wrote:

> What methods are people using to do low-level debugging on PowerMacs?
> By low-level, I mean tracking down problems in apps that are running outside
> of a source-code debugging environment like Metrowerks.
>
> On 68K Macs, Macsbug made it easy to figure out where things were hanging
> and crashing by using the sc7 and sc6 commands, for example. Is there any
> equivalent on PowerMacs?
>
> You can use Macsbug on PowerMacs but, as I understand it, only to debug
> emulated code. I need to debug native code.
>

Well....
   There's "The Debugger", by Steve Jasik. Debugs native apps, and
everything else. If you can think like Steve, you're home free. :-)

   There's "Macintosh Debugger for Power PC", part of the Mac on Risc SDK.
It's a two machine debugger, and it only really does apps, and some plug-ins.

   There's Macsbug. There are some nifty dcmds that help you debug ppc code.

   There's the Metrowerks debugger. Nice if you're using Code Warrior and
developing apps.

################
   Someday, there will be TMON PPC. Call Alan and tell him you want it now ;-)

   Someday, "Macintosh Debugger for Power PC" will be one-machine debugger
and will debug 68K code too. (One debugger to find them all, and in the
darkness bind them)

--
Marshall Clow
Aladdin Systems
mclow@san_marcos.csusm.edu

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

>From Jens Alfke <[e-mail]>
Date: Tue, 2 Aug 1994 17:42:46 GMT
Organization: Apple Computer

Bill Lipa, [e-mail] writes:
> What methods are people using to do low-level debugging on PowerMacs?
> By low-level, I mean tracking down problems in apps that are running outside
> of a source-code debugging environment like Metrowerks.
> On 68K Macs, Macsbug made it easy to figure out where things were hanging
> and crashing by using the sc7 and sc6 commands, for example. Is there any
> equivalent on PowerMacs?
> You can use Macsbug on PowerMacs but, as I understand it, only to debug
> emulated code. I need to debug native code.

You're basically correct. There are some 'dcmd's -- available on the
'develop' 17 CD -- the help with PPC debugging. They're PPC equivalents of
'il', 'sc', 'td', 'wh' and some special stuff for viewing routine
descriptors. Of course you still can't step through native code since MacsBug
is emulated.
  (I personally have not figured out how to get the native stack crawl
('scp') to work. Anyone know what address you have to give it as a parameter?)

One hint I can share: I've been having trouble with jumps to 0 -- this can be
caused by bogus RoutineDescriptors or by smashing transition vectors. It
turns out that (at least on my Mac) the random spoodge at location 0 tends to
look like a PPC instruction that branches to itself, thus causing an infinite
loop. This just freezes your machine, even if you do have a PPC debugger
running. Sadly, even EBBE doesn't help because 50FF8001 is not an illegal
instruction on PPC. 00000000, however, is illegal. So when I get one of these
freezes, I first do a 'tdp' and check if the PC is at 0 or 4. If so, I use
"sl 0 0" or "sl 4 0" to smash an illegal instruction in, then continue. I
then very quickly end up in the source level debugger with an "illegal
instruction" exception. From there I have a better chance of figuring out
what caused it.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

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

>From [e-mail] (Matthew Melmon)
Date: Tue, 2 Aug 1994 19:42:30 GMT
Organization: Apple Computer, Inc.

In article <31jodi$[e-mail]>, [e-mail] (Bill
Lipa) wrote:
>
>
> What methods are people using to do low-level debugging on PowerMacs?
> By low-level, I mean tracking down problems in apps that are running outside
> of a source-code debugging environment like Metrowerks.
>
> On 68K Macs, Macsbug made it easy to figure out where things were hanging
> and crashing by using the sc7 and sc6 commands, for example. Is there any
> equivalent on PowerMacs?

The Macintosh Debugger, shipped on ETO, can display source code,
PowerPC instructions, POWER instructions, the registers, it can
do stack crawls, it can even show you your code fragments and their
exports.  It can do all this either on the target, or connected to
the target via serial or EtherTalk cables (Personally, I don't
see what the big fuss about "two-machine" debugging is.  To be
blunt, it strikes me as the technically superior choice.  But hey,
c'est moi, and this is a tangent...)

To be fair and honest, I must admit MD can provoke you into
fits of realous jage.  But when it works, its way cool.  Heh.
Heh, heh, heh.

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

>From [e-mail] (Bruce Hoult)
Date: Wed, 3 Aug 1994 09:20:10 +1200 (NZST)
Organization: (none)

mclow@san_marcos.csusm.edu (Marshall Clow) writes:
>    There's "The Debugger", by Steve Jasik. Debugs native apps, and
> everything else. If you can think like Steve, you're home free. :-)
>
>    There's "Macintosh Debugger for Power PC", part of the Mac on Risc SDK.
> It's a two machine debugger, and it only really does apps, and some plug-ins.
>
>    There's Macsbug. There are some nifty dcmds that help you debug ppc code.

So I keep hearing.  But where do you *get* them from?  I don't see them on ETO.
I don't see them on the Mac on RISC SDK.  I don't see them on CodeWarrior/Gold.
I don't see them on Apple's ftp sites.

Maybe I'm blind.  I hope so :-)

-- Bruce

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

>From Brian Strull <[e-mail]>
Date: Tue, 2 Aug 1994 20:54:37 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Marshall Clow,
mclow@san_marcos.csusm.edu writes:
>   There's "Macintosh Debugger for Power PC", part of the Mac on Risc
SDK.
>It's a two machine debugger, and it only really does apps, and some
plug-ins.

I'm not sure why you say it only does apps.  MD can debug any PowerPC
code loaded by the Code Fragment manager, which is everything
(except maybe the emulator itself).

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

>From [e-mail] (Matthias Neeracher)
Date: 02 Aug 1994 22:49:57 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]>, [e-mail] (Bruce Hoult) writes:
> mclow@san_marcos.csusm.edu (Marshall Clow) writes:
>> There's "The Debugger", by Steve Jasik. Debugs native apps, and
>> everything else. If you can think like Steve, you're home free. :-)
>>
>> There's "Macintosh Debugger for Power PC", part of the Mac on Risc SDK.
>> It's a two machine debugger, and it only really does apps, and some plug-ins.
>>
>> There's Macsbug. There are some nifty dcmds that help you debug ppc code.

> So I keep hearing.  But where do you *get* them from?  I don't see them on
> ETO.  I don't see them on the Mac on RISC SDK.  I don't see them on
> CodeWarrior/Gold.  I don't see them on Apple's ftp sites.

But you will see them in the "develop" folder on the appropriate CDs.

Matthias

- ---
Matthias Neeracher <[e-mail]> http://err.ethz.ch/members/neeri.html
   "I don't know if this will help you solve your problem, but it's
    certainly entertained me to tell you this." -- Tim Dierks

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

>From Jens Alfke <[e-mail]>
Date: Tue, 2 Aug 1994 21:41:17 GMT
Organization: Apple Computer

Matthew Melmon, [e-mail] writes:
> the target via serial or EtherTalk cables (Personally, I don't
> see what the big fuss about "two-machine" debugging is.  To be
> blunt, it strikes me as the technically superior choice.  But hey,
> c'est moi, and this is a tangent...)

Well,
(A) It's damned slow;
(B) You have to go to the pain of either copying your executables to the
target machine before running them; or of copying all your source code and
.xSYM files to the debugging machine. (Depends on whether you need to run
your code on the development machine or not. Not many people have two
PowerMacs yet, so they probably want to run the code and develop it on the
same machine, at least if they use CW.)

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

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

>From [e-mail] (David Shayer)
Date: Wed, 3 Aug 1994 02:28:38 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Jens Alfke ([e-mail]) wrote:
:   (I personally have not figured out how to get the native stack crawl
: ('scp') to work. Anyone know what address you have to give it as a parameter?)

I've gotten SCP to work when I put in A6.  It works about as often
as SC does.  If A6 is trashed, it won't work.  Also, it tends to show
some junk stack frames, because SCP doesn't understand 68K frames
or mixed mode transition frames.

+------------------------------------------------------------------------+
|David Shayer                                 [e-mail] |
|Sentient Software / Symantec                 Applelink: SHAYER          |
|"When encryption is outlawed, only outlaws will have encryption."       |
+------------------------------------------------------------------------+


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

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

In article <31jodi$[e-mail]>,
 [e-mail] (Bill Lipa) wrote:

>On 68K Macs, Macsbug made it easy to figure out where things were hanging
>and crashing by using the sc7 and sc6 commands, for example. Is there any
>equivalent on PowerMacs?

The Debugger by Jasik designs. It's evil, but it does the job.
[e-mail]. Probably $300.

Cheers,

                / h+

--
  Jon Wdtte
  Hagagatan 1
  113 48 Stockholm
  Sweden


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

>From [e-mail] (David Shayer)
Date: Wed, 3 Aug 1994 19:39:47 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Bruce Hoult ([e-mail]) wrote:
: mclow@san_marcos.csusm.edu (Marshall Clow) writes:
: >    There's "The Debugger", by Steve Jasik. Debugs native apps, and
: > everything else. If you can think like Steve, you're home free. :-)
: >
: >    There's "Macintosh Debugger for Power PC", part of the Mac on Risc SDK.
: > It's a two machine debugger, and it only really does apps, and some plug-ins.
: >
: >    There's Macsbug. There are some nifty dcmds that help you debug ppc code.

: So I keep hearing.  But where do you *get* them from?  I don't see them on ETO.
: I don't see them on the Mac on RISC SDK.  I don't see them on CodeWarrior/Gold.
: I don't see them on Apple's ftp sites.

You can buy The Debugger from Jasik Designs, [phone].
You can buy Mac on RISC SDK from APDA, [phone].
You can get the Macsbug dcmds free on the CD in develop #17.

+------------------------------------------------------------------------+
|David Shayer                                 [e-mail] |
|Sentient Software / Symantec                 Applelink: SHAYER          |
|"Subvert the Dominant Paradigm."                                        |
+------------------------------------------------------------------------+


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

>From [e-mail] (The Weasel)
Date: 3 Aug 1994 23:24:51 GMT
Organization: Computer Science Department, Stanford University.

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

>One hint I can share: I've been having trouble with jumps to 0 -- this can be
>caused by bogus RoutineDescriptors or by smashing transition vectors. It
>turns out that (at least on my Mac) the random spoodge at location 0 tends to
>look like a PPC instruction that branches to itself, thus causing an infinite
>loop.

Now, if you were using the debugger it would tell you that you have an
invalid pc when you tried to jump off to nowhere land. This, however,
is only moderatley useful since tracing backwards is a huge pain in my
butt due to all of the mixed mode switches etc.

Peter





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

>From [e-mail] (Tom Rankin)
Date: Wed, 3 Aug 1994 20:17:19 GMT
Organization: S-CUBED, A Division of Maxwell Laboratories

In article <[e-mail]>, [e-mail] (Bruce Hoult) writes:
|> mclow@san_marcos.csusm.edu (Marshall Clow) writes:
|> >    There's "Macintosh Debugger for Power PC", part of the Mac on Risc SDK.
|> > It's a two machine debugger, and it only really does apps, and some plug-ins.
|>
|> So I keep hearing.  But where do you *get* them from?  I don't see them on ETO.
|> I don't see them on the Mac on RISC SDK.  I don't see them on CodeWarrior/Gold.
|> I don't see them on Apple's ftp sites.
|>
|> Maybe I'm blind.  I hope so :-)

I've got E.T.O. 14 and the "M.D. for PowerPC" can be found in the following
folder:

  E.T.O.:Tools - Objects:Power Macinthosh Tools:Macintosh Debugger for PowerPC

Squash 'dem bugs,

TR

--
- ------------------------------------------------------------------------------
Tom Rankin         Maxwell Laboratories, S-CUBED Division    3398 Carmel Mtn Rd.
[e-mail]             [phone]                 San Diego, CA 92121
- ------------------------------------------------------------------------------

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

>From [e-mail] (The Weasel)
Date: 4 Aug 1994 07:06:30 GMT
Organization: Computer Science Department, Stanford University.

In article <[e-mail]>,
Jon W{tte <[e-mail]> wrote:

>The Debugger by Jasik designs. It's evil, but it does the job.
>[e-mail]. Probably $300.

$350 full price and $225 if you have CodeWarrior. Steve is in Boston
right now, but you can still call and place orders.

Peter



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

>From Brian Strull <[e-mail]>
Date: Thu, 4 Aug 1994 00:59:42 GMT
Organization: Apple Computer, Inc.

Subject: Re: Debugging on PowerMacs
From: Bruce Hoult, [e-mail]
Date: Wed, 3 Aug 1994 09:20:10 +1200 (NZST)
In article <[e-mail]> Bruce Hoult,
[e-mail] writes:
>mclow@san_marcos.csusm.edu (Marshall Clow) writes:
>>    There's "The Debugger", by Steve Jasik. Debugs native apps, and
>> everything else. If you can think like Steve, you're home free. :-)
>>
>>    There's "Macintosh Debugger for Power PC", part of the Mac on Risc
SDK.
>> It's a two machine debugger, and it only really does apps, and some
plug-ins.
>>
>>    There's Macsbug. There are some nifty dcmds that help you debug ppc
code.
>
>So I keep hearing.  But where do you *get* them from?  I don't see them
on ETO.
>I don't see them on the Mac on RISC SDK.  I don't see them on
CodeWarrior/Gold.
>I don't see them on Apple's ftp sites.
>
>Maybe I'm blind.  I hope so :-)
>
>-- Bruce

Both MD for PowerPC and MacsBug are on ETO and the MoR SDK.
The Debugger is a third party product available through APDA and other
channels.

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

>From [e-mail] (Bruce Hoult)
Date: Sat, 6 Aug 1994 22:06:33 +1200 (NZST)
Organization: (none)

Brian Strull <[e-mail]> writes:
> >>    There's "The Debugger", by Steve Jasik. Debugs native apps, and
> >> everything else. If you can think like Steve, you're home free. :-)
> >>
> >>    There's "Macintosh Debugger for Power PC", part of the Mac on Risc SDK.
> >> It's a two machine debugger, and it only really does apps, and some plug-ins.
> >>
> >>    There's Macsbug. There are some nifty dcmds that help you debug ppc code.
> >
> >So I keep hearing.  But where do you *get* them from?  I don't see them on ETO.
> >I don't see them on the Mac on RISC SDK.  I don't see them on CodeWarrior/Gold.
> >I don't see them on Apple's ftp sites.
> >
> >Maybe I'm blind.  I hope so :-)
> >
> > -- Bruce
>
> Both MD for PowerPC and MacsBug are on ETO and the MoR SDK.
> The Debugger is a third party product available through APDA and other
> channels.

Thanks to everyone who's answered this.

I guess I'm going to have to take a course in communcation skills because
everyone has told me where to get The Debugger and "Macintosh Debugger for
Power PC", which I already knew perfectly well and I was using R2DB on my
PowerBook 100 (not pleasant, trust me!) for some time until a) I got the
single machine version, and b) I got CodeWarrior.

What I was *really* after was the location of the MacsBug PPC dcmds :-(

Someone mentioned that they are on the latest develop, so I'll try to
track down a copy.  Thanks to whoever it was.

No thanks to Apple, though: why on *earth* are such things in a $30
magazine and *not* on a $400/year developer tool mailing, or even *gasp*
on the SDK for programming the PowerMacs.  I guess that's too logical. :-(

-- Bruce

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

>From [e-mail] (David Shayer)
Date: Tue, 9 Aug 1994 05:45:03 GMT
Organization: Sentient Software

In article <[e-mail]>, [e-mail]
(Bruce Hoult) wrote:
>
> What I was *really* after was the location of the MacsBug PPC dcmds :-(
>
   They are on develop 17.

However, the current issue of develop is 19.

-- Marshall Clow
mclow@san_marcos.csusm.edu
(Hiding out on David's account)

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

>From [e-mail] (Dennis J. Ciplickas)
Subject: Guide for writing programs for both PowerPC and 680x0? etc...
Date: 08 Aug 1994 13:13:39 GMT
Organization: Electrical and Computer Engineering, Carnegie Mellon


Hiya,

No snide comments please, but I've yet to learn how to adjust my
Macintosh coding style to work for both the 68000 and the PowerPC.  I
am aware the code warrior is the approved compiler for the PowerPC.
Can anyone point me to books or CDs that tell me what differences
there are from the programmer's perspective and what the "approved"
techniques are for dealing with them?

I am very familiar with the X-window's style architecture-adaptable
source tree technique a la "imake."  Is anyone using anything like
this on the Mac?  I have heard that code warrior does not use standard
makefiles, but can somehow be kludged into working with them.  I rely
on recursive makefiles to build groups of related source code.  Will I
be able to implement this in code warrior without too much pain?

Looking forward to being native on both processors,
Dennis

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

>From [e-mail] (Steve Bryan)
Date: Mon, 8 Aug 1994 15:11:23 GMT
Organization: Sexton Software

In article <[e-mail]>, [e-mail]
(Dennis J. Ciplickas) wrote:

> Hiya,
>
> No snide comments please, but I've yet to learn how to adjust my
> Macintosh coding style to work for both the 68000 and the PowerPC. ...

The Macintosh toolbox remains largely the same from either type of
machine. Apple's strategy has been to provide a new set of headers files
(for C) and interface files (for Pascal) which are called universal
headers files that are intended to work whether they are used to compile
to 68K code or PPC code. If you follow some of the threads in this
newsgroup it appears some may have even automated their build process to
produce the fat binary result froma single set of source files. Anyhow I
believe the short answer to your question is that the universal header
files should provide compatibility with either type of output (68K or
PPC).

--
Steve Bryan                Internet: [e-mail]
Sexton Software          CompuServe: 76545,527
Minneapolis, MN 55415           Fax: [phone]

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

>From [e-mail] (John W. Baxter)
Date: Mon, 08 Aug 1994 09:48:51 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail]
(Dennis J. Ciplickas) wrote:

> Hiya,
>
> No snide comments please, but I've yet to learn how to adjust my
> Macintosh coding style to work for both the 68000 and the PowerPC.  I
> am aware the code warrior is the approved compiler for the PowerPC.
> Can anyone point me to books or CDs that tell me what differences
> there are from the programmer's perspective and what the "approved"
> techniques are for dealing with them?

A Power Macintosh is a Macintosh.  I haven't yet had to do anything other
than make adjustments to floating point number format, which differs among
three forms of Mac (68K without hardware floating point, 68K with hardware
floating point, and PPC).  Most of that can, for real programs, be fixed
by using the types float_t and double_t for computation, and either float
or double (setting options for the 8-byte double) for external storage.
There's a little extra code to put a double into the 10-byte format some
programs insist on in an Apple event parameter.

I haven't yet had to resort to different source files for 68K vs PPC [I
did all the assembler coding I ever want to do between 1958 and 1980 or
so]...a few (ugh!) #if things are sufficient.

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   "Occasionally...astronomers add a second to either June 31 or
    December 31..."   IM: OS Utilities, p 4-12
   [e-mail]

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

>From [e-mail] (Avi Rappoport)
Date: 9 Aug 1994 17:52:35 GMT
Organization: The Whole Earth 'Lectronic Link, Sausalito, CA

>In article <[e-mail]>, [e-mail]
>(Dennis J. Ciplickas) wrote:

>> Hiya,
>>
>> No snide comments please, but I've yet to learn how to adjust my
>> Macintosh coding style to work for both the 68000 and the PowerPC.  I
>> am aware the code warrior is the approved compiler for the PowerPC.
>> Can anyone point me to books or CDs that tell me what differences
>> there are from the programmer's perspective and what the "approved"
>> techniques are for dealing with them?

I wouldn't say we are "approved" but CodeWarrior is rather speedy on
the PowerPC (and the 68K for that matter :-).

In general, it's pretty easy to port.  You do have to watch out for
callbacks from system routines (usually found in dialogs and Apple Event
support).  Use the new Universal Headers from Apple (they come with
CodeWarrior) and follow the UPP rules -- works fine on both 68K and PPC.

Good sources include "Inside Macintosh: PowerPC System Software" (Addison
Wesley), "Power Macintosh Programming Starter Kit" by Tom Thompson, and
"Simple Porting to the Power Mac" by Chris Forden in MacTech Magazine,
May 1994 (p. 64-71).

I'd also find the archives for this group -- there are lots of answers
that have already been given.

--
Avi Rappoport
Technical Analyst
Metrowerks, Inc.
Please reply to: [e-mail]  [e-mail]  [e-mail]

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

>From [e-mail] (Vicente Giles)
Subject: HFSDispatch Trap. Success
Date: Wed, 17 Aug 1994 10:43:12 -0800
Organization: Uniersidad de Malaga

Hi,

Some time ago, I posted some code asking for help with a patch to HFSDispatch.
The problem was the patch worked ok without File Sharing and didn4t work
when File Sharing was on.

With some people pointing me to the problems File Sharing was causing, I was
able to correct the code and have it working properly (as far as I4ve tested).

This is to thank everybody who answered (special thanks to Larry Rosenstein
and Pete Gontier) and to made available my code, just in case anybody else
is interested. Anyway, I made no warranty about it and usual disclaimers
should be applicable. Use at your own risk, ...


By the way, I rewrote most of it not to use Asm, but as much C as
possible instead :). Here4s the code (Symantec C 7.03, Monaco 9, tabs = 4):

//

OSErr    ourHFSDispatch (  CInfoPBPtr pbptr )
{
    short                selector;
    CInfoPBPtr            ourPB;
    OSErr                result;
    long                oldHFSDispatch;
    ConstStr31Param     fileName;
    Boolean                weCanTouch;

    asm {
            move.w        d0, selector    ;; save parameters
            move.l        a0, ourPB

    ;; Get our globals. We are not using Symantec4s SetupA4()/RestoreA4()
    ;; so you MUST use a custom header (Set Proyect Type...). main needs
    ;; to be on the top of the compiled code, not Symantec's header, for
    ;; this to work
    ;;         Str255    gFileName = "\pTest File";
    ;;        long     gOldHFSDispatch;

            movem.l        a3-a4, -(sp)
            lea            main, a4
            move.l        gOldHFSDispatch, oldHFSDispatch
            lea            gFileName,  a3
            move.l        a3, fileName
            movem.l        (sp)+, a3-a4
        }

    weCanTouch = (selector == 9) && isFinder();

    asm {                                ; call original trap
            move.w        selector, d0
            move.l        ourPB, a0
            move.l        oldHFSDispatch, a1
            jsr            (a1)
            move.l        a0, ourPB
            move.w        d0, result
        }


//
//
//
//
//
error)
//

// I avoid the file name comparison till this point. If you do it before the
// call returns, you get the name of the previous file, when indexing
// thru the directory, in ioNameptr, so it fools the Finder with the file
// after the one we are interested in.

    // You can do what you like here. For example...
    if ( ourPB->hFileInfo.ioResult == 0 && weCanTouch
                && compareNames(fileName, ourPB->hFileInfo.ioNamePtr ) ) {
        ourPB->hFileInfo.ioFlLgLen = 0x0800;
        ourPB->hFileInfo.ioFlPyLen = 0x0800;
        ourPB->hFileInfo.ioFlRLgLen = 0x0800;
        ourPB->hFileInfo.ioFlRPyLen = 0x0800;
        }

    return result;
}

// This two next functions need to be interrupt safe, because of File Sharing
// reissuing synchronous calls as asynchronous

//
/// Finder is the current process ?? (quick and dirty way)

Boolean isFinder ( void )
{
    asm {
                move.l        0x0910, d0        ; CurApName
                cmp.l        #0x0646696E, d0
                bne.s        @end
                move.w        #1, d0
                rts
            @end
                clr.w        d0                ; return false
                rts
        }
}


//
/// Compare both file names. Returns true if they are equal. Shorter to write
// if it was to return false when equal :)

Boolean compareNames ( ConstStr31Param s1, ConstStr31Param s2 )
{
asm {
            movem.l        a0-a1/d1, -(sp)

            move.l        s1, a1
            move.l        s2, a0
            clr.l        d1                    ; avoid garbage
            move.b        (a0), d1            ; length of file name
        @compare
            move.b        (a0)+, d0
            sub.b        (a1)+, d0
            tst.b        d0
            bne.s        @different
            dbra        d1, @compare

        ; if we are here, d0 == 0, so both are equal. We must return true
            move.w        #1, d0
            bra.s        @end

        @different
            clr.w        d0                    ; false
        @end
            movem.l        (sp)+, a0-a1/d1
        }
}


   Vicente Giles Duran
   Servicio Central de Informatica
   Universidad de Malaga
   Campus de Teatinos
   [e-mail]

--
Vicente Giles               |
Universidad de Malaga.      |   Favourite drink:
Spain.                      |      Bacardi += Coke;

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

>From [e-mail] (Tng Tai Hou)
Subject: MPW PPCC funnies ...
Date: 10 Aug 1994 17:30:26 +0800
Organization: Institute Of Systems Science, NUS

I ran the latest MPW from the Mac on RISC SDK final release and
encountered two funnies which one wouldn't normally expect:

1.  '\r' is not ascii code 13 but 10. Is this normal? How
    should one write code which requires comparisons
    of '\r', '\t', '\n' etc if they are not the same across
    platforms (unix, dos, mac, vax etc), and not even the same
    across compilers within the same platform. Codewarrior
    works maps '\r' to ascii value 13 but MPW maps to ascii 10!!!

2.    fopen and a subsequent fclose leaves a memory leak!!! Can
    anyone varify this? I trace down a memory leak to an
    fopen, two sucessfull unleaking fprintfs, and fclose, upon
    which the memory leak was immediately detected.

I ran the compiler on a 8100 with loads of ram.

Please, can anyone comment on these points?

Thanks.


Tai Hou TNG
Singapore

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

>From [e-mail] (Matthias Neeracher)
Date: 11 Aug 1994 09:01:34 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <32a6ni$[e-mail]>, [e-mail] (Tng Tai Hou) writes:
> I ran the latest MPW from the Mac on RISC SDK final release and
> encountered two funnies which one wouldn't normally expect:

> 1.  '\r' is not ascii code 13 but 10. Is this normal? How
>     should one write code which requires comparisons
>     of '\r', '\t', '\n' etc if they are not the same across
>     platforms (unix, dos, mac, vax etc), and not even the same
>     across compilers within the same platform. Codewarrior
>     works maps '\r' to ascii value 13 but MPW maps to ascii 10!!!

I wrote about this about a month ago, and nobody challenged me on it, so here
goes again:

What I read (in ANSI X3.159-1989, section 2.2.2, _Character Display Semantics_)
is that:

- \n "Moves the active position to the initial position of the next line".
- \r "Moves the active position to the initial position of the current line".
- \n and \r "shall produce a unique implementation-defined value which can
  be stored in a single char object. The external representations in a text
  file need not be identical to the internal representations, and are outside
  the scope of this standard".
- This means that all you can rely on is that '\n' and '\r' produce different
  values and that you will get a newline if you write "\n" to a display device.
  You can't rely on '\n' meaning any particular character value either in
  memory or on disk.

Think C and (by default) CodeWarrior represent '\n' internally as 0x0A and
read/write it as 0x0D, but MPW C (optionally) CodeWarrior represent
'\n' as 0x0D. From the above passage, I believe that both variants are legit.

To make it short: If you want to look for character 13, compare with 13, if you
want to look for newline, compare with '\n'.

Matthias

- ---
Matthias Neeracher <[e-mail]> http://err.ethz.ch/members/neeri.html
   "Omne animal triste est post (or without) coitum"  -- Umberto Eco

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

>From [e-mail] (Ed Estes)
Subject: Opening the Apple CD ROM Tray.
Date: 09 Aug 1994 09:52:44 -0500
Organization: (none)

Greetings.

I am involved with a project that will be publishing several Compact Discs
containing multimedia data. We've discovered some users find it difficult to
open Apple's Newer CD Drive's tray because they think they've pressed the
button on the front of the drive hard enough when they haven't.  We'd like to
eliminate the need to press the button on the newer drives if possible.  Is
there a driver call we can make that will open the tray to these drives when
we need a particular disc, or can they only be opened by depressing the
hardware button on the front?

TIA.

--Ed

[e-mail]


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

>From [e-mail] (Jamie McCarthy)
Date: Tue, 09 Aug 1994 16:08:26 -0400
Organization: University of Michigan

[e-mail] wrote:

> Is
> there a driver call we can make that will open the tray to these
> [CD-ROM] drives when we need a particular disc, or can they only
> be opened by depressing the hardware button on the front?

I just stepped over to our LC 575, put a CD in, set an a-trap on
_Eject, and dragged the CD to the trash.  Tracing over the _Eject
reveals that it and it alone is responsible for opening the tray.

If you want to open it without a disc _already_ in the drive, I'm
not so sure how I'd go about that.  Here's some very old code of
mine that ejects any disks that may be in the floppy drives:

for (driveNum = 1; driveNum<3; driveNum++) {
  theOSErr = GetVInfo(driveNum, volName, &vRefNum, &freeBytes);
  if (theOSErr == noErr) {
      /* Physically eject the disk from the drive */
    theOSErr = FlushVol(NULL, vRefNum);
    theOSErr = Eject(NULL, vRefNum);
  }
}

This is really skainchy of me;  you can count on drive 1 being the
internal floppy, but everything else is up for grabs.  2 will usually
be the external floppy, 3 and up usually hard drives, but there are
no guarantees.  What the hell -- try looping from 2 to 100, you
might eject the CD-ROM tray...along with every SyQuest and optical
drive the user also happens to have hooked up...  :-)
--
 Jamie McCarthy   Internet: [e-mail]   AppleLink: j.mccarthy
 I speak for no one but myself.

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

>From Glenn R. Howes <[e-mail]>
Date: 9 Aug 1994 22:45:37 GMT
Organization: UW-Chemistry

Subject: Re: Opening the Apple CD ROM Tray.
From: Jamie McCarthy, [e-mail]
Date: Tue, 09 Aug 1994 16:08:26 -0400

In article <[e-mail]> Jamie McCarthy,
[e-mail] writes:
>[e-mail] wrote:
...
>This is really skainchy of me;  you can count on drive 1 being the
>internal floppy, but everything else is up for grabs.  2 will usually
>be the external floppy, 3 and up usually hard drives, but there are
>no guarantees.  What the hell -- try looping from 2 to 100, you
>might eject the CD-ROM tray...along with every SyQuest and optical
>drive the user also happens to have hooked up...  :-)

The following works at finding and ejecting the CD. I haven't tried to
find out if it works for empty drives. I got the info for this code
from a variety of places. There is a driver tech note on managing
audio cd's, and some of this came from there.


#define AUDIO_NAME    "\p.AppleCD"
#define dRAMBased        0x0040
#define gestaltAudioCD    'aucd'
// after finding the refNum for the CD drive call this
// to eject it.
OSErr EjectTheDrive(short refNum)
{
    OSErr             myErr;
    Str63            volName;
    HParamBlockRec    vParam;

    vParam.volumeParam.ioNamePtr = (StringPtr)&volName;
    vParam.volumeParam.ioCompletion = 0L;
    vParam.volumeParam.ioVolIndex = 0;
    do
    {
        vParam.volumeParam.ioVolIndex++;
        myErr = PBHGetVInfo(&vParam, false);
        if (!myErr && vParam.volumeParam.ioVDRefNum == refNum)
        {
            myErr = PBEject((ParmBlkPtr)&vParam);
            if(!myErr)
                myErr = PBUnmountVol((ParmBlkPtr)&vParam);
            break;
        }
    }while(!myErr);
    return (myErr);
}

// routine to find the reference number for the nth audio drive on
// the SCSI bus, usually you would have drive =1, driverName = "\pAppleCD"
OSErr FindAudioDrive(Str63 driverName, short drive, short *refNum)
{

    Byte        cdFlag;
    int            i;
    short         driveNum = 0, shiftBits = 1;
    *refNum = 0;
    cdFlag = WhereCDs(driverName);

    if (!HasAudioCD() || cdFlag == 0)
    {
        return (-1);
    }
    if (drive < 1 || drive > 7)
    {
        return (-1);
    }
    for (i = 0; i<7;i++)
    {
        if (cdFlag & shiftBits)
        {
            driveNum++;
            if (driveNum == drive)
            {
                *refNum = -33 - i;
                return (noErr);
            }
        }
        shiftBits <<= 1;
    }
    return(-1);
}
Byte WhereCDs(Str63 appleDriverName)
{
  unsigned         char where = 0;    /* assume no drives handled at beginning
*/
  short         scsiAddress;
  short         drvrRefNum;
  DCtlHandle    aDCtlEntry;
  StringPtr       aDriverName;

  for (scsiAddress = 0; scsiAddress < 7; scsiAddress++)
  {
    drvrRefNum = -33 - scsiAddress;
    aDCtlEntry = GetDCtlEntry(drvrRefNum);
    if (aDCtlEntry != nil)
    {
      if ((**aDCtlEntry).dCtlFlags & dRAMBased)
      {
        aDriverName = (StringPtr) ((*(DCtlPtr)aDCtlEntry).dCtlDriver+18);
      }
      else
      {
        aDriverName = (StringPtr)((**aDCtlEntry).dCtlDriver+18);
      }
      if ( PascalCompare(aDriverName, &appleDriverName[0]) == true )
      {
            where |= (1 << scsiAddress);
      }
    }
  }
  return where;
}
Boolean HasAudioCD(void)
{
    OSErr            err;
    long            result;

    err = Gestalt(gestaltAudioCD, &result);
    if ((err != noErr) || !(result))
        return FALSE;
    else
        return TRUE;
}
Boolean PascalCompare(Byte *one, Byte *two)
{
    short    length;
    length = *two+1;
    if (*one != *two) return (false);
    while (length --)
        if (*one++ != *two++) return (false);
    return (true);
}

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

>From [e-mail] (Preston Marshall)
Subject: PPC CDK User Comments
Date: 11 Aug 1994 14:01:12 GMT
Organization: Vanguard Research, Inc.

This is a list of comments and suggestions I have collected for converting
Symantec projects to the CDK environment.  Little of the content is
original, but I hoped that by collecting all of the "hints" in one place,
the process can be made easier for all.  BTW, I have no association with
Symantec.

Much of the input has been provided by Tom Emerson
([e-mail]) of Symantec's Development Tools Group, who has
answered dozens of E-mail inquiries from me.  If CDK users would E-mail me
input to this list, I will consolidate it and repost it, as required.  I
have not included any of the material available on the Symantec 7.0.4
release, so obtain that distribution before using any of these
suggestions.  Support for the CDK is available by sending mail to
[e-mail].


Preston Marshall    Internet:  [e-mail]

For those who E-mailed me, I will put together a mailing list and
distribute this list directly as soon as I c an get to it.

The list is organized into the following topic areas:

   TCL Changes
   Library and Include Changes
   PPCLink and Scripts
   Others
- ---------------------------------------------------------------------------------------------------
I. TCL Changes
- -------------------------------------------------------------

This is a bug in the handling of .o files inside the TPM.  If your source
file name with the .o appended exceeds the legal size, you will get an
error with a incorrect name.  You need to shorted long (29 char or more)
file names

>From Tom Emerson --

 CtoPstr and PtoCstr aren't supported on the PowerPC - you should use
c2pstr and p2cstr instead: the 68K libraries have been updated to include
glue for these so your code will work without further modification for both
runtime systems.  ... you could always define a macro in your
prefix:

   #define PtoCstr(x) p2cstr((x))
   #define CtoPstr(x) c2pstr((x))

TrapAvailable is a TCL function which is completely conditionalized out.
Evidently Apple has this in their libraries, while we don't. To work
around this I modified its definition in the TCL sources as follows: I
moved the conditionalization inside the {}s of the function, and added a
#else clause containing

        return true;

This will work since all the places that it is used inside the TCL result
in a true return value. This should work until we come up with a better
solution.


II.   Library and Include Changes
- -------------------------------------------------------------

I had problems resolving some ansi character utilities and __setjmp.  The
problem is the 7.0.4 patch does not include have some of the modified
headers.  The changed headers check whether you are using apple's or
Symantec's libraries before redefining symbols, such as setjmp.  The disk
release includes the files.  Ignore the instructions and update your
libraries, even if you have installed the on-line patch.  I'm not sure of
the legaliity of my including them here, so I didn't.

To get the disks, end mail to:
[e-mail]
with name and snailmail address  The disk also contains the native
compilers and the sources to the libraries.

The headers should be available on-line RSN, I am told.

III   PPCLink and Scripts
- -------------------------------------------------------------
You probably don't want to hear this, but when linking a large (500+file)
TCL 2.0 based application I give it (PPCLink)  25MB - any less and it
dies. (Tom Emerson)

The .ts script must be at the project file level of the project folder.
It can not be within a folder.

PPCLink should be used with the -mf option, which will allow it to use
non-contiguous memory.  There is disagreement on whether the TOOLSERVER
size should then be reduced to  2 meg.  I tried it, and still got link
errors reporting that it could not find enough contiguous memory.  When I
gave it large (40 megs) assignment directly, it linked fine.


IV Others
- -------------------------------------------------------------

I misinterpreted the Readme stuff with 7.0.4 and removed the Quickdraw
init.  The proper treatment is:

The libraries don't initialize Quickdraw, they define the global
QDGlobals so you don't have to. Previously you had to declare the global

        QDGlobals       qd;

(Quickdraw.h declares this as an extern.) Now this is declared in the
libraries so you don't have to think about it.  (Tom Emerson)

--
___________________________________________________________________
|     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] (Laurent Humbert)
Subject: Problem with FSRead-WriteNoCache
Date: Sun, 31 Jul 1994 19:54:14 GMT
Organization: SW15 Software

I modified my application to call FSWrite/ReadNoCache, from Apple's
MoreFile package, but after running some tests, I can't see any difference.
Does it really bypass the cache ?

Basically, my application sometimes needs to execute a very intensive
read/write loop. Between each file access, I call my SpinBeachBallCursor
function, but I noticed that if the Disk Cache Size (as set in the Memory
control panel), is big, then after a while, the cursor can stop spinning
for several long seconds, time for the cache to get written to disk, I
assume. This is very annoying as it really looks as if my program crashed.

Calling FlushVol is obviously not a solution as it would slow things down,
and I don't really want to install a VBL to spin the cursor.

Any ideas ?

Cheers,

Laurent Humbert
[e-mail]

__

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

>From [e-mail] (Jump Long)
Date: 1 Aug 1994 01:49:03 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail]
(Laurent Humbert) writes:

>I modified my application to call FSWrite/ReadNoCache, from Apple's
>MoreFile package, but after running some tests, I can't see any
difference.
>Does it really bypass the cache ?

Since I wrote that code, I guess I should answer this question...

The noCache bit is really mis-named. It's real name should be the
pleaseDontCache bit. The particular file system that handles the Read or
Write request may ignore the bit in some or all cases.

What good is it then?  It is your only way to tell the file system that
you'd just as soon not have the data cached and in many cases, your
request for no caching *is* taken.

In your case, you're probably using an HFS volume so you need to know what
the HFS file system does with the noCache bit. HFS respects the noCache
bit on any block-aligned I/O.  However, since HFS uses block disk devices,
it must perform all reads and writes to the driver in 512-byte blocks. If
*your* requests to the File Manager are not block aligned, then HFS will
use cache blocks as temporary buffers when it needs to read or write a
partial block.

For example, let's say you write 2048 bytes to a file starting at offset
10 into the file.  The file system first needs to modify the last 502
bytes of the file's first block so it *reads* the block into a cache
buffer, modifies the last 502 bytes of the cache buffer with your data,
and then marks that cache buffer "dirty" so it will be flushed with the
next file or volume flush.  Then the file system needs to write 2 full
blocks to the disk. If you've set the noCache bit, the file system writes
those full blocks directly to disk bypassing the cache.  Next, the file
system needs to modify the first 10 bytes of the 4th block of the file, so
it reads that block into a cache buffer, modifies the first 10 bytes of
the cache buffer, and then marks that cache buffer "dirty".  Notice,
that's 2 reads (unless the blocks are already in the cache), 1 or more
writes directly to the disk driver, and 2 deferred writes to the disk
driver (when the cached blocks are flushed) for your one write request to
the File Manager.

So, what can you do if you want to keep your file data out of the File
System cache?  Use the noCache bit so that block aligned I/O won't be
cached and (you guessed it), make all of your file I/O in multiples of
512-bytes starting at a 512-byte boundary in the file (0, 512, 1024,
etc.).

One other thing, the larger you make your I/O operations, the better
performance you'll get.  I'm working on a Tech Note where I'll try to
explain all of this much more concisely than I did here.

- Jim Luther


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

>From [e-mail] (Laurent Humbert)
Date: Tue, 2 Aug 1994 00:49:24 GMT
Organization: SW15 Software

In article <31i2cf$[e-mail]>,
 [e-mail] (Jump Long) wrote:

>In your case, you're probably using an HFS volume so you need to know what
>the HFS file system does with the noCache bit. HFS respects the noCache
>bit on any block-aligned I/O.  However, since HFS uses block disk devices,
>it must perform all reads and writes to the driver in 512-byte blocks. If
>*your* requests to the File Manager are not block aligned, then HFS will
>use cache blocks as temporary buffers when it needs to read or write a
>partial block.

[example]

>So, what can you do if you want to keep your file data out of the File
>System cache?  Use the noCache bit so that block aligned I/O won't be
>cached and (you guessed it), make all of your file I/O in multiples of
>512-bytes starting at a 512-byte boundary in the file (0, 512, 1024,
>etc.).

Thanks a lot for the explanation. That' all new to me. Your tech note will
sure be welcome.

No wonder FSWriteNoCache doesn't seem to work in my application: I have an
index table loaded in memory that allows my program to read and write an
absolute minimum number of bytes, the problem being that sometimes the user
might want to do some kind of batch operation and hundreds/thousands of
records have to be updated to disk, typically changing only one _bit_ per
record.

I'll have to think about it. Maybe in my loops I can also make a call to
FlushVol from time to time so that the beachball cursor doesn't seem to
freeze if the System is configured with a big Disk Cache.  Or maybe it's
time to make a few more things backgroundable in my program :)

Cheers,

Laurent Humbert
[e-mail]




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

>From Cameron Esfahani <[e-mail]>
Date: Mon, 1 Aug 1994 06:17:30 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Laurent Humbert,
[e-mail] writes:
> I modified my application to call FSWrite/ReadNoCache, from Apple's
> MoreFile package, but after running some tests, I can't see any difference.
> Does it really bypass the cache ?
>
> Basically, my application sometimes needs to execute a very intensive
> read/write loop. Between each file access, I call my SpinBeachBallCursor
> function, but I noticed that if the Disk Cache Size (as set in the Memory
> control panel), is big, then after a while, the cursor can stop spinning
> for several long seconds, time for the cache to get written to disk, I
> assume. This is very annoying as it really looks as if my program crashed.
>
> Calling FlushVol is obviously not a solution as it would slow things down,
> and I don't really want to install a VBL to spin the cursor.
>
> Any ideas ?
>
> Cheers,
>
> Laurent Humbert
> [e-mail]
>

What you are experiencing is the cache being flushed out to disk.
It is possible that other people are accessing the file-system
while you are executing your loop.  Do you give time to other apps
in your loop?  If so, and they are accessing the file-system, they
could be causing the flush.

There is another possibility.  You haven't made it very clear, but
do you read some blocks from a file, modify them (or not) and then
write them to another file, setting the readNoCache bit?  If so,
then you really haven't accomplished much.  You should set the
readNoCache bit on the read also.  By the time you get to the
write, the blocks are already in the cache from the read, so the
dirty blocks will also be in the cache.

Why don't you post your read/write code and I can look at it.

Cameron Esfahani
[e-mail]
The Devil's Eye

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

>From [e-mail] (Ben Jackson)
Subject: Talking to the network (TCP) -- how?
Date: 11 Aug 1994 22:03:10 GMT
Organization: Purdue University

I've skimmed the last thousand or so articles in this group and I've
read several FAQ's with info about MacTCP.  Nothing I read said
anything about how to go about creating and using a TCP stream on a
Mac.  I got the source to NCSA Telnet and a few small network
utilities, and they each seem to implement TCP themselves!  Is there
any socket-like interface available?  Is there any way to to create and
use a TCP stream in under 30k of source?  What about DNS (ie how do I
look up hosts)?

I'm not a Mac developer; I'm just interested in writing a Mac client for
a workstation lab monitoring package I'm working on.  I've written the
MS Windows client using WINSOCK, and I was hoping the Mac version would
be equally easy.

Please email.  I'll summarize if I get any information I understand.  :-)
--
Ben Jackson, [e-mail]

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

>From [e-mail] (Mark Hanrek)
Date: Thu, 11 Aug 1994 19:33:07 -0800
Organization: The Information Workshop

In article <32e76u$[e-mail]>, [e-mail] (Ben
Jackson) wrote:

> I've skimmed the last thousand or so articles in this group and I've
> read several FAQ's with info about MacTCP.  Nothing I read said
> anything about how to go about creating and using a TCP stream on a
> Mac.  I got the source to NCSA Telnet and a few small network
> utilities, and they each seem to implement TCP themselves!  Is there
> any socket-like interface available?  Is there any way to to create and
> use a TCP stream in under 30k of source?  What about DNS (ie how do I
> look up hosts)?
>
> I'm not a Mac developer; I'm just interested in writing a Mac client for
> a workstation lab monitoring package I'm working on.  I've written the
> MS Windows client using WINSOCK, and I was hoping the Mac version would
> be equally easy.

To everyone,

It is unbelievable to me how many people do not consider drawing from
example source code.

It is clear to me, first of all, that when people make such mistakes, it
is not their fault.  Even though so many are quick to call such people
"clueless".

It is the fault of the methods we use that predispose people to waste so
much damned time being forced to pursue random paths toward success in
programming.

We aren't lions on the Savannah who must prove their skill at surviving
through the greatest hardships.

It is like pulling teeth to get computer people to see that the game of "I
know and you are going to have to figure out how to find out for yourself"
is absurd.

Then it always triggers a flame war amongst supposedly bright computer
people when you suggest that the Internet newsgroup is the problem.

- -

The solution is a modern electronic forum.

Forums have a memory.

And they have an arrow that points to "Start Here".

Obviously whatever arrow there is supposed to be on the internet, it's not
working.


Mark Hanrek
The Information Workshop

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

>From [e-mail] (Mark Hanrek)
Date: Thu, 11 Aug 1994 19:46:31 -0800
Organization: The Information Workshop

In article <32e76u$[e-mail]>, [e-mail] (Ben
Jackson) wrote:

> I've skimmed the last thousand or so articles in this group and I've
> read several FAQ's with info about MacTCP.  Nothing I read said
> anything about how to go about creating and using a TCP stream on a
> Mac.  I got the source to NCSA Telnet and a few small network
> utilities, and they each seem to implement TCP themselves!  Is there
> any socket-like interface available?  Is there any way to to create and
> use a TCP stream in under 30k of source?  What about DNS (ie how do I
> look up hosts)?
>
> I'm not a Mac developer; I'm just interested in writing a Mac client for
> a workstation lab monitoring package I'm working on.  I've written the
> MS Windows client using WINSOCK, and I was hoping the Mac version would
> be equally easy.

Ben,

You'll find the answers to your questions in example source code.

You will find example source code in issue #10 of "develop" (I think) that
demonstrates TCP through the construction of a netnews reader.  Also, you
will find example source code in the "networking" section of the snippets
area, all available at...

   ftp://ftp.apple.com/

You will also find other more simple kinds of examples in some of the
newsreaders that are accompanied by their source code. There are a
surprisingly large number of these.   You will be able to access such
things at the "sumex" and "umich" archives, but you can get to all of them
at once at...

   ftp://nic.switch.ch/

There are also some things in the c.s.m.p. digests.

You will also want to look through the resources offered in...

   comp.sys.mac.comm

Finally, there is some leading edge TCP stuff at...

   ftp://seeding.apple.com/

- ---

As you can see, you skipped a ton of things.  Don't feel bad about this,
as it is not your fault, but the fault of the system.  Later on, try to
make the system better for the next guy.

Get to know your resources, then help others get to know them too.

Good luck to ya.


Mark Hanrek
The Information Workshop

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

>From [e-mail] (David Phillip Oster)
Date: Fri, 12 Aug 1994 14:02:27 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)


But, most of the example of using MacTCP are crap. Nothing you should
use in any production program. When things go wrong on a network, and
the nature of networks is that things _always_ go wrong sooner or later,
the network code will retry a number of times.  This means that
occasionally, system calls will take orders of magnitude more time
than they normally do. For this reason, any program that does network
i/o, or even uses the serial port, should always, always, always use
asynchronous i/o, so the user interface won't block when these network
errors happen. Even if your program doesn't have a user interface, another
program running at the same time might, and if you hang, you'll hang
up the user.

It isn't enough for a forum to have a memory. We need away of attaching
peer review, pointers to revisions, and criticism&praise to the
source code in the archives.


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

>From [e-mail] (Pete Resnick)
Date: Fri, 12 Aug 1994 11:10:46 -0500
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>, [e-mail] (David Phillip
Oster) wrote:

>But, most of the example of using MacTCP are crap. Nothing you should
>use in any production program. When things go wrong on a network, and
>the nature of networks is that things _always_ go wrong sooner or later,
>the network code will retry a number of times.  This means that
>occasionally, system calls will take orders of magnitude more time
>than they normally do. For this reason, any program that does network
>i/o, or even uses the serial port, should always, always, always use
>asynchronous i/o, so the user interface won't block when these network
>errors happen. Even if your program doesn't have a user interface, another
>program running at the same time might, and if you hang, you'll hang
>up the user.

(*LOUD APPLAUSE HEARD FROM THE GALLERY*)

Bravo!

If you call any device driver synchronously, you're doing it wrong.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Doctoral Student - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

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

>From [e-mail] (Matt Mick)
Date: 12 Aug 1994 20:06:45 GMT
Organization: Boston University

** WRONG **  The Newswatcher source has asynchronous i/o examples!  I
use it all the time!

--matt

Pete Resnick ([e-mail]) wrote:
: In article <[e-mail]>, [e-mail] (David Phillip
: Oster) wrote:

: >But, most of the example of using MacTCP are crap. Nothing you should
: >use in any production program. When things go wrong on a network, and
: >the nature of networks is that things _always_ go wrong sooner or later,
: >the network code will retry a number of times.  This means that
: >occasionally, system calls will take orders of magnitude more time
: >than they normally do. For this reason, any program that does network
: >i/o, or even uses the serial port, should always, always, always use
: >asynchronous i/o, so the user interface won't block when these network
: >errors happen. Even if your program doesn't have a user interface, another
: >program running at the same time might, and if you hang, you'll hang
: >up the user.

: (*LOUD APPLAUSE HEARD FROM THE GALLERY*)

: Bravo!

: If you call any device driver synchronously, you're doing it wrong.

: pr
: --
: Pete Resnick        (...so what is a mojo, and why would one be rising?)
: Doctoral Student - Philosophy Department, Gregory Hall, UIUC
: System manager - Cognitive Science Group, Beckman Institute, UIUC
: Internet: [e-mail]

--
                    __  __
   ____ ___  ____ _/ /_/ /_    Matt Mick      M.S. Student in BioMedical Eng.
  / __ `__ \/ __ `/ __/ __/                   Boston Univ., Boston MA
 / / / / / / /_/ / /_/ /_
/_/ /_/ /_/\__,_/\__/\__/      Internet:  [e-mail]    AOL:  mattmick

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

>From [e-mail] (Mark Hanrek)
Date: Fri, 12 Aug 1994 13:46:05 -0800
Organization: The Information Workshop

In article <[e-mail]>, [e-mail] (David Phillip
Oster) wrote:

> It isn't enough for a forum to have a memory. We need away of attaching
> peer review, pointers to revisions, and criticism & praise to the
> source code in the archives.

Yes, yes, yes!!!!

There are intelligent people around!!!!!

Man-o-man.  You made my day!!

Thanks, David.  And, Pete.  Without the ability to attach and update, it's
like one step forward and one step back.

It also allows for "accumulation of knowledge and refinement" so that it
doesn't always seem like subjects are starting from the beginning all the
time. :) Such as the subject of what to call the next offshoot of
comp.sys.mac.*.

Okay, let's see....  a modern forum should be.... attachable, and...
updatable,...  and allow peer review....

Got it.


Thanks. :)

Mark

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

>From [e-mail] (Robert Mah)
Date: Fri, 12 Aug 1994 19:07:07 -0500
Organization: One Step Beyond

[e-mail] (Mark Hanrek) wrote:

) [e-mail] (David Phillip Oster) wrote:
)
) > It isn't enough for a forum to have a memory. We need away of attaching
) > peer review, pointers to revisions, and criticism & praise to the
) > source code in the archives.
)
) Yes, yes, yes!!!!
)
) There are intelligent people around!!!!!
)
) Man-o-man.  You made my day!!
)
) Thanks, David.  And, Pete.  Without the ability to attach and update,
) it's like one step forward and one step back.
)
) It also allows for "accumulation of knowledge and refinement" so that
) it doesn't always seem like subjects are starting from the beginning
) all the time. :) Such as the subject of what to call the next offshoot
) of comp.sys.mac.*.
)
) Okay, let's see....  a modern forum should be.... attachable, and...
) updatable,...  and allow peer review....

That's all very nice and I too would like to see such things...

But who's going to spend the money to make it happen?

THAT is the real issue.  We have the technology (or most of it), the
question is who is going to donate 10's of thousands of dollars of
equipment and comm expenses.  Volunteers?

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

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

>From [e-mail] (Mark Hanrek)
Date: Fri, 12 Aug 1994 17:58:23 -0800
Organization: The Information Workshop

>
> That's all very nice and I too would like to see such things...
>
> But who's going to spend the money to make it happen?
>
> THAT is the real issue.  We have the technology (or most of it), the
> question is who is going to donate 10's of thousands of dollars of
> equipment and comm expenses.  Volunteers?


Bringing greater awareness to this issue is one way of doing it.

The more people who become dissatisfied with the way things are with a
newsgroup, instead of accepting it, the more people who will be thinking
about the problems, subsequently solving the issues that come up.

Your question is legitimate.

What is interesting is though you have asked it, and I have clarified
something about it, it will only make a difference to you, because in a
couple of days, the subject will potentially start from the beginning
again.

This makes this medium only good for one thing... constantly brewing
dissatisfaction over it.

Unfortunately, it pretty much dissallows for the development of consensus,
and resolve, and even leadership.  Leadership is often needed to develop
consensus in the first place -- a viscious circle.

It's a toughie no matter which way we slice it.


Mark Hanrek
The Information Workshop

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

>From [e-mail] (Bruce Hoult)
Date: Sat, 13 Aug 1994 16:54:09 +1200 (NZST)
Organization: (none)

[e-mail] (Ben Jackson) writes:
> I've skimmed the last thousand or so articles in this group and I've
> read several FAQ's with info about MacTCP.  Nothing I read said
> anything about how to go about creating and using a TCP stream on a
> Mac.  I got the source to NCSA Telnet and a few small network
> utilities, and they each seem to implement TCP themselves!  Is there
> any socket-like interface available?  Is there any way to to create and
> use a TCP stream in under 30k of source?  What about DNS (ie how do I
> look up hosts)?

Get the source for NewsWatcher 2.0b9 <ftp://ftp.acns.nwu.edu/pub/newswatcher/>
It has several examples of small bits of code doing an incidental ftp transfer
and stuff like that.

-- Bruce

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

>From [e-mail] (Peter N Lewis)
Date: Sun, 14 Aug 1994 15:38:52 +0800
Organization: NCRPDA, Curtin University

>: In article <[e-mail]>, [e-mail] (David Phillip
>: Oster) wrote:
>
>: >But, most of the example of using MacTCP are crap. Nothing you should
>: >use in any production program. When things go wrong on a network, and
>: >the nature of networks is that things _always_ go wrong sooner or later,
>: >the network code will retry a number of times.  This means that
>: >occasionally, system calls will take orders of magnitude more time
>: >than they normally do. For this reason, any program that does network
>: >i/o, or even uses the serial port, should always, always, always use
>: >asynchronous i/o, so the user interface won't block when these network
>: >errors happen. Even if your program doesn't have a user interface, another
>: >program running at the same time might, and if you hang, you'll hang
>: >up the user.

I'm not entirely sure which code you're talking about.  NewsWatcher
doesn't do that, Finger doesn't do that, Eudora doesn't, even Telnet
doesn't.  So exactly which code is it that you are referring to?

>Pete Resnick ([e-mail]) wrote:

>: (*LOUD APPLAUSE HEARD FROM THE GALLERY*)
>
>: Bravo!
>
>: If you call any device driver synchronously, you're doing it wrong.

Sorry to disagree with you Pete, but that's not true.  There is no
problems at all with using syncronous TCPReceives if you check that the
characters are available before you call the code, then it's guarenteed to
return immediately.  You wont get as high throughput as with chained io
completions, but a lot fo code doesn't need maximal throughput (eg a
backup program where you don't want to toast the machine while the user is
working on it).
   Peter.
--
Peter N Lewis <[e-mail]> - Macintosh TCP fingerpainter

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

>From [e-mail] (Pete Resnick)
Date: Mon, 15 Aug 1994 00:02:49 -0500
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

>>: In article <[e-mail]>, [e-mail] (David Phillip
>>: Oster) wrote:
>>
>>: >But, most of the example of using MacTCP are crap. Nothing you should
>>: >use in any production program. [...A]ny program that does network
>>: >i/o, or even uses the serial port, should always, always, always use
>>: >asynchronous i/o, so the user interface won't block when these network
>>: >errors happen. Even if your program doesn't have a user interface, another
>>: >program running at the same time might, and if you hang, you'll hang
>>: >up the user.
>
>I'm not entirely sure which code you're talking about.  NewsWatcher
>doesn't do that, Finger doesn't do that, Eudora doesn't, even Telnet
>doesn't.  So exactly which code is it that you are referring to?

How about all of the Snippets in the Apple Sample Code? They all do
synchronous I/O. I believe the original NewsWatcher code (not the stuff
that John Norstad wrote) which was out for public distribution also used
synchronous I/O. Basically, it's the stuff that's coming out of Apple
that's garbage. I have seen you use PBControlSync on many an occasion too,
but I forgive you. :-)

>>Pete Resnick ([e-mail]) wrote:
>
>>: If you call any device driver synchronously, you're doing it wrong.
>
>Sorry to disagree with you Pete, but that's not true.  There is no
>problems at all with using syncronous TCPReceives if you check that the
>characters are available before you call the code, then it's guarenteed to
>return immediately.

No, it isn't guaranteed. Now, it turns out that you and I both know
something of the internals of the MacTCP device driver, that it does not
service queued requests serially, but instead things get ripped off the
queue and are handled whenever the driver deems it "appropriate" to do so.
But this just happens to be inside knowledge of how the MacTCP driver
works. There is nothing in the documentation that says this. For all you
know, the driver could be servicing some other request when your call
comes through and it could take a long time (relatively speaking) for your
TCPRcv call to complete. It's just not deterministic. And for the serial
driver, such an assumption would be *dead wrong*. If you know there are
characters available and you make a synchronous call to PBRead on the
serial driver, some call sitting in front of you in the queue could take a
virtual eternity to complete and hang the machine for your user. The best
policy is don't chance it.

>You wont get as high throughput as with chained io
>completions, but a lot fo code doesn't need maximal throughput (eg a
>backup program where you don't want to toast the machine while the user is
>working on it).

Now, I never mentioned chained I/O. All I am talking about is calling the
driver asynchronously. If you want to set ioCompletion to nil and sit in a
loop like:

    while(pb->ioResult > 0)
        WaitNextEvent(...);

that's up to you; as you say, throughput will suffer, but sometimes you
don't care about that. But I am convinced, and will defend to the end,
that there's no good reason for production code ever to set that async
flag in the Device Manager routines to false.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Doctoral Student - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

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

>From [e-mail] (Michael C. Diehr)
Subject: What fonts are always available?
Date: 26 Jul 1994 21:50:51 GMT
Organization: University of California at San Diego

I'm developing an after dark module that uses text, and I was wondering if
(with system 7.0 or later) there is a base-case set of fonts & font sizes
I can count on being available.

If not, can I put font resources in my After Dark module's resource fork
and have them work?  Would this be violating anyone's copyrights (standard
apple fonts).

thanks!

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

>From [e-mail] (Eric Bowman)
Date: 26 Jul 1994 22:44:32 GMT
Organization: Reed College,  Portland, Oregon

In article <[e-mail]>,
Michael C. Diehr <[e-mail]> wrote:
>I'm developing an after dark module that uses text, and I was wondering if
>(with system 7.0 or later) there is a base-case set of fonts & font sizes
>I can count on being available.

You really should let the user choose from whatever fonts are available
if at all possible.

cheers,
bobo

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

>From [e-mail] (SusanLesch)
Date: 26 Jul 1994 19:15:13 -0400
Organization: America Online, Inc. (1-800-827-6364)

  Re article <[e-mail]>,
  [e-mail] (Michael C. Diehr):

  Chicago 12, Geneva 9, Geneva 12, and Monaco 9 are the only fonts
  guaranteed to be on a normal U.S. System. The Mac reserved fonts
  have not changed with System 7.

  Some "standard Apple" fonts like Helvetica and Palatino are
  licensed to you through Apple from Linotype. Courier, Times, and
  the TrueType versions of Chicago, Geneva and Monaco are licensed
  to you by Apple.

  To the best of my understanding, U.S. law would allow you to
  redistribute bitmaps of these fonts, but not any outlines.

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

>From Jens Alfke <[e-mail]>
Date: Wed, 27 Jul 1994 01:02:56 GMT
Organization: Apple Computer

Michael C. Diehr, [e-mail] writes:
> If not, can I put font resources in my After Dark module's resource fork
> and have them work?  Would this be violating anyone's copyrights (standard
> apple fonts).

Putting fonts anywhere other than in the System folder is dangerous. The
reason is that, after your app/XCMD/After Dark module/etc. closes up shop,
the font resources are released but there may still be handles to them in
internal Font Manager caches. These handles are stale and will cause Bad
Things to happen if the Font Manager decides to use them.

It sucks, but that's the way it works. If your program _has_ to have a
particular nonstandard font to display properly, you have to supply a
suitcase and tell the user to install the font.

QuickDraw GX eliminates this problem with GX fonts. But I believe it's still
with us for traditional Mac fonts.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

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

>From [e-mail] (Pete Gontier)
Date: 26 Jul 1994 18:48:25 GMT
Organization: Integer Poet Software

In article <[e-mail]>
[e-mail] (Michael C. Diehr) writes:

> I'm developing an after dark module that uses text, and I was wondering if
> (with system 7.0 or later) there is a base-case set of fonts & font sizes
> I can count on being available.

Resources related to Chicago, Geneva, and Monaco are in the ROM of my
Q800 and my System 7.1 file. That's it. You can usually assume Times
and Courier and some other really common fonts exist, but you still
need to verify their presence and do something appropriate (like refuse
to run) if they're not.

> If not, can I put font resources in my After Dark module's resource fork
> and have them work?  Would this be violating anyone's copyrights (standard
> apple fonts).

IANAL, but I believe the standard dogma is that you will be able to
fight off legal claims that you stole bitmap fonts but not fonts which
are also "programs", like PostScript and TrueType fonts. Of course,
this assumes you want to do any legal fighting at all. I wouldn't do
anything without a piece of paper from whoever made the fonts granting
you permission to use them.

There are technical issues, too. For example, rename the fonts you
include in your AD module with leading '.' characters so that they
don't show up in menus created by AddResMenu. And otherwise be careful
someone else doesn't get hold of one of your fonts, or Bad Things might
happen when your module closes.

--

Pete Gontier // 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] (Kevin Ashbridge)
Date: Thu, 28 Jul 1994 15:15:06 GMT
Organization: Ciba-Geigy Ltd.,Basel,Switzerland

In article <3143kg$[e-mail]>
[e-mail] (Eric Bowman) writes:

> In article <[e-mail]>,
> Michael C. Diehr <[e-mail]> wrote:
> >I'm developing an after dark module that uses text, and I was wondering if
> >(with system 7.0 or later) there is a base-case set of fonts & font sizes
> >I can count on being available.
>
> You really should let the user choose from whatever fonts are available
> if at all possible.

As far as I understand it, the English-language Finder fonts (Chicago
12 and Geneva 9&12, Monaco 9) are available in every version of System
7.

Kevin.

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

>From [e-mail] (Bill Hofmann)
Date: Sun, 31 Jul 1994 22:16:09 GMT
Organization: Fresh Software

In article <[e-mail]>, [e-mail] (Kevin
Ashbridge) wrote:

> In article <3143kg$[e-mail]>
> [e-mail] (Eric Bowman) writes:
>
> > In article <[e-mail]>,
> > Michael C. Diehr <[e-mail]> wrote:
> > >I'm developing an after dark module that uses text, and I was wondering if
> > >(with system 7.0 or later) there is a base-case set of fonts & font sizes
> > >I can count on being available.
> >
> > You really should let the user choose from whatever fonts are available
> > if at all possible.
>
> As far as I understand it, the English-language Finder fonts (Chicago
> 12 and Geneva 9&12, Monaco 9) are available in every version of System
> 7.
Well, everyone's right here.  It's nice to let the user set fonts if it's
appropriate (create a menu using AddResMenu(mh, 'FONT')).  If you want to
choose  or set particular fonts, you should save the font name in a
resource, and use GetFNum() to get the font ID.

Another option is to use a few script manager verbs which will return
various combinations of FontID/FontSize for standard system, std
application, small font, large font, etc.  I've used these with good
results on a passel of international systems.

-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] (Pete Figliozzi)
Subject: [Q] Universal Headers
Date: 31 Jul 94 12:37:25 -0400
Organization: The Ohio State University, Department of Physics


What's the deal with these Universal Headers I keep hearing about?

Thanks,

Pete

[e-mail]


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

>From [e-mail] ( nick.c )
Date: Tue, 2 Aug 94 01:14:15 GMT
Organization: The Pitt, Chemistry

In Article <[e-mail]>,
[e-mail] (Pete Figliozzi) wrote:

>What's the deal with these Universal Headers I keep hearing about?

    As I understand it, they're a collection of header files
  also called "universal interface" that are made by Apple
  and ship with Symantec's environments, CodeWarrior, d e v e l o p,
  the developer mailing and I don't know what else.  The idea
  (as I understand it) is to give folks a standard set of routines
  so that you can access from any environment, and across
  various platforms.  The most frequent use I can think of is
  adjusting LoMem variables.  By using these routines, you can
  adjust LoMem variables consistently, and if Apple later changes
  the rom memory location, they just update the headers, and
  you don't have to change your application.

    This is probably an oversimplification, but that's as much
  as I've been able to figure out.  Oh, and Symantec has another
  set of headers they used to use, but they recommend that you
  start using the universal headers, MW doesn't give you a choice.

                                        -- nick


Disclaimer: Just my opinion.

   _/   _/  _/  _/_/_/   _/   _/ "Sea Shells to C shells,  Waikiki to
  _/_/ _/  _/  _/   _/  _/_/_/     the Internet, a wave, is a wave..."
 _/ _/_/  _/  _/       _/ _/          CIS: 71232,766  eWorld: nick
_/   _/  _/   _/_/_/  _/   _/            Internet: [e-mail]


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

>From [e-mail] (Tom Emerson)
Date: 3 Aug 1994 10:36:31 GMT
Organization: Symantec Development Tools Group

In article <[e-mail]>, [e-mail] ( nick.c ) wrote:

> In Article <[e-mail]>,
> [e-mail] (Pete Figliozzi) wrote:
>
> >What's the deal with these Universal Headers I keep hearing about?
>
>     As I understand it, they're a collection of header files
>   also called "universal interface" that are made by Apple
>   and ship with Symantec's environments, CodeWarrior, d e v e l o p,
>   the developer mailing and I don't know what else.  The idea
>   (as I understand it) is to give folks a standard set of routines
>   so that you can access from any environment, and across
>   various platforms.  The most frequent use I can think of is
>   adjusting LoMem variables.  By using these routines, you can
>   adjust LoMem variables consistently, and if Apple later changes
>   the rom memory location, they just update the headers, and
>   you don't have to change your application.

Well, actually this isn't correct. The universal interfaces were created
to allow developers to use a single, consistent set of interfaces when
building applications for both the 68K and PowerPC based Macintoshes.
Through ETO #14 the headers are not universal between development
environments - they are written with MPW in mind and as such have required
some modification for our compilers. I think MetroWerks has made minor
changes as well.

With regards to low-memory globals, you've always had a portable method of
accessing them through the "SysEqu.h" header where each global is
#define'd to its address. Using them was more involved than going through
our LoMem.h (note that absence of the 'w') but portable across Symantec
and Apple environments. What the universal "LowMem.h" gives you over
SysEqu.h is a functional wrapper around each global to support
compatibility with both 68K and PowerPC architectures.

Both MetroWerks and Symantec have been working with Apple at making the
universal interfaces "universal" across development environments. These
should be coming down the pipe RSN.

>     This is probably an oversimplification, but that's as much
>   as I've been able to figure out.  Oh, and Symantec has another
>   set of headers they used to use, but they recommend that you
>   start using the universal headers, MW doesn't give you a choice.

The other set of headers are Apple's latest 68K (non-universal)
interfaces, which we include for backwards compatibility for people
porting their applications to 7.0 from previous versions of the
environment. These are not the default set of interfaces used to build the
precompiled headers.

   -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] (Neil Ticktin)
Date: Tue, 9 Aug 1994 06:38:28 GMT
Organization: MacTech Magazine/Xplain Corporation

>> In Article <[e-mail]>,
>> [e-mail] (Pete Figliozzi) wrote:
>>
>> >What's the deal with these Universal Headers I keep hearing about?


Pete,

Check out the August issue (I think) of MacTech Magazine -- it puts the
whole concept of the new headers into perspective.

Hope it helps,

Neil

- ---------------------------------------------------------------------
           Neil Ticktin, MacTech Magazine (formerly MacTutor)
PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: [phone]
 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
  [e-mail] * [e-mail] * [e-mail]
[e-mail] * [e-mail] * [e-mail]
   [e-mail] * [e-mail] * [e-mail]

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

>From [e-mail] (anthony brown)
Subject: best c++ book...
Date: 10 Aug 1994 23:54:16 GMT
Organization: Harvard University, Cambridge, Massachusetts

I know that this question has probably been ascked before, but I was
wondering which would be the best book on C++ programming on the mac.

I was thinking about getting the dave mark learn c++ on the macintosh.  I
have also seen a bunch of books for symentech c++ programming.

Could anyone recommend a book?

I will be using symantech c++ 6.0.1 to learn, then after I get c++ down,
I'm switching to codewarrior.

Anthony
--
*********************************************************************
*                                                                   *
*  Anthony Brown, Macintosh Programming Intern, Harvard Universtiy  *
*                                                                   *
*  "Classic Rock Music Stations,  The 70's are calling,             *
*   They want their 8 - Tracks back!"                    *
*                                                                   *
*   Dolphin's Rule!! Undefeated 17 - 0  The Perfect Team 1972-73    *
*                                    *
*********************************************************************


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

>From [e-mail] ( nick.c )
Date: Thu, 11 Aug 94 00:47:46 GMT
Organization: The Pitt, Chemistry

In Article <32bpb8$[e-mail]>, [e-mail]
(anthony brown) wrote:

>I know that this question has probably been ascked before, but I was
>wondering which would be the best book on C++ programming on the mac.
>
>I was thinking about getting the dave mark learn c++ on the macintosh.  I
>have also seen a bunch of books for symentech c++ programming.

    Symantec.  no 'h'.

    Dave Mark's book is a good place to start, friendly, mac based
      and focused on the language.  Bjarne Stroustrup's book
      _The C++ Programming Language_ is the basis for C++, and
      a great reference but tough to start with.  I've appended
      some posts that I had saved on my HD regarding C++ book
      recommendations.



==========

Path: newsfeed.pitt.edu!gatech!willis1.cis.uab.edu!news.lsu.edu!zachary
From: [e-mail] (John Zachary)
Newsgroups: comp.sys.mac.programmer
Subject: Re: CodeWarrior Gold 4
Date: 9 Aug 1994 20:10:20 GMT
Organization: Dept. of Computer Science, LSU, Baton Rouge
References: <31ru9t$[e-mail]>
 <31uk5a$[e-mail]>
 <325ll6$[e-mail]>

In article <325ll6$[e-mail]> [e-mail] (Michael A.
Balfour) writes:
>>  I'd avoid the overly technical books such as Stroustrup's  The C++
>>Programming Language, ARM and always avoid K&R.  The generic books such as
>
>I disagree with this.  If you have experience in Pascal or another high
>level language (even C) and you'd like to learn C++, I'd recommend The
>C++ Programming Language by Bjarne Stroustrup.  I'm still reading
>through it, but for every page I've read so far, I've learned something
>new.  It's not for someone completely new to programming, but for a
>programmer trying to learn a new language I think it's a great book!
>
>Mike Balfour
>CWRU Grad Student




I totally agree. Another book I would recommend is "Advanced C++ Programming
Styles and Idioms" by James Coplien, ISBN 0-201-54855-0. I learned from
(and am still learning from) both Stroustup's and Coplien's book. Coplien's
discussion on virtual functions and inheritance is particularly  clear
and concise, IMHO.


Don't let the term "advanced" scare you off.

--
_________________________________________________________________
John Morris Zachary, Jr.                ([e-mail])
Louisiana State University    ([e-mail])
_________________________________________________________________


=============


From: [e-mail] (John Brewer)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Favorite C++ Book?
Date: 16 Apr 94 16:41:49 GMT
References: <[e-mail]>
Organization: Wolfram Research, Inc.

In article <[e-mail]> Bob Jacobsen,
[e-mail] writes:
>What books do people recommend for C++ on the Mac?

I'd recommend some general C++ books to start out with.  Once you've
mastered the syntax and the key concepts of the language, then you can
branch out into platform-specific things like GUI frameworks.  Trying to
do everything at once will result in information overload.

If I were teaching a C++ class right now, I'd have the following books be
required reading:
Lippman, Stanley _The C++ Primer_ (If you don't know C) OR
Pohl, Ira(?) _C++ for C Programmers_ (If you do know C)
Budd, Timothy _An Introduction to Object Oriented Programming_

The following would be recommended supplemental reading:
Meyers, Scott _Effective C++_

You'll probably also want to pick up one or both of the following for
reference:
Stroustrup, Bjarne _The C++ Programming Language_
Ellis & Stroustrup _The Annotated C++ Reference Manual_

The reason I recommend either Lippman or Pohl is that, while Lippman is
probably the better book, it assumes you have no knowledge of C.  Since
Ihave over a decade of experience with C, I resent being told what a
"break" statement is again.  I also find that when I try to skip over
the stuff I already know, I invariably skip some new stuff by mistake.
Pohl assumes you know C, and therefore only covers the differences.  I
appreciate this approach.

Budd is a general book on object-oriented programming.  It deals with
primarily with general concepts, not syntax, and has examples in C++,
Objective C, Object Pascal, and Smalltalk.  It introduces the concepts
of classes and inheritance, as well as responsibility-driven design and
CRC cards.

Meyers is the best _second_ book on C++ that I know of.  It contains a
lot of general tips for writing better code.  The introduction alone
explained copy constructors better than some entire books.

I don't recommend Stroustrup as an introduction to C++, as it is way too
terse, but you really need it and/or the ARM as a language reference.

Good luck!

John Brewer
Wolfram Research, Inc.
(but speaking for myself)

==============


     Interet: [e-mail]         _/   _/  _/  _/_/_/   _/   _/
      eWorld: nick                 _/_/ _/  _/  _/   _/  _/_/_/
         CIS: 71232,766           _/ _/_/  _/  _/       _/ _/
                                 _/   _/  _/   _/_/_/  _/   _/

           "Science is nothing but perception" - Plato


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

>From [e-mail] (Howard Berkey)
Date: Thu, 11 Aug 1994 19:46:36 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <32bpb8$[e-mail]> [e-mail] (anthony brown) writes:
>I know that this question has probably been ascked before, but I was
>wondering which would be the best book on C++ programming on the mac.
>

I may get flamed for it, but I'll reiterate my opinion:  there are no
good books for learning C++ programming for any platform.

Your best bet is to pick up a good book on C++, i.e. the ARM, and to
pick up a good book on object oriented programming, like "Object
Oriented Programming: an evolutionary approach" by Cox and Novobilski,
or any other good OOP book.  Read the OOP book first.


>Could anyone recommend a book?
>
>I will be using symantech c++ 6.0.1 to learn, then after I get c++ down,
>I'm switching to codewarrior.
>

Do not use SC++ 6.x to learn C++.  At least update to the 7.x compiler
first.  There should be free updaters available on the net.

-H-






--
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Howard Berkey                                             [e-mail]
Segmentation Fault (core dumped)

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

>From [e-mail] ( nick.c )
Date: Thu, 11 Aug 94 20:31:46 GMT
Organization: The Pitt, Chemistry

In Article <[e-mail]>, [e-mail] (Howard Berkey)
wrote:

>Do not use SC++ 6.x to learn C++.  At least update to the 7.x compiler
>first.  There should be free updaters available on the net.

   ... at devtools.symantec.com and sumex-aim.stanford.edu.


     Interet: [e-mail]         _/   _/  _/  _/_/_/   _/   _/
      eWorld: nick                 _/_/ _/  _/  _/   _/  _/_/_/
         CIS: 71232,766           _/ _/_/  _/  _/       _/ _/
                                 _/   _/  _/   _/_/_/  _/   _/

           "Science is nothing but perception" - Plato


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

>From [e-mail] (Howard Berkey)
Date: Fri, 12 Aug 1994 05:58:36 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <[e-mail]> [e-mail] ( nick.c ) writes:
>In Article <[e-mail]>, [e-mail] (Howard Berkey)
>wrote:
>
>>Do not use SC++ 6.x to learn C++.  At least update to the 7.x compiler
>>first.  There should be free updaters available on the net.
>
>   ... at devtools.symantec.com and sumex-aim.stanford.edu.
>
>


Yep, thanks.  With any version greater than 6.0 you should be OK;
there were enough bugs in the point-oh version to make it very
frustrating to use to try to learn C++.

('you' referring to the original poster, of course).


-H-
--
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Howard Berkey                                             [e-mail]
Segmentation Fault (core dumped)

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

>From [e-mail] ()
Subject: testing if a sound is done
Date: Mon, 1 Aug 1994 19:29:07 GMT
Organization: University of California, Davis

Thanks for all the help with playing sounds asynchronously! :)  I found some source code and used it, and it's working great!  But now I need one more thing, I need to test if a sound is done playing.  I've tried:

if( SoundDone() )
    SndPlay( myChannel, mySoundHandle, true );

but it seems like SoundDone() returns true even when a sound is playing, because I get a whole bunch of sounds going one after the other.

So am I using SoundDone() incorrectly, or do I test to see if sounds are done playing a different way? Any help would be greatly appreciated!!

   ....   ...  ( ..    .......
       ..     .   ...    ..         Sean Logan
     .......         ..     ...
   .....   .   .  ....   .          [e-mail]
    ..   .     |\
 ...           ; `------.
             .'         ,~~
          @ /  .-----,;'
       @   @  @@     '
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

>From [e-mail] (Spencer Low)
Date: 1 Aug 1994 14:33:52 -0700
Organization: LowTek Creations

(Please wrap your messages to 75 columns if possible. Makes it a whole
lot easier to quote your stuff. Thanks :-)

Perhaps _SoundDone returns true, since the sound is done in the sense
that SndPlay has returned (since it's asynchronous). Have you thought
about using a completion routine that sets a flag? Then you could even be
sound specific (i.e. if (FireSoundDone()) ...).

Spencer
--
________________________________________________________________________
    Spencer Low ------- LowTek Creations ------- [e-mail]

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

>From [e-mail] (Christian Franz)
Date: Tue, 02 Aug 1994 15:18:28 +0000
Organization: Union Bank of Switzerland, CH

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

> Thanks for all the help with playing sounds asynchronously! :)  I found
some source code and used it, and it's working great!  But now I need one
more thing, I need to test if a sound is done playing.  I've tried:
>
> if( SoundDone() )
>         SndPlay( myChannel, mySoundHandle, true );
>
> but it seems like SoundDone() returns true even when a sound is playing,
because I get a whole bunch of sounds going one after the other.

I usually install a little callback procedure that sets a boolean flag for
the sound channel. Before starting the sound, I set the StillRunning flag
to true. Then, in the callback proc, I set it to false.
Therefore, all my program has to do is to scan all allocated sound channels
(in an array of ExtendedSoundChannelH) to find those who have run out.

In case I don't sound too clear about it, the StillRunning flag is riding
piggyback on the normal sound channel data structure, much like the window
information rides on the GrafPort data struct.

>
> So am I using SoundDone() incorrectly, or do I test to see if sounds are
done playing a different way? Any help would be greatly appreciated!!
>

>    .....   .   .  ....   .          [e-mail]

Cheers,
Christian

--
Christian Franz                    *       Union Bank of Switzerland, CH
[e-mail]     <- at home ->               [phone]
                      -= Project Final Frontier =-


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

>From Darrin Cardani <[e-mail]>
Date: Tue, 2 Aug 1994 13:40:50 GMT
Organization: AT&T Global Information Solutions, Atlanta

>In article <31jpo0$[e-mail]> Spencer Low writes:
>(Please wrap your messages to 75 columns if possible. Makes it a whole
>lot easier to quote your stuff. Thanks :-)
>
>Perhaps _SoundDone returns true, since the sound is done in the sense
>that SndPlay has returned (since it's asynchronous). Have you thought
>about using a completion routine that sets a flag? Then you could even be
>sound specific (i.e. if (FireSoundDone()) ...).

You could also try SndChannelStatus (); I believe it tells you when a sound
is done.

Darrin







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

>From [e-mail] (Thomas Reed)
Date: Tue, 02 Aug 1994 10:29:38 -0500
Organization: Washington University

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

>Thanks for all the help with playing sounds asynchronously! :)  I found
some source code and used it, and it's working great!  But now I need one
more thing, I need to test if a sound is done playing.

It doesn't sound like the code you found did a very good job.  It should
define a completion routine that will run when the sound completes.  You
can use the completion routine to set a flag to say the sound is done.  Of
course, if you want continous, uninterupted sound, like looping music or
something like that, you have to do things very slightly differently.

If you're interested in some better source code, I've got some.  I won't
claim that my code is perfect, or even near perfect.  But it gets the job
done, and it's not unstable.  It just isn't very flexible.  (Mainly
because it did what I needed it to, so I didn't bother to refine it
further.)  In the source code for my shareware solitaire game, you can
find a custom sound library.  I believe that the only place the code is
available right now is here:

  ftp://thomas_mac.wustl.edu/Public/for_ftp/Solitaire_code.sit

It was done in THINK C 5.0.

Hope this helps!  Let me know if you have any questions about my code...

-Thomas

=====================================================
Thomas Reed                     Washington University
[e-mail]           Medical School
[e-mail]            Saint Louis, MO
- ---------------------------------------------------
Clothes make the man.  Naked people have little or no
influence on society.  -- Mark Twain
=====================================================

Opinions posted are not the opinions of Wash. U.

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

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