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

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

C.S.M.P. Digest             Tue, 20 Oct 92       Volume 1 : Issue 189

Today's Topics:

    Extended PRam
    PathName from FSSpec (pascal code)
    simulating page-flipping via cluts
    HFS Calls in IM6?
    HOT KEY trouble
    Acessing the TRAP word
    Writing an external file system
    I wanna program a Newton - but how?
    Trap word parameter to Set/GetTrapAddress?



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: [e-mail]
Subject: Extended PRam
Date: 9 Sep 92 14:13:29 GMT
Organization: Penn State University

Does anyone know the format of PRam beond the 20 bytes documented in IM
or where it is documented?  Information about how to access it (ReadXPRam
and WriteXPRam?) would also be appreciated.  I am trying to set the alert
sound to some default for system 7 and it seems to be kept in XPRam
somewhere.  I also need to know where system 6.0.7 kept the defalt.

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

From: [e-mail] (Jon Pugh)
Date: 14 Sep 92 21:47:06 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] wrote:
>
> Does anyone know the format of PRam beond the 20 bytes documented in IM
> or where it is documented?  Information about how to access it (ReadXPRam
> and WriteXPRam?) would also be appreciated.  I am trying to set the alert
> sound to some default for system 7 and it seems to be kept in XPRam
> somewhere.  I also need to know where system 6.0.7 kept the defalt.

It would appear that no one has written down all the secret bytes of XPRAM,
although someone must arbitrate conflicts when we define stuff.  I've just
never needed to know.  I did disassemble the Sound cdev to figure out where
and how the beep resource number was saved for my SwitchBeep cdev
(available on ftp.apple.com in /pub/pugh/switchbeep.sit.hqx).

The ReadXParam and WriteXParam traps are apparently discussed in the
hardware manual (a WWDC trivia question was "What are the only traps not
defined anywhere in Inside Macintosh?").  They are register based traps
without glue, so they cannot be called directly from C or Pascal.

However, I have created two cheap routines which do exactly what you want.
Since I am a nice guy, at least at the moment, here they are.  Send money.
;)

FUNCTION GetBeep: Integer; INLINE $204F, $203C, $0002, $007C, $A051;

PROCEDURE SetBeep (theBeep: Integer); INLINE $204F, $203C, $0002, $007C,
$A052;

These routines use the 'snd ' resource ID number.  This is the same under
system 6 and 7.

As usual, these routines are unsafe and unsupported.  I might even be
hosing your stack since I hand assembled them but they seem to work for me.

Jon

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

From: [e-mail] (Matthew Xavier Mora)
Subject: PathName from FSSpec (pascal code)
Date: 9 Sep 92 00:21:34 GMT
Organization: SRI International

I spent the long weekend cursing at the AppleEventManager
trying to get the finder to open a control panel. Anyway,
one of the things I discoverd was that the alias manager will
give you a path name if you ask for it. Since my program needed to
display the path name, I wrote a function that will return a full
path name in a handle (not in a str255 so you it won't crash with long
path names) when you give it a fsspec.

I also figured out how to get the finder to open a control panel.
You need to send an open selection event. I finally found an example that
worked and ported it to pascal. If you would like to see that code I can
post it here also. Its a direct copy of C.K Han's C code that is on the
developers CD.

Here is the code:

{-------------------------------------------------------------------------}
{Path Name From FSSpec                                                    }
{by Matthew Xavier Mora                                                   }
{9-8-92                                                                   }
{Given a FSSpec this function will return a handle to the full path       }
{name. It creates the handle as it goes. It does not have the limited     }
{string length (255) problem like the ones I have seen. This of course    }
{requires system seven or better because of the use of the alias manager  }
{ Don't forget to dispose the handle when you are done with it.           }
{-------------------------------------------------------------------------}
{$PUSH}
{$-R}
 function PathNameFromFSSpec (var theFile: FSSpec): Handle;
  var
   i: AliasInfoType;
   theStr: STR63;
   h: Handle;
   oe: OSErr;
   alias: AliasHandle;
   theSize: longint;
 begin
  PathNameFromFSSpec := nil;
  oe := NewAlias(nil, theFile, alias);          {create a temporary alias}
  if alias = nil then                                       {if nil exit }
   exit(PathNameFromFSSpec);

  h := NewHandle(0);
  if h = nil then                                          {if nil exit. }
   exit(PathNameFromFSSpec);

  i := asiAliasName;                       { set the index to the Parent }
  if GetAliasInfo(alias, i, thestr) = noerr then     {get The parentName }
   begin                                     {returns error if bad alias }
    while thestr <> '' do      { will be '' when done traversing the path}
     begin
      theSize := longint(thestr[0]) + 1;
      thestr[0] := ':';  { use the size byte to store the colon. aux='/' }
                                                { Let Munger do the work }
      theSize := Munger(h, 0, nil, 0, @thestr, thesize);
      i := i + asiParentName;           {set the index to the next parent}
      oe := GetAliasInfo(alias, i, thestr);          {get the parentName }
     end;
                                                    {get the Volume Name }
    oe := GetAliasInfo(alias, asiVolumeName, thestr);
    theSize := longint(thestr[0]);
    theSize := Munger(h, 0, nil, 0, Ptr(ord(@theStr) + 1), theSize);

    PathNameFromFSSpec := h;             {return the newly created handle}
   end;
  DisposeHandle(Handle(alias));
 end;
{$POP}


Matt

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

From: [e-mail] (Matthew Xavier Mora)
Date: 14 Sep 92 20:13:59 GMT
Organization: SRI International

I spent the long weekend cursing at the AppleEventManager
trying to get the finder to open a control panel. Anyway,
one of the things I discovered was that the alias manager will
give you a path name if you ask for it. Since my program needed to
display the path name, I wrote a function that will return a full
path name in a handle (not in a str255 so it won't crash with long
path names) when you give it a fsspec.

I also figured out how to get the finder to open a control panel.
You need to send an open selection event. I finally found an example that
worked and ported it to pascal. If you would like to see that code I can
post it here also. Its a direct copy of C.K Han's C code that is on the
developers CD.

Here is the code:

{-------------------------------------------------------------------------}
{Path Name From FSSpec                                                    }
{by Matthew Xavier Mora                                                   }
{9-8-92                                                                   }
{Given a FSSpec this function will return a handle to the full path       }
{name. It creates the handle as it goes. It does not have the limited     }
{string length (255) problem like the ones I have seen. This of course    }
{requires system seven or better because of the use of the alias manager  }
{ Don't forget to dispose the handle when you are done with it.           }
{-------------------------------------------------------------------------}
{$PUSH}
{$-R}
 function PathNameFromFSSpec (var theFile: FSSpec): Handle;
  var
   i: AliasInfoType;
   theStr: STR63;
   h: Handle;
   oe: OSErr;
   alias: AliasHandle;
   theSize: longint;
 begin
  PathNameFromFSSpec := nil;
  oe := NewAlias(nil, theFile, alias);          {create a temporary alias}
  if alias = nil then                                       {if nil exit }
   exit(PathNameFromFSSpec);

  h := NewHandle(0);
  if h = nil then                                          {if nil exit. }
   exit(PathNameFromFSSpec);

  i := asiAliasName;                       { set the index to the Parent }
  if GetAliasInfo(alias, i, thestr) = noerr then     {get The parentName }
   begin                                     {returns error if bad alias }
    while thestr <> '' do      { will be '' when done traversing the path}
     begin
      theSize := longint(thestr[0]) + 1;
      thestr[0] := ':';  { use the size byte to store the colon. aux='/' }
                                                { Let Munger do the work }
      theSize := Munger(h, 0, nil, 0, @thestr, thesize);
      i := i + asiParentName;           {set the index to the next parent}
      oe := GetAliasInfo(alias, i, thestr);          {get the parentName }
     end;
                                                    {get the Volume Name }
    oe := GetAliasInfo(alias, asiVolumeName, thestr);
    theSize := longint(thestr[0]);
    theSize := Munger(h, 0, nil, 0, Ptr(ord(@theStr) + 1), theSize);

    PathNameFromFSSpec := h;             {return the newly created handle}
   end;
  DisposeHandle(Handle(alias));
 end;
{$POP}


Matt

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

From: [e-mail]
Subject: simulating page-flipping via cluts
Date: 11 Sep 92 09:03:44 GMT
Organization: University of Missouri - Kansas City

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

> How many games do you know that really, really _need_ 256 colors--not
> 254 or 255 but 256?  If you're clut-flipping to simulate page-flipping,
> OK;  if you're writing for a 2-bit-deep screen, I can see that.  Most
> games get along fine with 254 colors.
>

Two questions: How do you simulate page-flipping with clut-flipping??
Set one clut to all black and draw with it and then flip to the clut
with the proper colors? I'm not sure I see where this gains you
anything. Anyone care to explain in detail??

And second: Wouldn't this fail to accomplish anything at all on
a direct color screen, or am I *completely* misunderstanding (a
distinct possibility.)

Jonathan ([e-mail])

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

From: [e-mail] (Jamie R. McCarthy)
Date: 11 Sep 92 16:31:35 GMT
Organization: Kalamazoo College

[e-mail] writes:
>[e-mail] (Jamie R. McCarthy) writes:
>
>> If you're clut-flipping to simulate page-flipping,
>> [you need every single color]
>
>Two questions: How do you simulate page-flipping with clut-flipping??
>
>And second: Wouldn't this fail to accomplish anything at all on
>a direct color screen, or am I *completely* misunderstanding (a
>distinct possibility.)

The easy one first:  yes, clut-flipping does nothing on a direct-color
screen.  In fact, a direct-color screen doesn't even have a color table
to flip.

Clut flipping is a nasty little technique that lets you pretend you have
two video pages, each of which has half as many bits per pixel as the
real video page.  In short, you split each pixel in half, and alternate
between setting the clut so that one half is visible and the other half
not.  An example might help clarify.

Let's say we're working on an 8-bit-deep screen.  Conceptually, split
each pixel into two 4-bit halves, call them left and right.  To set the
pixel at x,y on the left video page to, say, color 7, you set the high
four bits of the actual pixel at x,y to 7, without disturbing the low
four bits.  To set the pixel on the right video page to color 4, you set
the low four bits to 4 without disturbing the high four bits.

Let's say the palette we're using is sixteen shades of gray.  (Note that
you only get sixteen colors, since each page gets only four bits per
pixel.  Note also that you can have different palettes for the left and
the right page, and that there's actually a good use for that:  there
are glasses that sync to your monitor that use LCD shutters to give a
decent 3-D effect.  But I digress.)  Then, to display the left page, you
set colors 0x00-0x0F to black, 0x10-0x1F to dark gray, ... , 0xF0-0xFF
to white.  To display the right page, you set 0x00, 0x10, ... 0xF0 to
black, 0x01, 0x11, ... 0xF1 to dark gray, and so on.

Note that you don't have to use hi-nybble/lo-nybble for left and right
pages;  you can split up the pixel any way you want.  It doesn't even
have to be an even split, and you can split it as many ways as there are
bits in the pixel in the first place.  If you don't mind having only two
colors and seeing the same eight frames over and over, you can do
eight-position full-screen animation at whatever your monitor's refresh
rate is, using just a tiny fraction of CPU power.

Note also that, if the palette(s) for your virtual pages all have all
their bits clear for white and all their bits set for black, you can
leave those two colors where they are, and the Palette Manager will be
usable.  (Though I'll concede that there's no good reason not to use
SetEntries instead of AnimatePalette when you're getting this
low-level...)
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "I may not understand what you say, but I'll defend to your death
  my right to deny it."                 - Albert, from 'Outrageously Pogo'

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

From: [e-mail] (Joe Francis)
Date: 14 Sep 92 20:55:33 GMT
Organization: Dartmouth College, Hanover, NH

Is this the technique that someone was trying to claim a software
patent on?

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

From: [e-mail] (Brian Patrick Arnold)
Subject: HFS Calls in IM6?
Date: 25 Aug 92 15:39:25 GMT
Organization: Carnegie Mellon, Pittsburgh, PA


Howdy,

Can anybody tell me whether the HFS High-level calls in Inside Macintosh
Vol 6 noted as being equivalent to HFS low-level calls in Inside
Macintosh Vol 4 ARE, IN FACT simply glue to HFS low-level traps, or are
they specific to System 7, i.e., traps themselves?  I noticed that
MacApp 3.0's TFile class uses these HOpenDF etc. without checking for
System 7 or File Manager Gestalt.  TFile does check for Alias manager
using Gestalt, to filter out whether it will do certain FSp, Finder and
Alias Manager calls, but it doesn't filter on the H calls.  I am
compelled to assume it is safe to use H calls documented in Inside
Macintosh vol 6 provided I have the correct include files, and the
correct linker glue?  Am I just stupid and I didn't find the sentence in
Inside Macintosh Vol 6 that explains that I can call the HFS High-level
calls (HRename, HOpenDF etc.) as long as HFS is present? These are the
ones that accept dirIDs, instead of continuing to use FSOpen etc with
working directories, and I am NOT talking about the FSp calls that
require System 7 obviously.  Somebody set me straight.  Thanks,

- - Brian

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

From: [e-mail]
Organization: Campus Computing Sites, University of Michigan-Ann Arbor
Date: Wed, 26 Aug 1992 03:27:07 GMT

In article <[e-mail]> [e-mail] (Brian Patrick Arnold) writes:
>
>Howdy,
>
>Can anybody tell me whether the HFS High-level calls in Inside Macintosh
>Vol 6 noted as being equivalent to HFS low-level calls in Inside
>Macintosh Vol 4 ARE, IN FACT simply glue to HFS low-level traps, or are
>they specific to System 7, i.e., traps themselves?
>
    All of the high level HFS calls ('Hxxx') are valid under System 6 -
EXCEPT HOpenDF which is only valid for Sys7.  However there is no easy way
to test for just "_OpenDF" implemented.  I usually test for the FSSpec
calls to be valid (via Gestalt) and if they are, then so is the OpenDF
routines.

>I noticed that
>MacApp 3.0's TFile class uses these HOpenDF etc. without checking for
>System 7 or File Manager Gestalt.  TFile does check for Alias manager
>using Gestalt, to filter out whether it will do certain FSp, Finder and
>Alias Manager calls, but it doesn't filter on the H calls.
>
    that would mean that MacApp 3 programs won't work under System 6!

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

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

From: [e-mail] (Kent Sandvik)
Date: 15 Sep 92 04:25:36 GMT
Organization: Apple

In article <[e-mail]>,
[e-mail] wrote:
> In article <[e-mail]> [e-mail] (Brian Patrick Arnold) writes:
> >I noticed that
> >MacApp 3.0's TFile class uses these HOpenDF etc. without checking for
> >System 7 or File Manager Gestalt.  TFile does check for Alias manager
> >using Gestalt, to filter out whether it will do certain FSp, Finder and
> >Alias Manager calls, but it doesn't filter on the H calls.
> >
>     that would mean that MacApp 3 programs won't work under System 6!

Huh? MacApp 3.0.1 TFile uses PBHOpenDenySync OR PBHOpenSync for opening the
data fork, and HOpenResFile for opening the resource fork System 6-wise,
and FSpOpenResFile if System 7 is present. The last thing is also
a little bit questionable, because HOpenResFile works fine in both
environments (looking at the code the MacApp engineers saved one
link assignment for the file name, so I guess they saved 20-30 cycles
on that one).

So there are no known problems as I know of opening files with
the MacApp provided TFile Open routines. Using PBHOpenDenySync before
PBHOpenSync is also smart; MacApp tests if the file has file
access permissions OK (shared volume) before trying PBHOpenSync
on a normal HFS based volume. I guess anyone else looking at
File I/O routines could take a look at the code inside UFile.cp
in the MacApp library folder.

Cheers,
Kent Sandvik/DTS

"I would rather have a thousands idiots attacking my position, than
have one idiot helping to defend it."    [Paraphrased from Voltaire]
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: [e-mail])
DISCLAIMER: Private activities on the Net.

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

From: [e-mail] (Eric Braun)
Subject: HOT KEY trouble
Date: 30 Jul 92 18:56:18 GMT
Organization: PANIX Public Access Unix, NYC

Hi,

I'm implementing a hot key by patching JGNEFilter and looking for the
appropriate key as the events flow by.  This works fine and dandy.
The problem is that the hot key is supposed to open up my DA and the
way it works now is that it'll open up the DA on top of almost
anything!

This is bad new cus you don't want a DA poping up on top of, say, a
file selection box, or any other modal dialog for that matter.

THE QUESTIONS: how can I tell if a modal dialog box is open so as to
temporarily disable the hotkey?  Are there any other situations that
might cause problems where I should also disable it?

Perhaps a hot-key would better be implemented in some other way?

thanks in advance  -eeb

___________________________________________________________
Eric Braun                Glass Bead Software
[e-mail]                803 President St.
[phone]                       Brooklyn, NY 11215
- --
___________________________________________________________
Eric Braun                Glass Bead Software
[e-mail]                803 President St.

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

From: [e-mail] (Timothy David Sharpe)
Date: 2 Aug 92 04:16:14 GMT
Organization: University of Michigan Engineering, Ann Arbor

In article <[e-mail]> [e-mail] (Eric Braun) writes:
>Hi,
>
>I'm implementing a hot key by patching JGNEFilter and looking for the
>appropriate key as the events flow by.  This works fine and dandy.
>The problem is that the hot key is supposed to open up my DA and the
>way it works now is that it'll open up the DA on top of almost
>anything!
>
>This is bad new cus you don't want a DA poping up on top of, say, a
>file selection box, or any other modal dialog for that matter.
>
  Well if you have a hot key, why not let someone use it whenever they want,
just put up a big cancel button in your DA's window.

>THE QUESTIONS: how can I tell if a modal dialog box is open so as to
>temporarily disable the hotkey?  Are there any other situations that
>might cause problems where I should also disable it?
>
  Maybe there's a way to find out if there's a ProcFilter taking all the events?

 If the machine is running TCP programs, your DA might cause a timeout error
<<I don't know how to check for that either though>>

>Perhaps a hot-key would better be implemented in some other way?
>
>Maybe figure out how to put a menu key into the Sys 7.0 Apple menu.

>thanks in advance  -eeb

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

From: [e-mail] (Jeremy Roussak)
Date: 2 Aug 92 09:19:58 GMT
Organization: Computer Science Dept, QMW, University of London

In <[e-mail]> [e-mail] (Timothy David Sharpe) writes:
>I'm implementing a hot key by patching JGNEFilter and looking for the
>appropriate key as the events flow by.  This works fine and dandy.
>The problem is that the hot key is supposed to open up my DA and the
>way it works now is that it'll open up the DA on top of almost
>anything!
>
>This is bad new cus you don't want a DA poping up on top of, say, a
>file selection box, or any other modal dialog for that matter.
>

>THE QUESTIONS: how can I tell if a modal dialog box is open so as to
>temporarily disable the hotkey?  Are there any other situations that
>might cause problems where I should also disable it?
>

I had a similar problem with Apollo, an INIT I've written. This
is my solution:

Boolean FrontIsDialog(void)
{
    WindowPtr w = FrontWindow();
    return (w!=nil && GetWVariant(w)==dBoxProc);
}

if (MyHotKeyPressed() && !FrontIsDialog())
    DoSpecialStuff();

Seems to work: just realised that it won't pick up moveable
modals, though.

Jeremy

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

From: [e-mail] ( Brian Scott)
Subject: Acessing the TRAP word
Date: 31 Jul 92 04:43:20 GMT


Hi,

When you overload a trap, how can you access the trap word
in the routine that handles the trap.  I am overloading the
PBRead routine.  I need to check whether the ASYNC bit of
the trap word has been set in my routine that handles PBRead.
Is this possible?

Any help is appreciated,

Thanks,

Brian

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

From: [e-mail] (Elizabeth Wylie)
Date: 31 Jul 92 06:34:15 GMT
Organization: U.C. Berkeley Open Computing Facility

In article <[e-mail]> [e-mail] ( Brian Scott) writes:
>
>Hi,
>
>When you overload a trap, how can you access the trap word
>in the routine that handles the trap.  I am overloading the
>PBRead routine.  I need to check whether the ASYNC bit of
>the trap word has been set in my routine that handles PBRead.
>Is this possible?

Check the registers using macsbug or tmon on entry to your patch.  I think
D2 has the trap word.  Not sure how documented this is, it might not be at all,
but it has worked for me under 2 system versions and all macs.  (Well not the
pre-plus ones, but that hardly had anything to do with traps).

E. Wylie

- ----
Increasing message length so my machine will actually post it..
.
.
.
... hate this thing.

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

From: [e-mail] (Pete Gontier)
Date: 1 Aug 92 16:44:25 GMT
Organization: cellular

[e-mail] (Elizabeth Wylie) writes:

>In article <[e-mail]> [e-mail] ( Brian Scott) writes:
>>When you overload a trap, how can you access the trap word
>>in the routine that handles the trap.  I am overloading the
>>PBRead routine.  I need to check whether the ASYNC bit of
>>the trap word has been set in my routine that handles PBRead.
>>Is this possible?

>I think D2 has the trap word.

It's D1. Do an 'atb control' in MacsBug, step once, and the trap word
is sitting there in D1.

>Not sure how documented this is, it might not be at all,
>but it has worked for me under 2 system versions and all macs.

And I think it will continue to work; all sorts of sofware makes this
assumption. I think 68000 family Macs will always do this as a result.
Be aware that it's valid only for OS traps, though.

Also be aware that code that makes assumtpions like this, and in fact
any assembly at all, is going to have to be rewritten for the RISC Macs
which apparently might be out as early as next year.
- --
 Pete Gontier // EC Technology // [e-mail]

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

From: [e-mail] (Elizabeth Wylie)
Date: 2 Aug 92 01:17:45 GMT
Organization: U.C. Berkeley Open Computing Facility


Well, ok.  It's in D1, then.

- -E Wylie

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

Subject: Writing an external file system
From: [e-mail] (Russell Street)
Date: Wed, 8 Jul 1992 04:19:02 GMT
Organization: University of Auckland, New Zealand.

Anyone got any idea how to write an external file system
for the Macintosh?  IM only points me to Tech Support,
which apparently does not give much support (though I
have not tried there yet).

Thanks for any information...
- --------------------------------------------------------------
Russell Street ([e-mail])
    It was the least I could do -- a quantity I specialize in.




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

From: [e-mail] (Charle Reiman)
Date: 8 Jul 92 16:09:48 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Russell Street) writes:

>Anyone got any idea how to write an external file system
>for the Macintosh?  IM only points me to Tech Support,
>which apparently does not give much support (though I
>have not tried there yet).

Short answer: You're doomed. Sorry.

Long answer: The external file interafce isn't etched in stone. If you
contact DTS, they'll first warn you away, then (if you persist in being
bothersome) send you a large bundle of unreleased documentation,
prefaced with many warnings and apolgies. This isn't the usual "Don't
use that global!" warning; they are very serious about the probability
of change.

My advice is to not do it. It'll take a lot of effort and reverse
engineering, plus your code will almost certainly break in the future.

Disclaimer: External file systems is a touchy subject with DTS. I am
not in DTS and do not speak for them. However, I am speaking from
personal experience.

- --
Charlie Reiman
[e-mail]

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

From: [e-mail] (Amanda Walker)
Date: Sat, 11 Jul 92 20:32:46 GMT
Organization: InterCon Systems Corporation

[e-mail] (Russell Street) writes:
> Anyone got any idea how to write an external file system
> for the Macintosh?  IM only points me to Tech Support,
> which apparently does not give much support (though I
> have not tried there yet).

The short answer is "it's not worth it."  The long answer is "it is possible,
but extremely aggravating."  This is part of why Apple won't help you;
you basically have to have carnal knowledge of the File Manager and the
Finder(s) in order to do it righ, and even then it will make you crazy.
You will swear at your Mac.  You will find yourself going to see Arnold
Schwarzenegger movies just to watch things blow up spectacularly.

