Click for MacWindows home

Works with older Macs, too

Mac OS 9 Cross-Platform Issues

Last updated April 25, 2003

On this page:


Mac OS 9 was released on October 23, 1999. Apple said it included 50 new features, including partial compatibility with OS X. Several of the improvements in Mac OS 9 affected or improved compatibility with Windows PCs and UNIX. This page contains a breakdown of what was new cross-platform-wise. (For a complete account of everything in Mac OS 9 for developers, see Apple's Technote 1176.)

As time goes on, we will to use this page to report cross-platform problems and solutions with Mac OS 9. If you know of issues, bugs, or fixes regarding Mac OS 9 and PC integration, please let us know.

Cross-platform improvments in Mac OS 9

We've divided the report into the following categories:


One of the most important new networking feature is browsing for file servers and other network devices over TCP/IP networks. It allows users to see IP devices listed without having to enter an IP address, just as you can now see AppleTalk devices in the Chooser. This is not a PC-compatibility feature, but is a catching-up to Windows networking, which has had TCP/IP browsing features through the Network Neighborhood for years. It is also enables Apple to move another step away from AppleTalk.

OS 9 also has improvement in cross-platform networking as well.

Open Transport 2.5

Open Transport is the networking technology for Mac OS. Improvements include:

Network Browser (Apple Menu)

The Network Browser application is the successor to the Chooser introduced on OS 8.6.

Network Services Location 1.1

Network Services Location (NSL) is a protocol-independent method of searching for network services. New features include:

AppleShare Client 3.8.5

This is the client for Apple Filing Protocol (AFP) file servers, such as AppleShare and NT Services for Macintosh.

File Sharing control panel and extension.

One aspect of TCP/IP browsing is that you can now do Personal File Sharing over TCP/IP. (This is still based on the Apple Filing Protocol, AFP). On versions before OS 9, you can only make Mac file available over AppleTalk. However, AppleTalk must be active in order to use this feature.

The feature is based on technology licensed from Open Door Networks, used in that company's ShareWay IP gateway product. In fact, there's a new background process called "ShareWay IP Personal Bgnd."

Other new features are passwords in masked text (instead of clear text) for better security. Also, the Users and Groups control panel has been integrated into the File Sharing control panel.

AppleScript 1.4

AppleScript now works over TCP/IP networks. Before OS 9, AppleTalk was the only network protocol AppleScript would work over.

Files and Disks

File Exchange 3.0.2 control panel

This is the control panel that mounts PC disks in the Finder and provides extension mapping of PC file names to Mac OS file type codes. (See also our Disk Tips page.)

New features for File Exchange 3.0.2 include:

Bug fixes:

Drive Setup

The Drive Setup utility can now format drives as UFS (UNIX File System) and "other common UNIX file system types."

File Manager

The File Manager is the part of the system software that helps with disk storage. New features for the File Manager include support for large files (forks over 2 GB) and long Unicode names.


LaserWriter 8 version 8.7

There's no word as to whether the new Postscript driver fixes some of the printing problems with Windows NT Server cause by LaserWriter 8.6. (We'd like to hear from you on this topic.) New features include:

USB Support

Improvements have been made that may make it easier to use cross-platform USB devices on Macs with built-in USB and on PowerBooks with USB PC cards. Includes support for audio devices such as speakers and microphones.

InputSprocket 1.7

InputSprocket enables gaming input devices such as joysticks to work with Macs. This version consolidates all the InputSprocket extent ion files into a single file. This version supports more cross-platform devices. In particular:

Palm Desktop 2.5

The Apple Extras folder installed on the hard drive contains a copy of Palm Desktop 2.5, an updated version of Claris Organizer, which Palm Computing bought from Apple. Palm Desktop is a scheduler and address book with the ability to synchronize with Palm OS-based devices.

System Features

Finder 9.0

System File

Mac OS Runtime for Java 2.1.4

Apple's implementation of the Java runtime environment for Mac OS applications and Java applets and applications adds a few new features and bug fixes.

OpenGL 1.1

OpenGL is a cross-platform 3D modeling technology used in gaming and other applications, which Apple recently adopted to replace it's own QuickDraw 3D. OpenGL was created by Silicon Graphics and is used in Windows and UNIX 3D graphics software.

Bundled Cross-platform Utilities

Mac OS 9 comes with DropStuff 5.1.2, StuffIt Expander 5.1.4 and the StuffIt Engine 5.1.3. These versions have no new features, but have been upgraded for OS 9 compatibility. Earlier versions are not compatible with OS 9.

Compatibility Issues (with cross-platform software)

StuffIt Deluxe. Aladdin Systems says about StuffIt Deluxe:

The StuffIt Deluxe 5.1 application will not work and is incompatible with OS 9..

The components of StuffIt Deluxe 5.1 using the StuffIt Engine, such as True Finder Intergration (Magic Menu, Archive Via Rename) and DropStuff, work with Mac OS 9 with the updated StuffIt Engine 5.1.3, which is installed with Mac OS 9.

Aladdin issued two updates that are OS 9 compatible:

See also Aladdin's OS 9 page.

SoftWindows. SoftWindows 5.0.5 and earlier and RealPC 1.0.5 and earlier are not compatible with Mac OS 9. FWB software has issued a patch for OS 9 compatibility patch for SoftWindows 98, another for SoftWindows 95 and another for RealPC (the DOS version). SoftWindows 5.0.9 and RealPC 1.0.9 are required to run them on OS 9. There are also other enhancements for all users:

Blue Lable PowerEmulator. Reader Jose Sanchez Nunez reports that Lismore's Blue Label PowerEmulator running Windows 95 runs well on Mac OS 9. (He has a Power Mac 6500/250).

Timbuktu Pro. Netopia has released Timbuktu Pro for Macintosh 5.21, an upgrade of its cross-platform remote control software for Mac OS 9. The new version is Mac OS 9 compatible and implements a number of new OS 9 features, including password support for the Keychain and IP Browser support that detects Timbuktu users on a TCP/IP network.

DHCP problems. Apple reports of two problems with DHCP in OS 9 and in recent pre-installed OS 8.6. The problems are with Open Transport OT 2.5.1 and 2.5.2, which come with all OS 9 configurations and on 8.6 shipped with iBooks, slot-loading iMacs, and Power Mac G4. The problem can cause the Mac to hang during startup, or for the DHCP lease to fail in certain conditions. This problem is fixed with Open Transpoft 2.6, which requires at lease Mac OS 8.6. (Apple had touted better compatibility with NT DHCP Server as one of the features of OS 9 and Open Transport 2.5.)

