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