Basically, this is one of those areas of the Toolbox Jungle where, if you can't
find your own way, you probably shouldn't be there :)...


Amanda Walker <[e-mail]>
InterCon Systems Corporation
- --
"Don't try to out-weird me--I get stranger things than you free with
 my breakfast cereal..."    --Hitchhiker's Guide To The Galaxy


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

From: [e-mail] (Reid Ellis)
Organization: Alias Research, Inc., Toronto ON Canada
Date: Tue, 14 Jul 1992 00:29:58 GMT

Russell Street <[e-mail]> writes:
|Anyone got any idea how to write an external file system
|for the Macintosh?  IM only points me to Tech Support,
|which apparently does not give much support (though I
|have not tried there yet).

Amanda Walker <[e-mail]> writes:
|The short answer is "it's not worth it."  The long answer is "it is possible,
|but extremely aggravating."

Have there been any word of this changing in the near future? [System
7.1, maybe?]

Reid
- --
Reid Ellis
[e-mail]        ||           [e-mail]
[e-mail] ||  [phone] [work]

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

From: [e-mail] (Amanda Walker)
Date: 14 Jul 92 16:24:07 GMT
Organization: InterCon Systems Corporation

[e-mail] (Reid Ellis) writes:
> Have there been any word of this changing in the near future? [System
> 7.1, maybe?]

