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

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

C.S.M.P. Digest             Mon, 23 Nov 92       Volume 1 : Issue 217

Today's Topics:

    Suppl. Gestalt Selectors List 1.0.1
    TimeDBRA
    TrapAvailable for C (Was Re: help with Link failures in THINK C 5.03)
    calling GetMenu twice on same MENU - actually seems ok?
    Resource Manager Questions



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] (Rene G.A. Ros)
Subject: Suppl. Gestalt Selectors List 1.0.1
Date: 22 Oct 92 17:29:09 GMT
Organization: VU Biology, Amsterdam, The Netherlands

Supplemental Gestalt Selector List 1.0.1

Last updated: Oct., 22 1992 11:04 CET (GMT+1)
(I have started to use version numbering for this list, previous
list was 1.0).

Thanks to those persons who responded to the previous posting.
The information you mailed me is added to this list.

Supplemental to the selectors listed in the Gestalt Chapter of
Inside Macintosh VI (IM VI), that is.
These can include selectors added by Apple's (system) software or by
software from third parties (your software?).
If a selector code is added by Apple software the entry also includes
if it is an addition to or not listed in IM VI.

I don't have all the documentation or knowledge and I don't want to.
I would like to see this list as a combined effort by different
persons who have together access to a wide area of information.
This list may contain (educated) guesses and perhaps even false
information, so no guarantee is made about the contents.
When there is a reference to a source you may expect there is a higher
probability it is correct.
If you have additions, corrections, comments, suggestions, news about
available software (latest version of GestaltDA?), etc., please mail me
([e-mail]). Please, mention the source you used.

If you read this list in a Usenet group: you can also read it by using
finger to the same address.
    Tip: finger [e-mail] | more
My .plan file which you see when you do this is more up-to-date. I will
post this list to comp.sys.mac.programmer once a month. Or when (a lot
of) information is added/corrected.

CONTENTS
    Changes
    Format used
    Gestalt Selector Codes & Responses
    Abbreviations
    Format 4-byte word version number
    About AppleShare File & Print Server selectors
    Sources
    Thanks to

####Changes (since 1.0)
    Added selectors : atlk, tabl, SLip
    Changes to info : mtcp, qdrw, qtim


####Format used:

    | ****'selector code' (Application [available since version])
    |     name (description, documentation) OR description
    |
    |     CONST declaration; (remark) *ref.number to source
    |
    |     contradiction:
    |       source A says "x"
    |       source B says "y"

    Some constant-names may not originate from official publications.
    Any bitpattern described is what I or others found on their machine
    with their configuration.


####Gestalt Selector Codes & Responses
****'admn' (AppleShare Admin appl [since v3.0?])
    gestaltASAdminAttr (not listed in IM VI)

    gestaltASAdmin        = 'admn';
    gestaltASAdminPresent = 0;
****'ApoL' (Apollo ext [since v1.0a7])
    gestaltINITApolloTable

    (response will be published by Jeremy Roussak,
     Apollo 1.0 is not yet released.)
****'asps' (AppleShare Print Server appl [since v3.0?])
    gestaltASPrintServerAttr (not listed in IM VI)

    gestaltASPrintServer        = 'asps';
    gestaltASPrintServerPresent = 0;
****'atkv' (System [since v7.0])
    gestaltATalkVersion *5
    Returns AppleTalk version in 4-byte words

    gestaltATalkVersion = 'atkv'; *3/5
    This is different from 'atlk' !
****'atlk' (System)
    gestaltAppleTalkVersion (addition)
    Returns the version of the .MPP driver.

    LAPMgrExists := (AppleTalkVersion >= 53); *5
****'AzNe' (NameView cp)
    unknown, Table?
****'BSDa' (CloseView cp)
    unknown
****'bugz' (System [Tuna Helper INIT rsrc]/Tune-up ext)
    unknown
****'conn' (System)
    gestaltConnMgrAttr (addition)

    additional responses exist but unknown (bit 2 & 3)
****'cpnt' (QuickTime ext)
    gestaltComponentMgrAttr (Component Manager)

    gestaltComponentMgr        = 'cpnt';
    gestaltComponentMgrPresent = 0; (guess)
****'dict' (System [since v7.1])
    gestaltDictionaryMgr (System 7.1 Dictionary Manager,
                          not listed in IM VI)

    gestaltDictionaryMgr = 'dict';
    new System 7.1 responses exist but unknown
****'eajt' (System)
    gestaltEasyAccessJTable (not listed in IM VI)

    gestaltEasyAccessJ = 'eajt'; *3
    Returns the base address of the Easy Access jump-trap table
****'ESOC' (Serial of Champions ext)
    unknown
****'flag' (Network Extension ext [since System v7.0 *5])
    gestaltFlagshipAttr (not listed in IM VI)

    gestaltFlagship           = 'flag'; *3
    gestaltFlagshipPresent    = 0;      *3
    gestaltFlagshipRegistered = 1;      *3
****'fpu ' (System)
    gestaltFPUType (addition)

    gestal68040FPU = 3; *2
****'fs  ' (System)
    gestaltFSAttr (addition)

    gestaltHasFileSystemManager = 2; *2
****'font' (System)
    gestaltFontMgrAttr (addition)

    additional System 7.1 responses exist but unknown
****'hdwr' (System)
    gestaltHardwareAttr (additions)

    gestaltHasRBV          =  2; (RBV)             *3
    gestaltHasOSS          =  5; (OSS)             *3
    gestaltHasSCSIDMA      =  6; (53C80 SCSI DMA)  *3
    gestaltHasSWIMIOP      =  8; (SWIM IOP)        *3
    gestaltHasSCCIOP       =  9; (SCC IOP)         *3
    gestaltHasIWM          = 11; (IWM)             *3
    gestaltHasSoftPowerOff = 19;                   *2
    gestaltHasSonic        = 20; (Sonic)           *3
    gestaltHasSCSI961      = 21; (Int. 53C96 SCSI) *1
    gestaltHasSCSI962      = 22; (Ext. 53C96 SCSI) *1
    gestaltHasDAFBVideo    = 23; (DAFB Video)      *3
