This document contains an overview and download information for Apple's Patch 3 for NeXTSTEP Release 3.3 and EOF 1.1. Apple recommends that all users of NeXTSTEP 3.3 install this patch set. Users of NeXTSTEP versions prior to release 3.3 should register for and install an upgrade from Apple to NeXTSTEP 3.3 before installing this patch. For more information, please see the Software Registration web page .

NeXTSTEP 3.3 Patch 3 supercedes NeXTSTEP 3.3 Patch 2, released in July of 1999. If you have already installed Patch 1 or 2 on your system, you can install this patch over your existing installation. If you have not installed Patch 1 or 2, you do not need to.

This patch does not address EOF 1.1. EOF 1.1 users should see TIL article 70084 for an explanation of some manual steps they can take to avoid some Year 2000 issues.

The NeXTSTEP Current Patch List, TIL article 70038 , contains information on all available patches and workarounds for all versions of NeXTSTEP, including EOF patches. Please read this document if you're not sure which patches you need on your system.

In addition, there is a NeXTSTEP 3.3 Patch 2 Developer package, NS33DeveloperPatch2.tar . This is a multi-architecture installer package, and should be installed on systems that have NeXTSTEP 3.3 Developer installed. IMPORTANT: If you are installing the Developer patch, please read TIL article 70084 to learn how to manually correct some issues with the developer components of EOF 1.1.

If you use Enterprise Objects Framework on your system, it should be installed before you install NeXTSTEP 3.3 Patch 3. Patch 3 includes fixes in system components that were originally installed by either EOF or the Foundation User Patch. The NeXTSTEP and EOF software packages should be installed in the following order:

• NeXTSTEP 3.3 User
• NeXTSTEP 3.3 Developer (optional)
• EOF 1.1 User (optional)
• EOF 1.1 Developer (optional)
• NeXTSTEP 3.3 Patch 3 User package
• NeXTSTEP 3.3 Patch 2 Developer package (optional)

After download, you may need to decompress the file with the command (example):

tar xf NS33CISCUserPatch3.tar

This will unpack the single 'tar' file used for download into the .pkg format compound document used by the NeXTSTEP installer. Your web browser or FTP client may perform this step for you.

To install NeXTSTEP 3.3 Patch 3, perform the following steps:

1. Log in as root on your NeXTSTEP system. If you're not sure how to log in as root, see your system administrator.

2. Double-click on the NS33CISCUserPatch3.pkg (or NS33RISCUserPatch3.pkg ) file.

3. Click the Install button in the Installer package window. An Install Package panel will open.

4. Click 'Install' in the Install Package panel and, when prompted for confirmation, click OK to proceed. The Installer window displays information about the progress of the installation, which may take several minutes.

5. If you do not need to install the Developer patch, skip to step 8 to complete the installation. To install NeXTSTEP 3.3 Developer Patch 2, double-click on the NS33DeveloperPatch2.pkg file.

6. Click the Install button in the Installer package window. An Install Package panel will open.

7. Click 'Install' in the Install Package panel and, when prompted for confirmation, click OK to proceed. The Installer window displays information about the progress of the installation, which may take several minutes.

8. When the installation completes, the system must be rebooted. Log out and use the reboot button on the login panel.

Corrected in NeXTSTEP 3.3 Patch 3

'gnutar' hangs on recursive links.
Apple reference # 2365132

ISSUE:
The version of 'gnutar' shipped with NeXTSTEP 3.3 Patch 2 CISC and RISC is based on GNU tar-1.12 and expects a later version of lstat than that found on NeXTSTEP. Some symbol names changed in the newer version of lstat. If these newer symbol names are not found, 'stat' is used instead of 'lstat' and 'gnutar' hangs on recursive links.

RESOLUTION:
'gnutar' has been modified to work correctly with both older and newer versions of lstat.

'at' schedules jobs incorrectly when no date is specified
Apple reference # 2358294

ISSUE:
The 'at' command in NeXTSTEP 3.3 Patch 2 for CISC and RISC scheduled jobs incorrectly when no date was specified.

RESOLUTION:

The version of 'at included in this patch schedules these jobs correctly.

Missing hard link to /usr/ucb/w
Apple reference # 2351777

