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

Text File | 1994-12-08 | 35.9 KB | 957 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 11 Aug 92       Volume 1 : Issue 165

Today's Topics:

    SourceBug vs THINK C Debugger?
    Using _ExitToShell (Re: Why can't I Quit?)
    Fraudulent compressed resources
    Easy question (!?)
    creating/using 'styl' & 'TEXT' resources
    Powerbook 100 Roms
    Perl under MPW??
    windowKind usage, the RIGHT way to do it...
    member() bug SOLVED (I hope)



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.  (This means you can't post questions to the
digest.)

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: quesnel@ems (Rene Quesnel)
Subject: SourceBug vs THINK C Debugger?
Date: 5 Jul 92 17:24:40 GMT
Organization: Faculty of Music, McGill University

Could anyone tell me how does the new SourceBug debugger that runs with
MPW C++ compare with THINK C's debugger in terms of ease of accessing
members of structures dereferenced from pointers to those structures or
accessing structure elements in a linked list? It is so simple with
THINK C and so cumbersome with SADE (sigh). I will gladly buy
SourceBug if it's worth the price.

Thank you,
Rene Quesnel
[e-mail]

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

From: [e-mail] (Kent Sandvik)
Date: 9 Jul 92 00:14:26 GMT
Organization: Apple Inc, Debugging Department

In article <[e-mail]>, quesnel@ems
(Rene Quesnel) wrote:
>
> Could anyone tell me how does the new SourceBug debugger that runs with
> MPW C++ compare with THINK C's debugger in terms of ease of accessing
> members of structures dereferenced from pointers to those structures or
> accessing structure elements in a linked list? It is so simple with
> THINK C and so cumbersome with SADE (sigh). I will gladly buy
> SourceBug if it's worth the price.

SourceBug relies on PascalObject meta-information, so unless
you are programming with MacApp I'm afraid that you will not be as
pleased with the information concerning class fields. They don't show
up in the third column. However the examination function shows all the
fields,
values and pointers in a C++ object -- in a really nice way.

I don't want to state that SourceBug is a lousy editor, I do know of C
programmers that use it because it's easy to learn, and is fine for
breakpoint settings, stack traces, C++ field value examination and many
other typical
common debugging cases. You have the choice of SourceBug, which is a very
good
high level debugger, SADE which has the neat features of extension
programming
and watch points, Steve Jasik's which is a combination of high-low level
debugger, and then MacsBug/TMON which you need now and then.

Cheers,
Kent/DTS

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

From: [e-mail]
Subject: Using _ExitToShell (Re: Why can't I Quit?)
Organization: Campus Computing Sites, University of Michigan-Ann Arbor
Date: Tue, 7 Jul 92 04:14:21 GMT

In article <[e-mail]> [e-mail] (Howard Berkey) writes:
>
>A better way to quit is to use ExitToShell() in this case as your app
>is guaranteed to be in the foreground when the user selects Quit or hits
>command-Q in your application.  Something like this in your file menu handler:
>
    You should NOT use ExitToShell() to exit applications anymore. With
Apple event Handlers the way they are constructed, it is recommended (or
required) that you leave the application through the "bottom" rather than
exiting abuptly so that the AEManager can clean up it's handler tables.


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

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

From: [e-mail] (Martin Friedrich)
Date: 7 Jul 92 08:48:38 GMT
Organization: University of Oldenburg, Germany

[e-mail] writes:

>In article <[e-mail]> [e-mail] (Howard Berkey) writes:
>>
>>A better way to quit is to use ExitToShell() in this case as your app
>>is guaranteed to be in the foreground when the user selects Quit or hits
>>command-Q in your application.  Something like this in your file menu handler:
>>
>    You should NOT use ExitToShell() to exit applications anymore. With
>Apple event Handlers the way they are constructed, it is recommended (or
>required) that you leave the application through the "bottom" rather than
>exiting abuptly so that the AEManager can clean up it's handler tables.

What do You mean by "through the "bottom""? The AEhandlers in the application
heap are removed automaticly (at least, I don't care about them, and never
get crashed on application exit...), and if a handler resides in the system
heap you must remove it explicitly. Supposing this handler is AEQuit handler
you can't do that while executing the handler, do you?
- --
LLaP
       Martin Friedrich

- -----------------------------------------------------------------------------
                         |"I never will understand
REAL      Martin Friedrich   (CS-Student)    | humans ..."
NICK      jupp                               | -- Spock, Patterns of Force
UUCP      friedrich@uniol                    --------------------------------
DOMAIN    [e-mail]
HOME      Straekweg 1 , 2986 Leezdorf

     Superior abilities breed superior ambitions
- -----------------------------------------------------------------------------

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

From: [e-mail] (Charles B. Cranston)
Date: 7 Jul 92 22:41:48 GMT
Organization: UM Home for the Terminally Analytical

In article <[e-mail]> [e-mail] (Howard Berkey) writes:

> A better way to quit is to use ExitToShell() in this case ...

If you're using MacTCP you had better terminate all your streams first,
or else next time you run the same application you'll hang bigtime...

I deal with this problem by writing a "terminate" function that closes
everything down, then calls ExitToShell...

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

From: [e-mail] (Grobbins)
Date: 8 Jul 92 04:41:44 GMT
Organization: C.K.'s Office Decorating Club

In article <[e-mail]> [e-mail] (Martin Friedrich) writes:
>[e-mail] writes:
>>    You should NOT use ExitToShell() to exit applications anymore.
>What do You mean by "through the "bottom""?
>... Supposing this handler is AEQuit handler
>you can't do that while executing the handler, do you?

It's just that it may not always be a good idea to call ExitToShell.
This is not particularly new; for example, you wouldn't ever call
ExitToShell from a completion routine or a def proc, I hope.

Nowadays it is more common with the kind of dispatching that the Apple
Event Manager does to be in a state where ExitToShell is a bad idea.
The classic case is the Quit event handler, which should just set a
flag telling your main program that it's time to go.

The System will clean up whatever it can whenever the application
quits, whether the app quits via an explicit ExitToShell or by dropping
out the bottom.  But it can't deal with exiting from within an event
handler or from code which may have been reached in any other bizarre
manner.  Just set a global done flag and let the main program bail when
the coast is clear.


Grobbins                 [e-mail]

Usual disclaimers apply.


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

From: [e-mail] (Philip Brandenberger)
Organization: Swarthmore College
Date: Thu, 9 Jul 1992 16:26:03 GMT

[e-mail] (Charles B. Cranston) writes:
> In article <[e-mail]> [e-mail] (Howard Berkey) writes:
>
> > A better way to quit is to use ExitToShell() in this case ...
>
> If you're using MacTCP you had better terminate all your streams first,
> or else next time you run the same application you'll hang bigtime...

Nawwww, just get ZapTCP!  It saves you the trouble of closing your
own streams!  :-)

- -Phil

- --
Philip J. Brandenberger
Swarthmore College, but I don't speak for it, in fact usually against it.
[e-mail]

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

Subject: Fraudulent compressed resources
From: [e-mail]
Date: 8 Jul 92 09:32:48 +1300
Organization: University of Otago, Dunedin, New Zealand

I would like to be able to tell (so I can warn users) when the file I am
processing contains compressed resources. So, you, say, just check that
"compressed" bit in the resource attributes and away you go...

Not so. Certain perfectly ordinary applications have the compressed bit set on
some perfectly normal resources. This causes my warning to come up when it
shouldn't. But then, how do the applications work? Why don't the resources get
decompressed and mangled? Somehow, the system knows something else about what a
compressed resource looks like. So does ResEdit, for that matter, because if
you look at these resources with it it will tell you that they aren't
compressed. DeRez tells the true story: the compressed bit in the attributes
is set.

So, has anyone encountered this before? What do I need to do to find out if
resources are *really* compressed?


Michael(tm) Hamel, Computing Services Centre, University of Otago, New Zealand

RADLETT (n.)
The single hemisphere of dried pea which is invariably found in an otherwise
spotlessly clean saucepan.


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

From: [e-mail]
Date: 8 Jul 92 03:08:32 GMT
Organization: Campus Computing Sites, University of Michigan-Ann Arbor

In article <[e-mail]> [e-mail] writes:
>I would like to be able to tell (so I can warn users) when the file I am
>processing contains compressed resources. So, you, say, just check that
>"compressed" bit in the resource attributes and away you go...
>
> [more problems when just checking the bit]
>
    There are two problems that you have to deal with...

1) As you noted, the System's resource compression scheme is smart enough to
check more than just the compressed bit.  It knows about the format of a
compressed resource & will look at the header and validate it as REALLY being
compressed.  Since the format for compressed resources is a) undocumented and
b) guarenteed to change, you're SOL unless you want to reverse engineer it
now and int he future.

