ADC Home > Reference Library > Technical Notes > Legacy Documents > Tools >
Legacy Document
Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.
Current information on this Reference Library topic can be found here:
|
Compiling with MPW C under A/UXDate Written: 11/3/92 Last reviewed: 3/1/93 SillyBalls compiles without errors in an exclusively MPW environment, but we can't compile it in an A/UX environment (CommandShell) on our UNIX partition. Here's our command line to invoke the MPW C compiler, along with the message we get before MPW C fails:
How can we get this to compile from A/UX? ___You're trying to execute the C compiler directly from the UNIX shell. That's a no-no, because it's not a standalone program, but an MPW Shell tool. Since those tools have to run inside the environment created by MPW Shell, when you attempt to run it directly, the environment it needs isn't there and it blows up. You need to run MPW the normal way, and then it'll work. A/UX 2.x and GetFrontProcessDate Written: 9/3/92 Last reviewed: 11/1/92
Under A/UX 2.x when I call The response from Gestalt is unfortunately in error; the Process Manager is not available under A/UX 2.x, because it's primarily based on system software version 6.0.x.
We recommend that you introduce an explicit check for A/UX 2.0, using the
standard Setting file types and creators with A/UX's setfile utilityDate Written: 6/12/90 Last reviewed: 8/1/92 Using A/UX language tools such as cc, ld, and make, how do I set a file's type and/or creator? (I can use ResEdit, but I want to include the command to set type/creator in the A/UX makefile, as I do using Link under the Macintosh Operating System). ___You can use the setfile utility under A/UX to set Macintosh types and creators. The syntax is the same as the MPW Tool of the same name, as follows::
Accessing Macintosh Operating System from A/UX programDate Written: 7/30/90 Last reviewed: 8/1/92 Is there a way that you may access a Macintosh Operating System file system from an A/UX program without going through the toolbox? ___Currently there is no way to access the Macintosh file system from an A/UX program without going through the toolbox. It may not be exactly what you want, but it is possible to write a faceless Toolbox application that works like most UNIX tools. Its only requirement is that, although the application can run from any terminal, someone must be logged in from the console for this faceless application to work correctly because the Toolbox must be active for it to work. Macintosh drivers under A/UX sometimes not locked in heapDate Written: 10/23/90 Last reviewed: 8/1/92
Under A/UX MultiFinder, RAM-based device drivers (loaded from a resource) are
sometimes installed by the system as ROM-based drivers. The undesirable side
effect of this is that the driver does not get locked in the heap when opened,
even if the
Here's why it happens: As part of installing a Macintosh Operating System
device driver, the ROM code compares the pointer to the driver to the value in
the low-mem var Under A/UX MultiFinder, it is possible to have heaps located above 0x800000. In fact, on my Macintosh IIx with 20 MB of RAM, virtually all my application heaps are above that address. When an application (actually, a printer driver called by an application) opens our spooling device driver, the driver does not get locked in the heap.
To work around the problem, we set the locked bit for the An alternative solution would be to have the driver lock itself. This is difficult because it would have to be done in the driver header code which is automatically prepended to the driver by the C compiler we use. (This header code loads a data resource, so the lock would have to precede that action). We could do our own header, but obviously that costs time and $$$. Please let me know if you can think of any problem with the first solution. I'm assuming that you will also follow up on having this 32-bit unfriendliness corrected in future system software. ___Your analysis of the situation with Macintosh drivers under A/UX is excellent. I checked the ROM listings and it is doing exactly what you said. The good news on the Macintosh Operating System side is that the same code on the Macintosh IIci and IIfx has already been fixed in the ROM. Because these are the only machines in 32-bit mode under 7.0, it shouldn't be a problem. On the A/UX side, I have filed a bug report. I'm not sure when it will be fixed, but your workaround should be OK. Checking network address for software protectionDate Written: 10/30/90 Last reviewed: 8/1/92 We need to have security for our software so that it will run on only one machine. With Macintosh systems we are forced to use an Ethernet address because that is the only unique hardware number we are able to access. We need to know if there is some type of operating system software running on A/UX 2.0 that we can use or if there is a hardware code unique to a machine that we as developers can get to. ___You could use the Ethernet address under A/UX, as long as you test that the system has an Ethernet card installed. There's no rock-solid serial number available on the Macintosh hardware platform. One of the considerations is that if the motherboard or the ROMs are repaired and switched, the serial number might change and cause problems with applications. The pros and cons considering software protection are many, and I don't want to take any stands. Instead I will give you some other clues how to protect software, and I will also include at the bottom of this letter the official Apple DTS statement concerning software protection. Anyway, one way (as you maybe know) is to use various dungles. We've had bad experience with ADB-based dungles and A/UX, so we suggest you use serial line-based (if you want to use the dungle method). Another method of registering software is to register a unique name on the network (AppleTalk or TCP/IP), and have the software check if there's already someone else using this label. It assumes that the machine is connected to a network. Concerning AppleTalk solutions you might use a simple PRegister (Using the NBP Protocol), or in the case of a TCP/IP solution maybe a background task that checks a port and reacts if someone with similar identity calls. There are also many other half-good solutions for registering a label and checking for this on the system. Unfortunately crackers are able to break these copy-protection schemes; the nice thing is that the number of crackers among Macintosh users is very small. So unfortunately I can't give you a definite answer of how to protect your application from illegal copying. I hope this resolution explains the current situation. If you want to comment or if you have any other questions, please let us know. --DTS Official position concerning software copy protection-- DTS's official position is that software copy protection is a bad idea, so we don't support development of protection schemes. Here is a summary of arguments against copy protection:
We feel that copy protection is not a worthwhile use of development time. We cannot help you develop a protection scheme, or provide support when protected software breaks with future hardware or software. A/UX 2.0 video ioctls not available with FinderDate Written: 11/30/90 Last reviewed: 8/1/92
In A/UX 1.1.1 there were video ioctls to get screen information ( The video ioctls documented in System Admin Reference won't work with the Finder because Finder remaps video memory to other locations. In this case the documentation does not mention it, so we will try to make this point clear in the next documentation release (use only during console mode). The suggested way is to play according to Macintosh rules when Finder is running, so many of the public domain screen dump utilities should work, even with menus. Beware of utilities that use FKEYs; they won't work with A/UX 2.0. If you want to write your own, check out the DTS Sample code FKEY, and trap the MenuHook for handling menus. Code for determining if a Mac application is running under A/UXDate Written: 12/4/90 Last reviewed: 8/1/92 How does our application know whether it is running under A/UX? ___Below you will find a piece of sample code that will enable you to know whether or not your application is running under A/UX: A/UX Sample Code:
A/UX technical information sourcesDate Written: 12/3/90 Last reviewed: 8/1/92 Is there a special AppleLink group address to send A/UX-related questions to rather than the general MACDTS address? ___There's a folder under Developer Services for A/UX-related (developers ask each other) questions. You'll find a lot of good information also from USENET, comp.unix.aux. Use a device driver to speak with ADB device from A/UXDate Written: 12/11/90 Last reviewed: 8/1/92 Does A/UX do a Global Reset on the Apple Desktop Bus (ADB) when it initializes? That is, if an ADB device's handler were changed by an INIT during the Macintosh Operating System stage of A/UX startup, would that change persist in A/UX? ___A/UX unfortunately does a reset on the ADB side when it boots. This means that any ADP opcodes that are sent to the devices are not recognized after the boot to the A/UX side. The only way for the moment to speak with the ADB device is by writing a device driver from the A/UX side. GetGamma and SetGamma support after A/UX 2.0.1ß2Date Written: 12/14/90 Last reviewed: 8/1/92 Are GetGamma (csCode 4) and SetGamma supported in A/UX 2.0.1? ___GetGamma (csCode 4) is not supported. SetGamma will be supported, starting with A/UX 2.0.1. A/UX symbolic debuggerDate Written: 1/10/91 Last reviewed: 8/1/92 Is there a symbolic debugger for "hybrid" applications under A/UX? MacsBug is not a solution for looking at data structures 1K in size. ___Unfortunately I'm not familiar with any A/UX debuggers. I have heard of one, but I can't say that I've ever used it. It's called UDB-OASYS Universal Remote Debugger. It's a multi-targeted, window-oriented, source-level debugger for single and multiple embedded microprocessor systems. If you'd like to contact OASYS and talk about it, they can be reached at (617) 890-7889. As for further information, you might have better luck calling the A/UX Hotline. Their number is (408) 974-5091. Use ps -efa to see Macintosh Operating System processesDate Written: 1/31/91 Last reviewed: 8/1/92 Can I use the ps -efa command to tell if a Macintosh program is running? ___You should be able to see the Macintosh Operating System processes with the ps -efa command (as you tried). It will be listed as Mac24 or Mac32, depending on whether you're running in 24- or 32-bit mode. You can even launch (start) these processes from the command shell. Use kill -9 to kill Mac OS but not an individual applicationDate Written: 1/31/91 Last reviewed: 8/1/92 Can I use the "kill" command to kill a Macintosh program running under A/UX? Is it even possible to kill a Macintosh Operating System-based program from the Command shell window? ___The kill -9 command should be able to kill the Macintosh Operating System. It obviously won't be able to kill an individual Macintosh program, however, since all Macintosh programs run under the framework of the one Macintosh Operating System process. A/UX 2.0.1 fixes console log-in terminal control bugsDate Written: 3/8/91 Last reviewed: 8/1/92 We are running A/UX 2.0 on both a Macintosh IIcx and a Macintosh IIci. When a console log-in session uses "set -o emacs" (emacs editing keys as opposed to vi) in the korn shell (ksh), the session hangs, whether the set command is in .kshrc or typed in. A remote connection as root can log in and kill the console process and return the system to the log-in program. Is this a A/UX ksh bug? ___Bugs found in the A/UX 2.0 console log-in terminal control code have been fixed in A/UX 2.0.1. The set command "set -o emacs" in vi works OK in A/UX 2.0.1. A/UX 2.0.1 and third-party partitioned hard disk drivesDate Written: 3/11/91 Last reviewed: 8/1/92 I've partitioned into two equal-sized Macintosh volumes on my third-party hard drive, and A/UX 2.0.1 refuses to recognize the second partition at all. Can you tell me how to get this second volume to mount on the desktop? ___The A/UX file system emulation doesn't recognize multiple Macintosh partitions on the same hard drive. The A/UX engineering team is working on this known restriction. A/UX & A/ROSE Macintosh Coprocessor Platform (MCP) protocolDate Written: 3/31/91 Last reviewed: 8/1/92 Are there any catches in developing MCP-based (Macintosh Coprocessor Platform) cards to be used under A/UX? Or can they be developed under the Macintosh Operating System as usual and then used under A/UX? ___A/UX doesn't currently understand the A/ROSE MCP protocols, so cards that are using A/ROSE will not work under A/UX. The only way to get the cards working is to write a specific A/UX device driver that talks with the card from A/UX. Use AppleTalk to print from Macintosh A/UX to a LaserWriterDate Written: 5/7/91 Last reviewed: 8/1/92 To print from a Macintosh running A/UX to a LaserWriter, would I use AppleTalk or TCP/IP? ___To print from an A/UX machine to a LaserWriter, you need to use AppleTalk. If you use your LocalTalk port as your AppleTalk connection, you will require no further hardware (other than your LocalTalk network). If you use your Ethernet as your AppleTalk connection, you will need some kind of router to translate these packets from Ethernet to LocalTalk, as LaserWriters are available only with LocalTalk connections. A/UX and the Macintosh Deferred Task Manager (DTM)Date Written: 7/11/91 Last reviewed: 8/1/92 The Deferred Task Manager (DTM) under A/UX is not supported at this time. A call to the DTInstall routine generates an unimplemented trap message. The reason for this is that DTM should only be used for low-level driver functions, and for A/UX this is handled by device drivers talking with the NuBus cards. To implement something with a similar functionality as the DTM provides, you'll need to write a separate UNIX device driver, because Macintosh OS NuBus device drivers as they are don't work with A/UX. For driver details, check the "A/UX Device Driver Kit," available from APDA.
|
Guest 1 % df -t / /dev/dsk/c5d0s0 8640 blocks 18880 i-nodes total 102204 blocks 23040 i-nodes Guest 2 % su Password: Guest 1 # df -t / /dev/dsk/c5d0s0 13752 blocks 18880 i-nodes |
Although the total number of blocks are the same, the number of free blocks differ: 8640 for Guest, but 13752 for root. About 5% of the total number of blocks are reserved and unavailable to user processes. If an ordinary process were to write out more than 8640 blocks, it would get a file system full error, so df is accurately reporting the situation.
In the event that an ordinary process fills up the file system, root can still get in and take appropriate action because root still has access to the remaining free space. The free space reserve also helps reduce disk fragmentation because there are always free blocks (really) available, so the system does not have to scatter blocks all over the disk when creating or extending files. Disk fragmentation can have a drastic impact on performance; according to the main entry for tunefs, the free-space reserve "value can be set to 0 for the file system, although up to a factor of three in throughput is lost over the performance obtained at a 10% threshold."
As the previous discussion implies, free-space reserve is a tuneable file system parameter that initially can be set using the newfs command, or later controlled using tunefs. (tunefs can only be performed on an unmounted file system; this means you can't tune the "/" partition currently in use. You must be able to boot A/UX separately so you can tune such a partition, so it is best to plan ahead and set such parameters when creating the partition.)
System V file systems do not have this feature, so df will report the same totals for both root and ordinary users.
How to recover if A/UX 2.0 Toolbox "hangs"
Date Written: 10/1/90
Last reviewed: 8/1/92
Why does A/UX 2.0 appear to "hang" frequently?
___A/UX 2.0 running Macintosh applications is subject to the same problems caused by those applications under the Macintosh Operating System. If an application is not "well behaved" according to the MultiFinder guidelines, it can cause random behavior such as hanging the Toolbox. But this is usually not as fatal as under the Macintosh Operating System. Usually when A/UX appears to "hang," it is the A/UX Toolbox, not A/UX itself, which is "hung." It is usually possible to kill off the A/UX Toolbox without having to resort to the drastic step of punching the reset button (which is very UNIX-unfriendly and means you should check the file system with fsck when you reboot).
So, what is the best way to kill off a runaway Toolbox? Well, if you have installed MacsBug for A/UX, you may be able to drop into the debugger using the key combination Control-Command-I (using the hardware programmers switch doesn't work). Once in MacsBug, you may be able to kill off the errant application with the es command, or reboot with the rb command. As a more drastic measure, you can try the key combination Control-Command-E, which should kill off the toolbox completely, log out the console and restart the log-in process on the console (in the absence of MacsBug, Control-Command-I is the same as Control-Command-E). Doing this is, of course, every bit as drastic as rebooting the Macintosh Operating System; any work not saved by toolbox applications will be lost, but A/UX is still safe. If you have access to A/UX via a serial or network terminal, you can log in as root and kill off the startmac process (essentially equivalent to Control-Command-E).
You should always try these methods before resorting to doing a hardware reset.
A/UX debugging tools
Date Written: 10/1/90
Last reviewed: 8/1/92
What debugging tools are available for A/UX?
___The debugging tools available depend on the task.
Very low-level kernel debugging: A kernel-level debugger ships with every system, although it is not included in the configuration. Documentation on the kernel debugger is in the release notes for the A/UX 2.0 Device Driver Kit.
Assembly debugging: The standard UNIX assembly debugger, adb, is provided.
Source level debugging: The standard UNIX source debugger, sdb, is provided. Additionally, an alternative source level debugger, cdb, is available through APDA.
Macintosh application debugging: Macintosh binaries can be debugged using MacsBug. MacsBug version 6.2 is compatible with A/UX. Place MacsBug and the Debugger Prefs file into the currently active A/UX System Folder, log out and then log back in. Once it is installed, you can drop into the debugger using the key combination Control-Command-I (using the hardware programmers switch doesn't work). Contact APDA for the latest information on MacsBug.
A/UX Toolbox application debugging: Use dbx, available from APDA.
A/UX 2.0 doesn't support IP encapsulation inside DDP packets
Date Written: 12/7/90
Last reviewed: 8/1/92
Can I get A/UX 2.0 to talk TCP/IP over the LocalTalk network? MacTCP seems to support this but I can't pummel A/UX into doing it.
___IP encapsulation inside LocalTalk DDP packets is not supported under the current A/UX 2.0.
Cloning A/UX
Date Written: 5/1/90
Last reviewed: 8/1/92
What is the easiest way to make a complete copy of A/UX from one SCSI hard disk to another?
___The dd command is the simplest way to copy A/UX. The following script documents the dd command usage and gives a sample dd command. If you use dd to copy slice 31, as in the example, the entire drive is duplicated, including the Macintosh Operating System partition.
# To clone an entire SCSI disk drive, issue the following command: # # dd bs=32b if=/dev/rdsk/cXd0s31 of=/dev/rdsk/cYd0s31 # # where X is the SCSI id of the input device and # Y is the SCSI id of the output device. # # if you have lots of memory, bs can be larger than 32b to allow # faster copying. bs=512k works well on machines with 4MB or # more. # # For example, to clone SCSI drive 4 onto SCSI drive 5 do: # # dd bs=32b if=/dev/rdsk/c4d0s31 of=/dev/rdsk/c5d0s31 # # The 31 at the end of the device name is a partition number # (31) referring to the entire drive. Substitute an appropriate # partition number to copy just a single partition. # # This is set up to clone 4 onto 5. # |
A/UX 3.0 and FSMakeFSSpec with null filename
Date Written: 5/1/92
Last reviewed: 8/1/92
I believe I've run across a bug (alternate behavior) in A/UX 3.0. When calling
FSMakeFSSpec
with a null filename (meaning that we're specifying a directory),
System 7 thinks it's cool, but A/UX 3.0 returns a fnfErr
. According to
Inside Macintosh Volume VI, the fnfErr
is OK in the sense that the
FSSpec is filled in, but it just doesn't match an existing file/folder.
If one then makes a call to NewAlias
, one gets noErr
in System 7, and fnfErr
in
A/UX. The cure is to call PBGetCatInfo
to get the directory's name and parent
dirID, and supply those in the call to FSMakeFSSpec
. Inside Macintosh
Volume VI states that empty file names could be used with FSMakeFSSpec
for
creating special FSSpecs
.
Yes, it's a bug in A/UX 3.0 final. It probably will be fixed in the next release of A/UX. Meanwhile, you'll need to continue using your workaround.
Mixing calloc and NewPtr
in a Macintosh program
Date Written: 5/7/92
Last reviewed: 8/1/92
In the past we had heard of a problem using calloc and
in the same
program. Is this true?NewPtr
There are a few difficulties, which you can deal with if you need to. The
primary problem is that calloc and all the other malloc routines weren't
designed for the Macintosh platform. Macintosh memory management is designed
around trying to squeeze as much as possible out of a limited memory area,
which is why handles are the primary storage scheme in a Macintosh; they can
move, and so greatly reduce memory fragmentation. Because the malloc tools
return a pointer, they have to be located in a locked block, so they tend to
lead to fragmentation if used with any other memory allocation calls (such as
NewPtr
). For this reason, any use of the malloc suite of allocation calls isn't
recommended for Macintosh programs. The only good reason to use them is if
you're porting a large body of code from other platforms; in this case, it may
be a reasonable tradeoff to keep the old allocation code.
You should also be aware that most of the Macintosh malloc routines never free
up memory. When you malloc some space, the routine must first allocate it from
the Memory Manager. It allocates a large block of space using NewPtr
and
divides it internally for distribution in response to malloc calls. If,
however, you eventually free all the blocks you allocated from this NewPtr
block, the block won't be released to the Memory Manager with the DisposPtr
call. This means that once you allocate some memory with malloc, you won't be
able to free it and then use that memory from a Macintosh allocation call.
Thus, if you had two phases to your program, one of which used the malloc calls
extensively and the second which used Toolbox calls, the second phase wouldn't
be able to use memory freed by the first phase. That memory is still available
in the malloc pool, of course; it simply can't be used by NewPtr
or NewHandle
.
The malloc routines supplied by THINK C work similarly, as described in their
Standard Libraries Reference. Thus, mixing the C and Macintosh allocation
routines requires special care.
Downloadables
|
Acrobat version of this Note (71K). |