Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-224.txt

Text File | 1994-12-08 | 41.8 KB | 1,239 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 21 Dec 92       Volume 1 : Issue 224

Today's Topics:

    Button() not callable from interrupt ?
    looking for a REALLY RaNdOM "RANDOM"
    MachineLocation dlsDelta: can I set?
    XVT's Portability Toolkit
    sndPlay while animating
    INIT's/System Extension Questions
    is there a way to find out who is using an app ?
    Hilite a Rect



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

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.  You can post articles to any newsgroup by
mailing your article to [e-mail].  So, to post an
article to comp.sys.mac.programmer, you mail it to
[e-mail].  Note the '-' instead of '.'
in the newsgroup name.

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
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month 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 entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


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

From: [e-mail] (Robert Lukassen)
Subject: Button() not callable from interrupt ?
Date: 9 Nov 92 09:36:42 GMT
Organization: Eindhoven University of Technology, the Netherlands

Hi,

I ran into a bit of trouble the other day when I tried to read the state of the
mouse-button from an interrupt-routine. I know that the state of the mouse-button
is represented by a single bit in some low-memory variable and this works well, but
why does (the old version of) Inside Macintosh claims that Button() can move or purge
memory. That is absolutely insane! A simple fetch of a low-memory variable can't
trigger a memory move or memory purge. What are they doing that makes calling
Button() so dangerous?

Robert
- --
+--------------------------------------+--------------------------------------+
|  Robert 'MacBear' Lukassen           |  Eindhoven University of Technology  |
|  Email: [e-mail]       |  The Netherlands                     |
+--------------------------------------+--------------------------------------+
| 'So logically ?  If she weighs the same as a duck, she's made of wood...    |
|  And therefore ?  ...a WITCH !!!!'   - Monty Python, the Holy Grail.        |
+-----------------------------------------------------------------------------+

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

From: [e-mail] (Phil Shapiro)
Date: 9 Nov 92 14:40:20 GMT
Organization: Symantec Corp.

>>>>> On 9 Nov 92 09:36:42 GMT, [e-mail] (Robert Lukassen) said:

 > I ran into a bit of trouble the other day when I tried to read the
 > state of the mouse-button from an interrupt-routine. I know that
 > the state of the mouse-button is represented by a single bit in
 > some low-memory variable and this works well, but why does (the old
 > version of) Inside Macintosh claims that Button() can move or purge
 > memory. That is absolutely insane! A simple fetch of a low-memory
 > variable can't trigger a memory move or memory purge. What are they
 > doing that makes calling Button() so dangerous?

I ran into a similar situation with GetMouse(), which IM I also
documents as moving memory. It turns out that the only time Button()
and GetMouse() (as well as some others) move memory is when then
all-but-dead Journaling Mechanism is enabled. (Supposedly it was
reserved in System 7 for a revised version of MacroMaker, one of the
few macro tools that actually used journaling. Thankfully, MacroMaker
rests in peace...)

If you disassemble these routines, you'll find that they check
JournalFlag at 0x8DE to see if journaling is currently enabled. A
possible solution is to add a similar check to your own code and use a
low mem global when necessary; it's probably simpler to always examine
low memory directly.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

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

From: [e-mail] (Larry Rosenstein)
Date: 9 Nov 92 18:23:05 GMT
Organization: Taligent, Inc.

In article <[e-mail]>,
[e-mail] (Robert Lukassen) wrote:
>
> mouse-button from an interrupt-routine. I know that the state of the

Use OSEventAvail with a 0 mask.  The event record will contain the state of
the mouse button.

Larry Rosenstein
Taligent, Inc.

[e-mail]

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

From: [e-mail] (Eric Schlegel)
Date: 10 Nov 92 16:36:53 GMT
Organization: Microsoft Corporation

In article <[e-mail]> [e-mail] (Robert Lukassen) writes:
>I ran into a bit of trouble the other day when I tried to read the state of the
>mouse-button from an interrupt-routine. I know that the state of the button
>is represented by a single bit in some low-memory variable and this works well,
>but why does (the old version of) Inside Macintosh claims that Button() can
>move or purge memory. That is absolutely insane! A simple fetch of a low-memory
>variable can't trigger a memory move or memory purge. What are they doing that
>makes calling Button() so dangerous?

Unfortunately, they're checking to see if journalling is on, and if so, making
a call to the journalling driver, which CAN move memory. It's not just a simple
fetch.

I had the same problem - currently I'm reading MBState directly, for lack of
a better solution, but I sure wish there was a better way...

- -eric
- ------
My opinions, not Microsoft's.

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

From: [e-mail] (Larry Rosenstein)
Date: 12 Nov 92 17:35:32 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Larry
Rosenstein) wrote:
>
> Use OSEventAvail with a 0 mask.  The event record will contain the state of
> the mouse button.