2) A number of companies are now offering developers (and in some cases users)
resource compression tools in order to reduce the size of their applications.
One of them (Alysis) uses Apple's scheme (and will break in the future), while
the other two (MindVision & Aladdin) have their own schemes and do NOT
even set the compressed bit (since that is reserved for Apple).  So you would
not be able to tell that those resources are compressed - unless you know
their headers too...


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

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

From: [e-mail] (michael j darweesh)
Date: 8 Jul 92 15:39:05 GMT
Organization: UB

The resources ARE compressed, but the system calls used to access these
resources transparently uncompress them for you. If the compressed bit is
set, then the version of the resource actually in the file IS compressed
and if you ask for a handle to it (perhaps via GetResource()), then
the system will return a handle to an uncompresses version of that
resource.

- -Mike

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

From: [e-mail] (Michael Hecht)
Date: 9 Jul 92 13:30:25 GMT
Organization: SAS Institute Inc.

In article <[e-mail]>, [e-mail]
(michael j darweesh) wrote:
>
> The resources ARE compressed, but the system calls used to access these
> resources transparently uncompress them for you.

I wish this were the case, but alas, it isn't.

I discovered the hard way that for compressed resources, SizeResource
returns the uncompressed size, but GetResource returns the compressed
resource data. It's left totally up to the calling application to compress
and decompress the data. All the Resource Manager does for you is keep
track of two different sizes.

