Aug 88 Mousehole
Volume Number: 4
Issue Number: 8
Column Tag: Mousehole Report
Mousehole Report 
By Rusty Hodgee, Mousehole BBS
From: gbryan (Geoff Bryan)
Subject: LSP Interfaces
Has anyone seen a more complete set of interfaces for the ROM & System routines
beyond what Think put out last fall? If not, it looks like a long session of porting over
the MPW 2.0 interface files. (What started me on this quest was the discovery that the
Shutdown Manager routines do not seem to be in last fall’s 1.11 update package. Don’t
know what else is missing or different.) [We have blasted Think repeatedly for taking
so long to keep LS Pascal up to date with the latest set of goodies from Apple. There is a
new version coming, they tell me, but, like the LS C update, who knows when? If
nothing is forth coming at the Boston Expo, you can bet we will blast them again! They
do have a Shutdown Manager glue patch you can get if you call for it. You might want to
look at TML’s new MPW Pascal II., available at the MacTutor booth at the Boston Expo.
-Ed]
From: pepnerd (Peter Kramer)
Subject: menus
I’m just a beginner at programming the mac. I’m trying to set up menus using the code
in “Using the Macintosh Toolbox with C” by Takatsuka et. al. I’m not sure how to call
InitGraf() in the situation where I have not set up any windows, only menus. In my
development system the example (Aztec C) the call to InitGraf() uses the argument
&thePort. However I cannot find where thePort is defined. Its quite distressing to
double click on an application icon and get nothing but a bomb!
From: ericlim (Eric Lim, Flushing, NY)
Subject: Re: menus
I’m not familiar with Aztec because I’m using MPW C 2.0.2 and I think the variable
thePort is defined in the “Quickdraw.h” header or include file.
From: think
Subject: Re: menus
It’s not important to know where thePort is defined; all that’s important is that you
pass the correct series of initializations in order to get your application started:
{
InitGraf(&thePort);
InitFonts();
InitWindows();
InitMenus();
TEInit()
InitDialogs(NIL); }
Typically, thePort is defined as an extern GrafPtr in Quickdraw.h (in LightspeedC) or
in the appropriate header for other C compilers. --Rich Siegel, THINK Technologies
[The variable thePort is one of those mysterious Quickdraw global variables that
no one ever talks about once you are convinced the proper call works correctly. The
first few issues of MacTutor, over three years ago, addressed this subject in depth,
explaining how the Quickdraw Globals are stored relative to A5 and how they work. The
Mac system is responsible for the Quickdraw Globals maintenance. Refer to Volume 1
of The Best of MacTutor for more information. -Ed]
From: laskey (Jim Laskey, Halifax, NS)
Subject: Second Stack
Is there a safe way for an application to allocate a second system stack? TGS systems
is currently developing a visual programming language known as Prograph. One of the
main features of Prograph is the ability to perform editing and debugging of source
code while in an execution state. All routine calling sequences are performed through a
system stack as per normal. However, the state of the execution system stack must be
kept separate from the system stack used during editing and debugging. The solution
was to allocate a second system stack just for execution and use the defacto system
stack for debugging and editing. Where does one allocate the second stack? For the sake
of the stack sniffer this second stack was allocated between ApplLimit and A5. Early
versions of Prograph used the following sequence to allocate the second stack;
newStack = ApplLimit;
ApplLimit = newStack - DefltStack;
MaxApplZone();
Until testing on the Mac II, this worked quite well. On the Mac II, strange things began
happening whenever Prograph switched to the second system stack. Text would not
show up in menus and window frames were drawn incorrectly. The only notable
difference between the Mac II and the other systems was that DefltStack was 16k
greater on the Mac II, presumably to handle color Toolbox calls. The stack allocation
algorithm was changed to the following;
newStack = ApplLimit + DefltStack / 2;
MaxApplZone();
This works fine. However, what happens when a Toolbox call needs a large chunk of
the stack? Is there a safe way for an application to allocate a second system stack?
[I don’t think so. This sounds like one of those nifty ideas that will probably
never work since it will never quite match up with Apple’s changing system file, and
MultiFinder evolution. I suggest you scrap this approach and try something less
controversial. Can Apple DTS suggest a safe approach? -Ed]
From: mark (Mark Murphy, Anaheim, CA)
Subject: New Stacks
I need to be able to create a new stack from within a script! The only thing I have found
is ‘doMenu “New Stack...”’. Yet, I do not wish the modal dialog to come up to the user.
I need to create a stack and be able to name it myself, from the script without user
input. Anyone have any ideas?
From: rdclark (Richard Clark, Tustin, CA)
Subject: Re: New Stacks
Well, since you’re probably not planning to use HyperDA with your stack (as it
wouldn’t allow you to write to the new stack anyway), you can get away with using an
XCMD. What this command should do is to duplicate an existing “template” stack and
then rename it. If the template doesn’t exist, then you should put up a dialog box to
Referenced by (2):