****'He20' (Helium cp)
    unknown
****'hgfd' (AppleShare File Server appl [since v3.0?])
    gestaltASFileServerAttr (not listed in IM VI)

    gestaltASFileServer        = 'hgfd';
    gestaltASFileServerPresent = 0;
****'icmp' (QuickTime ext)
    unknown
****'Intj' (Interjection ext)
    unknown
****'kbd ' (System)
    gestaltKeyboardType (additions)

    gestaltPwrBookADBKbd    = 12; (PowerBook ADB Keyboard)     *1
    gestaltPwrBookISOADBKbd = 13; (PowerBook ADB Keyboard ISO) *1
****'mach' (System)
    gestaltMachineType (additions)

    gestaltQuadra900    = 20; (Macintosh Quadro 900)     *1
    gestaltPowerBook170 = 21; (Macintosh PowerBook 170)  *1
    gestaltQuadra700    = 22; (Macintosh Quadra 700)     *1
    gestaltClassicII    = 23; (Macintosh Classic II)     *1
    gestaltPowerBook100 = 24; (Macintosh PowerBook 100)  *1
    gestaltPowerBook140 = 25; (Macintosh PowerBook 140)  *1
    gestaltQuadra950    = 26; (Macintosh Quadra 950)     *1
    gestaltPowerBook210 = 29; (Macintosh PowerBook 210)
    gestaltPowerBook230 = 32; (Macintosh PowerBook 230)
    gestaltPowerBook180 = 33; (Macintosh PowerBook 180)
    gestaltPowerBook160 = 34; (Macintosh PowerBook 160)
    gestaltMacLCII      = 37; (Macintosh LC II)
    gestaltMacIIvi      = 44; (Macintosh IIvi)
    gestaltPerforma600  = 45; (Macintosh Performa 600)
    gestaltMacIIvx      = 48; (Macintosh IIvx)
    gestaltPowerBook145 = 54; (Macintosh PowerBook 145)

    contradiction 1:
      TN129 says             "The Macintosh LC II is identical to the
                              Macintosh LC, except for the presence of
                              an MC68030 processor, so it returns the
                              same gestaltMachineType response as the
                              Macintosh LC (i.e. 19).
      According to M.Johnson "gestaltLCII = 37;"
    contradiction 2:
      DN PowerBook145 says   "gestaltPowerBook145 = 25; with sys 7.0.x
                         and  gestaltPowerBook145 = 45; with sys 7.1"
      According to M.Johnson "gestaltPowerBook145 = 54;"
****'mtcp' (MacTCP cp [since v1.1])
    gestaltMacTCPAttr
    0 is returned if MacTCP is present but unopened, *6
    1 is returned for MacTCP when it is opened.      *6

    gestaltMacTCPAttr   = 'mtcp'
    gestaltMacTCPOpened = 0;                         *6
****'mmu ' (System)
    gestaltMMUType (addition)

    gestalt68040MMU = 4; *2
****'MV10' (TearOFF cp)
    unknown
****'ppc ' (System)
    gestaltPPCToolboxAttr

    gestaltPPCToolbox        = 'ppc '
    gestaltPPCToolboxDenyIn  =  0; (Deny incoming net requests)  *3
    gestaltPPCToolboxDenyOut =  1; (Deny outgoing net requests)  *3
    gestaltPPCToolboxRTDeliv = 12; (supports real-time delivery) *3
    gestaltPPCToolboxStore   = 13; (supports store and format)   *3
    gestaltPPCToolboxCare    = 14; (supports "Don't care")       *3

    contradiction:
      TN129 says     "gestaltPPCToolboxPresent = 0;"
      GestaltDA says "gestaltPPCToolboxDenyIn  = 0;"
****'proc' (System)
    gestaltProcessorType (addition)

    gestalt68040 = 5; *2
****'qdrw' (System)
    gestaltQuickDrawFeaturesAttr (not listed in IM VI)
    There is a bug in the 'qdrw' selector that causes it to report
    that Color QuickDraw is always present, even on machines that
    don't support it.  Apple has acknowledged this bug on AppleLink.

    gestaltQuickDrawFeatures = 'qdrw'; *2
    gestaltHasColor          = 0;      *2
    gestaltHasDeepGWorlds    = 1;      *2
    gestaltHasDirectPixMaps  = 2;      *2
    gestaltHasGrayishTextOr  = 3;      *2
****'qtim' (QuickTime ext)
    gestaltQuickTimeVersion
    Returns QuickTime version in 4-byte words
    Bug with QT 1.5 (with system 7.0.1)? The response is $01508000 which
    would mean it's version 1.80 final??

    gestaltQuickTimeVersion = 'qtim';
****'SLip' (StuffIt SpaceSaver)
    gestaltStuffItSpaceSaverAddr
    Returns the addres of the SpaceSaver "command module" which allows
    developers to access all the functions of SS.
****'rsrc' (System)
    gestaltResourceMgrAttr (addition)

    additional response exist but unknown (bit 1)
****'tabl' (System)
    gestaltSelectorTable
    Returns the address of the Gestalt selector table itself.

    gestaltSelectorTable = 'tabl';
****'tsmv' (System)
    gestaltTextServicesMgrVersion? (not listed in IM VI)

    gestaltTextServicesMgr = 'tsmv';
    new System 7.1 responses exist but unknown