Unfortunately, this is wrong.  Eric Schlegel pointed out that the DTS Q&A
stack says that if Balloon Help is turned on, then OSEventAvail can move
memory.

Larry Rosenstein
Taligent, Inc.

[e-mail]

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

From: [e-mail] (Roby Sherman)
Subject: looking for a REALLY RaNdOM "RANDOM"
Date: 8 Nov 1992 12:09:06 -0500
Organization: The Tao of Programming

Hello all.

I'm looking for a pascal piece of code that illustrates a really nice
random number generation.

I'm working on an INIT that needs a few random numbers and at boot time,
Apple's RANDOM function seems to always retrurn the same old thing.
Any ideas?


          Thanks in advance...


                   --Roby

- --
[e-mail]                    Roby Sherman

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

From: [e-mail] (Bill Williams)
Date: 9 Nov 92 03:19:10 GMT
Organization: HoloNet (BBS: 510-704-1058)

Request for GOOD random number generator in Pascal:

I have lots of random number generator source, most are in "C" two are in
68000 assembly but one of them (My ultimate favorite) is actually in
Pascal (The language you requested) here it is:


===========

UNIT Portable_Random_Numbers;
INTERFACE

    FUNCTION Fetch_Random_Numbers: real;

    PROCEDURE Manually_Initialize_Seeds (value_1, value_2: LONGINT);

    PROCEDURE Auto_Initialize_Seeds;


IMPLEMENTATION

    VAR
        Random_Number_Seed_1, Random_Number_Seed_2: LONGINT; {
signed 32-bit integers }

    FUNCTION Fetch_Random_Numbers: real;

        VAR
            zz, kk: longint;

    BEGIN

        kk := Random_Number_Seed_1 DIV 53668;
        Random_Number_Seed_1 := 40014 * (Random_Number_Seed_1 - kk
* 53668) - kk * 12211;
        IF Random_Number_Seed_1 < 0 THEN
            Random_Number_Seed_1 := Random_Number_Seed_1 + 2147483563;

        kk := Random_Number_Seed_2 DIV 52774;
        Random_Number_Seed_2 := 40692 * (Random_Number_Seed_2 - kk
* 52774) - kk * 3791;
        IF Random_Number_Seed_2 < 0 THEN
            Random_Number_Seed_2 := Random_Number_Seed_2 + 2147483399;

        zz := Random_Number_Seed_1 - Random_Number_Seed_2;

        IF zz < 1 THEN
            zz := zz + 2147483562;

        Fetch_Random_Numbers := zz * 4.65661E-10;

    END;


    PROCEDURE Manually_Initialize_Seeds (value_1, value_2: LONGINT);

{ This is for repeatable use of the Random number generator }
{ requirement is that  Random_Number_Seed_1 be in the range [1,
2_147_483_562] and  Random_Number_Seed_2 }
{ be in [1, 2_147_483_398] ( [ -2**31 + 85, 2**31 - 85 ]). }

    BEGIN
        Random_Number_Seed_1 := value_1;
        Random_Number_Seed_2 := value_2;
    END;


    PROCEDURE Auto_Initialize_Seeds;

{ This version of Initialize_Seeds is Macintosh dependent. The theoretical }
{ requirement is that  Random_Number_Seed_1 be in the range [1,
2_147_483_562] and  Random_Number_Seed_2 }
{ be in [1, 2_147_483_398] ( [ -2**31 + 85, 2**31 - 85 ]). Here,
Random_Number_Seed_1 and }
{  Random_Number_Seed_2 are in [0, 32_737]. See reference [1] cited in the
comments of }
{ Fetch_Random_Numbers for more information on generating seeds. }

    BEGIN
        GetDateTime(randSeed);
        Random_Number_Seed_1 := abs(Random);
        Random_Number_Seed_2 := abs(Random);
    END;



END. { Portable_Random_Numbers }
- -------------


It is a classic Multiplicative Linear Congruential Generator as known
about for over 20 years and proven to be the best "shitty" safe and
equally distributed, evenly repeating random technique.

references :