ISSUE:
/usr/ucb/uptime, normally a hard link to /usr/ucb/w, was no longer linked after NeXTSTEP 3.3 patch 2 was installed.

RESOLUTION:
This patch restores this missing link.

Missing hard link to /bin/sh
Apple reference # 2351777

ISSUE:
/bin/jsh, normally a hard link to /bin/sh, was no longer linked after NeXTSTEP 3.3 patch 2 was installed.

RESOLUTION:
This patch restores this missing link.

Corrected in NeXTSTEP 3.3 Developer Patch 2

Indexing Kit example used two-digit date field
Apple Reference #2332090, 2331940

ISSUE:
The example application for the Indexing Kit used a two-digit year date entry field, which caused columns to be incorrectly sorted by date.

RESOLUTION:
The example application now uses a four-digit year for data entry and for sorting.

DBKit date formatter example used two-digit year format
Apple Reference #2337035, 2337355

ISSUE:
The date formatter example for DBKit only accepted dates of the form MM/DD/YY.

RESOLUTION:
The example now accepts dates of the form MM/DD/YYYY.

Corrected in NeXTSTEP 3.3 Patch 2

'at' command executed jobs queued after 31 Dec. 1999 before scheduled run date
Apple Reference #2324143, 2325511

ISSUE:
The name of the spool file which the 'at' command created for storing a job encoded the job's run date using a two-digit year date format. This caused 'atrun' to execute jobs queued for dates after 31 Dec. 1999 before they should be run.

RESOLUTION:
'at' now creates spool filenames that use four-digit years.


'atq' command formatted dates incorrectly
Apple Reference #2324153, 2325512

ISSUE:
The 'atq' command used the strings '19%2d' or '19%d' for formatting the last run date for the 'at' queue and the date at which the individual entries should be run.

RESOLUTION:
This command now formats the date with the correct century. To handle legacy filenames, two-digit dates less than '69' and three-digit dates are interpreted as being in the 21st century.

Leap year calculation in 'at' command didn't include 400-year rule
Apple Reference #2324154, 2325513

ISSUE:
The leap year calculation in the 'at' command failed to take into account the 400-year rule, resulting in incorrect behavior after leap day in the year 2000.

RESOLUTION:
This calculation has been corrected.

'atq' leap year calculation didn't include 400-year rule
Apple Reference #2324158, 2325514

ISSUE:
The leap year calculation in the 'atq' command failed to take into account the 400-year rule, resulting in incorrect behavior after leap day in the year 2000.

RESOLUTION:
This calculation is corrected.

'atrun' command assumed two-digit year for spooled jobs
Apple Reference #2324160, 2325515

ISSUE:
The 'atrun' command assumed that spooled jobs were named with a two-digit year format.

RESOLUTION:
'atrun' now handles job filenames with two-, three-, and four-digit years correctly.

RCS did not work correctly after 1999
Apple Reference #2327725, 2328459

ISSUE:
The RCS version shipped with NeXTSTEP 3.3 did not work correctly after 1999.

RESOLUTION:
This patch upgrades to RCS version 5.7, which handles dates past 1999. Refer to the RCS documentation for information on additional changes, features and bug fixes in this version of RCS.

' /bin/date' command didn't allow dates later than 1999 to be set
Apple reference #2328124, 2327723

ISSUE:
The '/bin/date' command didn't allow the system date to be set to any year past 1999. A secondary problem resulting from this error was that users of the Preferences application were unable to set a date later than 1999.

RESOLUTION:
The 'date' command now correctly handles two-, three-, and four-digit years for dates in the valid UNIX range (1 Jan 1970 00:00:00 - 31 Dec 2037 23:59:59). Two-digit years from 70-99 are interpreted as 1970-1999; two-digit years from 00-37 are interpreted as 2000-2037. Three-digit years from 070-099 are interpreted as 1970-1999; three-digit years from 100-137 are interpreted as 2000-2037.

'gnutar' command didn't accept dates later than 1999
Apple Reference #2328449, 2327724

ISSUE:
The 'gnutar' command has an option to only write files newer than a given date, but version 1.11.2, the version shipped with NeXTSTEP 3.3, didn't accept dates past the end of 1999, even using four-digit years.