****'vmcl' (System, VM on)
    unknown.
****'vmbs' (System, VM on)
    unknown.
****'wma.' (System)
    gestaltResponderAttr (Workstation Management Agent aka Responder,
                          not listed in IM VI)

    gestaltResponder        = 'wma.';
    gestaltResponderPresent = 0;
****'xttt' (System)
    gestaltExtToolboxTable
    Returns the base address of the Extended Toolbox trap table.

    gestaltExtToolboxTable = 'xttt';
****'YeHa' (SpeedyFinder7 cp)
    unknown


####Abbreviations:
    appl  - application
    cp    - control panel
    ext   - extension

    ADB   - Apple Desktop Bus
    AS    - AppleShare
    ASC   - Apple Sound Chip
    CPU   - Central Processing Unit
    DAFB  - ?
    DMA   - Direct Memory Access
    DN    - Developer Note
    FPU   - Floating Point Unit
    IOP   - Input/Output Processor
    IWM   - Integrated Woz Machine
    MMU   - Memory Management Unit
    OSS   - ?
    PPC   - Program-to-Program Communication
    RBV   - ?
    SCC   - Serial Communications Controller
    SCSI  - Small Computer System Interface
    SIMM  - Single In-line Memory Module
    Sonic - ?
    SWIM  - Super Integrated Woz Machine
    TN    - Technical Note
    VIA   - Versatile Interface Adapter
    VM    - Virtual Memory


####Format 4-byte word version number (*5):
    The format of the LONGINT result is as follows:

        byte;                        /* Major revision */
        byte;                        /* Minor revision */
        byte    development = 0x20,  /* Release stage */
                alpha = 0x40,
                beta = 0x60,
                final = 0x80, /* or */ release = 0x80;
        byte;                        /* Non-final release # */

####About AppleShare File & Print Server selectors
    The selectors are present when the application has ran.
    If it is still running (or wasn't properly quit) the response
    is one (1). When the application has properly quit the response
    is zero (0).
    'admn' AppleShare Admin
    'asps' AppleShare Print Server
    'hgfd' AppleShare File Server


####Sources:
    *1 Apple Inc.; TN129 May 1987, rev. May 1992
    *2 Symantec Corp.; THINK Pascal 4.0.1
    *3 Gestalt DA by Carl C.Hewitt, 1990
    *4 Apple Inc.; Developer Notes PowerBook 145
    *5 Apple Inc.; TN311 April 1992, rev. May 1992
    *6 MacTCP 1.1 Programmer's Guide.
    If no source mentioned, found by myself or others (see below).

    All trade names referenced are the trademark or registered
    trademark of their respective holder.


####Thanks to:
    Chris Wysocki<[e-mail]>,
    Cor Stoof <[e-mail]>,
    John van Wielink <[e-mail]>,
    Lawrence D'Oliveiro <[e-mail]>,
    Leonard Rosenthol<[e-mail]>,
    Marco Piovanelli <[e-mail]>,
    Mark B. Johnson <[e-mail]>,
    Pete Resnick <[e-mail]>,
    Quinn <[e-mail]>.

    These persons provided information used in this list. They did this
    on personal title, NOT on behalf of their employer.
    There is no reference to which information they provided.
    I assume information mailed to me about Gestalt selectors may be
    added to this list. If information was provided in a posting to a
    Usenet group, this is also included and the persons name added to
    the 'Thanks to' list.
    I will not mail you back only to say 'Thank you'.


####Moderator:
    Rene G.A. Ros (student Computer Science)
    D.C. van Krimpenstraat 3
    1067 SG  Amsterdam, The Netherlands
    Phone#    : [phone]
    Fax#      : [phone]
    Internet  : [e-mail]
                [e-mail]
    CompuServe: 100112,1363 (not prefered)
                >INTERNET:[e-mail]

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

From: [e-mail] (Matthew Xavier Mora)
Subject: TimeDBRA
Date: 16 Oct 92 18:28:39 GMT
Organization: SRI International

I would like to know how to determine what MHZ a mac CPU is using.
I see a global called TimeDBRA which IM says "TimeDBRA=$D00; number of
DBRAs executed per millisecond [word] V-352"

Is this a reliable figure? Can the speed of the processor be determined
with this value? I would like to know because I am working on a info
program like MacEnvy.

Also I know I can assume that a certain cpu is at xmhz according to the
product sheet (MacPlus is at 8mhz) but what if its using an accelerator?

My MacSE say timedbra=6
My Mac II says timedbra=10

My MacSE has a 16mhz 68000 upgrade.

So the main question is how can I figure out the speed of the system
in Mhz?

- --
- ----------------------------------------------------------------------
Matthew Xavier Mora                                [e-mail]
SRI International                                       [phone]
- ----------------------------------------------------------------------

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

From: [e-mail] (Keith Rollin)
Organization: Taligent
Date: Fri, 16 Oct 1992 22:12:57 GMT

In article <[e-mail]>, [e-mail]
(Matthew Xavier Mora) wrote:
>
> I would like to know how to determine what MHZ a mac CPU is using.
> I see a global called TimeDBRA which IM says "TimeDBRA=$D00; number of
> DBRAs executed per millisecond [word] V-352"
>
> Is this a reliable figure? Can the speed of the processor be determined
> with this value? I would like to know because I am working on a info
> program like MacEnvy.

You cannot determine the CPU speed this way. TimeDBRA can have different
values depending on, say, whether or not the on-chip-cache for the 68040 is
on or off, or whether a Mac IIci has a cache card.

> So the main question is how can I figure out the speed of the system
> in Mhz?

I'm afraid I don't have any clever ideas here. In my mind, the question
isn't "How fast is my Mac going?" but "Is my Mac going fast enough for my
needs?" A raw MHz rating isn't going to tell me that.

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

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

From: [e-mail] (Jim Reekes)
Date: 19 Oct 92 18:44:27 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Matthew Xavier Mora) wrote:
>
> I would like to know how to determine what MHZ a mac CPU is using.
> I see a global called TimeDBRA which IM says "TimeDBRA=$D00; number of
> DBRAs executed per millisecond [word] V-352"