There have been rumblings about a File System Manager, which would support
a well-defined external file system interface, but like many things
originally planned for System 7, it was evidently harder than it seemed, even
for Apple :).

We can but hope for it.

Amanda Walker <[e-mail]>
- --
"Many of the truths we cling to depend greatly upon our point of view."
        --Obi-Wan Kenobi in "Return of the Jedi"

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

From: Quinn <[e-mail]>
Organization: The University of Western Australia
Date: Thu, 16 Jul 1992 01:42:43 GMT

>Amanda Walker <[e-mail]> comments on the joys of writing
>external file systems:
>|The short answer is "it's not worth it."  The long answer is "it is
>|possible, but extremely aggravating."
>
>Reid Ellis <[e-mail]> then asks:
>Have there been any word of this changing in the near future? [System
>7.1, maybe?]

Interesting question.  Personally I'm waiting for the "File System
Manager" to be finalised.  Do this:  Get a copy of Gestalt DA 0.4,
look at the gestaltFSAttr selector and observe the meaning of bit 2
("File System Manager present").  Most of you will have this bit
clear, however those of you with Macintosh PC Exchange installed
will have it set.  Curious.  Methinks PC Exchange comes with an
early version of the File System Manager and that one day, hopefully
in the not too distant future, Apple will reveal the secrets of it
to everyone.

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Waiting, waiting, waiting...

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