RESOLUTION:
'gnutar' has been updated to version 1.12, which accepts dates after 1999.

'zsh' command could have displayed incorrect date in command prompt after 1999
Apple Reference #2331360, 2332042

ISSUE:
The 'zsh' command could be configured to display the date in the command prompt. This date display did not function correctly after 1999.

RESOLUTION:
This problem is corrected.

NSCalendarDate's two-digit year format returned three-digit years after 1999
Apple Reference #2331365, 2331975

ISSUE:
NSCalendarDate's +descriptionWithCalendarFormat: method's two-digit year format (%y) returned three-digit years after 1999. For example, '2000' was displayed as '100,' rather than '00'.

RESOLUTION:
This method now returns an appropriate two-digit year when the %y format is employed. Users are strongly cautioned that two-digit year values are inherently ambiguous and can result in serious software errors.

'enscript' command displays incorrect year in file timestamp after 1999
Apple Reference #2331367, 2331658

ISSUE:
The 'enscript' command has an option that printed a file's timestamp as a page header. This header displayed an incorrect year after 1999.

RESOLUTION:
This problem is corrected.

'nroff' and 'troff' macros displayed two-digit dates that were incorrect after 1999
Apple Reference #2331436, 2331978

ISSUE:
The macros used by 'nroff' and 'troff' automatically generated certain date values which displayed two-digit years, and which were incorrect after 1999.

RESOLUTION:
These macros now display correct four-digit years both before and after 2000 for automatically generated dates.

NSCalendarDate calendar format methods interpreted all two-digit dates as 20th century
Apple Reference #2331983, 2332180

ISSUE:
NSCalendarDate's -dateWithString:calendarFormat: and -initWithString: calendarFormat: methods interpreted all two-digit dates as being in the 20th century; i.e., "00" was interpreted as "1900".

RESOLUTION:
These methods now follow the Microsoft Exceltm convention used in later versions of Foundation, where two-digit dates less than 30 are interpreted as 21st century dates (2000-2029) and two-digit dates 30 and greater are interpreted as 20th century dates (1930-1999). Users are strongly cautioned that two-digit year values are inherently ambiguous and can result in serious software errors.

Motorola DSP assembler output incorrect page header in 2000
Apple Reference #2331999, 2332113

ISSUE:
The Motorola 56K DSP assembler output an incorrect page header in year 2000.

RESOLUTION:
This problem is corrected.

Motorola DSP librarian output incorrect library file dates after 1999
Apple Reference #2332012, 2332136

ISSUE:
The Motorola 56K DSP librarian output incorrect dates in library file listings after 1999.

RESOLUTION:
This problem is corrected.

Motorola 56K DSP Linker output incorrect page header
Apple Reference #2333271, 2333840

ISSUE:
The Motorola 56K DSP Linker output an incorrect page header in year 2000.

RESOLUTION:
This problem is corrected.

'/usr/ucb/w' displayed year values later than 1999 incorrectly as three-digit values
Apple Reference #2334633, 2333834

ISSUE:
The '/usr/ucb/w' command displayed the year value in date stamps after 1999 as three digits, i.e., the year 2000 displayed as '100' rather than '00'. Although the use of a two-digit year format is not preferred practice, changing the date format to use four-digit years could cause errors in programs that call the 'w' command.

RESOLUTION:
'/usr/ucb/w' now outputs two-digit years after 1999. It is the responsibility of the calling program to resolve the ambiguity of the two-digit year values in w's output.

Generated date for text pasted into new mail message incorrect for dates after 1999
Apple Reference #2334672, 2333902

ISSUE:
When creating a new message in a mailbox by pasting text into the mailbox, the generated date for the message was not correct for dates after 1999.

RESOLUTION:
This problem is corrected.

FTP daemon sent wrong file modification time for files created or modified after 1999
Apple Reference #2336094, 2336098

ISSUE:
The FTP daemon's 'MDTM' command sent the wrong modification time in reply to files created/modified past 1999. For example, the year 2000 was formatted as 19100.

RESOLUTION:
A correcting factor allows the 'MDTM' command to correctly format dates after 1999.

Fax software date stamps used two-digit year format
Apple Reference #2337034, 2337450