But, it's the number of milliseconds for executing DBRAs from the ROM.
This is different from the code speed being ran out of RAM.
This number also doesn't consider many other factors such as 8, 16, or 32
bit bus addressing, NuBus speeds, etc.

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | RAll 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.S

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

From: [e-mail] (Matt Mora)
Date: 20 Oct 92 16:14:44 GMT
Organization: SRI International, Menlo Park, California

In article <REEKES-191092114530@90.10.20.67> [e-mail] (Jim Reekes) writes:
>
>But, it's the number of milliseconds for executing DBRAs from the ROM.
>This is different from the code speed being ran out of RAM.
>This number also doesn't consider many other factors such as 8, 16, or 32
>bit bus addressing, NuBus speeds, etc.


If the figure is unreliable, then what's the purpose of this global?

Does anybody know?




Matt





- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

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

From: [e-mail] (Michael Peirce)
Date: 21 Oct 92 06:13:34 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Matt Mora) writes:
> In article <REEKES-191092114530@90.10.20.67> [e-mail] (Jim Reekes) writes:
> >
> >But, it's the number of milliseconds for executing DBRAs from the ROM.
> >This is different from the code speed being ran out of RAM.
> >This number also doesn't consider many other factors such as 8, 16, or 32
> >bit bus addressing, NuBus speeds, etc.
>
>
> If the figure is unreliable, then what's the purpose of this global?
>
> Does anybody know?

Pure conjecture, but...

There are a number of things on the Mac that need direct, time critical
attention by the CPU (such as the floppy disk and maybe AppleTalk).
The code that does this *is* in ROM and probably uses the value to
set up time critical code.

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Makers of...        --   voice: [phone] fax: [phone]
- --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce

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

From: [e-mail] (Kent Borg)
Date: 21 Oct 92 14:49:23 GMT
Organization: Camex Inc., Boston MA

In article <[e-mail]> [e-mail] (Michael Peirce) writes:
>
>In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Matt Mora) writes:
>> In article <REEKES-191092114530@90.10.20.67> [e-mail] (Jim Reekes) writes:
>> >
>> >But, it's the number of milliseconds for executing DBRAs from the ROM.
>> >This is different from the code speed being ran out of RAM.
>> >This number also doesn't consider many other factors such as 8, 16, or 32
>> >bit bus addressing, NuBus speeds, etc.
>>
>>
>> If the figure is unreliable, then what's the purpose of this global?
>>
>> Does anybody know?
>
>Pure conjecture, but...
>
>There are a number of things on the Mac that need direct, time critical
>attention by the CPU (such as the floppy disk and maybe AppleTalk).
>The code that does this *is* in ROM and probably uses the value to
>set up time critical code.


More conjecture:

When that global was conceived the computer world was a simpler place.
CPU data books still gave timing data for individual instructions,
timings were still predictable.  It was a fair measure of raw computer
speed.  These days, with nested caches and pipelined chips, timings
are not even going to be always repeatable.

It makes me wonder how one does do timing critical code?  I guess by
avoiding the point.  Localtalk timing is not CPU determined, is it?
Isn't it the UART which clocks out those bits?  The CPU simply needs
to be fast enough to supply the data and swallow the data.  For the
floppy, I didn't think the CPU regulated the motor speed, I thought it
just stuffed some hardware to set it.  (So why do they turn off
interrupts?  Probably they have no buffer space on the IWM chip
either.)

Non-Apple Sound Chip sound seems the most critical--and note, sound is
one thing that broke on some accelerators. Maybe they were the ones
that didn't adjust the TimeDBRA early enough in the boot
process...comments Mr. Reekes?


- --
Kent Borg            [e-mail] or [e-mail] (when it is *working*)
                                            H:[phone]  W:[phone]
As always, things look better when some costs are left out.
                              -Economist 3-28-92 p. 94

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

From: [e-mail] (Mike Bell)
Date: 21 Oct 92 20:27:16 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Kent Borg) writes:

>
> More conjecture:
>
> When that global was conceived the computer world was a simpler place.
> CPU data books still gave timing data for individual instructions,
> timings were still predictable.  It was a fair measure of raw computer
> speed.  These days, with nested caches and pipelined chips, timings
> are not even going to be always repeatable.
>
> It makes me wonder how one does do timing critical code?  I guess by
> avoiding the point.  Localtalk timing is not CPU determined, is it?


Well, sort of. While the actual data is clocked, the  LocalTalk protocol
timing is CPU speed dependent. For example, the IDG and IFG times are
measured by the processor. So, faster processors would run LocalTalk at the
wrong speed unless the time parameters were adjusted for each processor speed.



  -Mike



****************************************************************************

Mike Bell                                                                                    email: [e-mail]
Senior Engineer
68000 High Performance Software Group
MS 60-CS
Apple Computer, Inc.
20525 Mariani Ave.
Cupertino, CA 95014

****************************************************************************

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

From: Steve Christensen <[e-mail]>
Date: Thu, 22 Oct 1992 00:57:19 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Matt Mora, [e-mail] writes:
>[e-mail] (Jim Reekes) writes:
>>But, it's the number of milliseconds for executing DBRAs from the ROM.
>>This is different from the code speed being ran out of RAM.
>>This number also doesn't consider many other factors such as 8, 16, or
32
>>bit bus addressing, NuBus speeds, etc.
>
>If the figure is unreliable, then what's the purpose of this global?
>Does anybody know?

