Oct 91 Mousehole
Volume Number: 7
Issue Number: 10
Column Tag: Mousehole Report
A/UX and Monitors 
By Larry Nedry, Mousehole BBS
From: Grinch
Re: Help Manager Resources
Hello, I have a question...
I’ve read IM6’s chapters on using the Help Manager to add Balloon Help to my
application icon and menus. It gives examples of the resources to compile but, silly me,
I haven’t figured out how to make SARez do this.
SARez retches when I give it these examples. Is there a header of some sort I have to
add to define the new resource formats? Is it in IM6? I also note that there doesn’t seem
to be any coverage of the correct resource type for movable modal dialogs either.
I’d appreciate a few words of direction on how to get this done.
From: Atom
Re: Help Manager Resources
Yes, there is a header file for balloon resources. In MPW 3.2 it’s called
“BalloonTypes.r” (naturally enough!) If you’re using Think C or Pascal as I’m
surmising, you might want to ask Symantec tech support about getting the latest
headers. There are many new header files for System 7, and (at least in MPW) a few
minor changes in some of the old ones. Also, movable modal dialogs don’t have a special
resource type; they’re just an ordinary window with a new window definition ID (like
plainDBox, documentProc, etc.) I don’t recall the value or exact name of this constant
right off, but it’s in IM V6, I think in the Compatibility Guidelines chapter. In any case
it’s in the latest headers. Hope this helps.
From: Craigb
Re: Detecting A/UX?
I am writing a program, that when A/UX is present, will (hopefully) communicate
will a deamon running in A/UX. So, my two questions are : 1) How do you detect A/UX is
running? I know that can be done, but how? 2) How does one communicate to and from
A/UX to Mac OS? I am writing my program in Think C.... for what it’s worth...
From: Mrteague
Re: Detecting A/UX?
You can detect that you are running under A/UX by using Gestalt with the selector
‘a/ux’ - if it isn’t running, you will get a gestaltUnknownErr (otherwise you will get
the A/UX version # in the lower word of the response parameter). If you really must
muck about in low memory globals and don’t have Gestalt, then you need to look at the
Hardware Configuration Flags at $0B22 - I don’t know which bit is set offhand, but one
of the bits set means A/UX is running. By the way, with MPW 3.2 and later, Gestalt
glue is provided that allows you to use Gestalt on any machine with any version of the
System (otherwise Gestalt is only available in System 6.0.4 or later, or in ROM on the
Mac IIci and later).
Anyway, given that, how do you mean “communicate” with a dameon? If you are
running a Macintosh application under A/UX, then you are running in a virtual
machine, which is basically MultiFinder (System 6.0.5 for A/UX 2.0, and System 6.0.7
for A/UX 2.01), and it is just another UN*X process, in it’s own protected memory
space, so you can’t do any dirty tricks by poking around in memory, because you will
get a privilege violation. If you write a standard UN*X program (COFF format), you
will be able to use all the standard UN*X libraries etc - but then it won’t be a Mac
application. It is possible to sort of “merge” the 2 worlds, but I don’t know enough
about that to tell you.
I suggest if you are serious about writing applications for A/UX, that you get all the
necessary tools and documentation - you won’t be able to do it without it. I assume if
you have A/UX, you have all the documentation that comes with A/UX for programming
under A/UX. From the Mac side, you should get Inside Mac Volume VI (the latest for
System 7.0), and of course all the earlier ones. Specific to THINK C - you will want to
make sure you have the latest version of THINK C (4.05?), as earlier versions are not
32 bit clean (the latest isn’t entirely either, but it will do), and you certainly might
have problems creating code that will run under A/UX, and you certainly couldn’t
actually run THINK C itself under A/UX, unless you are willing to live with the
limitations of the 24-bit memory model under A/UX.
I have written a number of Macintosh applications that run fine under A/UX, and adapt
to A/UX specific features (such as filenames use "/" as the delimiter, not ":" as on the
Mac OS etc). If you can tell us more about what you are trying to achieve, we may be
able to help you further, or tell you that it will be a waste of time.
Hope this helps.
From: Mikel
Re: Detecting A/UX?
Here’s a code snippet from one of Apple’s sample programs:
{1}
dummy:=SysEnvirons(1,theWorld);
WNEIsImplemented:=((theWorld.machineType>=0) AND
(NGetTrapAddress(_WaitNextEvent,ToolTrap)<>
NGetTrapAddress(_Unimplemented,ToolTrap)));
flagPtr := PtrToWord(kHWCfgFlags);
haveAUX := BAnd(flagPtr^,$0200) <> 0;
Hope this helps.
From: Rodman
Re: Blocking switch under MultiFinder
Another way would be to set the high bit in the spareflag of the window record when
you wish the window to become modal. You’ll find this a little easier.
From: Salmon
Re: Blocking switch under MultiFinder
You can stop MultiFinder from switching by changing the windowKind field of the
window record to 2 before calling WaitNextEvent. This will prevent switching. I have on
occasion managed to kill the Finder but I’m still not sure how. (You can’t get it back,
but you can keep working).
From: Aikidoka
Re: Blocking switch under MultiFinder
Thanks to everyone for their help on my MultiFinder switch problem. We were
working on some interactive multi-media displays using MacroMind’s Director. While
running under MultiFinder, a person could click in the upper right corner, and the
thing would switch to the Finder, or whatever other program we might have had
running in the background. Not what we wanted. Changing the windowKind field caused
Director to bomb. What we wound up doing is running Director under System 7.0. It
doesn’t switch under System 7.0.
From: Cxer
Re: MaxAppleZoom Patch
The following patches can be made with ResEdit to bypass the time bomb:
For MAZ 1.3:
in INIT 1, change 65AE at offset 578 to 4E71
in INIT 1, change 65AE at offset 5D4 t 4E71
in cdev -4064, change 6AE at offset C4E to 4E71
in cdev -4064, change 65B0at offset CD6 to 4E71
For MAZ 1.31:
in INIT 1, change 65AE at offset 576 to 4E71
in INIT 1, change 6AE at offset 5D2 to 4E71
in cdev -4064, chage 65AE at offset C4C to 4E71
in cdev -4064, change 6B0 at offset CD4 to 4E71
These patches were developed by Bob Boonstra (jrb@mbunix.mitre.org) who
comments that he has numerous comments that they work and none to the contrary.
Matthew Russotto (russotto@eng.umd.edu) has since discovered why the patch works:
the code being bypassed is an obfuscated way of accessing the low-memory global Time
($20C). The code also contains deliberate attempts to prevent use of a debugger during
the time bomb check.
From: Walrus
Re: Think Reference 1.0
I just wanted to plug a product I just got today, Symantec’s Think Reference.
Many of you probably got the mailer sent out by Symantec. It is not just an Inside Mac
DA, it’s an application (run in 256K) that has a pretty good hypertext Mac Toolbox
reference. Obviously, if you are a Mac wizard, you probably don’t need it, for all you
others....
From: Walrus
Re: Think Reference 1.0
Think Reference does some explaining about the trap calls, their inputs and outputs as
well as providing a ‘Copy Template’ (you can specify a C or Pascal template). Since this
is not an Addison-Wesley product, they were not really able to put IM directly into the
database, they basically paraphrase it -- which is great, that’s why I bought Macintosh
Revealed. And for that reason I haven’t yet gotten rid of IM DA.
If I remember correctly, the Programmer’s Online Companion was basically just the
call and did no explanation of what it was for. The Think Reference does that and it has a
lot of information about Mac structures and the other details that I always have to dig
into Inside Mac for.
One point should be noted. It does not include IM VI (except for Gestalt information).
That’s okay, I need to build my biceps.
From: Salmon
Re: Error in Vital Signs MT 7/91
On page 28 of the July issue of MacTutor, the author of the Vital Signs DA states that
the definition of StringPtr in the Think C headers is wrong. This is WRONG. The
definition of StringPtr in the headers is correct. His definition is most definitly
WRONG. He states
typedef Str255 *StringPtr
However, Str255 in ThinkC is defined as
/* 2 */
typedef unsigned char Str255[256]
This declares Str255 to be a pointer to an array of char.
Therefore the suggested typedef would declare StringPtr to be a pointer to a pointer to
an array of char, which is wrong.
A more serious issue. The code given on p. 36 has a bug. The declaration of diskname as
StringPtr diskname; should be Str255 diskname.
Then when diskname is passed to PBHGVInfo, there will be storage declared. As it is
now, an uninitialized pointer is passed to PBHGetVInfo. If the pointer happens to be
NULL, nothing happens. If the pointer happens to contain an address where data or code
resides...
Boom.
From: Jimm
Re: Multiple monitors/move window
I have a multiple monitor setup with a 2 page monochrome (1 bit) and a 13" 8 bit
monitor. When a window is created with GetNewWindow from a resource on the 1 bit
monitor and then moved to the 8 bit monitor, CopyBits’ed images (from 8 bit offscreen
grafports) are displayed in full color. Direct drawing calls, however, are all in Olive
green and white. Examination of the pixmap record of the cGrafPort associated with the
window shows the pixelsize to be 1. What’s the deal? If it is a one bit deep map, why do
the pixmaps transfer in full color? Do I have to destroy the CGrafPort associated with
my window and recreate it when the window changes screens? When the window is
created on the 8 bit screen (when I move the menu bar there with the monitors CDEV)
everything works flawlessly. Any ideas?
From: Jimm
Re: Multiple monitors/move window
Adding to the previous question, when I create the window on the 8 bit screen using
NewCWindow, the pixmap^^pixsize is still 1. It doesn’t matter where I create the
screen or where I move it to, the pixmap always claims to be 1 bit deep. When a window
is created on an 8 bit screen, why does the window manager create a one bit deep
pixmap?
From: Rodman
Re: Multiple monitors/move window
Do you have a window color table associated with the window? If not, I would suggest
starting there.
From: Jimm
Re: Multiple monitors/move window
Well it appears that when you open a window, it always sticks you with the pixmap of
the main screen. When you draw out of the pixmap, it looks around and says ‘hey maybe
there’s another screen out there and I should draw on it instead.’ Consequently, you
cannot get the screen depth from the pixmap associated with your CGrafPort. I was
banging my head against the wall forever because I was trying to activate the palette of
my window while the control panel (used to change screen depth) was still the front
window. Once I waited until my window was frontmost, my problems disappeared.
From: Rguerra
Re: Monitor Depths
Thanks for the reply. I’m actually interested in what depth modes a particular
monitor is CAPABLE of displaying. This info should be available from the Slot Manager.
The CURRENT depth is, as you point out, readily available. Has anyone figured out
exactly how to get that info from the Slot manager in order to deal with systems that
don’t have HasDepth implemented?
From: Arlen
Re: Monitor Depths
Why is the Slot Manager necessary? I’ve always used the GetGDevice call from Color
Quickdraw. This returns a handle to a graphic device (GDHandle). The Graphic Device
data structure (IM V-129) contains a PixMapHandle called gdPMap. This handle refers
to a pixel map data structure (IM V-52) which contains an integer pixelSize, which
holds the current depth of the monitor. Am I missing something?
From: Mikel
Re: MPW C Profilers
Has anyone heard of any profilers for MPW C? I know THINK C has a header, but I am
an MPW kind of guy. I thought I read about such a beast once, but I’m blanking now.
Something similar to Jon Bentley’s “More Programming Pearls” profiler would be
pretty nice.
As an aside, anyone know what Apple’s Advanced Development folks are using the gcc
compiler for? Portable operating systems? Hmmm.
From: Mrteague
Re: MPW C Profilers
I guess the closest thing to what you want, is the Performance Tools for MPW -
consists of a library, interface files for Pascal and C, sample files, a MPW Tool called
PerformReport, and the ROM Map files required for performance reporting. I have used
it a little bit with Pascal, but not with C, so I can’t help you there. Basically, you need
to add some code to your application to turn on profiling etc - you specify such things
as the sampling size etc. Then you build your application with the library linked in, and
create a LinkMap. Then run your application and exercise it appropriately, and quit.
Then you concatenate the LinkMap and the appropriate ROMMap and run the
PerformReport tool. It has been helpful to me in some situations. Hope this helps.
From: Mikel
Re: MPW C Profilers
Thanks for your reply. I did find the PerfTools and built the sample programs that
were included. I never did get the PerfDisplay working correctly though, as the main
segment procedures were mapped to segment 127, and the linker never generated a
segment #127. Anyway, it’s pretty much what I was looking for.
From: Macneil
Re: New User
I too am curious as to the “rules”, usually they are shouted out at one. Here we are
left to depend on our own consciences?
From: Sysop
Re: New User
I like to keep it simple. No upload/download ratios. If you have something you want to
share please upload it. If you see something you want then download it (except for the
MacTutor sources. $5.00 each). This is a BBS where Mac programmers can exchange
ideas.
Have fun,
sysop
Referenced by (2):