ISSUE:
The date stamps written by the fax software used a two-digit year format, and the aging code which detected and removed old fax log files failed when the year changed from '99' to '00'.

RESOLUTION:
To avoid causing problems with any software that might parse the fax log date stamps, the two-digit year format is still used, but the aging algorithm is modified to behave correctly both before and after the year 2000.

Verbose file listing from the 'tp' command printed incorrect two-digit dates after 1999
Apple Reference #2337845, 2338047

ISSUE:
The verbose file listing from the 'tp' command printed two-digit dates that were incorrect after 1999.

RESOLUTION:
The 'tp' command is now modified to output a correct four-digit date both before and after 1999.

Active.mbox had two-digit year in the Date header
Apple Reference #2339224, 2338436

ISSUE:
The welcome email message from Steve Jobs had a two-digit year in the header.

RESOLUTION:
This message now displays a four-digit year.

'Mail.app' read receipt date parsing could have failed for two-digit years less than 70
Apple Reference #2339301, 2338432

ISSUE:
The 'Mail.app' date parsing for read receipts could have failed for two-digit years less than 70.

RESOLUTION:
The 'Mail.app' date parsing is now modified to accept two-digit years less than 70 and treat them as within the 21st century. Two-digit years from 70-99 are interpreted as within the 20th century. This problem is very similar to Apple reference 2344011/2338435, also corrected in this patch. Additionally, three-digit years are interpreted as an offset from the year 1900, so year '100' is taken to be 2000.

Invalid date arguments could crash Sybase 4.6
Apple Reference #2340499, 2339379

ISSUE:
In the Sybase 4.6 version that shipped with NeXTSTEP 3.3, lack of error-checking code could cause an array underflow when certain invalid date values are passed. This error causes Sybase's Year 2000 compliance test suite to crash.

RESOLUTION:
More complete error checking now detects the problem date values and raises an appropriate Sybase exception.

'Mail.app' read receipt date parsing could have failed for two-digit years less than 70
Apple reference #2344011, 2338435

ISSUE:
The 'Mail.app' date parsing for read receipts could fail for two-digit years less than 70.

RESOLUTION:
'Mail.app' has been modified to accept two digit years less than 70 and treat them as 21st century years. Two-digit years from 70-99 are interpreted as 20th century. Additionally, three-digit years are interpreted as an offset from the year 1900, so year '100' is taken to be 2000. Note, however, that the date value being parsed is in the form of a literal string taken from the received mail's header (which is displayed with the message) and there is no way to modify this string to display the year as a four-digit value. If mail is received with a date in year '100', the value '100' is displayed as the year, but internally the year is evaluated as 2000.

' sendmail' date header used two-digit year format
Apple reference #2345707, 2345799

ISSUE:
The 'Date:' header line of mail messages created with the '/usr/ucb/mail' command showed the date and time of creation using a two-digit year format.

RESOLUTION:
The 'mail' command now writes a four-digit year in the 'Date:' header.

' /usr/bin/refer' command assumed all references had dates in 20th century
Apple reference #2345894, 2345940

ISSUE:
The 'nroff' and 'troff' preprocessor, '/usr/bin/refer,' discarded references with dates whose century was not '19' in certain circumstances.

RESOLUTION:
The 'refer' command now recognizes bibliographic references in any century.

' at' command sometimes scheduled jobs incorrectly after Feb 29 in leap years
Apple reference 2346578, 2346551

ISSUE:
The calculation in the 'at' command used to determine the day of the year that a job should execute didn't properly account for the additional day in leap years when the user entered the job in the year prior to a leap year. For example, if a user scheduled a job for March 2, 2000 in June of 1999, with the syntax 'at 8am Mar 2,' the 'at' command incorrectly scheduled the job for March 1, 2000.

RESOLUTION:
The day-of-year calculation used by 'at' for scheduling jobs in the next year is corrected to account properly for leap years

Year wasn't set correctly after 1999 in i386 and m68k real-time clock chips
Apple reference #2253936

ISSUE:
The year value wasn't stored correctly after 1999 in the RTC chip on i386 and m68k hardware. One symptom of this error was that users of the Preferences application were unable to set a date later than 1999. This issue only affected the CISC version of NeXTSTEP 3.3.

RESOLUTION:
This problem has been corrected.