TimeDBRA is calculated by executing a DBRA loop in ROM (with interrupts
turned off and cache turned on, and the DBRA loop preloaded into the
cache) as part of the startup process.  So running out of ROM or RAM
has essentially no difference since the only hit you'd take would be
for a single cache fetch of the loop instruction (DBRA), which is
pretty much insignificant.

The only other thing that affects the timing of the loop is if interrupts
are enabled while the loop is executing.  This will increase the time it
takes to execute the loop, plus you may also have to re-fetch the DBRA
instruction.

TimeDBRA is used for generating timing loops when (1) the loop time is
under 16ms (1 tick), or (2) using the Delay() routine wouldn't work (if
interrupts were disabled, for example).

For the speed-sensitive portions of the ROM and system software, it's
important that they work on a wide variety of machines, no matter if
it's a 16MHz '020 or a 33MHz '040.  TimeDBRA-based loops provide one
means of throttling executing speed (when needed).

steve

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

From: [e-mail] (Philip Craig)
Date: 22 Oct 92 22:15:49 GMT
Organization: Canon Information Systems Research Australia

In article <[e-mail]> [e-mail] (Matt Mora) writes:
>In article <REEKES-191092114530@90.10.20.67> [e-mail] (Jim Reekes) writes:
>>
>>But, it's the number of milliseconds for executing DBRAs from the ROM.
>>This is different from the code speed being ran out of RAM.
>>This number also doesn't consider many other factors such as 8, 16, or 32
>>bit bus addressing, NuBus speeds, etc.
>
>
>If the figure is unreliable, then what's the purpose of this global?
>
>Does anybody know?

I always thought it was used by AppleTalk code to work out some timing
details for the processor it was running on. I know I've seen references
to AppleTalk fixes taking account of DBRA.
- --
   _/_/_/ _/  _/ _/ _/     _/ _/_/_/ _p_h_i_l_i_p_@_r_e_s_e_a_r_c_h_._c_a_n_o_n_._o_z_._a_u   _--_|\
  _/  _/ _/  _/ _/ _/     _/ _/  _/  Phone: [phone]        /      \
 _/_/_/ _/_/_/ _/ _/     _/ _/_/_/   Fax:   [phone]        \_.--._/
_/     _/  _/ _/ _/_/_/ _/ _/     PO Box 313 North Ryde 2113 AUSTRALIA  v

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

From: [e-mail] (Pete Resnick)
Subject: TrapAvailable for C (Was Re: help with Link failures in THINK C 5.03)
Date: 19 Oct 92 01:57:40 GMT
Organization: University of Illinois at Urbana

Here is my version of TrapAvailable for C. Hope it comes in handy:

Boolean TrapAvailable(short theTrap)
{
    long trapAddress;

    if(theTrap & 0x0800) {
        theTrap &= 0x07FF;
        if(theTrap >= ((GetToolTrapAddress(_InitGraf) == GetToolTrapAddress(0xAA6E)) ? 0x0200 : 0x0400))
            return(false);
        trapAddress = GetToolTrapAddress(theTrap);
    } else {
        trapAddress = GetOSTrapAddress(theTrap);
    }
    return(trapAddress != GetToolTrapAddress(_Unimplemented));
}

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] (Bill Williams)
Organization: HoloNet (BBS: 510-704-1058)
Date: Mon, 19 Oct 1992 08:12:43 GMT

Hers my more verbose version of "Trap_Available", it is not as efficient
but a little more clear.

INTEGER_16 Number_Of_Toolbox_Traps(void)
{
#define INITGRAF_TRAP        0xA86E

    if (NGetTrapAddress(INITGRAF_TRAP, ToolTrap) ==
NGetTrapAddress(0xAA6E, ToolTrap))
        return(0x200);
    else
        return(0x400);

}
/*=**************************************************************************=*/


/*=**************************************************************************=*/
INTEGER_16 Get_Trap_Type(INTEGER_16 trap_Number)
{
#define TRAP_MASK        0x0800

    if ((trap_Number & TRAP_MASK) > 0)
        return(ToolTrap);
    else
        return(OSTrap);

}
/*=**************************************************************************=*/


/*=**************************************************************************=*/
Boolean Trap_Available(INTEGER_16 trap_Number)
{
    INTEGER_16        trap_Type;
    Boolean    function_Result;


    function_Result = FALSE;
    trap_Type = Get_Trap_Type(trap_Number);
    if (trap_Type == ToolTrap) {
        trap_Number = trap_Number & 0x07FF;
        if (trap_Number >= Number_Of_Toolbox_Traps())
            trap_Number = _Unimplemented;
    }

    if (NGetTrapAddress(trap_Number, trap_Type) !=
NGetTrapAddress(_Unimplemented, ToolTrap))
        function_Result = TRUE;

    return(function_Result);

}


Bill Williams


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

From: [e-mail] (Jim Reekes)
Date: 21 Oct 92 18:05:32 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Pete
Resnick) wrote:
>
> Here is my version of TrapAvailable for C. Hope it comes in handy:
>
> Boolean TrapAvailable(short theTrap)
> {
>     long trapAddress;
>
>     if(theTrap & 0x0800) {
>         theTrap &= 0x07FF;
>         if(theTrap >= ((GetToolTrapAddress(_InitGraf) == GetToolTrapAddress(0xAA6E)) ? 0x0200 : 0x0400))
>             return(false);
>         trapAddress = GetToolTrapAddress(theTrap);
>     } else {
>         trapAddress = GetOSTrapAddress(theTrap);
>     }
>     return(trapAddress != GetToolTrapAddress(_Unimplemented));
> }