{1. L'Ecuyer, Pierre, Efficient and Portable Combined Random Number }
{ Generators. Communications of the ACM, 31, 6 (June 1988), 742-749, 774 }

L'Ecuyer reports that a comprehensive battery of over 20 different tests
were performed on the generator that involved billions of psuedo-random
numbers and over 200 hours of VAX-11/780 CPU time. The empirical behavior
of the generators is very satisfactory for this class of generator.


Hope that solves it!

Bill Williams

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

From: [e-mail] (Tony Wingo)
Date: Mon, 9 Nov 1992 21:38:04 GMT
Organization: Apple Computer

In article <[e-mail]>, [e-mail]
(Roby Sherman) wrote:
>
> Hello all.
>
> I'm looking for a pascal piece of code that illustrates a really nice
> random number generation.
>
> I'm working on an INIT that needs a few random numbers and at boot time,
> Apple's RANDOM function seems to always retrurn the same old thing.
> Any ideas?
>

To the best of my knowlege, Apple's random number generator is based on
Park and Miller's "Minimal Standard Random Number Generator", which is
about as good as you are going to get for a 31-bit multiplicative residue
RNG.  The reason you are always getting the same sequence is that you are
not setting the seed to something different each time you start up.  Set it
to something like the time of day.

For coding examples, and some theory, check out Park and Miller's article:
"Random Number Generators: Good Ones Are Hard To Find", CACM Vol 31, Number
10 (Oct 1988).

And of course, if you really want to get down to the nitty-gritty theory
behind RNG's, there is always Vol 2. of Knuth.

- -tony
>>usual disclaimer<<

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

From: [e-mail] (Sandra Stewart-Cole)
Date: 12 Nov 92 21:55:44 GMT
Organization: University of Illinois at Urbana

In <[e-mail]> [e-mail] (Roby
Sherman) writes:

>Hello all.

>I'm looking for a pascal piece of code that illustrates a really nice
>random number generation.

>I'm working on an INIT that needs a few random numbers and at boot time,
>Apple's RANDOM function seems to always retrurn the same old thing.
>Any ideas?


interesting thing to note... I suppose it is because the seed for it is
connected to how long the machine has been on? (i.e. in the same Mac, an INIT
will see the same thing every time)

If you want a way of generating different random numbers, the principle isn't
too tough. one quick psuedo-random number would just be some modulo math on the
current date/time value. (for example, date mod 99 will give you a random
number between 0 and 98) Depending on how random you want the number, you can
get into some very fancy number twiddling to make things more erratic, but in
all likelihood, some modulo of the date/time (which is seconds since 12 am
1/1/04) with an odd value should give you a useable base.

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

From: [e-mail] (Bill Hofmann)
Subject: MachineLocation dlsDelta: can I set?
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Date: Fri, 13 Nov 1992 18:02:13 GMT

IM V describes the MachineLocation struct and routines to set/get the
CPU's location.  One of the fields is gmtFlags.dlsDelta, which is totally
undocumented, and from what I can tell, unused, but always 0.  I'd love to
use it for, of all things, daylight savings delta information.  Is there anyone
who knows anything about this field?  Anyone care to email me on the
side with Apple's future plans? (I'm already so non-disclosed, I can't
tell you my real name...).

- -Bill Hofmann (or so you think)

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

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Fri, 13 Nov 1992 20:36:41 GMT

[e-mail] (Bill Hofmann) writes:

>IM V describes the MachineLocation struct and routines to set/get the
>CPU's location.  One of the fields is gmtFlags.dlsDelta, which is totally
>undocumented, and from what I can tell, unused, but always 0.  I'd love to
>use it for, of all things, daylight savings delta information. Is there anyone
>who knows anything about this field?  Anyone care to email me on the
>side with Apple's future plans? (I'm already so non-disclosed, I can't
>tell you my real name...).

Back in February, I asked an Apple person (whose identity I will
protect) about just this issue and got the following response:

>Unfortunately, there aren't any plans right now to use the dlsDelta field
>of the MachineLocation record. That's really sad considering it's right
>there and useable, but there's nothing there to trust, just like you
>suspected.

[...Some gross INIT ideas to slove a problem that I posed to him...]

>I hope these ideas help you. It's a tough problem, and I can't think of any
>clean solutions. If you decide to use a dirty solution like the one I
>described, make sure you do a lot of testing, especially when new system
>software releases are done. I'll suggest to the system software engineers
>that the dlsDelta field should be used in future system software releases.

It doesn't look good.

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

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

From: [e-mail] (Daryl Spitzer)
Subject: XVT's Portability Toolkit
Organization: MIND LINK! - British Columbia, Canada
Date: Fri, 13 Nov 1992 19:57:12 GMT

Does anyone know anything about XVT's Portability Toolkit?  A friend pointed
out their ad. in BYTE.  He tells me it's expensive, but if it does what they
advertise, it would be worth it:

        - supports Mac, Microsoft Windows, OS/2 PM, OPEN LOOK, OSF/Motif
          & character

        - native look & feel

        - access to complete functionality of each system

So is this for real?

(If so, why should one wait for Bedrock?)

- --
- -------------------------------------------------------------------
 [e-mail]     "Life isn't just, life just is."
         [e-mail]              -- Me  (I think.)