NeXT-based 68HC68T1 clock chip doesn't store the century
Apple Reference #2339331

ISSUE:
The 68HC68T1 clock chip in NeXT computers didn't store the century of the year. This issue only affected the CISC version of NeXTSTEP 3.3.

RESOLUTION:
Since the clock chip uses the "every fourth year is a leap year" calculation, this won't cause any problems until 2100.

Hewlett-Packard real-time clock used a two-digit year
Apple Reference #2333833

ISSUE:
The Hewlett Packard real time clock used a two-digit year, and the code that set the real time clock date behaved improperly after 2000. This issue only affected the RISC version of NeXTSTEP 3.3.

RESOLUTION:
Two-digit years less than 70 are now interpreted as 21st century, while years greater than or equal to 70 are interpreted as 20th century.

Corrected in NeXTSTEP 3.3 Patch 1

HCRX & HCRX24 cards are not supported
Apple Reference #45838, 54418, 54461, 54462
The new Hyperdrive graphics cards (HCRX and HCRX24) are now supported. Note that although the HCRX card is only 8 bits deep, it can be run in "color-recovery" mode as a 24-bit device. If you are running the HCRX card as the console boot device in 8-bit color mode, turn off boot graphics in your configuration to obtain the proper color map.

MIDI driver doesn't load
Apple Reference #50481

This has been fixed.

HP getty panic
Apple Reference #52993
When an HP computer running NEXTSTEP Release 3.3 boots with the serial driver configured, a getty turned on for a serial port, and the modem connected and turned on, the system panics. This has been fixed.