Your version is very close to the one I use.  They're both based on the
original version published by MacDTS and now in Inside Mac.  I've added an
explaination as to how this works.  I also avoid tertiary expressions
unless it's very very short and simple.


#define       kOSTrapBit          (1<<11)  /* bit 11 is the OS Trap bit */
#define       kATrapBits          0xA800   /* bits used by the A-Trap mechanism */

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// InitGraf is always implemented (trap 0xA86E). If the trap table is big
// enough, trap 0xAA6E will always point to either Unimplemented or some
other
// trap, but will never be the same as InitGraf. Thus, you can check the
size
// of the trap table by asking if the address of trap 0xA86E is the same as
0xAA6E.

short NumToolboxTraps(void)
{
    if ( GetToolboxTrapAddress(_InitGraf)
         == GetToolboxTrapAddress(_InitGraf + 0x0200) )
        return (0x0200);
    else
        return (0x0400);
}

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Check to see if a given trap is implemented.  GetTrapAddress may fuck up
and
// wrap around into the trap table if you give it a toolbox trap that is
out of
// range, so check for this first.

Boolean TrapExists(short theTrap)
{
    long            trapAddress;

    if ( !(theTrap & kOSTrapBit) )                    // is it an OS trap?
        trapAddress = GetOSTrapAddress(theTrap);
    else {
        theTrap &= ~kATrapBits;                       // get the trap
number
        if ( theTrap < NumToolboxTraps() )            // can this tool trap
exist?
            trapAddress = GetToolTrapAddress(theTrap);
        else
            return (false);
    }
    return ( GetToolboxTrapAddress(_Unimplemented) != trapAddress );
}


- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | RAll 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.S

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

From: [e-mail] (Mike Engber)
Date: 22 Oct 92 19:17:22 GMT
Organization: The Institute for the Learning Sciences


Ok, here's my TrapAvailable implementation. The only reasons I can offer
for why you should bother to look are:

  * TRAP_AVAIL is a #define macro and the determination of whether or
    no the trap is a tool or os trap is done at compile time by a smart
    compiler (like THINK C). So that's a small efficiency gain.

  * It's very terse. Obfuscated C code fans should love it. Unfortunatly,
    several of the line are > 80 chars - so if your viewing it wrapped it
    may be hard to read.

Below are the .h and a .c file. TRAP_AVAIL is the macro thats
supposed to be used (as opposed to the two fns).  Written in THINK C.

- -ME

- ---

***trapU.h***

#include <traps.h>

/* see IM VI p 3-8 */
#define TRAP_IMPL(trap,type)    (NGetTrapAddress(trap,type) != NGetTrapAddress(_Unimplemented,ToolTrap))
#define NUM_TOOL_TRAPS          (NGetTrapAddress(_InitGraf,ToolTrap) == NGetTrapAddress(0xAA6E,ToolTrap) ? 0x0200 : 0x0400)
#define TRAP_TYPE(trap)         (trap & 0x0800 ? ToolTrap : OSTrap)
#define TRAP_AVAIL(trap)        ((TRAP_TYPE(trap) == ToolTrap) ? ToolTrapAvail(trap) : OSTrapAvail(trap))

extern Boolean ToolTrapAvail(short theTrap);
extern Boolean OSTrapAvail(short theTrap);


***trapU.c***


#include "trapsU.h"

Boolean ToolTrapAvail(short theTrap){
    return (theTrap & 0x7FFF >= NUM_TOOL_TRAPS) ? false : TRAP_IMPL(theTrap,ToolTrap);
}

Boolean OSTrapAvail(short theTrap){
    return TRAP_IMPL(theTrap,OSTrap);
}

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

From: [e-mail] (Pete Resnick)
Date: 22 Oct 92 22:03:26 GMT
Organization: University of Illinois at Urbana

[e-mail] (Mike Engber) writes:

>  * TRAP_AVAIL is a #define macro and the determination of whether or
>    no the trap is a tool or os trap is done at compile time by a smart
>    compiler (like THINK C). So that's a small efficiency gain.

For OSTraps, it is certainly more efficent. For ToolTraps, depending on
how many times you call TrapAvailable, NUM_TOOL_TRAPS being a macro
would generate quite a bit more code. I like it in principle though.
Also, using NGetTrapAddress produces glue, whereas using
GetToolTrapAddress and GetOSTrapAddress just put the traps in-line.

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] (Mike Engber)
Subject: calling GetMenu twice on same MENU - actually seems ok?
Date: 21 Oct 92 13:45:42 GMT
Organization: The Institute for the Learning Sciences


I know why you shouldn't call GetMenu twice on the same MENU. But,
recently I had decided this was the bug I was tracking and it turned
out not to be. It seems (in System 7 at least) that GetMenu has been
change to compensate for this common error. Can anyone confirm this?

And yes, I checked that the word at offset 6 didn't happen to be
zero after the first call to GetMenu.

Along similar lines, TN#78 warns that you need to set ResErrProc
to NULL while you call get menu, else if you're using a ResErrProc
on 128ROM machines your ResErrProc will get called when it shouldn't.
Has this ever been fixed? It's a pretty subtle point and one I would
never have know about if someone hadn't pointed it out to me.

In the end, none of these trap bug fixes really does any good
(as far as cleaning up code goes) if you want backward compatibility.
It sort of depressing to see all these hacks cluttering my code
with no real hope of ever eliminating them. I guess PowerPC will
offer some chance - depends on how backward compatible they make its
ToolBox.

- -ME

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

From: [e-mail] (Larry Rosenstein)
Date: 22 Oct 92 21:37:45 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Mike
Engber) wrote:
>
> out not to be. It seems (in System 7 at least) that GetMenu has been
> change to compensate for this common error. Can anyone confirm this?