From: [e-mail] (David S.A. Stine)
Organization: cisco Systems, Menlo Park, California, USA
Date: Tue, 21 Jul 1992 07:51:14 GMT

In article <[e-mail]> [e-mail] (Amanda Walker) writes:
>[e-mail] (Russell Street) writes:
>> Anyone got any idea how to write an external file system
>> for the Macintosh?  IM only points me to Tech Support,
>> which apparently does not give much support (though I
>> have not tried there yet).
>
>The short answer is "it's not worth it."  The long answer is "it is possible,
>but extremely aggravating."  This is part of why Apple won't help you;
>you basically have to have carnal knowledge of the File Manager and the
>Finder(s) in order to do it righ, and even then it will make you crazy.
>You will swear at your Mac.  You will find yourself going to see Arnold
>Schwarzenegger movies just to watch things blow up spectacularly.

Indeed. I can second this, having had the pleasure of writing one...

>Basically, this is one of those areas of the Toolbox Jungle where, if you can't
>find your own way, you probably shouldn't be there :)...

As a pointer to find your own way, I would recommend that you break out your
copy of MacNosy (if you want to do this level of programming, you MUST have
Nosy) and disassemble the AppleShare client. It has an EFS contained within it
which translates the Finder HFS calls into AFP calls.


dsa


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

From: Quinn <[e-mail]>
Organization: The University of Western Australia
Date: Wed, 22 Jul 1992 01:45:40 GMT