HPPA 8-bit color problems
Apple Reference #54419
On HPPA machines, choosing 8-bit color leads to color glitches. 8-bit color modes had issues with bad color map entries. This has been fixed. Note, however, that a related bug (#54420) has not been fixed. This bug arises when you change the brightness on multi-headed HP 715'sPit causes color map glitches on 8-bit displays. The issue seems to occur only after power cycling and booting with boot graphics. Booting verbosely should avoid the issue.

gdb and floats
Apple Reference #24436
gdb does not interpret floating point numbers correctly when specified as message arguments. This has been fixed.

Miscellaneous gdb panics
Apple Reference #50727, 54401
gdb occasionally hangs or panics when used with certain applications. This has been fixed.

gdb's *step: command behaves like *next
Apple Reference #52634
*step: now steps into methods, instead of stepping over them.

Stack frames in gdb's browser are reversed.
Apple Reference #54968
Between NEXTSTEP Release 3.2 and Release 3.3 the top-to-bottom order in which stack frames are listed in the Edit/Browser tool were inadvertently reversed, so that the outermost function appeared at the bottom instead of the top. This was not done in an internally consistent way, so that if you clicked on the third stack frame from the bottom, for instance, Edit took you to the third one from the top. This has been fixed so that it works the way it did in NEXTSTEP 3.2.

Cached kmsgs not properly initialized
Apple Reference #51192
When using a cached kmsg, the ikm_delta field was not being initialized. This is especially important in the exception handing code when sending the exception message. Cached kmsgs are now properly initialized.

ipc hash leak
Apple Reference #54071
Certain procedures can cause the kernel to hang due to an ipc hash leak. This has been fixed.

Incorrect results from exp()
Apple Reference #54173, 54399
libc's exp() gives incorrect results on Intel-based computers. This has been fixed.

Memory leak in _openDefaults
Apple Reference #54226
_openDefaults can leak 1024 bytes per invocation. This has been fixed.

Control words and longjmp
Apple Reference #54674
longjmp did not preserve the FPU control word across fninit. This has been fixed.

Packet size negotiation logic is flawed
Apple Reference #54180
NetWare performs packet size negotiation during the server discovery process. This negotiation process is flawed. For example, suppose that the client station first sent its favorite packet size (1024 bytes for Ethernet, for example) to the server on the other side of a LAN switch. The server would then send back its favorite packet size (say, 4096 for FDDI) which the client simply accepted as the negotiated block sizePdespite the fact that this size is illegal for Ethernet. This issue arose because neither the server nor the client are aware of the existence of the LAN switch that is bridging the FDDI and Ethernet LANs. The patch causes the workstation to ignore negotiated packet sizes larger than what its immediate medium can support. This should be sufficient until such time as NeXT implements "burst mode" transfers.

Network socket `bind' fails to detect *address in use
Apple Reference #54216
A bug was introduced during the porting of Stanford's IP Multicast code that allowed multiple local clients to bind to the same IP address (that is, the code failed to detect that the address was in use). This patch corrects that error.

Various netinfo bugs
Apple Reference #36740, 39778, 49580, 49585, 49607, 49899, 50175, 51088, 51809, 51944, 53423
A number of bugs were fixed in netinfo. The following are some of the more notable bugs that were fixed:

• 39778: If you have a second account with a uid of 0, netinfo authentication can fail. If a netinfo domain had multiple users with the same UID, authentication for that UID would be unreliable.
• 49607: lookupd should number domains starting at 1. Minor change. When lookupd received a SIGUSR2 to log it's current connections, it numbered domains started at 0 rather than 1.
• 49899: Permission denied even when _writers is *. Directories with _writers * were only writable by root.
• 50175: nidomain must byte-swap master's address. This bug caused nidomain -c to fail to create clones on Intel-based computers. The master's IP address was byte-swapped, resulting in an incorrect and unusable database.
• 51088: Memory smasher in netinfod. This bug would cause random netinfo crashes. It was the result of ni_writeprop() freeing some memory twice.
• 51809: netinfod[PID]: tag test: can't get masters /machines/ip_address/I^AT*s^ directory. The netinfo clone start-up configuration checking routine had a couple of syslog messages that were missing an argument. If a clone was mis-configured, it would print a garbled error message.
• 51944: file name is freed, then used. A very rare bug that only occurred if a file system error occurred while the server was shutting down, and it got an error while writing the checksum file.
• 53423 netinfod shouldn't call ni_error() - localization calls getpwuid(). A rare bug that could cause netinfo to hang before printing an error message if it detected an internal error.

SimpleNetworkStarter messes up mail server configurations
Apple Reference #54245
This bug caused SimpleNetworkStarter to install its mail-server package every time it ran. The result was that the last computer that was configured using SimpleNetworkStarter would really be the mail server. Confusing information would be left behind on other computers, and mail would not be correctly configured. This has been fixed.

netinfo's clone self-check has RPC issues
Apple Reference #54920
This bug caused sporadic start-up issues on clone netinfo servers. The bug was caused by errors in the clone configuration self-check routines that ran at start-up time. These self checks have been disabled in this update.

localized Colors... menu item in Terminal
Apple Reference #49523
There was no Colors.. menu item in localized versions of Terminal. This has been fixed: the Colors command is now present in the localized versions of Terminal.

Various cosmetic fixes for localized text
Apple Reference #49525, 49559, 50876, 51668, 52463
Various cosmetic fixes were made to text localization:

• Raising the color panel from any application while you are working in a language other than English produces a *parse error: message in the console window (and the panel contains English text).
• The window title that is displayed while loading Preferences is in English, even when you are working in a language other than English.
• When working in French, Configure's Inspector.nib shows some English text.
• When working in French, some configuration text fields aren't wide enough to contain entire sentences.
• The Spanish version of Loginwindow's preferences panel was poorly formatted.
• Several of the localized Preferences, Configure, and SimpleNetworkStarter files were fixed to provide cleaner UI.

• The User Info confirmation panel does not display the path of the login shell when you are working in French.
• The Program Hooks pop-up menu has no valid labels in the Group Default Configuration panel when you are working in French.
• Some fields in the Create Bulk panel aren't properly localized.
• Clicking on the User Account login name format pop-up list after creating multiple users in a domain and then reading an input file containing user names causes UserManager to crash.
• This issue still exists when running UserManager in Swedish on Intel or NeXT architectures. As a workaround, run UserManager in another language.
• The Group menu doesn't work when working in German.

Cannot choose a language other than English when you create a new user account
Apple Reference #51223
New template files were added so that system administrators will be able to create new user accounts with certain localization defaults already set. If you are a system administrator and would like to use User Manager to create new user accounts with defaults localized for French, German, Italian, Spanish, or Swedish, you need to select all of the languages when you install the patch. This will ensure that all of the default files are available for your use in usr/template/languages. Note that this will also install other updated language files that are included on the patch. If you use Preferences to select another language that has not been previously installed from the original release software, these updated files would appear in that language while the rest of the UI files in a particular application would appear in the next language you have selected in Preferences which has been installed.

A related bug still exists, however: if you install NEXTSTEP Release 3.3 using one of the European languages and then create an English user account with UserManager, when the new user logs in Workspace will use the language that you chose during installation, instead of English. The user can work around the issue by simply choosing the proper language in Preferences and then logging out and logging back in again. Note that new user accounts are only affected in this way if English is chosen when creating the user account.

Shift-hyphen does not produce an underscore in UK keyboard mapping
Apple Reference #54171
The *alt: and *shift: keys were reversed in the UK keyboard mapping file. This has been fixed.

Fixed Pitch Font issues in non-English languages
Apple Reference #54228
Selecting Fixed Pitch Font in Font Preferences while working in a language other than English caused Preferences to crash. This has been fixed.

VM allocation in WindowServer
Apple Reference #54132
The WindowServer should use vm_allocate instead of malloc for backing storePcurrently, it almost never gives VM back to the operating system. This has been fixed.

Crash while displaying images
Apple Reference #54134, 54138
Certain images, displayed in certain graphics modes, can crash the WindowServer. This has been fixed.

12-bit window flushing delays
Apple Reference #54137
Flushing 12-bit windows on 24-bit displays takes longer than it should. This has been fixed.

cu and tip incorrectly set the UID
Apple Reference #51555, 51785
cu and tip incorrectly set the UID. This has been fixed.

SoftPC filename length
Apple Reference #51590
Use of DOS filenames greater than 31 characters in length causes issues in SoftPC. This has been fixed.

pbs and appkitServer launched with incorrect group permissions
Apple Reference #52531
pbs and appkitServer now launch with the correct group permissions.

CERT Advisory: sendmail vulnerabilities.
Apple Reference #52842, 56026
The sendmail security vulnerabilities described in CERT Advisory CA-95:05 have been fixed. Contact CERT for more details.

Services don't register in ProjectBuilder
Apple Reference #54217
None of the Services items were active in the version of ProjectBuilder supplied with NEXTSTEP Release 3.3. For instance, third-party source code control apps such as DevMan didn't function as advertised. This has been fixed.

Floppy operations don't work as intended
Apple Reference #54220
The floppy operations in workspace were broken. For instance, a floppy was not represented by the proper DOS, MAC, or NeXT floppy icon; instead, a folder icon was displayed. Or, after mounting a floppy (with Check for Disks), the disk was mounted but the Disk menu contained Check for Disks and Eject onlyPit was missing Initialize. These bugs have been fixed.

Internal error in rld
Apple Reference #54260
rld would sometimes get the internal error: *lookup_symbol() failed. This has been fixed.

Multiple devices in Add panel
Apple Reference #54428
Configure treats the last byte of the EISA id as a *don't care: byte. This fixes a issue where Configure would show multiple instances of some devices in the *Add Devices: panel.

Failure to read multiple backups on HPPA machines
Apple Reference #55452
Reading of multiple files/backups failed. Creation of multiple backups on the same tape was not a Issue, but only the first backup could be read on a HP platform.

THE INFORMATION IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. APPLE COMPUTER, INC. DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. MOREOVER, APPLE COMPUTER, INC. DOES NOT WARRANT OR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE USE OF THE INFORMATION CONTAINED HEREIN IN TERMS OF ITS CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. ANY STATEMENTS MADE TO YOU BY APPLE COMPUTER, INC. OR CONTAINED HEREIN IN THE COURSE OF PROVIDING YEAR 2000 RELATED FIXES, YEAR 2000 DIAGNOSTIC TOOLS, OR REMEDIATION SERVICES (IF ANY) ARE SUBJECT TO THE YEAR 2000 INFORMATION AND READINESS DISCLOSURE ACT (112 STAT. 2386). IN CASE OF A DISPUTE, THIS ACT MAY REDUCE YOUR LEGAL RIGHTS REGARDING THE USE OF ANY SUCH STATEMENTS, UNLESS OTHERWISE SPECIFIED BY YOUR CONTRACT OR TARIFF.