On a IIci, Quadra, and PB140, the ROM version of GetMenu seems to test
whether the defproc handle is a handle to an MDEF resource.  If not then it
assumes that the MDEF needs to be read in.  I don't have an older machine
to examine, in order to see if this is patched in earlier machines.

This should handle the most common cases of calling GetMenu twice, but it
won't help if you install a custom defproc that's not a real MDEF and call
GetMenu on that menu.  For example, rather than creating an MDEF resource,
some applications that use custom menus create a small handle that JMPs to
the defproc code, which is linked into the app.  I don't think the ROM test
will detect this case.

Larry Rosenstein
Taligent, Inc.

[e-mail]

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

From: [e-mail] (Christopher Suley)
Subject: Resource Manager Questions
Date: 21 Oct 92 16:08:50 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

I am writing some code that grabs resources out of a file that the user
chooses using StandardGetFile or SFGetFile.

When I am done with the file, I would like to call CloseResFile( refNum ),
but I realize that an enterprising user might choose to scrounge around
in the System file.  Closing the System file is a Bad Thing, so I am
trying to find a way to recognize that I have opened the System file,
and not close it.

IM V1 indicates that the System file is referred to with reference number 0.
However, I have found evidence to the contrary.

Using FSpOpenResFile (HOpenResFile under System 6), I watched in MacsBug as
I opened the System file.  The reference number returned was 2!  So, my
checking for refNum > 0 before CloseResFile( refNum ) was ineffective, and
I enjoyed a spectacular crash.

So, what is the official way to recognize that you have opened the System
file?  Should I just check to see if the type and creator are 'ZSYS','MACS'?

I also have a second question.  If I open up a resource file and grab its
resources, I don't want to dispose of resources that are already in use.
Would code like this be acceptable?:

n = Count1Resources( resType );
for ( i = 1 ; i <= n ; i++ )
  {
    SetResLoad( false );
    h = Get1IndResource( resType, i );
    SetResLoad( true );
    if ( GetHandleSize( h ) )
      disposeMe = false;
    else
      {
        disposeMe = true;
        LoadResource( h );
      }

    // yatta yatta yatta

    if ( disposeMe )
      ReleaseResource( h );
  }

Thanks in advance.

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

From: [e-mail] (Marshall Clow)
Date: 21 Oct 92 17:20:30 GMT
Organization: Hewlett Packard San Diego Printer Division

In article <[e-mail]>, [e-mail]
(Christopher Suley) wrote:
>
> I am writing some code that grabs resources out of a file that the user
> chooses using StandardGetFile or SFGetFile.
>
> When I am done with the file, I would like to call CloseResFile( refNum ),
> but I realize that an enterprising user might choose to scrounge around
> in the System file.  Closing the System file is a Bad Thing, so I am
> trying to find a way to recognize that I have opened the System file,
> and not close it.
[ stuff deleted ]

What you really want to do is to check if the file is already open. This
is true no matter what file you are modifying, System file or watever. If
the file is already open, then you don't want to close it. You can check
using PGetCatInfo, and checking the flags. One of them (bit 2) tells you if
the resource fork is open [See IM-IV pp 125]

> I also have a second question.  If I open up a resource file and grab its
> resources, I don't want to dispose of resources that are already in use.
> Would code like this be acceptable?:
[ code deleted ]
Looks ok to me.

> Thanks in advance.
You're welcome.

One other point: Remember to SetResLoad ( false ) before you open the
resource file, so that resources marked 'preload' will not get loaded.

Marshall Clow
San Diego Printer Division      Hewlett Packard
Internet: [e-mail]   AppleLink: HP.Marshall    AOL: MClow

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

From: [e-mail] (Jamie R. McCarthy)
Date: 21 Oct 92 17:34:08 GMT
Organization: Kalamazoo College

[e-mail] (Christopher Suley) writes:
>
>I am writing some code that grabs resources out of a file that the user
>chooses using StandardGetFile or SFGetFile.
>
>When I am done with the file, I would like to call CloseResFile( refNum ),
>but I realize that an enterprising user might choose to scrounge around
>in the System file.  Closing the System file is a Bad Thing, so I am
>trying to find a way to recognize that I have opened the System file,
>and not close it.

I would suggest that opening the System file (or any file already open)
is a very touchy thing to do.  Witness ResEdit's superstitious behavior
when you mess with it or with ResEdit itself.

The first thing that comes to mind, when you say you're getting 2 as the
System's refnum, is that you've just opened another access path to its
resource fork, which is not a Good Thing.  Might this be possible?

If you were I, I'd special-case the opening of the system file (checking
type/creator should do it, make sure it's in the blessed folder too).
(If you want the app to be able to open itself, you'll have to
special-case that as well.)  I'd handle a resource read by setting the
current resource file to 0 and reading it in (make sure you don't make
any cross-segment function calls that might require 'CODE' to be loaded
in).  Would that work?
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Regrettably, my college's computer has once again deleted my in-box without
 even telling me who the senders were. If you sent me mail around Sunday night,
 contact me. Don't resend a long (100K) letter, it'll just delete it again.

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

From: [e-mail] (Keith Rollin)
Date: 21 Oct 92 18:53:04 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Christopher Suley) wrote:
>
> I am writing some code that grabs resources out of a file that the user
> chooses using StandardGetFile or SFGetFile.
>
> When I am done with the file, I would like to call CloseResFile( refNum ),
> but I realize that an enterprising user might choose to scrounge around
> in the System file.  Closing the System file is a Bad Thing, so I am
> trying to find a way to recognize that I have opened the System file,
> and not close it.

Marshall Clow and James McCarthy have responded to this question already.
Unfortunately, there are problems with their solutions.