David S.A. Stine talks about the easiest way to figure out external
file systems on the Mac:

>As a pointer to find your own way, I would recommend that you break out
your
>copy of MacNosy (if you want to do this level of programming, you MUST
have
>Nosy) and disassemble the AppleShare client.

Damn the licencing agreement, full speed ahead!  (-:

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Who was going to quote chapter and verse but can't *actually*
     find a copy of Apple's system software licencing agreement |-:

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

From: [e-mail] (Steve Dorner)
Date: 24 Jul 92 01:58:08 GMT
Organization: Qualcomm, Inc., San Diego, CA

Quinn <[e-mail]> writes:
>>Nosy) and disassemble the AppleShare client.
>Damn the licensing agreement, full speed ahead!  (-:

That's right; you're not allowed to "reduce the software to human-
perceivable form".  Apple's lawyers are such kidders.
- --
Steve Dorner, Qualcomm, Inc.
Yes, I'm still working on Eudora and it's still free.

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

From: [e-mail] (Milt Roselinsky)
Date: 27 Jul 92 21:24:31 GMT
Organization: "Tenon Intersystems"

Russell Street <[e-mail]> writes:
|Anyone got any idea how to write an external file system
|for the Macintosh?  IM only points me to Tech Support,
|which apparently does not give much support (though I
|have not tried there yet).

In IM IV, there is an obscure reference to "eXternal File
System Development Package for Foreign File Access".  I was able to
get this through dts, and used it to implement NFS as a XFS under MachTen.
The package was a very nice headstart on what was required, with example
code for a "read only" file system.

milt

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

From: [e-mail] (Scott Bronson)
Date: 28 Jul 92 05:53:41 GMT

In <[e-mail]> [e-mail] (Steve Dorner) writes:

>Quinn <[e-mail]> writes:
>>>Nosy) and disassemble the AppleShare client.
>>Damn the licensing agreement, full speed ahead!  (-:

>That's right; you're not allowed to "reduce the software to human-
>perceivable form".  Apple's lawyers are such kidders.

Truly.  I remember long summers hacking on the Apple II, burying my
nose in the mini-assembler and poking bytes in by hand.  Towards the
end of the summers, I would normally be able to tell you what certain
code did simply by looking at the hex dump.  What do you think every
time you see 4E71?  Well, I knew most 6502 opcodes this comfortably.

If they had had this agreement back then, then they would have been
in violation of their own agreement when they assembled it, right?

Just a thought...

    - Scott

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

From: [e-mail] (Matt Weiser)
Subject: I wanna program a Newton - but how?
Date: 23 Jul 92 20:18:09 GMT
Organization: Martin Marietta WIS

How does one get in on the ground floor of Newton software
development?  Is there an Apple contact?  Anyone have a phone #
or e-mail address?

We have a couple of really great uses for this type of product,
but we don't want to have to wait for the Newton to
release to be able to begin development.


Thanks a ton!

Matt Weiser
[e-mail]

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

From: [e-mail] (Jon Pugh)
Date: 2 Aug 92 17:06:40 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Matt Weiser) wrote:
>
> How does one get in on the ground floor of Newton software
> development?  Is there an Apple contact?  Anyone have a phone #
> or e-mail address?

Email [e-mail]

Good luck.

Jon

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

From: [e-mail] (Russell Street)
Subject: Trap word parameter to Set/GetTrapAddress?
Date: 31 Jul 92 06:11:24 GMT
Organization: University of Auckland, New Zealand.

I am slightly confused about the Trap Word parameter
to Get/SetTrapAddress:
    What should it be? :-)
For instance do I use "0xA9FD" for _ExitToShell or "0xFD"
or NGetTrapAddress or what?

I have always used the straight trap word (0xA9FD) and that
appears to work, but other people strip of high parts or
other strange things (or reasonable depends on which way you
look at it).

I would really like to get this clear (even in my own mind).
Information relevant to modern systems only, PLEASE!

- -------------------------------------------------------
And with that remark, folks, the case of the Crown vs
Russell Street ([e-mail]) was proven.

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

From: [e-mail] (Pete Gontier)
Date: 1 Aug 92 16:57:49 GMT
Organization: cellular

[e-mail] (Russell Street) writes:

>I am slightly confused about the Trap Word parameter
>to Get/SetTrapAddress... For instance do I use "0xA9FD"
>for _ExitToShell or "0xFD" or NGetTrapAddress or what?

There is some masking necessary. xSetTrapAddress has always
wanted a trap *number*, not a trap word. It just so happens
that it does some masking of its own, just in case people
pass in a trap word, but this masking is not very ... shall
we say... sophisticated. After all, the caller is supposed
to pass the right info. :-) Here's the code I use:

#define kTrapNumberMask            0x07FF
#define kUnimplementedTrapWord    0xA89F

