|
|
This Technical Note contains a collection of archived Q&As relating to a specific
topic--questions sent the Developer Support Center (DSC) along with
answers from the DSC engineers. Current Q&A's can be found on the Macintosh Technical Q&A's web site.
[Oct 01 1990]
|
Compiling with MPW C under A/UX
Date 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:
mac1.borison 18 % /MPW/Tools/C -o SillyBalls.o SillyBalls.c
# /MPW/Tools/C - Fatal Error : 421
# can't allocate memory for global symbol table
#------------------------------------------------------------------------------
File "OSUtils.h"; Line 173 # Compiling SillyBalls.c
#------------------------------------------------------------------------------
|
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 GetFrontProcess
Date Written: 9/3/92
Last reviewed: 11/1/92
Under A/UX 2.x when I call Gestalt(gestaltLaunchControl, &reply) the value
returned in reply = 0x7F indicating that the Process Manager is available.
However, when I call GetFrontProcess I crash. Is this a known bug and if so
what is the recommended way to check for the availability of GetFrontProcess?
(This is only a problem under A/UX 2.x; A/UX 3.0 works fine.)
___
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 gestaltAUXVersion selector ('a/ux'), and if the version < 3.0,
assume the Process Manager is not available.
Setting file types and creators with A/UX's setfile utility
Date 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::
SetFile [option...] file/folder...
-a attributes # attributes (lowercase = 0, uppercase = 1)*
-c creator # file creator
-d date # creation date (mm/dd/yy [hh:mm[:ss] [AM | PM]])*
-l h,v # ICON location (horizontal,vertical)*
-m date # modification date (mm/dd/yy [hh:mm[:ss] [AM | PM]])*
-t type # file type
Note: Period (.) represents the current date and time.
Note: The following attributes may be used with the -a option:
L Locked
V Invisible*
B Bundle
S System
I Inited*
D Desktop*
M Shared (can run multiple times)
A Always switch launch (if possible)
|
Accessing Macintosh Operating System from A/UX program
Date 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 heap
Date 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 dNeedLock bit is set in the driver's header flags.
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 ROMBase. If the driver pointer is greater than ROMBase, the
driver is assumed to be in ROM. Its pointer, rather than Handle, is put in the
DCE and a dCtlFlag bit is cleared to indicate a ROM-based driver. Since a
driver in ROM can't move, the Device Manager ignores its dNeedLock bit and does
not call HLock when opening the driver. Before making the comparison, the
Device Manager calls _StripAddress on the driver pointer. Then, rather than
call _StripAddress on the ROMBase, the code clears the high byte to zeros!
(This happens at ROM address 40806A3C on my Macintosh IIx). This means that a
driver loaded into the heap at any address higher than 0x800000 is installed as
a ROM-based driver.
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 'DRVR' resource,
ensuring the driver is locked when read into the heap, regardless of what the
Device Manager does. In our case, this driver is stored as a resource in a
print driver file. Once the print driver is closed, so is its file, and our
driver is therefore removed from the heap. Otherwise, the driver would forever
be locked in the heap, even when not open.
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 protection
Date 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:
- You will have to put your valuable resources into engineering a scheme, which usually means disassembling the ROM to understand the disk drivers, HFS, MFS, etc., as well as fully understanding how the hardware for each machine your software runs on works. This extra work adds time to your development schedule.
- You'll have to maintain your software when it doesn't work on future machines or system software releases. Virtually every copy-protection scheme devised so far (that we know about) has required revision for new Apple CPUs.
- You'll have to test the software on all machines and products, including third-party hardware and file system software.
- You'll have to support possibly angry users who have problems using the software because of the protection scheme, or have broken "key" disks, or other problems. Users may be frustrated by an inability to copy software to a hard disk, make backups, or immediately use the software with new hardware or software.
- Every copy-protection scheme devised so far (that we know about) can be defeated by commercial products that remove or circumvent the protection.
- Protected software frequently receives poor reviews or mentions in the press because of the protection scheme.
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 Finder
Date Written: 11/30/90
Last reviewed: 8/1/92
In A/UX 1.1.1 there were video ioctls to get screen information (VIDEO_PIXSIZE,
VIDEO_ADDR, and VIDEO_DATA), and one to map the physical screen into user
address space (VIDEO_MAP). We used these to do documentation on our system in
the form of screen dumps. (The normal screen dump function cannot be used with
a menu held down with the mouse.) Under A/UX 2.0 these ioctls are unavailable
when the Finder is running, WHY? They work fine if the Finder is not running
(using the console emulator only). Can you tell me how I can get the same
information, specifically base address, bytes per line, screen rows, and map
the screen in with the Finder running, BUT not be a toolbox application?
___
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/UX
Date 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:
#define BTstQ(arg, bitnbr) (arg & (1 << bitnbr))
/*
* GetGestaltResult returns the result value from Gestalt for the specified
* selector. If Gestalt returned an error GetGestaltResult returns 0. Use
* of this function is cool only if we don't care whether Gestalt returned
* an error. In many cases you may need to know the exact Gestalt error
* code so then this routine would be inappropriate. See GetAUXVersion, for
* example.
*/
long GetGestaltResult (OSType gestaltSelector)
{
long gestaltResult;
if (Gestalt (gestaltSelector, &gestaltResult) == noErr)
return (gestaltResult);
else
return (0);
}
#define HWCfgFlags 0xB22 /* Low memory global used to check
if A/UX is running */
/*
* getAUXVersion -- Checks for the presence of A/UX by whatever means is
* appropriate. Returns the major version number of A/UX (i.e. 0 if A/UX is
* not present, 1 for any 1.x.x version 2 for any 2.x version, etc.)
* This code should work for all past, present, and future A/UX systems.
*/
short GetAUXVersion ( void )
{
long auxVersion;
short err;
short *flagPtr;
/*
* This code assumes the Gestalt glue checks for the presence of the
* Gestalt trap and does something intelligent if the trap is unavailable,
* i.e., return unknown selector.
*/
auxVersion = 0;
err = Gestalt (gestaltAUXVersion, &auxVersion);
/*
* If gestaltUnknownErr or gestaltUndefSelectorErr was returned, then
* either we weren't running on A/UX, or the Gestalt trap is
* unavailable so use HWCfgFlags instead.
* All other errors are ignored (implies A/UX not present).
*/
if (err == gestaltUnknownErr || err == gestaltUndefSelectorErr) {
/* Use HWCfgFlags */
flagPtr = (short *) HWCfgFlags;
if (BTstQ(*flagPtr, 9))
auxVersion = 0x100; /* Do Have A/UX, so assume version 1.x.x */
}
/*
* Now right shift auxVersion by 8 bits to get major version number
*/
auxVersion >>= 8;
return ((short) auxVersion);
|
A/UX technical information sources
Date 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/UX
Date 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ß2
Date 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 debugger
Date 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 processes
Date 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 application
Date 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 bugs
Date 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 drives
Date 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) protocol
Date 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 LaserWriter
Date 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.
SGetCString in A/UX archives should be SGetCString
Date Written: 7/25/91
Last reviewed: 8/1/92
The Slot Manager function SGetCString is called SGetCString, with a lower-case
"c," in both libmac.a and libmac_s.a archives under A/UX 2.0 and 2.0.1. It
should be SGetCString according to the rules of MPW and Inside
Macintosh. This is another case where the case-sensitivity of UNIX bites.
If you have any similar problems with other calls to the Macintosh toolbox, try
a script such as this:
Also, check libmac_s.a if you are using shared libraries. The A/UX Toolbox:
Macintosh ROM Interface manual has a list of supported Slot Manager
calls.
Use A/UX libraries to emulate Macintosh Toolbox functions
Date Written: 7/30/91
Last reviewed: 8/1/92
How can I use the Macintosh Toolbox functions from the A/UX kernel? When I link
my module into the kernel, ld can't resolve the references to toolbox
functions.
___
Macintosh Operating System ROM Toolbox emulation under A/UX is done with the
help of a device driver, /dev/uinter0, which handles the A-line trap interrupt
emulation. This will not work in the kernel side, because you can't signal
A-line traps suddenly to another device driver (without a lot of pain; anything
is possible in software). For this reason, you should use the A/UX libraries
that support most of the toolbox side concerning hardware. Slot Manager
support, for example, is done with the slot libraries (-lslot).
Let DTS know if you need additional device driver support in the current
hardware-related libraries. Otherwise, in the A/UX (or UNIX) device driver
world, you should follow the rules and libraries of A/UX (most of the operating
system-related traps are mapped to UNIX-equivalent calls anyway).
MacX client and reading Macintosh Command key
Date Written: 8/27/91
Last reviewed: 8/1/92
I need some help with MacX under A/UX: Is there any way to read the Command key
from a MacX client? Pressing the Command key doesn't produce a keypress
event.
___
The Command key is not activating a keypress because the Command key is used in
the Macintosh side of the X world for the menu shortcuts and other things, and
in order to avoid confusion, the design team made a deliberate decision not to
trigger any key events on the X Windows side concerning the Command key.
If you have an important reason why this should be otherwise, please let DTS
know.
MPW-like development environment under A/UX
Date Written: 11/15/91
Last reviewed: 8/1/92
Are there any tools or packages that give a programmer MPW-like functionality
under AU/X? Can I use any of my MPW tools under A/UX?
___
You can't directly use MPW for UNIX development work at this moment. A new A/UX
development product called the A/UX Developer's Tools is useful for developing
applications on the A/UX platform. It provides you with a "toolset" to create
UNIX and X Window Systems for Macintosh and other UNIX-based platforms, as well
as hybrid Macintosh/UNIX applications on the A/UX platform. It also includes
MPW 3.2 for writing pure Macintosh Operating System applications.
A/UX Developer's Tools work in conjunction with the A/UX operating system
running on an SE/30 or any Macintosh II series computer. The product is
composed of three CD-ROMs (MPW, X11, and A/UX tools), as well as user and
reference manuals. It includes the following features:
- A development environment for Macintosh, UNIX, X Window System and hybrid
(Macintosh and UNIX) applications all on one platform.
- Macintosh development tools on UNIX. Complete MPW (shell, C, C++, Object
Pascal, and assembler), ResEdit, SADE, and MacsBug are included.
- A/UX system call library for Macintosh-based applications that take advantage
of the power of UNIX. XCMDS that can make A/UX system calls allow HyperCard
stacks to use UNIX features.
- Toolbox application debugging from UNIX using dbx, with Apple-added
extensions to allow source-level debugging of both UNIX applications and UNIX
hybrids--applications that take advantage of the A/UX Toolbox.
- Industry-standard ANSI C with Macintosh enhancements. Includes aids in
developing portable C code and access to routines written in Pascal.
- C++ Language System that enables object-oriented code development for
producing powerful, easily maintainable code.
- Full X Window System development environment. Including X11 Release 4, Xlib
library and Xtk toolkit, MIT's Athena Widget Set, desktop client applications,
and utilities.
- Commando interface tools to add selected Macintosh user interface elements to
standard UNIX applications.
- Complete, easy-to-read documentation for all product features.
If you're interested in this product, please feel free to call APDA at (800)
282-2732. Alternatively, you may also want to investigate some of the
third-party A/UX development options by browsing through the Redgate Buyer's
Guide library on AppleLink (in the Third Party Connection folder).
Mounting & unmounting a SCSI removable volume under A/UX
Date Written: 12/20/91
Last reviewed: 8/1/92
What commands do I enter to unmount a removable media drive with a HFS
partition under A/UX, and then remount it or a different cartridge later?
Sometimes when I drag it to the trash it pops back on the desktop. What
commands would I use to mount and unmount an A/UX "Unreserved 1" partition?
___
The capability for ejecting SCSI volumes is not yet supported in A/UX; the only
way to eject a volume such as yours is by using a manual eject, such as by
pressing a button on the drive. Thus, if both Macintosh Operating System and
A/UX partitions from a disk are mounted, your user needs to unmount the A/UX
partition from the file system by using unmount, and then unmount the disk from
the Macintosh Operating System by throwing it in the trash and ejecting the
volume by pushing the eject button on the drive before the Macintosh Operating
System detects and remounts it.
To mount and unmount A/UX partitions, you use the "mount" and "unmount"
commands in A/UX, as described in A/UX's manual pages.
Timeout versus delay call for A/UX driver
Date Written: 1/7/92
Last reviewed: 8/1/92
When the A/UX kernel calls our network driver's INIT routine, part of our
initialization requires us to wait for approximately 1 second or so. To
implement the delay we use the delay(v.v_hz) system call. This works for A/UX
2.x, but when the driver executes the system call delay(v.v_hz) under A/UX 3.0,
the system never returns. Any ideas?
___
You should use the timeout() kernel library call instead of the delay() kernel
routine. delay() will always do a sleep, and thus it's hard to get a wakeup
state back from this.
Timeout wants a function pointer, which will call back the original thread
after a defined time, like 1 second or so. It's surprising that delay() seemed
to work OK in your driver in A/UX 2.x kernels. Maybe you were just lucky with
the overall timing.
A/UX 2.0.1 and LaserWriter 7.0 compatibility
Date Written: 1/30/92
Last reviewed: 8/1/92
Is it safe to install the System 7.0 printer drivers under A/UX 2.0.1 systems?
We have A/UX users, System 6.X users, and System 7.0 users all sharing the same
printers.
___
There are no known incompatibilities between A/UX 2.0.1 and the System 7 print
architecture. A complete LaserWriter installation on the A/UX machine should
include three pieces of software: the LaserWriter driver, the PrintMonitor
application, and Laser Prep. To make sure A/UX's native spooling operates
normally, do not update or modify your Backgrounder system extension (INIT). If
you follow these steps you'll have a signed treaty, no more laser wars.
A/UX 2.01 ignores enumerator field in NBP tuple
Date Written: 3/3/92
Last reviewed: 8/1/92
I am having problems with AppleTalk using A/UX 2.01. Only one NBP (Name Binding
Protocol) name is allowed per AppleTalk socket; that is, it ignores the
enumerator field in the NBP tuple and keeps only the first name for every
socket. The same code under the Macintosh Operating System seems to work fine.
Is there a known bug here?
___
There is in fact a bug with NBP and the enumerator field under A/UX 2.01. At
this point there is no workaround. However, the A/UX group is aware of the
problem and there should be a fix at some point in the future.
AppleSingle/AppleDouble file format
Date Written: 10/1/90
Last reviewed: 8/1/92
How can I find out more about the AppleSingle/AppleDouble file format
specification?
___
The AppleSingle/AppleDouble file format specification was originally designed
to facilitate storage of Macintosh files on A/UX. It has been generalized to
allow storage across a variety of platforms. More information on this file
format is contained in Chapter 6 of the A/UX 2.0 manual, A/UX Toolbox:
Macintosh ROM Interface. It is also available as a separate document titled
"AppleSingle/AppleDouble Formats for Foreign Files Developer's Note." This
document is available in printed form from APDA, and in electronic form on the
Developer CD Series disc and on AppleLink in the Developer Support
folder.
A/UX 2.0 and text file CR-to-LF conversion
Date Written: 5/1/90
Last reviewed: 8/1/92
When and why are carriage return characters translated to linefeed characters
by A/UX 2.0?
___
To understand the significance of this question you must realize that Macintosh
applications expect lines in text files to be terminated by a carriage return
character (CR, 0x0D) while A/UX applications expect the lines to end with a
linefeed character (LF, 0x0A). To allow the same files to be read and written
by both kinds of applications, the A/UX Toolbox performs some magic
translations when Macintosh applications read and write these files. While
every attempt has been made to make this translation completely transparent to
both the user and the application, some situations can arise where unexpected
results ensue.
First, translation NEVER occurs except for files of type 'TEXT', and then only
when the file is written to the "/" UNIX partition. Translation does not occur
if the file resides on a Macintosh file system, and binary files are not
affected. But, if you have a file of type 'TEXT' and move that file to the UNIX
partition, THEN change the file type to something other than 'TEXT',
translation will have already taken place and the file will have bad data.
When does this translation occur? Translation takes place on _Write and _Read
calls. At that point, the A/UX toolbox looks at the file type and the
destination/source file system and determines if translation is appropriate.
This means, for example, if you create a file of type 'TEXT' and write some
data to it, then change the file type, translation will have already occurred,
so you should always set the correct file type before writing any data.
Finally, how does the toolbox deal with "ordinary" UNIX files transferred to an
HFS volume? For a more detailed discussion of the exchange of files see the
question: "What assumptions are made when the A/UX Toolbox moves a file between
an HFS partition and an A/UX partition?" With respect to CR/LF translation when
transferring ordinary UNIX files, the Toolbox tries to determine if the file is
a text file in the UNIX sense. It does this in the same way the "file" utility
does it (man (1) file). For more information on how it does this, see the
question: "How A/UX 2.0 handles file and creator information." If the file
looks like an ordinary text file, like a shell script or source code,
translation occurs; otherwise it does not. As long as the A/UX Toolbox can
identify the UNIX file type and the toolbox can handle transfer both to and
from the HFS partition, the process is completely reversible and no ambiguity
occurs. But beware of transferring data only in one direction with the Toolbox.
Suppose, for example, you transfer a file from A/UX to a Macintosh using a
serial communication program, but then use the A/UX Finder to copy it back to
the A/UX partition. You may not end up with an identical file because
translation has taken place in one direction, but not the other.
A/UX Toolbox and HFS-to-A/UX file conversion
Date Written: 10/1/90
Last reviewed: 8/1/92
What assumptions are made when the A/UX Toolbox moves a file between an HFS
partition and an A/UX partition?
___
Implicit carriage return/line feed translation occurs for text files. See the
question: "A/UX 2.0 and text file CR-to-LF conversion."
There are some other assumptions made regarding text files. Macintosh files, in
addition to having the data in the data fork, often have additional information
stored in the resource fork. UNIX has nothing corresponding to a resource fork,
nor does UNIX have information such as the Finder maintains for files like type
and creator information; so this information is not lost when the file is
transferred to an A/UX partition. A/UX defines some special UNIX file types.
The simplest form is the AppleSingle format. This includes a header indicating
the size and location of data within the file; various entries for file Finder
information; and resource and/or data fork (if appropriate). This is fine for
binary Macintosh files such as applications or word processor and graphics
files, but in the case of plain text files, this presents a problem for UNIX
utilities that expect only to see the text (data) in a file, so A/UX defines a
second format referred to as AppleDouble.
AppleDouble format stores the Macintosh file in a pair of separate UNIX files.
The data fork resides in a UNIX file all by itself, and all the other parts of
the file go into a separate file under the same name but with a "%" character
prepended. For example, if you have a Macintosh text file named "Foo," which
also has a resource fork, and you copy that file to a UNIX partition, it still
appears as a single file to the A/UX Finder and other Macintosh applications,
but to UNIX process there are two separate files named "Foo" (the text) and
"%Foo" (the resource and other data).
Creation of an AppleSingle/AppleDouble file is NOT performed for files of type
'TEXT' which have no resource. Only a plain UNIX text file is created and all
Finder information is lost. This simplifies working with text files between
Macintosh and UNIX applications, avoids having the excess baggage of
"%filename" files floating around and getting separated and allows UNIX text
files to be transferred to HFS partitions and back without change. Explicit
conversion between AppleSingle, AppleDouble, and plain UNIX files is possible
using the fcnvt utility.
How A/UX 2.0 handles file and creator information
Date Written: 10/1/90
Last reviewed: 8/1/92
How does A/UX 2.0 associate file and creator information with ordinary UNIX
files?
___
File and creator information has no counterpart in the A/UX file system. All
files under UNIX are just streams of bytes, and some conventions have developed
over the years to help applications determine the kind of files they are
dealing with. Many of these conventions are exploited by the A/UX "file"
utility to identify files.
The first few bytes of a file are often used to store a special number or
string referred to as a "magic number." Various magic numbers for files are
contained in the file /etc/magic. For example, a file beginning with the string
"#!/bin/sh" is a Bourne shell script. This is just a text file and the default
for plain text files is to be owned by the TextEditor application. Plain text
files will show up in the A/UX Finder with the TextEditor document icon. If you
double-click the icon, TextEditor is launched to edit the file, but if you take
that same file and make it executable (in the UNIX sense) using chmod, it
suddenly becomes executable by the CommandShell and has a CommandShell document
icon associated with it. If you double-click the icon, the CommandShell is made
the foreground application and commando is launched for the script.
The apparent type and creator is a fiction maintained entirely by the A/UX
Toolbox; it is returned to Macintosh applications just like real type/creator
information, using the GetFInfo call, but it does not exist in the A/UX file
system. If you want explicit type/creator information to be associated with a
file, it must be an AppleSingle/AppleDouble format file.
Altering MultiFinder memory under A/UX 2.0
Date Written: 10/1/90
Last reviewed: 8/1/92
How can I get A/UX 2.0 to increase the amount of virtual memory available to
MultiFinder?
___
Because A/UX is a virtual memory environment, A/UX can allow MultiFinder to run
in a memory partition larger than physical RAM. There currently are some
limitations based on the MultiFinder environment you are using, and there are
of course tradeoffs when creating a virtual memory partition much larger than
physical RAM, but here is the scoop:
In the 24-bit environment, A/UX limits MultiFinder to 8 MB. In the 32-bit
environment, the limit is 16 MB. You can alter the default size by modifying
the scripts /mac/bin/mac24 or /mac/bin/mac32 and adding the -m option to the
startmac24 or startmac command lines. For example:
would create a 10 MB partition. Alternatively, you can alter the default size
on a user-by-user basis by setting the environment variable TBMEMORY in the
user's .log-in script. For example:
will accomplish the same thing.
A/UX 2.0 recognizes AppleTalk Phase 2 (but not Phase 1) routers
Date Written: 10/1/90
Last reviewed: 8/1/92
Why does A/UX 2.0 seem not to find all the AppleTalk zones in my network?
___
The A/UX 2.0 AppleTalk implementation is AppleTalk Phase 2, and Phase 2 nodes
do not recognize Phase 1 nodes and routers. You need to upgrade your routers to
Phase 2. Alternatively, you can connect your A/UX machine to LocalTalk, which
does not have this limitation.
Root has more free space than ordinary users
Date Written: 10/1/90
Last reviewed: 8/1/92
Why does root have more apparent free space than ordinary users?
___
When using Berkeley file systems, the system reserves a portion of the
partition (called the "free-space reserve") and makes it unavailable to user
processes. For example, if you log in as Guest and issue the following
commands, here is what you will see:
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 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.
Back to top Downloadables
|
|
Acrobat version of this Note (71K).
|
Download
|
| 