- -------------------------------------------------------------------

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

From: [e-mail] (John Werner)
Date: 13 Nov 92 21:03:15 GMT
Organization: UC Berkeley School of Education

In article <[e-mail]>, Daryl Spitzer wrote:
>
> Does anyone know anything about XVT's Portability Toolkit?
> [...]
> So is this for real?

Here's an editied verion of what I answered last time someone asked this
(in comp.lang.c++)...

At my last job I was involved in a research project evaluating future
cross-platform projects.  We spent most of our time evaluating and
prototyping with XVT.  One of their current products is also mostly written
with XVT.  So I can give you some opinions.

For totally-from-scratch portable development of simple applications, XVT
probably isn't so bad.  Code that's written using just the XVT api is
indeed portable.  The catch is that the API is basically a lowest common
denominator of all the environments it supports.  The people at XVT will
deny this; it's sort of a religious issue with them.  But just try to get
them to support some functionality that isn't directly supported by all the
environments, and you'll find out the truth.  We were trying to get them to
support floating windows and pop-up menus, among other things, and they
refused, basically for religious reasons.

What little I saw of XVTs C++ class library made me want to run and hide.
It was just a set of wrapper classes around the various objects in the C
api.  I spent a fair amount of time writing my own MacApp-inspired C++
library around XVT.  It's possible to do, and it was actually kind of fun
for me, but it's something XVT should have done themselves.  I think
writing a real class library is definitely the way to go if you plan to
write a large user interface with XVT.

One more complaint: XVTs resource language is a piece of junk.  It's
impossible to be any more polite about it than that.  It really stinks out
loud.  For all but the simplest applications you'll have to code the
resources separately on each platform.

And finally, the programmers at my last job who developed a Windows product
using XVT absolutely HATED it.  Part of this was related to dialog box
support: XVT doesn't have a very complete or flexible set of dialog
functions.  They don't allow you to define custom controls in dialogs at
all portably.  Related to this is the fact that mixing platform-specific
code into an XVT application is a major nightmare; you start running into
lots of "who's in charge" issues, and lots of things that are just plain
XVT bugs.  We had the source code, so at least we could fix them.

Summary: If you're writing a simple program, without complicated dialogs,
or if you're willing to take the time to write a large class library around
XVT, it might be worth using.  Otherwise don't.

PS: Have you considered writing in MacApp and then porting to Bedrock (the
new portable class library being developed by Apple and Symantec) when it
comes out (sometime next year?)?

> (If so, why should one wait for Bedrock?)

Bedrock is going to be an entirely different animal: an application
framework/class library, ala MacApp.

- --
John Werner                         [e-mail]
UC Berkeley School of Education     510-642-9651

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

From: [e-mail] (Matthew Alan Kane)
Subject: sndPlay while animating
Date: 15 Nov 92 19:08:01 GMT
Organization: School of Computer Science, Carnegie Mellon

Situation:
I have animation running during vbl
and am playing snd resources with sndPlay.

Problem:
How do I keep my animation going while the sound is playing?

Thanks,

Matthew Kane
[e-mail]

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

From: [e-mail] (M. Scott Smith)
Date: 15 Nov 92 23:58:30 GMT
Organization: The Great Beyond

In article <[e-mail]> [e-mail] (Matthew Alan Kane) writes:
>Situation:
>I have animation running during vbl
>and am playing snd resources with sndPlay.
>
>Problem:
>How do I keep my animation going while the sound is playing?
>
>[e-mail]

Hi..

   I assume when you call SndPlay, the computer then freezes until it's
done playing the sound?  Or even if you're playing it asynchronously and
that's not working well, the following should help.

   I wrote some simple code in Think C for a game I'm working on to play
sounds in the background.  For me the sounds seem totally independent of
the animation; that is, the animation doesn't get in the way of the sound
and vice-versa.  It works.

Here's the code:

First, set up a sound channel.

void ThisWorks(void)
{
  SndChannelPtr   myChannel;
  OSErr           myErr;
  SndCommand      mySndCommand;
  Handle          mySoundEffect;

  myErr = SndNewChannel(&myChannel, sampledSynth, initMono, nil);

  mySoundEffect = GetResource('snd ', SOUND_RESOURCE_ID);

  mySndCommand.param1 = 0;
  mySndCommand.param2 = 0;
  mySndCommand.cmd = flushCmd;

  myErr = SndDoImmediate(myChannel, &mySndCommand);
  myErr = SndPlay(myChannel, mySoundEffect, true);
}

Of course, you need to include <sound.h> at the beginning of your program.

I'm not certain the "flushCmd" deal is necessary..  (I wrote this awhile ago,
in Pascal at first, so if you're using Pascal and have a problem converting
it, buzz me.)  I think that just flushes the channel in case any other sounds
are playing on it.