My ResCompare program always said that compressed resources were different,
because it was using the size returned by SizeResource to determine how
much data to compare. I changed it to use the size returned by
GetHandleSize after loading the resource, and now it works much better.

- --Michael

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT

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

From: [e-mail] (SCOTT I CHASE)
Subject: Easy question (!?)
Date: 8 Jul 92 03:18:07 GMT
Organization: Lawrence Berkeley Laboratory - Berkeley, CA, USA

Hello all (especially bc, who I haven't seen since my days at The Tech),

Well, I just tried my first little toy program in Think C on my new IIci.
Armed with my Think C manual (just about useless), six volumes of Inside
Macintosh (incredible useful, but painfully expensive),  and my cat (worse
than useless, but doesn't cost much) I tried to write a simple program to catch
events and show me what I caught.  I plan to use it as a shell for a background
process to do some CPU-intensive stuff, i.e., do a little bit after catching
each null event.

My problem is that I am surprised to see that I am catching not only null
events (event.what == 0) but also events with event.what == 15.  The
manual says that this is an application-defined code.  So I assume that
I should never get one unless I am passing events around myself.  What's
going on?  Thanks in advance for any pointers.  -Scott

So that there is no ambiguity, here is the offending code:

#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <console.h>
main()
{
int        Col1 = 1, Row1 = 1;
char        GotEvent;
EventRecord myEvent;
RgnHandle   cursorRgn;
int        Sleep = 1;
int        menu_ID;
int        menu,item;
int        QUIT = (2<<16) + 1;

    FlushEvents(everyEvent,0);
    printf("Starting...\n");    /* initialize Toolbox Managers */

    while (1) {
         GotEvent = WaitNextEvent(everyEvent, &myEvent, Sleep, cursorRgn);
             switch(myEvent.what) {
             case mouseDown:
                 menu_ID = MenuSelect(myEvent.where);
                if (menu_ID == QUIT) ExitToShell();
                item    = menu_ID &  0xFFFF;
                menu    = menu_ID >>     16;
                 printf("Menu Item Selected: Menu = %ld, Item = %ld\n",
                         menu,item);
                 break;
            case 0:
                printf("GOT NULL EVENT\n");
                break;
            default:
                printf("Unexpected Event Recorded: Type = %ld\n",myEvent.what);
                break;
             }
          }
}

- --------------------
Scott I. Chase            "The question seems to be of such a character
[e-mail]        that if I should come to life after my death
                and some mathematician were to tell me that it
                had been definitely settled, I think I would
                immediately drop dead again."      - Vandiver

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

From: eric_gorr@coglab_psych.uoregon.edu (Eric Gorr)
Organization: University of Oregon Network Services
Date: Wed, 8 Jul 92 16:14:55 GMT


I am not certain as to the answer, but what I found extremely useful
when starting to program on the MAC was the Macintosh C Programming
Primer, vol I & II.  (There is a second edition for Vol I which covers
system 7.)

I highly recommend the book.



In article <[e-mail]>, [e-mail] (SCOTT I CHASE)
writes:
>
> Hello all (especially bc, who I haven't seen since my days at The Tech),
>
> Well, I just tried my first little toy program in Think C on my new IIci.
> Armed with my Think C manual (just about useless), six volumes of Inside
> Macintosh (incredible useful, but painfully expensive),  and my cat (worse
> than useless, but doesn't cost much) I tried to write a simple program to catch
> events and show me what I caught.  I plan to use it as a shell for a background
> process to do some CPU-intensive stuff, i.e., do a little bit after catching
> each null event.
>
> My problem is that I am surprised to see that I am catching not only null
> events (event.what == 0) but also events with event.what == 15.  The
> manual says that this is an application-defined code.  So I assume that
> I should never get one unless I am passing events around myself.  What's
> going on?  Thanks in advance for any pointers.  -Scott


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

From: [e-mail] (SCOTT I CHASE)
Date: 8 Jul 92 18:55:08 GMT
Organization: Lawrence Berkeley Laboratory - Berkeley, CA, USA

Thanks to the many people who wrote to tell me that event 15 is no longer
reserved for applications, but rather used my System 7 to generate
suspend/resume and mouseMoved events.  I have learned two lessons:
(1) Always start with IM6 and work backwards.  The early volumes are full
of outdated information, even though they cost me an arm and a leg.
(2) The ThinkC debugger is probably handling my application in a way that
generates the flurry of event 15's.  When run from the Finder, I am told
that my program does not repeatedly generate the events in question.  I will
have to check this when I get home tonight.

Thanks again to all who took the time to answer (and at least one person
who actually compiled and ran my program!)

- -Scott

- --------------------
Scott I. Chase            "The question seems to be of such a character
[e-mail]        that if I should come to life after my death
                and some mathematician were to tell me that it
                had been definitely settled, I think I would
                immediately drop dead again."      - Vandiver

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

From: [e-mail] (PEGG, DAVID J)
Organization: University of Tennessee Computing Center
Date: Wed, 8 Jul 1992 21:57:00 GMT

In article <[e-mail]>, [e-mail] writes...
>
>My problem is that I am surprised to see that I am catching not only null
>events (event.what == 0) but also events with event.what == 15.  The
>manual says that this is an application-defined code.  So I assume that
>I should never get one unless I am passing events around myself.  What's
>going on?

>From the Macintosh C Programming Primer, pg. 133:
"osEvt (formerly known as app4Evt): The system will post an osEvt just before
it moves your event into the background (suspends it) and just after it brings
your application back to the foreground (resumes it).  You can also set your
application up to receive mouseMoved events.mouseMoved events are posted when
the user moves the cursor outside a predefined region (such as a text-editing
window) or back in again.  When your application receives a mouseMoved event,
it can change the cursor to one appropriate for that region."

The book refers me to IM V:249, but I don't have access to that volume.
However, I believe that _is_ event.what == 15.

Good luck,
 -Michael Lewis

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

From: [e-mail] (Mike Engber)
Subject: creating/using 'styl' & 'TEXT' resources
Organization: The Institute for the Learning Sciences
Date: Wed, 8 Jul 1992 16:03:04 GMT

Here's a followup to the question someone asked about how
to create the 'styl' resources to accompany your 'TEXT' resources.
I assumed that this was well known - but he told me he got a lot
of me too requests - so here's the method I've been successfully
using (since yesterday).

There's an untested C function at the end if you want to skip
the discussion (the code pretty much says it all).

I checked the Tech Notes and Q&A stack and didn't see this info
anywhere - so this is all empirically determined. If anyone knows
different please speak up.

At first I blindly saved the handle returned by GetStylHandle as the
'styl' resource. After crashing the machine and then thinking about it
for a few seconds (like taking a look at the data structure I was
saving) it became obvious that this was a ridiculous thing to try.

The secret seems to be use the calls GetStylScrap & SetStylScrap.
GetStylScrap is documented in IM V and SetStylScrap in IM VI (I assume
is was accidentally left out of V?) They're both discussed in Mac
Revealed volume IV.

MacRevealed's discussion on p. 322 of how StyledTE puts items of
type 'styl' on the clipboard is what tipped me off as to what to
do. Chernicoff doesn't come right out and say it - my guess is
because 'styl' resources weren't in widespread use at the time the
book was written.

GetStylScrap returns you a handle that you can just pass to AddResource.
GetStylScrap returns a new handle on every call - so you don't have to
worry about making a copy lest you trash something your TERecord is
still holding onto. The format of this handle is described in IM V
p. 265-266 - but basically its a list of styles that get mapped onto
your text.

Once you have a 'styl' resource you use SetStylScrap to apply it
to your text (which is already installed in your TERec).

I assume it's obvious how to deal with the 'TEXT' resources. If not
I can elaborate. One possible gottcha is to forget that TextEdit
still has a hold of the hText handle and will DisposeHandle on it
when you TEDispose. So you don't want to blindly pass the the hText
handle to AddResource (make a copy - or remove it from the
TERec - replacing it with a dummy handle)

The ResEdit 'styl' editor expects a 'TEXT' resource and its asscociated
'styl' resource to have the same rsrc id. Sounds like a good convention
to me. But there is nothing to keep you from violating it - except you
won't be able to edit your resource with ResEdit.

In summary - the ToolBox call I wanted, but which doesn't exist would
be something like: (if the ToolBox followed C conventions)

- - warning - completely untested code to follow -

TEHandle GetTEStylNew(short id,Rect* destRect,Rect* viewRect){
 Handle   textHandle = GetResource('TEXT',id);
 Handle   stylHandle = GetResource('styl',id);
 TEHandle hTE        = NULL;

 if(textHandle){
   hTE = TEStylNew(destRect,viewRect);
   HLock(textHandle);
   TESetText(*hTE,GetHandleSize(hTE),hTE);
   HUnlock(textHandle);
   ReleaseResource(textHandle);
   if(stylHandle){
     SetStylScrap(0,(*hTE)->teLength,stylHandle,false,hTE);
     ReleaseResource(stylHandle);
   }
 }
 return hTE;
}

Using this approach, copies of the 'TEXT' and 'styl' data are installed
in the new TEHandle. This means that saving will require you to first
remove any existiong 'styl' and 'TEXT' resources and then use
AddResource with the 2 new handles.

Yes, it would be possible to install the original 'TEXT' resource
handle into the TERec (rather than copying the the text in with
TESetText) - This would mean your TERec would be directly editing
the 'TEXT' resource (& you wouldn't have to go through the remove and
add process to save changes to it). But there is no way to accomplish
an analogous thing for the 'styl' resoruce - so I thought it best to
treat them both consistently.

- -ME

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

From: [e-mail] (Michael Hecht)
Date: Thu, 9 Jul 1992 14:07:58 GMT
Organization: SAS Institute Inc.

In article <[e-mail]>, [e-mail] (Mike
Engber) wrote:
> I checked the Tech Notes and Q&A stack and didn't see this info
> anywhere - so this is all empirically determined. If anyone knows
> different please speak up.

There's documentation in Q&A Stack 4.1: Toolbox & IAC: TextEdit: 12/19/90:
Saving and restoring styled TextEdit records. (I found this using the
Developer Info Assistant's "Search" card, looking for "TextEdit" and
"style". Just thought you'd want to know!)

> The secret seems to be use the calls GetStylScrap & SetStylScrap.
> GetStylScrap is documented in IM V and SetStylScrap in IM VI (I assume
> is was accidentally left out of V?)

IM V predates SetStylScrap. It was first documented in TN #207, Styled
TextEdit changes in System 6.0, which is where most of the IM VI
information comes from. Reading this is a must if you plan to implement
your own styled text editor using TextEdit. It greatly simplifies applying
stylistic changes to the text.

You might also want to look at TEStylInsert, which *is* documented in IM V
(right under the documentation for GetStylScrap, actually :-). It is, I
think, easier to use than SetStylScrap in this situation, since it will
insert both the text *and* the styles in one easy step.

In other words, this:

>    HLock(textHandle);
>    TESetText(*textHandle /*sic*/,GetHandleSize(textHandle /*sic*/),hTE);
>    HUnlock(textHandle);
>    ReleaseResource(textHandle);
>    if(stylHandle){
>      SetStylScrap(0,(*hTE)->teLength,stylHandle,false,hTE);
>      ReleaseResource(stylHandle);
>    }

becomes this:

     HLock( textHandle );
     TEStylInsert( *textHandle, GetHandleSize( textHandle ), stylHandle,
hTE );
     HUnlock( textHandle );

     ReleaseResource( textHandle );
     ReleaseResource( stylHandle );

Note: According to IM V, "when [stylHandle] is NIL and/or hTE has not been
created using TEStylNew, there is no difference between [TEStylInsert] and
TEInsert."

If anyone wants some simple code for displaying styled text in a scrolling
field of a dialog, let me know. It's great for help and info messages that
you can edit with ResEdit!

> The ResEdit 'styl' editor expects a 'TEXT' resource and its asscociated
> 'styl' resource to have the same rsrc id. Sounds like a good convention
> to me. But there is nothing to keep you from violating it - except you
> won't be able to edit your resource with ResEdit.

This is a good convention. The answer in the Q&A stack also suggests saving
the 'TEXT' part of the record as the data fork of a normal TEXT file, and
saving the 'styl' part as a 'styl' resource in the same file ('styl' 128?).
That way, other text editing apps can read it, whether they support styled
text or not.

- --Michael

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT

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

From: [e-mail] (Mike Diehr)
Subject: Powerbook 100 Roms
Organization: Philips Interactive Media
Date: Wed, 8 Jul 92 17:42:32 GMT


What sort of roms does the PB 100 have?  Specifically, I'm wondering
if I can do any Quicktime programming in think C.  Obviously, I
won't have color.  But will Quicktime run at all in B/W?

Also, are the roms 32 bit clean?


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

From: Quinn <[e-mail]>
Organization: The University of Western Australia
Date: Thu, 9 Jul 1992 06:26:11 GMT

In article <[e-mail]> Mike Diehr,
[e-mail] writes:
>What sort of roms does the PB 100 have?

The same as the Macintosh Portable.

>Specifically, I'm wondering if I can do any Quicktime programming in
think
>C.  Obviously, I won't have color.  But will Quicktime run at all in B/W?

QuickTime (at the moment) requires an 68020 or better.  The PB100
has a 68000.  Bad luck!  Rumours of a later version that runs on
68000s abound but it is not yet released.

>Also, are the roms 32 bit clean?

Mu.  The question of 32 bit cleaness is invalid on the 68000 which
only has 24 address lines (which is where the 24 bit problem
originates).

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- World's proudest PB100 owner (-:

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

From: [e-mail] (Patrick Stickler)
Subject: Perl under MPW??
Date: 8 Jul 92 12:41:50 GMT
Organization: University of Helsinki, Finland

Does anyone know if Perl has been ported to the Mac under MPW. Would
this even be feasable? Any info would be much appreciated.

Please reply via email. Thanks.


//////////////////////////////////////////////////////////////////////////
       Patrick Stickler             WSOY, Information Systems Division
    [e-mail]           Bulevardi 12, Helsinki FINLAND
      ([phone]                      (+ 358 0) 61681
==========================================================================
        The comments contained herein cannot reflect the official
           views of my employer.  (proof left for the reader)
//////////////////////////////////////////////////////////////////////////

- --

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

From: [e-mail] (John Major)
Date: 9 Jul 92 16:09:06 GMT
Organization: Bolt Beranek and Newman Inc., Cambridge MA


There is an excellent port of Perl done by Matthias Neeracher
on WUARCHIVE.WUSTL.EDU, in mirrors2/rascal.../programming (the
original was on rascal... but was moved to WUARCHIVE because
of disk space limitations).

Good luck -

John Major
[e-mail]
ALINK:D6590
617/873-8165

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

From: [e-mail] (Philip Brandenberger)
Subject: windowKind usage, the RIGHT way to do it...
Organization: Swarthmore College
Date: Thu, 9 Jul 1992 16:15:30 GMT

[e-mail] writes:
> In article <[e-mail]> [e-mail] (Steve Dorner) writes:
> >
> >A certain screensaver which I do not care to name (it's part of a
> >commercial security package) does its thing by creating a window in
> >the frontmost application's heap

> [Stuff deleted....]

> >Does this strike anyone else as incredibly hostile behavior?
> >
>     Putting a window into someone else's layer is an evil thing in its
> own right,

> [Stuff Deleted....]

>     Actually if they are going to continue to put things into application's
> layers, then at least use negative IDs which are reserved for things like
> DA's and system windows.

Alright, how does one avoid adding a window to the (front of the)
foreground app's windowlist?  My impression is that nearly all screensavers
do, partly because the other approach, that is recalcing the visRgn's
of windows doesn't really work for the Finder's desktop, which will either
"bleed through" (if you don't call empty the GrayRgn) or cause icon
positions will sometimes be recalculated because the size of the
GrayRgn has changed.

Comments?

- -Phil

- --
Philip J. Brandenberger
Swarthmore College, but I don't speak for it, in fact usually against it.
[e-mail]

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

From: [e-mail]
Date: 9 Jul 92 17:47:53 GMT
Organization: Campus Computing Sites, University of Michigan-Ann Arbor

In article <[e-mail]> [e-mail] (Philip Brandenberger) writes:
>[e-mail] writes:
>> In article <[e-mail]> [e-mail] (Steve Dorner) writes:
>> >
>> >A certain screensaver which I do not care to name (it's part of a
>> >commercial security package) does its thing by creating a window in
>> >the frontmost application's heap
>
>> [Stuff deleted....]
>
>> >Does this strike anyone else as incredibly hostile behavior?
>> >
>>     Putting a window into someone else's layer is an evil thing in its
>> own right,
>
>> [Stuff Deleted....]
>
>>     Actually if they are going to continue to put things into application's
>> layers, then at least use negative IDs which are reserved for things like
>> DA's and system windows.
>
>Alright, how does one avoid adding a window to the (front of the)
>foreground app's windowlist?  My impression is that nearly all screensavers
>do, partly because the other approach, that is recalcing the visRgn's
>of windows doesn't really work for the Finder's desktop, which will either
>"bleed through" (if you don't call empty the GrayRgn) or cause icon
>positions will sometimes be recalculated because the size of the
>GrayRgn has changed.
>
    There are three common approaches to writing a screensaver - the
System 7 way, the After Dark way and the easy way.

    The easy way (and the most incompatible) is to do what is described
above and simply put a whole new window up in whatever layer happens to be
current at the time that the screen saver needs to kick in.  This will work
under both 6 & 7, but since the Sys6 Process Manager is undocumented, you
have to do this - under Sys7, you do what Darkside does (or I assume it does,
Tom??) and switch yourself to the frontProcess and THEN bring up a window in
your own process.

    What After Dark does is to patch out the world, in this case the global
QDBottlenecks, and when the screen saver is active, make all drawing that
intersects with the screen the equivalent of a NOP (it does allow drawing
into offscreens ;).  I believe the QT/Sunset uses a similar approach.


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

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

From: [e-mail] (Jon W{tte)
Subject: member() bug SOLVED (I hope)
Date: 9 Jul 92 18:30:34 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden


I recently got mail from Symantec tech support. It turns
out that if you use 4 byte ints, but don't turn on far code
or data, the declaration for member() in oops.h is faulty.
Turning off 4byte ints, or changing oops.h fixes the bug
(this bug is in 1.1.2 so it has to be recently discovered)

change:

char __member(...);

should be:

#if __option(far_code) || __option(far_data)
char __member(void *, void*);
#else
char __member(void *, short);
#endif


Yahoo ! (Of course, haven't tried it yet, but it looks like
this is the problem)

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

### You have the Easy Access virus. This virus may cause strange sounds
### and weird keyboard behaviour when you press the shift key repeatedly.

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

From: [e-mail] (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Thu, 9 Jul 1992 23:19:19 GMT

> [e-mail] (Jon W{tte) writes:

   I recently got mail from Symantec tech support. It turns
   out that if you use 4 byte ints, but don't turn on far code
   or data, the declaration for member() in oops.h is faulty.

This is correct.

   Turning off 4byte ints, or changing oops.h fixes the bug
   (this bug is in 1.1.2 so it has to be recently discovered)

This is not - IT DIDN'T FIX MY BUG !

I've tried to help a lot of people here, so I hope I'll
get some help back. I'm at a dead end. AUGH ! (I'm writing my
own class library just to get around this - I DON'T WANT TO)

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

### You have the Easy Access virus. This virus may cause strange sounds
### and weird keyboard behaviour when you press the shift key repeatedly.

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

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