Marshall suggests looking at the resource-fork-is-open bit returned by
GetCatInfo. The problem with this is that this bit is set if the file is
open by _any_ process, when what you need to know is if the file is open by
_your_ process.

James suggests special checking for the System file. However, this ignores
other files that might be open, such as your own application, files open by
Suitcase, or System 7.1 font files.

A working solution is shown in DTS sample code #18. I think that someone
else posted an slightly different approach which I considered a little
better, but I'm afraid I can't remember what/who it was right now.

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

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

From: [e-mail] (Jamie R. McCarthy)
Date: 21 Oct 92 19:52:08 GMT
Organization: Kalamazoo College

[How do you get access to a resource fork that may already be open, e.g.
the System, your own app, another running app, a suitcase opened by
Suitcase, etc.?]

[e-mail] (Keith Rollin) writes:
>
>A working solution is shown in DTS sample code #18. I think that someone
>else posted an slightly different approach which I considered a little
>better, but I'm afraid I can't remember what/who it was right now.

I vaguely recall someone saying to open the resource file, then to check
the lo-mem global TopMapHndl.  If it was already open, the global
wouldn't change;  otherwise it would.  But I can't find any reference to
TopMapHndl.  Does this sound at all familiar?

By the way, am I correct in assuming that God will strike you down if
you try to open the System's resource fork with write access?  'cos
StdFile.p (sample #18) only demonstrates read access.  I expect ResEdit
is full of custom code that basically duplicates what the Resource
Manager does except it allows direct munging of already-open files like
the System...
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Regrettably, my college's computer has once again deleted my in-box without
 even telling me who the senders were. If you sent me mail around Sunday night,
 contact me. Don't resend a long (100K) letter, it'll just delete it again.

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

From: [e-mail] (Christopher Suley)
Date: 21 Oct 92 19:56:28 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

[e-mail] (Keith Rollin) writes:
>[e-mail] (Christopher Suley) wrote:
>>
>> I am writing some code that grabs resources out of a file that the user
>> chooses using StandardGetFile or SFGetFile.
>>
>> When I am done with the file, I would like to call CloseResFile( refNum ),
>> but I realize that an enterprising user might choose to scrounge around
>> in the System file.  Closing the System file is a Bad Thing, so I am
>> trying to find a way to recognize that I have opened the System file,
>> and not close it.
>
>Marshall Clow and James McCarthy have responded to this question already.
>Unfortunately, there are problems with their solutions.
>
>Marshall suggests looking at the resource-fork-is-open bit returned by
>GetCatInfo. The problem with this is that this bit is set if the file is
>open by _any_ process, when what you need to know is if the file is open by
>_your_ process.

Actually, I'm doing this from a Control Panel (forgot to say that), so I'm
not really a process.  I don't think it matters who has it open, I just want
to know if it's open at all.

>A working solution is shown in DTS sample code #18.

Sample code #18 says to use read-only permission to get a unique access path
to a file, but cautions that you shouldn't use a read-only file because
someone else might come along and stomp on it.  Since all I am doing is
reading some resources out of the file into my own data structures, then
immediately closing (if appropriate) the file, does this affect me?  The
Mac OS isn't pre-emptive, so as long as my code is executing, no one else
is going to munge the resources I'm copying, right?

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

From: [e-mail] (Matt Mora)
Date: 21 Oct 92 20:06:31 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:

>I vaguely recall someone saying to open the resource file, then to check
>the lo-mem global TopMapHndl.  If it was already open, the global
>wouldn't change;  otherwise it would.  But I can't find any reference to
>TopMapHndl.  Does this sound at all familiar?


TopMapHndl=$A50; 1st map in list [handle] IM vol 1 page 115




Matt



- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

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

From: [e-mail] (Keith Rollin)
Date: 22 Oct 92 00:40:08 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Christopher Suley) wrote:
>
> Sample code #18 says to use read-only permission to get a unique access path
> to a file, but cautions that you shouldn't use a read-only file because
> someone else might come along and stomp on it.  Since all I am doing is
> reading some resources out of the file into my own data structures, then
> immediately closing (if appropriate) the file, does this affect me?  The
> Mac OS isn't pre-emptive, so as long as my code is executing, no one else
> is going to munge the resources I'm copying, right?

Keerect, keemosabi. Open-read-only/read/close will work as long as you
don't call WaitNextEvent (or let the Finder do it, which is the process
you're running under (with System 7)).

Both you and James pointed out that the technique I was referring to in
Sample Code #18 has been removed. Sorry for that dangling pointer. The
technique was to look at TopMapHndl, remember it, call FSpOpenResFile (yes,
I'm a System 7 bigot), and see if TopMapHndl had changed. If it had, then
the resource fork had just been opened, and needed to be closed when you
were done.

It's been a while since I've done this, so I hope I haven't forgotten
anything. I think it was Lawrence D'Oliveiro who described a method like
this several months ago. If so, I hope he'll point out any ommissions,
caveats, etc.

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

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

From: Quinn <[e-mail]>
Organization: The University of Western Australia
Date: Fri, 23 Oct 1992 01:08:13 GMT

Will someone *please* bundle up *the* definitive solution to this
problem and mail it to Mike Kelly <[e-mail]> so he can
put it in the FAQ.

Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  -- "FAQ you, a***h***!", The Usenet Terminator (-:

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

From: [e-mail] (William Knott)
Date: 23 Oct 92 06:21:33 GMT
Organization: Apple Computer


One of the original fears that Christopher Suley stated was that 'Closing
the System file is a Bad Thing'.  I do agree with this, however calling
CloseResFile on the System File will not close it, the resource manager
contains a check to make sure a file marked as non-closable is not closed, and
the system approprately enough is one of them

- -----
Bill Knott
Apple Computer, Inc.

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

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