Actually, it's useful to set up multiple channels (on sound-capable Macs you
have 4), because then you can use one channel for a continuous soundtrack,
and another channel for sound effects, etc.  (Of course this method might
cause problems if you're competing with other programs for the same channel,
etc.)

Hope that helps!

M. Scott Smith
  ([e-mail] || [e-mail])

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

From: [e-mail] (Jim Reekes)
Date: 16 Nov 92 21:19:52 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (M. Scott Smith) wrote:
>
> In article <[e-mail]> [e-mail] (Matthew Alan Kane) writes:
> >Situation:
> >I have animation running during vbl
> >and am playing snd resources with sndPlay.
> >
> >Problem:
> >How do I keep my animation going while the sound is playing?
>
> Here's the code:
>
> First, set up a sound channel.
>
> void ThisWorks(void)
> {
>   SndChannelPtr   myChannel;
>   OSErr           myErr;
>   SndCommand      mySndCommand;
>   Handle          mySoundEffect;
>
>   myErr = SndNewChannel(&myChannel, sampledSynth, initMono, nil);
>
>   mySoundEffect = GetResource('snd ', SOUND_RESOURCE_ID);
>
>   mySndCommand.param1 = 0;
>   mySndCommand.param2 = 0;
>   mySndCommand.cmd = flushCmd;
>
>   myErr = SndDoImmediate(myChannel, &mySndCommand);
>   myErr = SndPlay(myChannel, mySoundEffect, true);
> }

You didn't initialize the channel pointer before calling SndNewChannel.
This will trash random locations of memory.  You need to add the line:

    myChannel = nil;

before calling SndNewChannel.

> I'm not certain the "flushCmd" deal is necessary..

It's not.  Also, the next problem is that after you play this sound you
need to know when you can dispose of the sound channel.  Also, in this
example the channel was a local variable on the stack so you'll lose your
referece to it.  It needs to be a global or some how be made available
later in the program so you can call SndDisposeChannel. Using a
CallBackProc and the callBackCmd will help you to determine when the sound
has finished.

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

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

From: [e-mail] (Marc Lesure)
Subject: INIT's/System Extension Questions
Date: 5 Nov 92 18:46:23 GMT
Organization: Arizona State University

I have an INIT that I wrote under System 6.x which works just fine.  The
INIT still works under System 7.0 if it resides in the System folder,
however if I put it in the Extension folder it fails.  The problem seems to
be the call to the routine OpenDriver(), under the extension folder it
returns the error openErr.  The device driver resides in the INIT resource
fork.  Any suggestions?

Also, are there any snippets showing the best way to show an INIT icon
during the booting sequence?

Thanks!

- -----------------------------------------------------------------------
Marc Lesure / Arizona State University / Tempe, AZ
"Between the world of men and make-believe, I can be found..."
"False faces and meaningless chases, I travel alone..."
"And where do you go when you come to the end of your dream?"

UUCP:       ...!ncar!noao!asuvax!lesure
Internet:   [e-mail]

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

From: [e-mail] (Christopher Klaus Larson)
Date: 9 Nov 92 01:08:45 GMT
Organization: College of Engineering - University of California - Davis

In article <[e-mail]> [e-mail] (Marc Lesure) writes:

>Also, are there any snippets showing the best way to show an INIT icon
>during the booting sequence?

I'm not sure if this is the _best_ way to show an icon during startup, but
it has always worked for me. :-)

Feel free to use this as you see fit. Optimizations and bug fixes welcome.

It is written in THINK C and requires the inclusion of the MacTraps library.
Hopefully the comments within the code are a sufficient explination of how
it works.

I have seen other examples that perform this operation but they were
written in assembly.

Sorry about the lines longer than 80 characters.

- -- Chris
[e-mail]

Code Follows ...
- ----------------------

/******************************************************************************

    Draw_Init_Icon.c    1992 - Chris Larson

    This function will draw an Init's icon on the screen during startup.

    Include the line,

        extern void Draw_Init_Icon (short icon_id);

    in your INIT source with your function prototypes and pass in the
    resource ID of the icon you wish to be drawn. If color QD exists, the
    function will attempt to draw a 'cicn' resource. If there is no color QD,
    it will draw an 'icn#'. If an error occurs, SysBeep is called and nothing
    is drawn.

******************************************************************************/

#include <Quickdraw.h>
#include <Types.h>
#include <OSUtils.h>
#include <Resources.h>
#include <Memory.h>
#include <LoMem.h>