DOS Mounter 98. Software Architects says that DOS Mounter is not compatible with Mac OS 9, but that a fix will be released before the end of the year. DOS Mounter 98 is a Mac utility for using and formatting PC disks.

Problem with OS 9 keychain and NT Server. Several readers report problems with adding NT Servers to the Keychain. There is a condition as well as a limitation.

Condition: In order to enable the Mac OS 9 Keychain to add NT Servers, the NT Server must be set to allow users to SAVE the password, not just CHANGE the password.

Limitation: Once the NT Server is set this way, you can add the NT Server by dragging it from the Chooser to the Keychain, but not by dragging it from the Network Browser.

David Roessli adds that the NT user SAVE option is located in the MacFile control panel (attributes). If you don't allow the user to save the password, Mac OS 9 gives the following error message after you enter your user ID and password:

An error has occurred. Unable to add an item to the current Keychain. The specified item is no longer valid. It may have been deleted from the Keychain.

Roessli also notes that the Microsoft UAM can be installed, but you can't log in through the MS UAM to add it to the Keychain.

Also thanks to Darrin Raposa for contributing to this item.

Apple PC Compatibility Card. A reader reports that he was able to get Apple's discontinued PC Compatability Card and the Jason Linhart networking patch running on Mac OS 9. To get it to work, he re-installed the PC Setup 1.6.4 software and the netpatch after a clean install of the OS. (We had previously reported that the card did not run under OS 9.)

Apple says that the card won't run on any of these OS version after 8.1, but it actually will run with 8.5 and 8.6 as well (see the MacWindows Emulation Tips page).

OrangePC card conflict with Mac OS 9.0.4. Bradford Pollock reports of an incompatibility between the recently released Mac OS 9.0.4 and 9.0.2 and Orange Micro's OrangePC software (for its PC coprocessor cards for Macs). Pollock says Orange Micro has admitted the problem, which causes all keyboard key strokes to be repeated (as in "MMaaccWWiinnddoowss" instead of "MacWindows").

However, Michael Corn wrote to say that the conflict between Mac OS 9.0.4 and the Orange Micro's software only occurs with virtual memory turned on. Turning VM off gives you normal operation.


Thursby's DAVE. DAVE 2.5 is required with Mac OS 9. DAVE 2.1 is not supported by Mac OS 9.

Security problem with NetWare. An MSNBC article reports of a problem with Mac OS 9 and the Prosoft Engineering NetWare Client for Mac OS. When users log out of Mac OS 9, the NetWare NDS are not closed, but remain active for other users.

MacLinkPlus. DataViz posted MLP-OS 9 updater, a patch for MaclinkPlus 11.00 that updates it for OS 9 compatibility. DataViz says it solves problems with contextual menus and decompressing Stuffit archives (an error -119). The free update is available for Enlish, French, and German versions of the Mac utility for translating between Mac and PC files. DataViz says it solves problems with contextual menus and decompressing Stuffit archives (an error -119). The free update is available for Enlish, French, and German versions of the Mac utility for translating between Mac and PC files.

Why Unicode support in Mac OS 9 won't support Win 2000 language problem

Microsoft Knowledge Base article Q239474 describes a problem with Windows 2000 Server and Services for Macintosh that Microsoft is caused by lack of Unicode support in Mac OS. The problem has to do with "localized" (non-English) versions Mac OS not being able to see file names on Win 2000 SFM shares. Mac OS 9 will support Unicode, but Rob Newberry of Group Logic, the developer of ExtremeZ•IP (the AFP-over-IP server for Windows NT), doesn't think OS 9 will fix the problem:

Your item today referencing the problem with non-U.S. English Mac OS clients and US servers ends with a reference that Mac OS 9 supports UNICODE.

While it is true that Mac OS 9 does support UNICODE, the level of support for UNICODE in Mac OS 9 will not help this particular problem. The UNICODE support for Mac OS 9 comes in the form of a new set of APIs which, while available for all volumes, only actually work on HFS+ volumes.

First off, application programs must be revised to support these new APIs, and not even the Mac OS Finder has been completely revised yet -- while I do not know if the Mac OS 9 Finder uses these APIs or not, I do know that it does not FULLY support them. That is because the new APIs allow you to support file names of up to 255 UNICODE characters, but Apple has publicly documented in a TIL article that the Mac OS 9 Finder still only allows 31-character file names.

Secondly, even after the Finder and other programs have been revised to fully support the new APIs, these APIs travel through the File Manager of the Mac OS and eventually down to the Mac OS File System Manager, which hands the particular requests to drivers for each of the available file systems that the Mac supports -- for example, HFS, HFS+, MS-DOS (via Mac OS File Exchange) and AFP (via AppleShare client). Currently, only the HFS+ driver can handle UNICODE, so these other drivers simply supply the old behavior (by converting the UNICODE down to ANSI if possible). It has not even been clearly documented what happens when an application tries to actually use the new features of the new APIs on a volume that does not support them, although I'm quite certain a particular error code is returned to the application.

Finally, in order for these new features (such as UNICODE and long file names) to work against AFP servers, Apple would need to provide a new version of the AFP protocol. The current AFP protocol version, 2.2, defined in Inside AppleTalk and some secondary PDF documents available from Apple, have no mechanism for the client to communicate UNICODE file names to the server. I believe Apple plans to address these limitations in a future version of AFP, but I do not expect that version to be available in the near future.

Rob Newberry
Director of Fajita Technology
Group Logic, Inc.

Reader reports:

A problem with OS 9.0.4 freezing while logging onto NT Server

Readers have been reporting problems with Mac OS 9.0.4 freezing while logging on to Windows NT Server. Here are some of their reports and one suggestion:

May 8, 2000 --Several readers have reported that Macs running OS 9.0.4 freeze when they try to log into and mount a volume with NT Server, Services for Macintosh. Vinh Phan reports the problem with a Power Mac G4) logging into a Windows NT Server with Service Pack 6. He says "I get the username and password prompt but I cannot access the share." Rick Kerr had the problem with a G4/450 and a PowerBook G3: "[The Mac] sees the server, but freezes the machine when trying to mount the server." Both readers said their Macs with OS 8.X don't have this problem.