static void * AS_GetTrapAddress (short trapWord) {
    return ((void *) NGetTrapAddress (trapWord & kTrapNumberMask, (trapWord & 0x0800) ? ToolTrap : OSTrap));
}

static void AS_SetTrapAddress (void *proc, short trapWord) {
    NSetTrapAddress ((long) StripAddress(proc), trapWord & kTrapNumberMask, (trapWord & 0x0800) ? ToolTrap : OSTrap);
}

Well, this isn't actually the code I use. Whenever I see a new "standard"
interface in the headers, I try to move toward it. In this case, there
is now glue for SetToolTrapAddress, or something like that, and the
code I'm using now takes advantage of that. I just don't happen to have
a copy of it lying around.

>I have always used the straight trap word (0xA9FD) and that
>appears to work, but other people strip of high parts or
>other strange things (or reasonable depends on which way you
>look at it).

It is quite strange, and frankly I've never bothered to look into
how or why it works. I came up with these magic numbers with the
help of DTS and MacApp.

>I would really like to get this clear (even in my own mind).
>Information relevant to modern systems only, PLEASE!

Well, that's a good and bad thing to request. You have to be aware
of which machines your code won't work for. My understanding of the
code in Inside Mac VI that does things in a similar way is that the
IM code is able to accomodate really old trap tables on machines that
no one wants to support any longer. On the other hand, you have to
be aware of which ones they are. There's a tech note, I believe.
- --
 Pete Gontier // EC Technology // [e-mail]

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

From: [e-mail] (Keith Rollin)
Date: 3 Aug 92 02:27:58 GMT
Organization: Taligent

In article <0yrmt6=[e-mail]>, [e-mail] (Pete Gontier) writes:
>
> [e-mail] (Russell Street) writes:
>
> >I am slightly confused about the Trap Word parameter
> >to Get/SetTrapAddress... For instance do I use "0xA9FD"
> >for _ExitToShell or "0xFD" or NGetTrapAddress or what?
>
> There is some masking necessary. xSetTrapAddress has always
> wanted a trap *number*, not a trap word. It just so happens
> that it does some masking of its own, just in case people
> pass in a trap word, but this masking is not very ... shall
> we say... sophisticated. After all, the caller is supposed
> to pass the right info. :-) Here's the code I use:
>
> #define kTrapNumberMask            0x07FF
> #define kUnimplementedTrapWord    0xA89F
>
> static void * AS_GetTrapAddress (short trapWord) {
>     return ((void *) NGetTrapAddress (trapWord & kTrapNumberMask, (trapWord &
0x0800) ? ToolTrap : OSTrap));
> }
>
> static void AS_SetTrapAddress (void *proc, short trapWord) {
>     NSetTrapAddress ((long) StripAddress(proc), trapWord & kTrapNumberMask,
(trapWord & 0x0800) ? ToolTrap : OSTrap);
> }
>
> Well, this isn't actually the code I use. Whenever I see a new "standard"
> interface in the headers, I try to move toward it.


I looked into this a couple of weeks ago. If I remember correctly, here's how
things are laid out:

In the beginning, there was G/SetTrapAddress. This guy took a trap number. Since
trap numbers were shared between OS and Toolbox traps, that's all you needed to
specify.

Then the 128K ROMs came out, and there weren't enough trap numbers. Or, at
least, the Apple Engineers realized at that time that they would soon run out of
trap numbers. So they allowed the duplication of trap numbers between OS and
Tool traps, and added NG/SetTrapAddress. This function, which was implemented
with glue, required the programmer to specify whether the trap number was for an
OS function or Toolbox function. When the old G/SetTrapAddress routine is called
with an ambiguous trap number, it makes a guess as to whether it's for an OS
trap or a Toolbox trap.

Internally, the glue for NG/SetTrapAddress looked at the trapType parameter and
simply called G/SetTrapAddress with some bits set. For example, a call to the
old-style SetTrapAddress invokes trap word 0xA047. A call to the newer-style
NSetTrapAddress with trapType == OSTrap invokes trap word 0xA247, and a call to
NSetTrapAddress with trapType == ToolTrap invokes trap word 0xA647.

With the latest MPW and THINK headers, you no longer need the glue.
G/SetToolTrapAddress and G/SetOSTrapAddress invoke these trap words directly.
This is the same philosphy used with the new PBxxxSync and PBxxxAsync calls that
allow you to eschew the Boolean parameter you used to have to pass to those
routines.

I believe that there is an undocumented variation of the 0xAx47 trap (perhaps it
is documented and I just missed it). 0xA447 does just what Pete's routines above
do. It looks at the full trapword, and then alters the OS trap table or the
Toolbox trap table accordingly. Take this with a grain of salt, since I haven't
actually tried this myself.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

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

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