#define DI_INITIAL_OFFSET       8
#define DI_BOTTOM_OFFSET        8
#define DI_ICON_HEIGHT          32
#define DI_ICON_WIDTH           32
#define DI_ICON_OFFSET          8
#define DI_NO_COLOR_QD          0x4000
#define DI_BEEP_LENGTH          30
#define DI_ICNPOUND_ROWBYTES    4
#define DI_INCPOUND_MASK_OFFSET 128
#define DI_CHECKSUM_CONSTANT    0x1021
#define DI_PVT_GBL_SIZE         76

#define LEFT_OFFSET_POINTER ((short *)0x092C) /* Last 4 bytes of CurAppName */
#define CHECKSUM_POINTER    ((short *)0x092E) /* hold position & checksum   */

typedef struct
    {
    Byte        QD_Private_Global_Space[DI_PVT_GBL_SIZE];
    long        randseed;
    BitMap      screenBits;
    Cursor      arrow;
    Pattern     dkGray;
    Pattern     ltGray;
    Pattern     gray;
    Pattern     black;
    Pattern     white;
    GrafPtr     thePort;
    } QD_Variables;

void Draw_Init_Icon (short icon_id);

void Draw_Init_Icon (short icon_id)
{
    CIconHandle     icon_handle = NULL;
    Rect            destination_rect;
    Rect            source_rect;
    BitMap          icon_bitmap;
    BitMap          mask_bitmap;
    GrafPort        local_port;
    QD_Variables    my_vars;
    long            our_a5;
    long            old_a5;

    /* Prepare A5 for InitGraf call */

    asm 68000
        {
        move.l  a5,old_a5
        lea     our_a5,a5
        move.l  a5,CurrentA5
        }

    /* InitGraf and open our GrafPort */

    InitGraf (&(my_vars.thePort));
    OpenPort (&local_port);

    /* Determine if position is valid. If not, set to initial value.
       If so, do nothing. */

    if ((((*LEFT_OFFSET_POINTER)<<1)^DI_CHECKSUM_CONSTANT) != (*CHECKSUM_POINTER))
        *LEFT_OFFSET_POINTER = DI_INITIAL_OFFSET;

    /* Compute destination Rect. */

    destination_rect.bottom = local_port.portRect.bottom - DI_BOTTOM_OFFSET;
    destination_rect.left = local_port.portRect.left + *LEFT_OFFSET_POINTER;
    destination_rect.top = destination_rect.bottom - DI_ICON_HEIGHT;
    destination_rect.right = destination_rect.left + DI_ICON_WIDTH;

    /* If color QD exists, use 'cicn'. If not, use 'ICN#'.
       SysBeep and return if resource unavailable. */

    if (!(ROM85&DI_NO_COLOR_QD))
        {
        icon_handle = GetCIcon (icon_id);
        if (!icon_handle)
            {
            SysBeep (DI_BEEP_LENGTH);
            return;
            }
        PlotCIcon (&destination_rect,icon_handle);
        DisposCIcon (icon_handle);
        }
    else
        {
        icon_handle = (CIconHandle)GetResource ('ICN#',icon_id);
        if (!icon_handle)
            {
            SysBeep(DI_BEEP_LENGTH);
            return;
            }

        HLock (icon_handle);

        /* Set source Rect and intialize source BitMaps. */

        SetRect (&source_rect,0,0,DI_ICON_HEIGHT,DI_ICON_WIDTH);

        icon_bitmap.bounds  = mask_bitmap.bounds = source_rect;
        icon_bitmap.rowBytes = mask_bitmap.rowBytes = DI_ICNPOUND_ROWBYTES;
        icon_bitmap.baseAddr = (Ptr)(*icon_handle);
        mask_bitmap.baseAddr = (Ptr)(((Byte *)(*icon_handle))+DI_INCPOUND_MASK_OFFSET);

        /* Draw the 'ICN#' using its mask. */

        CopyMask (&icon_bitmap,&mask_bitmap,&(local_port.portBits),&source_rect,&source_rect,&destination_rect);

        HUnlock (icon_handle);
        ReleaseResource (icon_handle);
        }

    ClosePort (&local_port);

    /* Update drawing position and checksum. */

    *LEFT_OFFSET_POINTER += DI_ICON_WIDTH+DI_ICON_OFFSET;

    *CHECKSUM_POINTER = ((*LEFT_OFFSET_POINTER)<<1)^DI_CHECKSUM_CONSTANT;

    /* Reset A5 */

    asm 68000
        {
        movea.l old_a5,a5
        move.l  a5,CurrentA5
        }

    /* We're outa here. */

    return;
}


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

From: [e-mail] (Mark R. Valence)
Date: 9 Nov 92 14:29:44 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Christopher Klaus Larson) writes:

> In article <[e-mail]> [e-mail] (Marc Lesure) writes:
>
> >Also, are there any snippets showing the best way to show an INIT icon
> >during the booting sequence?
>
> I'm not sure if this is the _best_ way to show an icon during startup, but
> it has always worked for me. :-)
>
> Feel free to use this as you see fit. Optimizations and bug fixes welcome.

I have two minor comments:

1.  You save A5, and then restore A5 AND CurrentA5 to the A5's original
value.  This is dangerous, as you are assuming A5 points to a valid
quickdraw globals area upon entry to your code.  I would suggest
instead that you save BOTH A5 and CurrentA5 in separate locations, and
restore them separately.  If you don't, you will see some weird bugs
with some pretty widely used INITs (I won't mention any names).

2.  You should probably give some credit to the guys who wrote the
original and most widely used version of this code.  They were the
ones, I believe, who first used CurApName for temporary storage, and
made it the "standard".  I, too have written my own version of this
code (it's smaller than the original, and does the same stuff), but my
code still credits the original source.

Mark.

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

From: [e-mail] (Paul Franklin)
Date: 11 Nov 92 23:46:58 GMT
Organization: University of California at Davis

In article <[e-mail]> [e-mail] (Mark R. Valence) writes:
>In article <[e-mail]>
>[e-mail] (Christopher Klaus Larson) writes:
>
>> Feel free to use this as you see fit. Optimizations and bug fixes welcome.
>
>I have two minor comments:
>
>1.  You save A5, and then restore A5 AND CurrentA5 to the A5's original
>value.  This is dangerous, as you are assuming A5 points to a valid
>quickdraw globals area upon entry to your code.  I would suggest
>instead that you save BOTH A5 and CurrentA5 in separate locations, and
>restore them separately.  If you don't, you will see some weird bugs
>with some pretty widely used INITs (I won't mention any names).

Very true. I do assume that A5 and CurrentA5 contain the same value
upon entry -- a POOR assumption. The value of CurrentA5 should be
saved and restored to its value on entry, not restored to A5's entry
value.

>2.  You should probably give some credit to the guys who wrote the
>original and most widely used version of this code.  They were the
>ones, I believe, who first used CurApName for temporary storage, and
>made it the "standard".  I, too have written my own version of this
>code (it's smaller than the original, and does the same stuff), but my
>code still credits the original source.

Absolutely. The original routine was written by Paul Mercer, Darin Adler,
and Paul Snively from an idea by Steve Capps. Their code did standardize
the use of CurApName for temporary storage. In no way do I attempt to
take credit for thier work and I apologize for this omission.

Thanks for the comments.

(Sorry it took so long for me to respond -- we have had some problems
with our news server so I had to post this from a friend's account.)

- -- Chris
[e-mail]

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

From: [e-mail] (Jim Walker)
Organization: USC  Department of Computer Science
Date: 18 Nov 92 15:10:54 GMT

In article <[e-mail]>
 [e-mail] (Marc Lesure) writes:

>Also, are there any snippets showing the best way to show an INIT icon
>during the booting sequence?

I have one I call ShowIcon7 which is compatible (I think) with IconWrap,
and which (under System 7) will show color icons of iclx types. Under
System 6, it does black and white.  It's written in THINK C 5.  Source and
compiled code is available by ftp from bigbird.csd.scarolina.edu in
pub/mac.
- --

 -- Jim Walker  USC Dept. of Math.  [e-mail]

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

From: [e-mail] (Jerry Sy)
Subject: is there a way to find out who is using an app ?
Date: 16 Nov 1992 21:49:18 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)


Here's my problem.

I have an application that runs in multiuser mode out on an appleshare
server volume.  Now whenever I make some changes and want to update,
I can't because people are using the program.  Now the appleshare
program will tell me who is currently logged on, but not who is
using my program.

is there a way to determine (programmatically or otherwise) who is
using an app on the server, short of going to each and every one
of the 50 users who are currently logged in ?

thanks
jerry


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

From: [e-mail] (Leonard Rosenthol)
Date: 17 Nov 92 05:02:25 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] (Jerry Sy) writes:
>
>I have an application that runs in multiuser mode out on an appleshare
>server volume.  Now whenever I make some changes and want to update,
>I can't because people are using the program.  Now the appleshare
>program will tell me who is currently logged on, but not who is
>using my program.
>
>is there a way to determine (programmatically or otherwise) who is
>using an app on the server, short of going to each and every one
>of the 50 users who are currently logged in ?
>
    Nope, there is no way to tell who has a file open.  This is a REAL
problem if you want to do multi-user software, where a given file could be
open by many people at the same time.

- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician

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

From: [e-mail] (Manuel Veloso)
Date: 17 Nov 92 14:10:16 GMT
Organization: Harvard University

In article <[e-mail]> Jerry Sy, [e-mail]
writes:
>is there a way to determine (programmatically or otherwise) who is
>using an app on the server, short of going to each and every one
>of the 50 users who are currently logged in ?
>
>thanks
>jerry

What you could do, although it would be a lot of work, is install a
ServerEvent handler on the server & watch for FPOpenFork. When you get
it, check to see what file it is & who's opening it...if it's an
application, you've probably got a launch...

Manny

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

From: [e-mail] (Brian Foley)
Subject: Hilite a Rect
Date: 17 Nov 92 05:16:17 GMT
Organization: University of California, Berkeley


How do you hilite a rect using the current hilite color?
I am using InvertRect() now, but it would be "better" to do it
in color.  Inside Mac is rather vague on the subject I tried using

BitClr ((Ptr) HiliteMode, pHiliteBit);  /* IM V-61 */

but that gave me a bus error.

brian foley

[e-mail]
Science and Mathematics Education
University of California, Berkeley

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

From: [e-mail] (Stepan Riha)
Date: 17 Nov 1992 08:30:44 -0600
Organization: National Instruments, Austin, TX

In article <[e-mail]> [e-mail] (Brian Foley) writes:
>How do you hilite a rect using the current hilite color?
>I am using InvertRect() now, but it would be "better" to do it
>in color.  Inside Mac is rather vague on the subject I tried using
>
>BitClr ((Ptr) HiliteMode, pHiliteBit);  /* IM V-61 */
>
>but that gave me a bus error.

I never use the BitClr function (for byte to long sized variables) because
you get the extra trap dispatch overhead.  The way I code my highlights is:

    *(char*)HiliteMode &= ~(0x01<<hiliteBit);

Note that <Quickdraw.h> defines pHiliteBit = 7 and hiliteBit = 0, that's
because BitClr(ptr, bitNr) counts the high order bit of *ptr as bit 0.
IM I p.470-471.

However, I don't know why your code using BitClr should cause a buss error.

    - Stepan
- --
   Stepan Riha -- [e-mail]


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

From: [e-mail] (Mike Engber)
Date: 17 Nov 92 15:37:47 GMT
Organization: The Institute for the Learning Sciences

>I never use the BitClr function (for byte to long sized variables) because
>you get the extra trap dispatch overhead.  The way I code my highlights is:
>
>    *(char*)HiliteMode &= ~(0x01<<hiliteBit);
>
>However, I don't know why your code using BitClr should cause a buss error.

My guess is the the original poster is using THINK C which defines globals
as external vars - (not their addresses). From LoMem.h:
 char HiliteMode : 0x938;

In which case your suggestion will suffer the same problem. He needs to use:
 BitClr(&HiliteMode,pHiliteBit);

I made this same mistake myself recently. It's so easy (and foolish) to copy
code right from IM w/o thinking.

- -ME

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

From: [e-mail] (Christopher Klaus Larson)
Date: 18 Nov 92 21:14:04 GMT
Organization: College of Engineering - University of California - Davis

In article <[e-mail]> [e-mail] (Brian Foley) writes:
>
>How do you hilite a rect using the current hilite color?
>I am using InvertRect() now, but it would be "better" to do it
>in color.  Inside Mac is rather vague on the subject I tried using
>
>BitClr ((Ptr) HiliteMode, pHiliteBit);  /* IM V-61 */
>

If you are using THINK C >= 5.0, the variable HiliteMode contains the
value of the hilite mode byte, not the addresss of the hilite mode byte.
Try the following:

    *((char *)0x0938) &= 0x7F;

    or

    HiliteMode &= 0x7F; (THINK C only)

before your call to InvertRect(). That should do the trick. 0x0938 is the
address of HiliteMode and 0x7F will mask off pHiliteBit.

- --Chris
[e-mail]

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

From: [e-mail] (Daniel Morrow)
Date: 19 Nov 92 00:09:19 GMT
Organization: Drexel University

In article <[e-mail]> [e-mail] (Christopher Klaus Larson) writes:
>In article <[e-mail]> [e-mail] (Brian Foley) writes:
>>
>>How do you hilite a rect using the current hilite color?
>>I am using InvertRect() now, but it would be "better" to do it
>>in color.  Inside Mac is rather vague on the subject I tried using
>>
>>BitClr ((Ptr) HiliteMode, pHiliteBit);  /* IM V-61 */
>>
>
>If you are using THINK C >= 5.0, the variable HiliteMode contains the

(some stuff deleted, then) Try this:
>
>    *((char *)0x0938) &= 0x7F;
>
>    or
>
>    HiliteMode &= 0x7F; (THINK C only)
>

I use Think 5.0 and all I do is say:
    BitClr(&HiliteMode, pHiliteBit);

This works quite nicely.

- -Dan.

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

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