May 9, 2000 --John DeMillion suggests a fix: delete the AppleShare Prep file in the Preferences folder. DeMillion reports his experience with freezing and OS 9.0.4:

I have about 15 machines running MacOS 9.0.4 hitting a number of NT 4 SP6 volumes with no problems directly related to the volumes (although I've noticed random hard freezes that even MacsBug doesn't handle with v9.0.4 that we didn't have before).

May 10, 2000 -- Several readers have responded to say that they have not seen the problem of the Mac OS 9.0.4 Chooser freezing when logging in to a Windows NT Server, which we've been reporting for the past few days. Rick Kerr, one of the readers who first reported the problem, said that he solved the problem by replacing a faulty Ethernet cable.

May 31
David Jackson

I have also seen this problem when logging on to my NT server I also get the message 'Finder unexpectedly quit' after I cancel the log on process. For some reason the Mac tries to logo on twice to the NT server and on the second time the make invariably freezes. I reinstalled system 9 again this seemed to cure the problem for a short amount of time, but always rears its ugly head again. HELP!!!

May 31
Paul Proudfoot

I have a site running G4 desktops and OS 9, plus other Macs on OS 8.x against a Win NT 4 server. The users are complaining (and I have observed it) intermittent freezes for about 15-30 seconds on the OS 9 Macs. No actions are possible, then the system comes back to life and works OK. This happens in random applications. I have updated the boxes to 9.04 and the latest MS updaters but no joy.

I am looking at an incompatibility between NTFS and the AppleShare under OS 9 and am looking at using an earlier version of the AppleShare client as an experiment. This site does not experience (not reported or observed) the freezing at logon time to the server.

June 1, 2000 A Suggestion
Scott Krajewski recommends cleaning out the Servers folder in the System folder and setting Apple Menu Options not to remember recent servers. This has caused login freezing in past OS versions. If you are having this problem and have tried this, please let us know if it works for you. (Meanwhile, reports having this problem with an iBook.)

June 1, 2000
Etienne Douaze

Greetings from Singapore. Just a short note to tell you that I experience the same problem using my graphite iBook to connect to an NT server. I get the prompt, enter ID and passwd and ... FREEZE ! The iBook runs on OS 9.0.2.

June 12, 2000
Frank Santore

Scott Krajewski's recommendation worked for me. I've been trying to squash this one for a long time. I had nothing in the servers folder to clean out, so essentially I just set the Apple Menu Options to remember 0 servers: voila. No more hangs. My workaround was to always put away the NT network volumes prior to logging out under multi-user and the hang would also not occur.

June 6, 2000 More suggestions
Mike Craney

We are running a NT server with 3 different volumes on a Level 5 RAID. The volume sizes total 100 GB. We have experienced the same problem with file transfer lags and log-in freezes. We were able to fix the log-in issue by deleting the AppleSharePrep file, the Finder preferences and using Micromat TechTool to do a clean desktop rebuild. (Also make sure that file sharing and program linking are enabled and that the connect over TCP/IP option buttons are both checked. Also verify that the Mac Target volume has it's sharing enabled). The suggestions for cleaning out the recent servers did NOT make a difference. We also use the keychain feature to remember the log-in and this does not interefere with operations.

One note on file transfer lags - even though it may lag, time the total transfer and calculate the transfer rate - you will be surprised that it calculates to an "appropriate" speed depending on your NIC and Network set-up...if you are running NT Services for Macintosh, this protocol is notoriously problematic and slow. An alternative that is extremely fast and stable is ExtremeZ-IP from Intergraph. There is a free demo available. [See the MacWindows ExtremeZ-IP page.]

Also - have the SYSAdmin check the settings on the NT server. There is a option buried in the services setup that lets you adjust the priority and CPU allocation of file transfers. We adjusted ours to maximum for file transfers and this also helped the speed.

June 6, 2000

Danny Thomas noticed some similarities of this problem with another with AppleShare IP caused by an alias of a Eudora folder on the server:

This must be a different from the infamous "Apple Menu Options" (AMO) AppleShare bug, but David Jackson's posting does have some similarities. As described on the link below, AMO hangs came from a system bug leading to a continuous code loop attempting to access an alias the user doesn't have the privileges for. The access failed, but the buggy code ignored the return code and kept retrying. That bug was fixed finally in MacOS 9, even though the ASIP engineers had found it around the time of the release of MacOS 8.5.1

David's experience in the bug returning later does sound similar which in our case came when AMO remembered an alias it shouldn't have. Maybe he could install MacsBug and try the suggestion on this link. Basically when the machine hangs, drop into the debugger and look at the list of open files to see if there's an alias to the server in the bottom few entries.

In our case pre-MacOS 9 to our ASIP server, the problem nearly always came from an alias to another user's Eudora folder kept on the server. NB while cleaning out the AMO config file or disabling remember recent items worked for a lot of people, it never worked for us though completely disabling AMO did. When we identified the problem alias, it was not found amongst those remembered by AMO,

Mac OS 9 IP file sharing slower than AppleTalk

November 3, 2000 --
Scott Christopher
QA Software Test Engineer
Miramar Systems, Inc.

Scott Christopher of Miramar Systems tested Mac OS 9's file sharing service and sent us the results, which were surprising. He says the implementation of Mac OS 9's IP file server is slower than file serving over AppleTalk. (Miramar Systems' PC MacLAN AFP product for Windows works over both AppleTalk and IP.)

I thought it interesting to point out that IP is not always faster than AppleTalk. As we all know, OS 9 was the first Mac OS to offer File Sharing over IP as well as AppleTalk by simply checking the "Enable File Sharing clients to connect over TCP/IP" in the File Sharing Control Panel.

But what I have consistently found is that the implementation of OS 9's IP server is slower than AppleTalk.

I also found that when an IP capable client queries over AppleTalk to OS 9 about its IP capabilities, it will always reply with "No"

This automatically forces the client to log in via AppleTalk. At first I thought this was a bug, but after some testing I think this was done to give the client the fastest possible connection. When the same query is put to an AppleShare IP 6.x Server, the reply is always "Yes" and an IP session is then started.

This was a Mac G3 350 running ThruPut read and write tests to a Mac G3 266, both running OS 9. It plainly shows that AppleTalk is faster than IP when dealing with OS 9's built-in file sharing.

An explanation from Apple

April 25, 2003
Ethan Lowry
AppleCare Engineering

I noticed that some people have complained that their Mac OS 9 personal file sharing connections are slower over IP than AppleTalk. This is because Mac OS 9 uses OpenDoor's ShareWay IP to share over IP. What happens is the packets go out onto the AppleTalk stack, but are then intercepted off the AppleTalk stack, a TCP header and stuff is added and then sent out. When the packets come in over TCP, they have the TCP stuff stripped off and then the packets are put back onto the AppleTalk stack and sent to personal file sharing. There is no way it will ever be faster since the personal file sharing truly only supports AFP/AppleTalk. Native AFP over IP exists only in AppleShare IP and Mac OS X.

There is an illustrated explanation of how this works on Open Door's site.

"Trash bug" with Mac AFP network clients.

This is a problem that causes the contents of mounted volumes to appear in the Trash of a Macintosh client on startup. We've has reports of this occuring with a variety of AFP (Apple File Protocol) file servers, including Windows NT SFM, Linux running Netatalk, MacServerIP, ExtremeZ-IP and AppleShare IP. If you seen this problem please let us know.

This does not seem related to the MS-confirmed Caplin bug with Windows NT, or to a problem with MacServer IP and files not deleting from the Trash.

The problem seen with Windows NT Services for Macintosh

December 8, 2000
Brian Frobisher reports this problem he is having with NT server 4.0 with SP 6 and using SFM:

We are finding that certain folders from one of the mounted volumes keep appearing in various user's Trash cans and they do not have the user privileges to move and or delete the files in question so I am not sure how the server is putting them in the trash.

This has happened to use before and has gone away, and now it is back and happening all over our network since last week.

February 21, 2001
Brian Frobisher

We are experiencing the "Files and Folders" in the trash can from time to time. (OS 9.04, Windows NT 4.0 Server SP 6 SFM).

My fix is to reboot the NT server and then it seems to be good for a long time (2 months or so without rebooting)

I have a similar and possibly related problem where privileges seem to change on folders in the Mac Volumes and I am not sure why this occurs. I just reapply the rules and then reboot and it stays good for quite a while also.

The problem seen with MacServerIP

December 19, 2000
Dan Corjulo

I have found this problem also happening with MacServerIP for Windows 2000. This would seem to eliminate SFM, since MacServerIP replaces that.

We are finding that certain folders from one of the mounted volumes keep appearing in various user's Trash cans and they do not have the user privileges to move and or delete the files in question so I am not sure how the server is putting them in the trash.

This has happened to use before and has gone away, and now it is back and happening all over our network since last week.

The problem seen with ExtremeZ-IP

March 1, 2001
Yvan Rodrigues

Just to add my $0.02 to the trash bug. We have noticed this problem since I installed a trial copy of ExtremeZ-IP on my server for mac file sharing. My clients are on OS 8.5/8.6.

The problem seen with Linux and Netatalk

December 21, 2000
Rob Simons

Wow! I thought I was the only person with the weird trash problem reported on your site.

I have a small network of about a dozen Macs served up by two servers: a Linux box (Netatalk) and a Windows 2000 box. The contents of one particular folder (containing several thousand files and almost 1.5GB of data) on the Netatalk server occasionally show up in my Trash folder. I cannot move the files, although I can delete them (ouch!) The parent folder of these files is on the root level of a Netatalk volume and it disappears when the files show up in my trash. But I can't make a new folder with the same name because the OS thinks it does exist. The only way I can return my machine to normal is by doing a forced reboot. A restart will cause the trash to be emptied. This has probably happened to me at least a dozen times. I have not found any pattern other than it's always the contents of the same folder and it only happens on my machine.

December 21, 2000
Allyn Martin

We have been having the same issues with our Linux 6.2 servers on Dell PowerEdges, before with NT SFM on Compaq servers. Many problems came from doing collects with Quark Xpress v 4.1 - so we started collecting with Flight Check Collect. Problem seemed to go away.

I think 2x in the last 45-60 days we have had someone working and they have discovered items in their trash and we were able to save them. No explanation as to why they happened. Not a cause of the common Quark Xpress collect as before.

February 26, 2001
Blair Stilwell

I use a Linux/netatalk file server to serve about 30 users. We are using netatalk version 1.4.99-0.20001108. The bug has occurred on Mac OS 9.04, with version 3.8.6 of the AppleShare Client. In some cases, an entire (22 GB) share will end up on in the users Trash. In other cases, just a subdirectory (1GB-5GB) ends up in the Trash.

The users do not have the ability to drag stuff to the Trash, but only to delete it immediately, which makes it even more odd that the folders are in their Trash can. The users don't have enough access to write to the root directory of the share, so to restore the files they must restart their computer - if they are lucky enough to notice them as they empty their Trash. It has really become an occupational hazard!

I have submitted a bug report to the Netatalk developers, but I am not convinced the server is completely to blame. I see reports of it happening on Windows NT and 2000, and a report of it happening on ASIP 6.3.1. Maybe it is time to collectively report these anomalies to Apple.

The problem seen with AppleShare IP 6.3.1

February 20, 2001
Warren Masons

I work for an educational institution that has experienced and struggled with this problem in a network of 114 Macintosh dual processor G-4 clients, running OS 9.0.4, since June 2000. The twist is that we run Macintosh G-4 servers with AppleShare IP 6.3.1 for file sharing. With your reports of non-Macintosh servers, this leads me to believe that the problem is client related.

A typical "trash bug" scenario begins with slow execution of our client startup AppleScript, which handles the volume mount, resets screen resolution and resets sound volume. Next, the AppleTalk network arrows, in the upper-left hand corner of the screen, blink as they try to connect to something. We have hypothesized, with some limited network research to back it up, that this may be a repeated ping to a folder that does not exist. Finally, the shared volumes mount. Once the scenario has completed, the client will be unstable and the mounted volume will appear in the trash.

The bug then appears to move to the network where it dramatically increases AppleShare activity within a subnet. Other clients seem to catch the "trash bug", as the number of instances increase, but this may be coincidental. We have discussed all above aspects of this problem extensively with Apple and they have not been responsive.

There are some irregularities with the "trash bug." We used to have 3 volumes mount and sometimes only one would land in the trash. In other instances, it is necessary to open the trash and click once in the trash window to get the volume contents to appear.

While there is no solution, we have found that if the startup AppleScript opens and closes the trash that the client will be near stable for a user session. This does not solve the "trash bug" nor does it make an impact on the network portion of the problem.

DHCP Problems with Mac OS 9.2

Suggestions and workarounds are described below.

September 6, 2001 -- Daniel Nicole reports a problem with Mac OS 9.2 and NT-based DHCP:

I manage a LAN with about 40 PCs and 200 Mac. The machines receive IP addresses using the DHCP service on a NT 4 SP6 server. There are problems with the PCs and Macs running Mac OS 9.1,but all machines under MacOS 9.2 (Power Mac G4 733 MHz) make me crazy:

They are correctly receiving IP addresses from the DHCP servers (I can ping this machines with the correct IP addresses), but the machines are requesting and additional IP address ( or, out of the range of the DHCP. The consequence is hundreds of NACK's from the DHCP.

Apple Switzerland says that there is no know bug with Ethernet or Open Transport 2.77 in MacOS 9.2.

September 7, 2001
Darren Lee

After reading from the posting of Daniel Nicole in your website, I have noticed I have the same situation. I recently purchased some new Power Mac G4 733Mhz with OS 9.2. My NT Server now chucks out large DHCP NACK errors every few hours with the Mac machines requesting additional IP addresses, although the Mac machines still work well.

September 12, 2001
Randal Bahner:

I've experienced a similar problem when I connected my new G4/867 to my small LAN.

I previously had two G3's and a Windows 98 machine receiving their IP addresses from a Linksys cable/dsl rounter in dynamic DHCP mode. Also connected we a couple of ethernet printers and a Linksys hub. The network ran flawlessly. 

I connected a new G4/867 w. 9.2 and I have problems. I get strange IP addresses (like the and for some reason the G3's and the G4 won't respond to the DHCP server (rounter/switch) 

The router/switch is new and works fine. I suspected a hub on the network, so replaced it with a new switch and so far so good. But I found it strange that this problem seemed to crop up only after I connected the G4 to my original network. 

September 12, 2001
Shaun Wolfosn is also using Linksys router hardware:

Ever since installing 9.2 on my G4 Powerbook connected to a linksystems router w/ tcp/ip set to DHCP my computer freezes when waking from sleep. I have changed to a static IP address and it seems more stable. 

Can't connect to my AT&T toshiba cable modem without a router. Spent hours on the phone with AT&T and Apple and have had a few tech out at the house with no luck...

September 12, 2001
Ibrahim Dajani sees the problem at home but not at work:

I have not seen this problem at work. However, I have a home network with a Cube 450, an iMac 266, Beige G3, a Power Book G3/233 Wallstreet II and a home-made Athalon 700 PC all connected to the a 10 BaseT Hub networked it to the DHCP network of my cable modem provider. The Cube is running Mac OS 10.04 and 9.2.1 and DHCP does NOT work with it in either OS's. Luckily, the beige G3 with 9.2.1 and the iMac running 9.1 both pick up an IP address easily. The only way I can get the Cube to work with this set up is to MANUALLY enter all the relevant IP address info copied from the other two Macs. The Power Book G3 with 9.1 picks up an IP address through DHCP only half of the time. And it will work for a while then drop the IP address altogether. The manual method does NOT seem to work properly with it either. There was never an issue with the PC with Windows ME getting in on the network. p.s the " IP address ( or" behavior I've seen happen over and over on both the Wallstreet and the Cube.

September 20, 2001
Bryce Steiner is having this problem with Mac OS 9.2.1, which sounds similar to this DHCP problem we've been reporting:

I just upgraded a Mac G3 to OS 9.2.1 from 9.1. I have a problem that I haven't had before. The Mac will disconnect from the Server and the shares will disappear with an AppleShare Server Message that says "the File Server's connection has unexpectedly closed down (date)" I thought at first my Windows 2000 server went down, but it didn't and the other Macs that I have kept the shares just fine. OS 9.2.1 is the only one with the problem.

Problem with @HOME:

September 12, 2001
Peter Mitchell is using a cable modem:

I may have a similar problem. I connect to my ISP ( with my G4 Powerbook and encounter many more bad IP addresses since upgrading to Mac OS 9.2. 

Occasionally I get as an address. Other times an address starting with 146.x.x.x is assigned and this is also invalid even though I can ping it.  

My normal address should star with 24.64.x.x

The only way around this problem is to power down the computer and cable modem, disconnect the cable ground the cable then connect and power up all systems. It is a very frustrating procedure since it occurs about 30 percent of the time when I am connecting.

Workaround for @HOME access:

September 14, 2001
Jamie Anderson

I, too, have been experiencing a more frequent loss of connectivity to @Home recently. I have been blaming @Home and Code Red, though. I hadn't attributed the problems to 9.2. I don't go through the whole reboot procedure that your reader Peter Mitchell describes, however. I go to the TCP/IP control panel and in the options window available while in the advanced user setting I disable TCP/IP, close the control panel saving the changes, and then reopen the control panel and reactivate TCP/IP (and also uncheck the 'load only when needed' option). That usually refinds my @Home 24.x.x.x IP.

Suggestions and workarounds

September 13, 2001
Jack Jackson has a suggestion:

I would suggest to your readers having problems with networking in Mac OS 9.2.1 that they move their "Open Transport Preferences" and "TCP/IP Preferences" files from the Preferences folder to the trash then restart and reapply their network settings. Several people have noted that this procedure cured their strange network problems after updating to 9.2.

September 13, 2001
Bhavesh Patel of the Mac Driver Museum gave up and uses static addressing:

My iMac has the same DHCP problem after upgrading from 9.1 to 9.2.1. My DHCP server is an SMC Barricade cable/dsl router. DHCP works fine with my PC's running 2000, 98 and Macs running 8.6, 9.1.

With 9.2.1 my iMac will get an IP address but stops network traffic after about 10-15 minutes. If I go to the TCP/IP control panel and change my profile, which forces a DHCP request, the iMac obtains another address and functions again for a while.

I've since switched to static addressing and haven't had any further problems. Seems like something broke in Apple's DHCP client implementation.

September 13, 2001
Glenn Henshaw has a workaround:

I saw the 0.0.1.x address today. I did it to myself by asking for a DHCP address while TCP/IP was set up for PPP.

I use IPNetMonitor from Sustainable Softworks to renew the address. It's more reliable than playing with the TCP control panel.

September 13, 2001
Shawn Post also has a workaround:

I get strange IP addresses (like the and for some reason the G3's and the G4 won't respond to the DHCP server (router/switch)

I had the above problem occasionally with 9.1. I haven't actually had this problem with 9.2 yet but with 9.1 if I take the TCP/IP control panel and change it to something other than DHCP save this setting and open the Chooser and try to connect to a TCP/IP only server. After this change TCP/IP back to DHCP and the problem goes away.

Occasionally this is repeated several times to get it to work.

September 13, 2001
Graeme Bennett (Editor of the Mac Buyers Guide):

We have also been experiencing this DHCP problem. Strangely, we noticed it Sept. 8 and only affects our Mac OS X installation. We're wondering if it could possibly be related to the Unix clock rollover.

We've been reading a growing number of reports of problems accessing DHCP information from within Mac OS X and the problem has suddenly begun affecting our (ADSL) Internet connection in Mac OS X. Mac OS 9.1 on the same machine works fine, and the settings are identical under OS X. For some reason, though, Mac OS X can't seem to negotiate DHCP settings successfully, and can't access external domain names. (Our internal intranet hosts still work.) iDisk volumes still mount, and we can still ping hosts, so we know that TCP/IP is still working. As noted in your report, our Windows machines on the same hub all work fine. It's all quite mysterious.

[NOTE: We have a suggested workaround for the problem on OS X on our Mac OS X Special Report page.]

September 24, 2001
Howard Modell

This is a problem I and others with Macs see at work. Our company's network is Windows NT 4 based (though moving towards Win2K). Ever since upgrading to 9.1 (and it is not fixed with 9.2.1), DHCP seems to be "broken". All 9.x Macs demonstrate the problem.

Basically, if TCP is switched to DHCP, the Mac goes into a "freeze cycle", repeatedly reporting bogus ˆIP's (beginning 169.x) with the same IP given for both machineIP and gateway/router, and a subnet mask of The Mac freezes for 30 seconds, provides a bad IP, allows a few seconds to do something, then cycles, fetching another bad IP.

I read on one of Apple's BB that the problem might be that NT's DHCP server is returning a badly formed packet (missing an endbyte) and the OT software is rejecting it and trying again. The same someone said that using BOOTP worked for him, and so it does .. in those cases where there is a BOOTP server available.

OS 9.1/9.2.1 disconnecting from AFP servers (TC/IP connections only)

Dozens of readers have reported this problem, which appears to be caused by the Ethernet drivers of Mac OS 9.1-9.2.1. The problem occurs with TCP/IP connections, not AppleTalk. To fix the problem, Apple released Apple Ethernet Update 2.0 for Mac OS 9.2.1 on October 16. From the readme file:

The Apple Ethernet Update 2.0 consists of version 2.4.3 of the Apple Ethernet extension. This improves AppleShare connections in high-traffic network environments. When you use certain Mac OS 9 applications while connected to AppleShare volumes, disconnections can occur. You may see "TickleTimeout" disconnect messages in the Mac OS X Server 10 Apple File Service access log. The Apple Ethernet Extension 2.4.3 prevents these disconnections from occurring.

This article is divided into four sections:

Please note that if you have a Windows NT/2000 server, you may be experience the mismatch duplex setting problem described on our Windows Servers Tips page.

Reports of the problem

October 4, 2001
Bryan Schappel

Since the release of Mac OS 9.1 (and up) we've been seeing problems with the Macs staying connected to a Windows 2000 server. During file copy or printing operations a Mac user will get an alert that the server has shutdown, which is not the case. The Macs are connecting to the 2000 box using SFM and TCP/IP. I've seen this happen regardless of the service pack on W2K.

The Macs all have static IP's. File sharing between Macs is not allowed. This is only seen with the Win server as Linux servers do not have this problem.

October 5, 2001
Bryce Steiner describes the general problem:

I just upgraded a Mac G3 to OS 9.2.1 from 9.1. I have a problem that I haven't had before. The Mac will disconnect from the Server and the shares will disappear with an AppleShare Server Message that says "the File Server's connection has unexpectedly closed down (date)" I thought at first my Windows 2000 server went down, but it didn't and the other Macs that I have kept the shares just fine. OS 9.2.1 is the only one with the problem. All the IP addresses are static.

October 5, 2001
Greg Volger

We have numerous iMacs running 9.1 that are being dropped from the Win 2000 server (SP2). This is running havoc at our school - students cannot complete their work. Students seem to lose connection when they are doing a file transfer. The Event viewer gives the error: 12061.

October 5, 2001
Daniel Hoffman

We've been seeing it off and on for weeks now. Primarily the servers drop off while printing from Quark Xpress 4.11 to our Splash RAS. Usually these Quark files have hi-res art in them, but not always. We've also seen it opening .eps and .psd files in Photoshop 6.0.1, again, usually hi-res (large) files, but not always. Most of our Macs are 9.1, but a couple are 9.2.1; all are DHCP and connect using TCP/IP under the Microsoft User Authentication Module (UAM); printing is done with Adobe's PS driver.

8.7.2 via AppleTalk. All our servers are Win 2K, SP2. The same problematic files will function (open, print, etc.) flawlessly from the user's desktop.

In my testing I have pretty much ruled out:

  • File/folder permissions issues
  • 3rd party Quark Xtensions
  • 3rd party Photoshop Plugins
  • Mac extensions conflicts
  • "Load TCP/IP as needed" setting in TCP/IP control panel
  • DHCP vs. Static IP issues

Unique elements of our environment are:

  • Font Reserve Server 1.0.1
  • Cumulus Workgroup Server 5.0.10
  • OTG DiskXtender/MediaStor digital asset management system running a JVC DVD-Ram jukebox

October 5, 2001
Bob Heeth also sees the problem with ExtremeZ-IP running on Windows NT:

You posted today a problem regarding disconnects of Mac 9.1 clients from Windows 2000 servers. We have also been experiencing this with Windows 2000 as well as Windows NT running Group Logic ExtremeZ-IP software.

October 15, 2001
Drew Robertson is getting the 12061 error previously reported recently when he's disconnected:

We are getting Error 12061 on the Windows 2000 Server when Macs get disconnected from our Windows 2000 Mac Volumes. We are also getting Error -5,006 on the Mac side when trying to delete, move, or update files. Are the two problems related?

I have posted a this question on some newsgroups and received acknowledgments that others are getting the -5006 error. No one has posted a reason and Apple and Microsoft are no help.

Last year (February 7, 2000), we also had a report of the -5006 error when deleting trash. We don't see any relation between the two at this point.

Note: there are also reports of this problem on our Windows 2000 report page.

Explanations of the cause of the problem

October 5, 2001
Adam Goldsmith says Apple points to the drivers:

Evidentially this is a known bug in the built-in drivers when using 9.1 and later. I will find out the internal Apple bug number, but Apple's recommendation is to use a 3rd party NIC. The dropping occurs with all sorts of servers, not just NT-based.

October 8, 2001
Jeff Pollard

I have something to add to the ongoing discussion about Macs dropping off of NT servers while processing large Quark and Photoshop file:

We're experiencing this on a Windows 2000 server running ExtremeZ-IP. Most Mac clients are 9.1 on Titanium G4s and Dual 533 towers. We've been experiencing this problem for MONTHS and have been trying to convince Group Logic that the problem exists. They finally recognized the problem earlier this week and wrote:

Group Logic has been investigating reports of this problem since Mac OS 9.1 shipped. Group Logic has performed extensive analysis of the problem, and has, with Apple, determined that the cause is due to problems in the Ethernet driver in recent versions of the Mac OS. Specifically, Apple's 2.4.1 and 2.4.2 drivers exhibit this behavior. According to Apple engineers, this is due to the way these versions of the Ethernet driver (Apple Enet extension) allocate memory. Group Logic has reports that this problem affects other AFP/TCP servers as well, including Apple's own AppleShare IP server

We have begun experimenting with switching out the Apple Enet extensions mentioned above with a previous version (2.3). The older extension doesn't seem to have any ill effects on the system, but it's too soon to tell if this has (at least temporarily) solved our problem.

Group Logic sent us a lengthy and detailed report about the problem:

Since Mac OS 9.1 shipped, Group Logic has received repeated reports from users of its ExtremeZ-IP product concerning Macintosh clients becoming unexpectedly disconnected from Windows servers. This seems to happen much more frequently with Mac OS 9.1 and 9.2 on newer G4 systems, particularly when users open or print QuarkXPress documents or Photoshop documents located on the server. Group Logic has reports that this problem affects other AFP/TCP servers as well, including Apple's own AppleShare IP server.

As is our policy, we took these reports seriously and immediately began to research the problem and potential solutions. This effort continued for months, involved testing a number of proposed solutions both internally and with the help of our customers, and culminated with the successful testing of the solution described below. We are now waiting on Apple to release the Ethernet driver which resolves the problem.

This problem is unrelated to the use of ExtremeZ-IP or other third-party products. Group Logic has determined that problems in the Ethernet driver in recent versions of the Mac OS are causing the disconnects. Specifically, Apple's 2.4.1 and 2.4.2 drivers exhibit this behavior. According to Apple engineers, this is due to the way these versions of the Ethernet driver allocate memory.

Apple's internal tracking number for this issue is 2705579. Inquiries about this problem may be directed to appropriate support contacts at Apple, or to other contacts that customers may have at Apple.

In the meantime, as a workaround, Group Logic has encouraged its customers to copy documents from the server to the local hard drive before editing them, then copy them back to the server after working with them.

Alternatively, the problem may be alleviated by using a third-party Ethernet card rather than the built-in Ethernet port.

Group Logic's technical analysis of the problem is as follows:

The Mac OS client is issuing a read (AFPRead) request to the server, and the server is indeed sending the requested data. However, after receiving a portion of the data, the Mac OS client stops receiving data appropriately and "hangs" for a period of 20 seconds or more, refusing to acknowledge data from the server and sometimes refusing to give any indication to the network that it is still alive. Such behavior, with no other traffic on the local network, is not consistent with normal TCP/IP networking.

Under normal circumstances, during this pause, the TCP/IP stack of the server operating system aborts the connection with the client after resending the data a specific number of times; when the Macintosh finally responds later, the connection has been reset and the Mac reports a disconnect to the user. Group Logic has also tested modifications on the server side to increase the number of retransmissions, but in this situation, the Macintosh still refuses to accept data and eventually stops and shuts down the connection on its own.

October 15, 2001
Sean McGown agrees with some of previous reports that QuarkXpress has a role to play in this issue:

I've observed this behavior during printing, collect for output, etc. since 9.0.4. QuarkXpress is the only application I've experienced this with. I'm almost sure it's a Quark thing. Quark also refuses to let go of linked files on W2k servers and CDROMs forcing you to quit Quark to unmount the volumes.

My personal opinion is that QuarkXpress also has terrible problems with file locking and unlocking. On numerous occasions I've been unable to edit a linked file (a picture in Photoshop, an Illustrator file, etc.) when the Quark document was open. Likewise, I've had many occasions when a file was opened off a CD to view, even after closing the document, I couldn't unmount the CD without completely quitting Quark.

Suggestions for workarounds

Back-grading Enet extensions

October 8, 2001
Jeff Pollard

We have begun experimenting with switching out the Apple Enet extensions mentioned above with a previous version (2.3). The older extension doesn't seem to have any ill effects on the system, but it's too soon to tell if this has (at least temporarily) solved our problem.

October 15, 2001
Bryce Steiner

I haven't seen the problems related specifically related to Quark, but in regular operating anything it happens. I replaced the Apple Enet driver with the version from OS 8.6. It seems to have fixed the problem. I no longer get disconnected and it seems to be a little faster.

Trashing prefs and zapping PRAM

October 10, 2001
Rob Jones suggests:

I've had this problem since the release of 9.1.

I found a potential solution on Apples forums. Does not appear to care what type of server you have. Here is the thread. Read Brian Birch's solution.

What I did specifically:

  • Rebooted the system.
  • Moved these item from the Preferences folder to the trash and deleted them (Apple Share Prep, AppleTalk, File sharing, TCP/IP).
  • Zapped the PRAM with TechToolLite 3.0.1 (which automatically reboots the computer).
  • After the reboot all I had to reset was my TimeZone and TCP/IT settings.
  • Did all of these steps yesterday on two computers that were getting dropped on regular basis.

No drops so far.

October 15, 2001
Andy Halley

This morning I installed an Asante Fast Ethernet PCI Card and disabled Apple's Ethernet drivers and still had the same problem. So I tried Rob Jones' suggestion: Moved these item from the Preferences folder to the trash and deleted them (Apple Share Prep, AppleTalk, File sharing, TCP/IP). Zapped the PRAM with TechToolLite 3.0.1 (which automatically reboots the computer)

I am pleased to report that my two G4's are running just fine and hopefully (knock on wood) my problems are solved. I will continue to monitor performance over the next several days to ensure the success of the fix.

October 15, 2001
However, Ben Roche says that this worked only temporarily:

[Trashing preference files, and resetting parameter RAM] seems to work but only for a few days but comes back. I fine that if I do a copy first I don't get the problem. Most of our work is pictures (10Mb-900Mb), we are mainly opening just the picture files on our Macs over the network.

Other suggested workarounds

October 5, 2001
Tim Moore has seen the problem with the Helios AFP server for Unix, and offers a suggestion:

Here, we've experienced similar issues with the Helios EtherShare software, with various incarnations of OS 9 Macs connecting via TCP/IP.

One approach we've had to take to stop the connection from disconnecting is to hold down option-command when connecting in the Chooser, in order to force the connection to occur over AppleTalk and not TCP.

(It's always a good idea to do a Get Info on the mounted icon, just to make sure you've actually succeeded in making an AppleTalk connection).

October 10, 2001
Andy Halley

A friend of mine, Scott Chaffee, gave me this suggestion- Load Acrobat Distiller at startup and set up a "Watched Folder" on the server that is disconnecting-let Distiller run in the background. Distiller keeps monitoring the folder on the server thereby keeping a constant connection so that it cannot disconnect due to idle time.

October 12
Ben Roche

The company I work for has also been having problems with disconnects from our AFP server. I have tried the trashing of Apple Share prep, AppleTalk etc. Prefs, with no success. I look after about 20 Macs and the following workaround seems to work for them all. If I get the operator to copy a file off the server (small around 20 Mb) before he opens the file he need to work on, the problem doesn't seem to happen. I also noticed the Mac with 3rd party 10/100 NIC don't suffer from the problem.

October 15
Glenn Barker suggests a different fix:

Many of your readers may find that their reported drops from Win 2000 servers is down to auto-negotiation of network speed between Ethernet cards. I experienced similar problems with my Titanium G4 running OS 9.1 and our Win 2000 servers, but ONLY after the local servers were switched from 10 Mbps onto 100 Mbps network ports.

The network service to my G4 however remained through a 10 Mbps port. The servers NICs were set to auto- negotiate speeds, but this obviously wasn't happening. Setting the Win 2000 server NICs manually to 100 Mbps Full Duplex cured the problem .

Barker is correct about duplex mismatching. In fact, this is known problem and solution that we have been reporting for some time. (See our Windows Servers Tips page.) However, as many readers have reported Macs disconnecting from many non-Windows AFP file servers, we believe the OS 9.1/9.2.1 problem is a separate issue.

October 16, 2001
Christoph Sahm describes a method to force AppleTalk connections:

We resolved the problem with our Windows 2000 server by reverting to AppleTalk.Do do this permanently, we used the "AppleShare Client Setup" application. You cannot disable TCP/IP directly, but you can change the port number to a bogus port and set all TCP timeouts to 0, which we did.

Result: AFP always connects via AppleTalk, which does not seem to suffer from this specific problem.

Comments on the Fix (Apple Ethernet Update 2)

October 17, 2001 -- Yesterday, Apple posted Apple Ethernet Update 2.0 to fix the problem of Mac OS 9.1 and 9.2.1 disconnecting from AFP file servers. From the readme file:

The Apple Ethernet Update 2.0 consists of version 2.4.3 of the Apple Ethernet extension. This improves AppleShare connections in high-traffic network environments. When you use certain Mac OS 9 applications while connected to AppleShare volumes, disconnections can occur. You may see "TickleTimeout" disconnect messages in the Mac OS X Server 10 Apple File Service access log. The Apple Ethernet Extension 2.4.3 prevents these disconnections from occurring.

MacWindows readers reportthat Apple Ethernet Update 2 does fix the problem on Mac OS 9.2.1. Ben Roche and Brad Allen reported that the upgrade works with Windows 2000 Server SP2. So did Robert Minch:

I installed the update to 18 production Macs running 9.2.1 and have seen no timeouts on the system log of our W2K server. Now we just have the usual random Quark and Outlook crashes. Looks like things are back to normal.

Daniel Hoffman said the new driver solves the issue of file servers dropping off the Mac when spooling large Quark print jobs. Jason Thomas reports that the update fixes the problem with NetWare:

I applied this patch to a dual processor G4 I use in my office. I have

been testing the NetWare Native File Access Pack on both NetWare 5.1 and NetWare 6...I applied the patch this morning, and logged into both a production NetWare 5.1 server and a NetWare 6 server. I kept the connections open with some folders open, and I even let the machine sleep. When I woke it back up, all seemed well, and I began some file copies. Everything worked as advertised, and I did not drop a connection at all.

However, he also sees the problem with Mac OS X 10.1:

We are still waiting on the 10.1 fix. Apparently, with 10.1, third party NICs do the trick. We were experimenting today with our NetWare 6 box, and one of our students used another G4 running 10.1 with an Asante NIC to connect. He was able to connect, create folders in a share, and dump a 500+ MB disk image up to the server. There were no disconnects and there were no long delays when building folder lists. According to an informed source, Apple knows this to be a problem and are working on a fix (but I heard that information third-hand).

This is the first we've heard of the problem with Mac OS X 10.1.

The installer doesn't run in Mac OS 9.1, but Greg Volger tried unsuccessful to drag the extensions there:

I installed the Apple Ethernet 2.4.3 extensions on my OS 9.1 machines and still have the same problem. My NT server Event Viewer gives the error 12061.

December 28, 2001
Joerg Erdei

Installing Apple Ethernet 2.4.3 from Apple Ethernet Update 2.0 did solve the server unexpected disconnect problem on every OS 9.1 Mac I tested.

Long logon times

This is a known problem easily solved by deleting aliases of the server in System folder:Server on the Mac. For more information, see our Windows 2000 special report page.

| Top of this Mac OS 9 Special Report Page |

Other MacWindows Departments

| Product Solutions | News Archives | Site Map |
MacWindows Home |

Serving the cross-platform community since November 15, 1997.
This site created and maintained by
Copyright 1999-2001 John Rizzo. All rights reserved.