ftp.nice.ch/pub/next/system/patches/knownbugsin3.x.v11.1.rtf

This is knownbugsin3.x.v11.1.rtf in view mode; [Download] [Up]

``It just works!'' Ð Steve Jobs

``I want YOU to tell me whether or not a bug has been cured in NS_3.1!'' Ð Raf Schietekat

#import 3.1 ReleaseNotes
Thanks for letting us know, NeXT¼ (at last). Items that were mentioned in this file before will not be removed if they occur in 3.1 ReleaseNotes.

Known Bugs in NeXTSTEP
Purpose
Establishing a centralised database of bugs in NeXTSTEP, meant to be consulted by users to steer clear of trouble and by NeXT for cleaning up NeXTSTEP. The source of the information: NeXTSTEP's users (NeXT has abstained so far). Just check whether any bug you discover has been included already, and send a report to me if it hasn't; for items that are included as open-ended for a previous release, tell me whether they are now cured or not. The purpose: to help you avoid trouble, make it unnecessary to waste much time trying to identify a bug or finding out whether it has already been identified, and to share workarounds. This is a personal and purely voluntary effort (I must be crazy or something).
It has been reconfirmed several times that NeXT is not interested in this initiative, neither to divulge knowledge about bugs (maybe they don't want to kill the Ask_NeXT with the golden eggs, why else would they not try this to filter out most of the doubles?), nor to use its results (you are therefore invited/urged to relay any item in here that you find of interest to you and that you can reproduce (to be fair) in the latest release, to Bug_NeXT@NeXT.com).

Coverage
The following is limited to the official NeXTSTEP distribution, and excludes facts included in /NextLibrary/Documentation/ReleaseNotes.
A selection of bugs known to me (almost all, really), and not already included in the ReleaseNotes.
A selection of suggestions I want to make (many, but far from all), sort of compensation for maintaining this file¼
A selection of ``refereed'' reproducible bugs reported to me (indicated are: who discovered (by default the reporter), who reported, who verified).
Notices of fixes by NeXT's programmers wanted!
Some rumours and input from other sources (indicated as such).
This file incorporates all my reports to Bug_NeXT(ec) that are still valid (i.e., 1358, 1446, 1897 (not second item: cured), 1899, 2028, 2064, 2100, 2101 on Bug_NeXTec, none on Bug_NeXT) and replaces various submissions (among them earlier versions of this compilation), e.g., Bug_NeXT.48688 is KBNS.11.0.

Identification
A system has been introduced in version 10.1 (10.0 was only known as 8.0 together with 9.1) as follows, and has gone through some changes. KBNS.xx.y.zzz is an item that has been added to this collection (Known Bugs in NS) since version xx.y with a tag zzz. Missing tags mean that a preliminary item was revoked/revised before release. xx.y.zzz is the constant here, and can be used to identify an item. xx.y can be used to quickly scan new items (this will replace the rather clumsy colour scheme previously used).
After an underscore, information about the lifetime of an item is included: after an underscore comes one version or a range (with a ±), where the boundaries are either o (for open: the actual validity range may extend further than indicated), or c (for closed, the actual validity is known not to extend past this boundary, at the end this may be read as the c for cured). By default, all entries here have been marked _o3.0o. A letter may be omitted if it would make no sense.
Limitation: I didn't provide a revision tag.

Copyright
Permission to reproduce anything from this file is given, provided that this source is mentioned (so that it can work as a central repository). A notification is appreciated in case of large distribution.
I have quoted literally from a few sources (NeXT documentation, Developer mailings) with reference to their origin, to avoid introducing mistakes.

I invite you
to submit your own reproducible NeXTSTEP_3.0 bugs that are not yet included here to me, for inclusion in the next version, as well as comments, high acclaim and¼ bugs in this file! Please only NeXTSTEP_3.0. And only reproducible bugs (I don't want to get swamped, this is a voluntary effort, and I reserve the other categories to myself here, kinda like compensation; suggestions to fix obvious shortcomings are a border case). Try to classify them somewhat like this file does, and collect them together. It would be very helpful to include testimony that someone else could reproduce the bug from a concise description: I could then include that almost literally and without having to test it myself.
NeXT programmers are urged to send reports of bug fixes.
Please no big files: first Build a project with option clean, no big .snd or .tiff files, and check if it's not already sufficiently covered here¼

To submit material,
Edit one of the following messages (only the parts in italics). Don't send several messages: collect your items.

Remember:
· Format: NeXT Mail when the triangle is not visible in the deliver button (i.e., not uuencoded) can cause trouble for some sites (mostly non-Internet), such as mine, so click once or twice (or more) until you have Non-NeXT, or make sure you force uuencoded mail (include and delete an ellipsis=alt-period, for instance). See category Mail.
· Size: Don't send more data than absolutely necessary. First Build a project with option clean, no big .snd or .tiff files, and check whether the subject is not already sufficiently covered in a version that you got from sonata at most a few days before¼ Most bugs can be perfectly described in only a few lines of text (which is all that will be included here anyway).

Please include your name in alias style (John_Doe) and Internet style (jdoe@foo.bar.com: I can't reach you if your address contains characters other than @, period and alphanumerics, so if you have something with ! or % ask someone else to submit for you).
(NeXT can be contacted at Bug_NeXT@NeXT.com in America and at Bug_NeXTec@NeXT.com in Europe, but you can be almost sure they won't return anything else than an automated log notice with their reference number. They prefer one item per message only. BTW, you're invited to submit copies of items herein, maybe statistics will guide them to fulfill our desires¼ Unless of course we can be persuaded that they will follow this file closely.)
If you want to submit a known-bug report.
    To: Raf_Schietekat
    Subject: KBNS.XX.X.rtf submission

    The version of this compilation that I have is: Version 10.
    Category: Hardware (a category is the thing with the largest font in this file)
    Subcategory: Pizza Box
    NeXTSTEP version: o2.1±3.0o (it applies to everything from 2.1 to 3.0, I didn't yet test outside of that range)
    Real name (first and last name linked with an underscore): John_Doe
    E-mail: jdoe@foo.bar.com (NeXT Mail preferred), my old address john@next.dee.com is now invalid
    Severity: (hardware reset required/NMI reboot required/login window appears/application crash/data corruption/display mishap¼) none of these: unrecoverable hardware damage
    References: Bug_NeXTec knows this as #8764349872 (just kidding) and I posted it to comp.sys.next.bugs on 1993-01-15.
    Verified: X_Y (x@z.com) has tried it too and roughly confirms my findings
    Description: A NeXT computer won't always start up again after it has been dropped to the floor. I think there's a specific pattern here, but I've been unable to obtain cooperation from other labs to complete my analysis.
    Documentation: A statistical analysis is documented in foo.bar.com:~ftp/next/bugs/droppings.rtfd
    Workaround: Covering the floor with mattresses often helps, but this is a rather awkward solution.
    General comments: I think your bugs collection stinks. I never use it. It has never saved me any time. Why don't you just quit.
If you want to contest or clarify anything, answer any question, provide a workaround, or wish to notify me that the item is fixed (NeXT¼).
    To: Raf_Schietekat
    Subject: KBNS.XX.X.rtf comment

    The version of this compilation that I have is: Version 10.
    Real name (first and last name linked with an underscore): John_Doe
    E-mail: jdoe@foo.bar.com
    Identification: KBNS.00.0.000_o3.0o
    Comment: Isn't that a very naughty number! I have tested this in 3.1 and it is not solved!
    General comments: I think your bugs collection stinks. I never use it. It has never saved me any time. Why don't you just quit.

``Warning''
Grave dangers and lowly suggestions, from NeRDy to nerdy, are mixed together here, and only some indication of severity has been provided; but until NeXT develops an application that lets one easily develop a fully specified (in the dimensions of application, reproducibility, severity, estimated effort for repair etc.) standard report that can be easily routed, letting it be submitted by e-mail, automatically returning known bugs in that area, and requesting a confirmation before having the engineers look at it (automatically selecting from life threatening to silly comment in the engineer's own area of expertise together with a count of the users that confirmed this item, still allowing him to choose something of lesser priority if he is getting depressed or something) instead of the present human filter NeXT(ec)@NeXT.com that is apparently very loath to accept anything of much detail or other, and automatically confirming a fix and adding it to the list ``is fixed for the next release'', ``will be fixed'', ``we're not sure if this is a bug we should spend time on let's see who else complains'', ``we disagree'' or something else (blabla), sending it to the submitter so that his part of the application can keep this in a to-check list to see if it has indeed been fixed to satisfaction (still allowing him to reconsider if he sees that he made a mistake), also including this program suite in NeXTSTEP for use by developers of third-party applications (!), that's all that can be expected (these were two sentences, but I thought one would be clearer).

Aliases
Please disregard all mail addresses further on in this collection (they may be stale, not apply to your site or be awkwardly mutilated). All references to contributing authors (also indirectly!) and some others use these aliases, so it's the best way to look for them. I will maintain only this list, and not care about anything that looks like a mail address further on.
N means NeXT Mail literate, m means only ASCII mail, . is unknown. You can sort by first name by piping through sort. To add these to your Mail's private aliases (warning: may or may not preserve existing aliases that appear in this list, unlike what I said earlier): e.g., Quit Mail, pipe the aliases through awk '{print $1,$3}' >> ~/.NeXT/.mailalias and relaunch Mail. A date indicates a verified communication on that address. Please report any errors.
To reach addresses like jdoe@foobar.bitnet from the Internet, you may need to disguise them as jdoe%foobar.bitnet@uunet.uu.net or something.
Remember: NeXT Mail when the triangle is not visible in the deliver button (i.e., not uuencoded) can cause trouble for some sites (mostly non-Internet), such as mine, so click once or twice (or more) until you have Non-NeXT, or make sure you force uuencoded mail (include and delete an ellipsis=cmd-period, for instance). See category Mail.

Steven_Abell:         . abell@netcom.com
Mark_Adler:           N madler@cco.caltech.edu
Dale_Amon:            . amon@cs.qub.ac.uk                    1993-07-24
Ronald_Antony:        m rca@cs.brown.edu                     1993-05-11
Andrew_Athan:         . athan@object.com
Ian_Bainbridge        . ian@mindvox.phantom.com              1993-06-22
Christian_Baur:       . cbaur@informatik.uni-muenchen.de     1993-04-09
Arrigo_Benedetti:     . arrigo@cube.sublink.org
Dale_Brisinda:        N dale@pegasus.cuc.ab.ca               1993-09-22
Dan_Brown:            N dbbrown@mrj.com                      1993-06-21 (previously dbbrown@eastrg2.cray.com)
Robert_Brown:         N brown@quorum.com                     1993-03-29
Bill_Bumgarner:       N bbum@stone.com                       1993-07-04
Thomas_Burkholder:    N Thomas_Burkholder@NeXT.com
Tim_Dawson:           . prism!mspboss!tdawson@is.com         (clean domain style?)
Matthew_Dillon:       N dillon@overload.berkeley.ca.us       1993-05-..
Dion_Dock:            . dockd@storm.cs.orst.edu              1993-05-20
Nicolas_Dore:         N nico@imani.cam.org                   1993-06-24
Garance_Drosehn:      N gad@eclipse.its.rpi.edu              1993-04-05
Harvey_Dueck:         . harv@ali.bc.ca                       1993-09-23
Carl_Edman:           N cedman@princeton.edu                 1993-08-17
Marc_Elvy:            . elvy@marble.com                      1993-04-23
Henry_Flurry:         N henryf@imagine.com                   1993-02-..
Charles_Fu:           N ccwf@cns.caltech.edu                 1993-07-08
Thomas_Funke:         . thf@zelator.in-berlin.de             1993-01-..
Windflower_Gilbert:   N windy@pencom.com                     1993-08-10
Bruce_Gingery:        N bruce@totsyssoft.com                 1993-08-29
Errol_Ginsberg:       N errol@ridgeback.com
Brian_Glaeske:        . glaeske@plains.NoDak.edu             1993-06-14
David_Griffiths:      . dave@prim.demon.co.uk                1993-03-06
Eric_Guichard:        . guichard@sociologie.ens.fr           1993-01-..
Charles_d'Harcourt:   . charles@harcourt.com                 1993-08-12
Bradley_Head:         N brad@instep.wimsey.bc.ca             1993-09-28
Anthony_Heading:      . heading@signal.dra.hmg.gb            1993-02-20
Jonathan_Hendry:      . jon@afs.com                          1993-04-21
Scott_Hess:           N scott@nic.gac.edu                    1993-01-.. (this address will probably survive shess@ssesco.com)
Art_Isbell:           N isbell@cats.ucsc.edu
Beth_Katz:            . dhutchen@millersv.bitnet             1993-01-26
Robert_Kedoin:        N rob@lighthouse.com                   1993-06-14
Dylan_Kohler:         N dylan@angst.com
David_Koski:          N dkoski@gorgatron.tuc.noao.edu        1993-04-29
Daniel_LaLiberte:     . liberte@cs.uiuc.edu                  1993-02-03
Dennis_Lam:           . lam@tds.com
Hermann_Lauer:        N hlauer@dali.uphys.uni-heidelberg.de  1993-05-10
Alexander_Lehmann:    . alex@hal.rhein-main.de               1993-04-22
Jeff_Martin:          N Jeff_Martin@NeXT.com                 1993-09-23
Mark_McCallum:        . mccallum@world.sinet.slb.com
Don_McGregor:         N mcgredo@proponent.com                1993-09-14
James_McKelvey:       N mckelvey@fafnir.com                  1993-01-26 (mckelvey@suite.com at work)
Mark_Mendel:          . radical!mgm@is.com                   (clean domain style?)
Uwe_Meyer-Gruhl:      . meyergru@informatik.tu-muenchen.de   1993-06-15
James_Moosmann:       . moose@antilles.nosc.mil              1993-08-18
Mai_Nguyen:           N Mai_Nguyen@NeXT.com
Robert_Nicholson:     . robert@steffi.demon.co.uk            1993-08-21
Eric_Norum:           N eric@skatter.usask.ca
Moises_Oliveira:      . oliverm@nevada.edu
Ali_Ozer:             N Ali_Ozer@NeXT.com
Mike_Panzitta:        . mike%doberman@Princeton.edu          (clean domain style? mike@doberman.com perhaps?)
Antonio_Pascoa:       . apf@io.fct.unl.pt                    1993-01-15
Lorin_Rivers:         . lorinr@altsys.com                    1992-11-..
Michael_Ross:         N mross@antigone.com                   1993-02-..
Ivo_Rothschild:       . equinox1!ivor%gun.com                1993-09-21 (clean domain style?)
Corey_Satten:         . corey@milton.u.washington.edu
Raf_Schietekat:       N rfschtkt@banruc60.bitnet             (see remark above about reaching bitnet from Internet)
Douglas_Scott:        N doug@foxtrot.ccmrc.ucsb.edu          1993-04-19
Eric_Scott:           N eps@toaster.sfsu.edu                 1993-02-02
Michael_Shaler:       N mshaler@tdocad.sps.mot.com           1993-05-17
Frank_Siegert:        m frank@atlas.physchem.chemie.uni-tuebingen.de 1993-05-..
Douglas_Simons:       N doug@thoughtful.com                  1993-07-07
Subrata_Sircar:       N ssircar@canon.com
Jeremy_Slade:         . slade@alpine.lance.colostate.edu     1993-03-31
Howard_Smith:         N smith@nextone.niehs.nih.gov          1993-02-23
Kate_Smith:           N Kate_Smith@NeXT.com                  1992-12-..
Charles_Spitzer:      . charlie@snowflake.az.stratus.com     1993-04-05
John_Stockwell:       N john@dix.mines.colorado.edu          1993-02-02
Dimitri_Tischenko:    N dimitri@dutiws.twi.tudelft.nl        1993-03-11
Frank_Thomas:         N frank@glocke.robin.de                1993-08-31
Linus_Upson:          N lupson@geom.umn.edu                  1993-02-..
Gordon_Van_Huizen:    . gvh@metrosoft.com                    1993-03-31
Paul_Verket:          N verket@venice.sedd.trw.com           1993-02-15
Marcel_Waldvogel:     . marcel@nice.usergroup.ethz.ch        1993-03-31
Ivo_Welch:            . ivo@next.agsm.ucla.edu
Gerben_Wierda:        N gerben@rna.indiv.nluug.nl            1993-04-..
Montgomery_Zukowski:  . monty@intuitiveedge.com

Errata Not for unverified reports by others. References may be to the original items or to their modifications.
About version 6.
wierda@ltb.ltb.bso.nl for Gerben_Wierda was already stale (site removed) then.
I won't send out individual update notifications anymore.
About version pre-8.0.
Raf_Schietekat:       N rfschtkt@maze.ruca.ac.be             (sorry, not usable yet, although I thought it was)
About version pre-9.1.
The filter suggested for use with the Aliases list may or may not preserve existing aliases, unlike what I said earlier (that it would).
About version pre-9.1.
Look again at /bin/diff. The bug is different from what I described earlier.
About version¼ (not mentioned hereafter).
KBNS.10.1.005 About setuid scripts on different platforms.
KBNS.10.1.021 KBNS.10.1.022 Bug_NeXTec.44209 About crashing because of freed NXBrowserCell images: see KBNS.10.2.010 (wasn't a bug)
KBNS.00.0.091
KBNS.00.0.216 Oops, didn't see make depend.
``KBNS.00.0.279 tmpnam(3) According to Bug_NeXT report #14996 as quoted in ``core dump'' in a 1992-09 Developer mailing, this function always returns the same name. That makes it unusable to create a temporary file. Workaround: use mk(s)temp(3) or NXGetTempFilename(AppKit) instead (NXTempFilename() as suggested by the ``core dump'' quote doesn't exist). When will this be solved? Is tmpfile(3) affected or is this still usable?'' This was before 3.0, so I removed KBNS.00.0.279 (including Alexander_Lehmann's patch), but tmpnam has got a new report KBNS.10.3.023.
KBNS.10.2.018 is really an application of KBNS.10.2.013
KBNS.00.0.032 Was a mistake, explained in previous versions.
KBNS.00.0.328_o3.0o KBNS.11.1.rev (Reported on comp.sys.next.programmer on 1993-04-04 by myself, supported by Charles_Spitzer. NXLocalizedString doesn't look at .lproj folders in a Contents Inspector, not even English.lproj. Workaround, anyone? Tell us both.) We just used NXLocalizedString instead of NXLocalStringFromTableInBundle¼ Sorry for the false alarm.

Acknowledgements
Thanks to the contributing authors (especially Subrata_Sircar, who is a major contributor and who also installs the different versions on the ftp sites), and to the administrators of the ftp sites.
Sponsors welcome¼

Blah blah¼
Remark that I formulated most of this as if I, Raf_Schietekat, were speaking directly to NeXT, the programmers. This is for historical reasons, and probably an idle supposition¼ unless they read this file on their own initiative.
Well, 't is a cumbersome affair, compiling this file, but if it benefits the NeXT community¼

Administrator and author of the anonymous entries (``me'')
Raf_Schietekat (Flanders, Belgium)
(real, i.e., with triangle in the Deliver button) NeXT Mail preferred
I can't reach sites with ! or % in their address, or ending in ``at''
Please no big files: first Build a project with option clean, no big .snd or .tiff files, and check if it's not already sufficiently covered here¼

AppKit, Common
Generally
KBNS.00.0.001_o3.0o Shelf space. Introduce shelves for OpenPanel, SavePanel, FontPanel, ¼

Localisation Yes indeed, what about American English vs. real English? :-)
KBNS.00.0.002_o3.0±3.1o Reported, and verified (also for 3.1), by Subrata_Sircar, from Mai_Nguyen
A bug¼
From: Mai_Nguyen@NeXT.COM (Mai Nguyen)
Date: Tue, 8 Dec 92 18:33:25 -0800
Subject: [36810] Localizing Floating-Point Values

The CLibLocalization notes under /NextLibrary/Documentation/NextDev/ReleaseNotes gives more details on how to change NXNumberGroup, NXCurrencyGroup,  and NXCurrencyFormat. There is a 3.0 bug such that NXNumberGroup, NXCurrencyGroup and NXCurrencyFormat are not defined in the international.strings file. So, one could do a dwrite, but this is not a good solution either, since it will affect the GLOBAL database, i.e. it's not settable depending on the language preferences.

If you have set up the defaults correctly, setFloatValue: will be set with the proper delimiter.
For example:
1) You need to specify the proper delimiter via NXNumberGroup with a dwrite:
dwrite GLOBAL NXNumberGroup '","""""'
As I specified earlier, you may need to change your settings depending on your language yourself. But once they are set, doing a setFloatValue: will display the proper delimiters.
(The above dwrite will use a , for the decimal point for example)
KBNS.10.1.026_o3.0o, confirmed by Frank_Siegert When using the German language package, the cdate in a File Viewer set to List display is shown as, e.g., ``Mai 10 56td:24'', where ls -lga indicates ``May 10 14:24''. The month, date and minutes are correct, but the hour makes no sense at all. The ``td'' seems to be a constant. If the item doesn't belong to the current year, entries are like ``Mai 10 ?'' instead of ``May 10  1992''.

Mouse cursor
KBNS.00.0.003_o3.0o Suggestion: provide better feedback than NXBeep()ing all the time. There shouldn't be a Help... command (RenderManager.app at least) or a cursor change to a question mark (every application) over Views for which NeXTSTEP Help isn't available. This is more serious than displaying the return key image on non-key panels, which was corrected in this release. And if a modal session is running, non-sensitive areas of the application might be indicated by the mouse changing to, e.g., a don't-enter-this-street sign.

NXFrameLinkRect()
KBNS.00.0.005_o3.0o Bug
Q: When I use the function NXFrameLinkRect() to draw a link fence around a rectangle, it doesn't draw correctly in a scaled view. What am I doing wrong?
A: This is a known bug in the AppKit. QA860 describes a patch.

NXLogError()
KBNS.10.3.025_o3.0o Should move to Common, in libsys_s.a, also see KBNS.10.2.039. Now this useful function has to be emulated by programs that don't already link with libNeXT_s.a and want to avoid the burden of doing so, in the following way (as far as I can tell, I just tried to mimick the observed behaviour rather than disassemble NeXT's version), ready for copy-paste inclusion in any program:
#define someStupidArbitraryValue 500
#import <ansi/ansi.h>
#include <syslog.h>
extern char **NXArgv;
  // has to be set to argv in main()
  //   ([Application new] normally does that, I think)
static void NXLogError(const char *format,...){
  /*var*/
    char theString[someStupidArbitraryValue]; // how I hate C strings
    FILE *pFILE_tty;
  /*set up theString*/{
    // matches NeXT's version in that %m is never recognised,
    // not even if the message will go through syslog
    /*var*/ va_list args;
    va_start(args,format);
    vsprintf(theString,format,args);
      // how silly that C doesn't offer a solution
      // that doesn't need this vsprintf version of sprintf
    va_end(args);
    }
  if(NULL!=(pFILE_tty=fopen("/dev/tty","w")))
    /*then*/{ // yes, there's a controlling terminal, so the app has been
              // started from a shell (NeXT's version seems to cache this
              // information)
      fprintf(pFILE_tty,"%s",theString);
      // can anyone tell me whether NXLogError normally adds a \n for
      // apps started from a shell?
      fclose(pFILE_tty);
    }else{ // no controlling terminal, so it's syslog time...
      /*var*/ char *progName;
      progName=rindex(NXArgv[0],'/'); progName=progName?progName+1:NXArgv[0];
      openlog(progName,LOG_PID,0);
        // don't know about other options for second argument
      syslog(LOG_USER|LOG_ERR,theString);
      // what does closelog do anyway?
    }
  }

NXReadColor(), NXWriteColor()
KBNS.00.0.006_o3.0o Suggestion about uniformity. All (?) other functions to read something from a typed stream use the location of what is to be read, and this function returns it by value. The others write from a reference, this one writes without indirection. How about fixing this?

NXRunAlertPanel()
KBNS.10.3.032_c3.0±3.1o Bug that crashes the application, reported for 3.0 and 3.1 (``never [¼] under 2.1'') by Douglas_Simons on NeXT-prog@cpac.washington.edu on 1993-07-07, Bug_NeXT.47046, verified for 3.0 by me.
-appDidInit:sender{ // appDidInit is not essential to this problem
  /*var*/ char *outMsg;
  if(KERN_SUCCESS==vm_allocate(task_self(),(vm_address_t *)&outMsg,300,TRUE)){
    sprintf(outMsg,"This is the string");
    NXRunAlertPanel(NULL,outMsg,NULL,NULL,NULL);
    NX_ASSERT( // this is no problem
       KERN_SUCCESS==vm_deallocate(task_self(),(vm_address_t)outMsg,300) ,
      "KERN_SUCCESS==vm_deallocate(task_self(),(vm_address_t)outMsg,300)");
    }
  NXRunAlertPanel(NULL,"Other message",NULL,NULL,NULL);
  return self;
  }
``Other message'' never appears, because the application crashes during the second NXRunAlertPanel. I used vm_allocate() here to strip the problem down to its essentials; Douglas_Simons used an NXStream opened from memory. Verified workaround: NXRunAlertPanel(NULL,"%s",NULL,NULL,NULL,outMsg);. NXRunAlertPanel seems to do some strange thing with a HashTable, which did a (now invalid) access at outMsg. The backtrace for Douglas_Simons
#0  0x500b588 in hash ()
#1  0x500b2ca in -[HashTable _insertKeyNoRehash:value:] ()
#2  0x500b3b0 in -[HashTable insertKey:value:] ()
#3  0x500b494 in -[HashTable insertKey:value:] ()
#4  0x503973c in NXLoadLocalizedStringFromTableInBundle ()
#5  0x50394b4 in NXLoadLocalStringFromTableInBundle ()
#6  0x6094fca in _NXDoLocalRunAlertPanel ()
#7  0x6096d70 in NXRunAlertPanel ()
and for me
#0  0x500c606 in isEqual ()
#1  0x500f464 in -[HashTable valueForKey:] ()
#2  0x5012eec in -[NXStringTable valueForStringKey:] ()
#3  0x503971c in NXLoadLocalizedStringFromTableInBundle ()
#4  0x50394b4 in NXLoadLocalStringFromTableInBundle ()
#5  0x60950d2 in _NXDoLocalRunAlertPanel ()
#6  0x6096d70 in NXRunAlertPanel ()
Cure: NXRunAlertPanel should leave this argument alone, rather than document this.

NXSaveToFile()
KBNS.00.0.007_o3.0c Reported by Subrata_Sircar for 3.0 and to be cured in 3.1, not verified (anyone?), Bug_NeXT.29066
From: ssircar@canon.com
Date: Mon, 3 Aug 92 11:10:26 -0700
Subject: [29066] NXSaveFile() question

NXSaveToFile() doesn't release resources if an error occurs; specifically, if the file cannot be saved and an "disk full" error occurs, unlink() won't reclaim the disk space until the program quits.

NXSetDefaultValue()
KBNS.00.0.008_o3.0o If you are having problems with this function, bug Jeff_Martin@NeXT.com about it. I've read about a problem on NeXT-prog@cpac.washington.edu 1993-02-19, but got no answer from him when asking for a clarification of his ``explanation''.

NXSizeBitmap()
KBNS.00.0.009_o3.0c Bug, from a reply of Ali_Ozer to Dennis_Lam on next-prog@cpac.washington.edu, 1993-01-14, reported to be cured in 3.1 by Subrata_Sircar Will produce a false result when reading from 12-bit windows when the specified width is uneven. This may cause errors in the archiving of an NXImage (actually in the backing store of an NXCachedImageRep).

NXWorkspaceRequestProtocol and related methods
KBNS.00.0.010_o3.0c app:fileOperationCompleted: doesn't get called¼ Reported by NeXT in a 1993-01 Developer mailing, quoted literally, reported to be cured in 3.1 by Subrata_Sircar. ``#30234 -- Using performFileOperations:... method of the Workspace protocol, the delegate does not receive the app:fileOperationCompleted: method. This isn't something you're doing wrong, it's actually a bug in the kit. It will be addressed in the 3.1 release. In the meantime, if you need notification on the completion of a file operation, you can compose a string and do a system() call.'' That would be system(3), because system isn't actually a system call itself, of course! There was also a reminder about the options parameter being currently ignored and provided only for future expansion.
KBNS.00.0.011_o3.0o [[Application workspace] beginListeningForApplicationStatusChanges] Bug, not verified ``can cause NeXTSTEP to stop ejecting floppy disks from the Workspace (no kidding!)'' according to Gordon_Van_Huizen in a 1993-03-07 comp.sys.next.(bugs/programmer) posting, if the following message isn't sent first, e.g., in the appDidInit: method:
[[Application workspace] getInfoForFileSystemAt:"/"
	isRemovable:&removableFlag
	isWritable:&writableFlag
	isUnmountable:&mountableFlag
	description:&fileSystemDesc
	type:&fileSystemType];
See also KBNS.00.0.092: is this about the same thing?
KBNS.00.0.012_o3.0±3.1o [[Application workspace] findString:] Bug, confirmed for 3.1 by Subrata_Sircar (``[In 3.1, this yields "syntax error on line 1, teletype" replacing the selection.]'') (Formulation adapted just a bit.) When I run
#import <appkit/appkit.h>

[[Application workspace] findString:"weirdTestString" inFile:"/Users/rfschtkt/Library/Comments/Systems/NeXT/knownbugsin3.Xv10.3.rtf"];
through Eval and close this window, it does get opened again, but the string is not selected, and Edit doesn't even scroll it into view (Edit works correctly from WM's Finder, though).
KBNS.00.0.013_o3.0±3.1o [[Application workspace] hideOtherApplications] doesn't, according to Marcel_Waldvogel and Gordon_Van_Huizen in a 1993-03-31 comp.sys.next.programmer exchange, confirmed for 3.1 by Subrata_Sircar
KBNS.00.0.014_o3.0o [[Application workspace] openFile:fromImage:at:inView:theView] Suggestion If theView isn't visible when this method is executed, the animation should really start from the miniwindow or else application icon's tile, not from somewhere on the screen where once happened to be a suitable origin.

NXZoneFromPtr()
KBNS.11.1.026_o3.0c Not thread-safe! Reported by Bradley_Head on c.s.n.(b&p) on 1993-09-28
To Bradley_Head's knowledge, the bug was never documented, and was furtively fixed in 3.1. Verification: disassemble the code.

/Object
KBNS.00.0.015_o3.0±3.1o Reported, and verified (also for 3.1, ``Partially fixed.  Object works, Application doesn't.''), by Subrata_Sircar, from Mike_Panzitta
Subrata_Sircar agrees with me that, unlike what Mike_Panzitta says, it's the first case which is correct as documented (look it up), but the second method should produce the same result, also as documented.
Newsgroups: comp.sys.next.programmer
From: mike%doberman@Princeton.EDU (Mike Panzitta)
Subject: isKindOf: and IsKindOfClassNamed: problems
Date: Mon, 28 Sep 92 06:23:57 GMT

Has anyone noted these problems with the above methods:

-  Second, and more important, I have discovered in a program (actually
   interactively within GDB) this interesting phenomena:

   (gdb) print [aClassObject isKindOf:[Process class]]
   $6 = 0
   (gdb) print [aClassObject isKindOfClassNamed:"Process"]
   $7 = 1

   The second case is the one that is correct. Wrong: see above.

/Object/Cell/ActionCell/ButtonCell
KBNS.00.0.016_o3.0±3.1o Reported, and verified (also for 3.1), by Subrata_Sircar, from Steven_Abell
-initIconCell:, when called with an argument that can't be found, can do some partial work that might cause trouble later. Shouldn't such a method succeed or do nothing at all?
From: abell@netcom.com (Steven T. Abell)
Subject: Bug in ButtonCell initIconCell:
Date: 4 Dec 92 00:46:05 GMT

Yesterday I posted about a problem under Subject:[poMatrix sizeToFit].
Today I found the problem. It consists of a bug in ButtonCell initIconCell:
mixed with a little bit of carelessness.

I forgot to put my tiffs into my PB project.

When I used [poButtonCell initIconCell:<icon_name>], NXImage couldn't find
the icon, so it didn't update the image pointer. But the image pointer is
part of a union, and that field is normally occupied by a pointer to a font.
However, it *did* otherwise configure the ButtonCell to have an icon. This
eventually results in NXImage's getSize: method being used on the lurking
font. Crash! Splat!

My immediate problem went away as soon as I moved my tiffs in to the project.
But the failure behavior of initIconCell: is worth looking out for.

/Object/Cell/ActionCell/SliderCell
KBNS.00.0.031_o3.0o KBNS.11.1.rev Specification bug. The purpose of a continuous slider (a poor man's ``hot link'') is that the ``target'' is at all times aware of the position of the slider. That means that the current semantics of setContinuous:YES is wrong (makes no sense): the action should also be sent on mouse-down.
-setContinuous:(BOOL)flag{ // situation in NS_3.0 (functionally equivalent)
  if(flag){
      cFlags2.dontActOnMouseUp=FALSE;
	// what is this for? isn't dontActOnMouseUp always FALSE?
	// if it isn't, this method doesn't correctly set up non-continuous behaviour
	// why is there no equivalent when flag is FALSE?
      cFlags2.actOnMouseDragged=TRUE;
    }else{
      // see comments about dontActOnMouseUp in flag==TRUE
      cFlags2.actOnMouseDragged=FALSE;
    }
  return self;
  }
-setContinuous:(BOOL)flag{ // as it should be
  cFlags2.actOnMouseDown=cFlags2.actOnMouseDragged=cFlags2.dontActOnMouseUp=flag?TRUE:FALSE;
    // maybe dontActOnMouseUp should remain FALSE always,
    // if the Window Server doesn't guarantee that the mouse-up event
    // has the same location as the previous mouse-down or mouse-dragged
  return self;
  }
Whenever continuity is switched on and afterwards at changes of either target or action instance variables, a SliderCell should ask Application to remind it to send an action message just before Application begins waiting for its next event (this includes the functionality that awakeFromNib would provide for the SliderCell's controlView).
Humble suggestion on the side: all tracking controls should display a shadow indicating what value the target thinks the control has at all times; only for continuous settings is this shadow not drawn (merely a performance issue). This includes sliders (and functional equivalents), radio buttons, and such (e.g., matrices in the presence of an inspector for individual cells).
KBNS.00.0.033_o3.0o KBNS.11.1.rev Suggestion to avoid wasting performance. Along the same line of reasoning, a continuous SliderCell should generate action messages only for events that change the position of the slider bar (i.e., not if the mouse is dragged sideways or outside the range of the Slider¼). Suggestion: there should be a notification at mouseUp time in case the drags are processed using some cheaper drawing style that is not appropriate for permanent display (cf. RenderMan).

/Object/Cell/NXBrowserCell See /Object/Responder/View/Control/NXBrowser

/Object/HashTable
KBNS.10.2.038_o3.0o Message that keeps appearing on the Console and is apparently harmless: why?
*** HashTable: count differs after rehashing; probably indicates a broken invariant: there are x and y such as isEqual(x, y) is TRUE but hash(x) != hash (y)
This message occurs about daily. HashTable should use NXLogError() instead to mark with process and time, to allow the culprit(s) to be identified¼ Also see KBNS.10.3.025: Bill_Bumgarner pointed out that linking with libNeXT_s.a just for NXLogError may be too much of a burden.

/Object/NXImage and related classes  See also NXSizeBitmap().
KBNS.00.0.017_o3.0o Reported and verified by Subrata_Sircar, from Henry_Flurry
Something that will fail on a NeXTstation Turbo Color, and only there. Subrata_Sircar: ``I tested it on a
new NeXTStation TurboColor (with the new keyboard), an old NeXTStation TurboColor, a NeXTStation mono, a NeXTDimension, and a NeXTStation color.  As I recall the problem occurred only on the NeXTStation TurboColor.'' The test application is probably still available from Henry_Flurry (eliminated here to save space).
From: henryf@imagine.com (Henry Flurry)
Date: Tue, 17 Nov 92 17:16:41 -0500
To: Next Prog <next-prog@cpac.washington.edu>
Subject: Image typedStream read/write failure on NeXTstation Turbo Color ONLY!!!

Howdy!

It looks like I stumbled across a 3.0 platform dependant bug.

It appears that in certain ways of creating an NXImage object, the read/write cycle on a NSTurbo Color will fail.

Here's a project which generates a small app that generates an error when running on our NSTurbo Color, but succeeds on all of our other machines.

In our tests, using an image with no-alpha or not changing the size of the image will cause the app to generate no errors.

I'd like people to verify this problem on their platforms, so I can be assured that this is not a problem in the installation of 3.0 on the NSTC.

Please mail me which platforms this does and does not work on.

Thanks!

- Henry

P.S. To decode the following, copy (cmd-C) the lines from "begin" to "end" (inclusive) and type on the command line, where you want the project to be:
	paste | uudecode ; zcat ImageFail.DIR.tar.Z | tar -xvf -

(DON"T COPY/PASTE the above line or you clear the pasteboard!)

You should find a directory ImageFail.DIR with a PB.project within it.

Thanks again!

[Here was a project directory, tar'ed, compressed and uuencoded.]
KBNS.00.0.018_o3.0c Reported and verified by Subrata_Sircar, from Dylan_Kohler, reported to be cured in 3.1 by Subrata_Sircar
I don't know if NXImage is the exact right place to classify this. Dylan_Kohler gives an example TIFF file: ``For this first image, when you compress it using the JPEG appkit routines (at factor 10, for instance, though I think any factor reveals the problem) and then uncompress it±±it changes the bright, pure red areas to bright green!'' He submitted this to Bug_NeXT: 30568. The TIFF file is probably available from Dylan_Kohler, and has not been included here, to save 12.6 kB.
He further mentions some problems with LZW compression, either producing corrupted lines or crashing the program, that have been fixed before the 3.0 release (I don't know whether the bug was in the compression or in the uncompression.)
KBNS.00.0.019_o3.0o Reported by Henry_Flurry, verified by me
Here's a portion of the test example that Henry_Flurry sent to me, somewhat altered by me.
@implementation Controller
-open:sender{
  /*var*/
    char     filename[MAXPATHLEN+1];
    NXImage  *theImage;
    NXPoint  point = {0.0, 0.0};
    NXStream *stream;
    int	     numAttempts;
    BOOL     success = NO;
    BOOL     getOpenPathName();
  getOpenPathName(filename, "");
      for(numAttempts=1;
	  (!success) && (numAttempts <= 10);
	  numAttempts++){
  if(stream=NXMapFile(filename,NX_READONLY))
    {//then
	theImage=[NXImage allocFromZone:[self zone]];
	[theImage init];
	NXSeek(stream,0,NX_FROMSTART);
	if(success=([theImage initFromStream:stream]?YES:NO)){
	    [theImage setDataRetained:YES];
	    printf("Imaging...\n");
	    [view lockFocus];
	      [theImage composite:NX_COPY toPoint:&point];
	      [view unlockFocus];
	    [view display];
	    [theImage free];
	  }else{
	    // initFromStream: already freed theImage
	    // isn't that introducing special behaviour that is
	    // difficult to remember?
	    printf("ERROR initFromStream (attempt %d)\n", numAttempts);
	  }
      NXCloseMemory(stream,NX_FREEBUFFER);
    }else{
      printf("ERROR reading %s\n", filename);
    }
	}
  return self;
  }
BOOL getOpenPathName(char *buf, char const *theType)
/* single file from previously chosen directory */
{
    static id	openPanel = nil;
    char const *fileTypes[2] = {0,0};

    *buf = 0;
    if (!openPanel)
        openPanel = [OpenPanel new];
    if (theType && *theType)
	fileTypes[0] = theType;
    [NXApp setAutoupdate:NO];
    if ([openPanel runModalForTypes:fileTypes]) {
	strcpy(buf,[openPanel filename]);
	[NXApp setAutoupdate:YES];
	return YES;
    } else {
	[NXApp setAutoupdate:YES];
	return NO;
    }
}
@end
When executing this in its application (easily reconstructed), the first time a RIB is read initFromStream: fails the first time. However, I couldn't track down the error, and it seems to depend in strange ways on whether or not the stream is reopened with every attempt or not (indentation indicates reversal of for and if), and whether or not a sprintf is used instead of getOpenPathName: initFromStream: may continually fail up to the limit allowed by this test code, or (even with this code), initFromStream: may fail once more later in the session. Warning: working with .ribs seems to be very dangerous. Some time after testing this out, I got these console messages
Feb 13 13:02:48 flexus WM[25145]: DPS client library error: Error while writing to connection, DPSContext c42c0, data -102
Feb 13 13:02:48 Workspace[25145]: Exiting due to Window Server death
Feb 13 13:02:49 Workspace: Controller exited.
and this Alert Panel: NXRunAlertPanel("Workspace Manager Error","Try to save changes to files in other applications before logging out.","Log Out",NULL,NULL);
Well, that's a good opportunity to halt and reboot, to shrink the swapfile :-(.
KBNS.00.0.020_o3.0c Reported by Subrata_Sircar, Bug_NeXT.39170 (Bug_NeXT.39484 for a workaround), reported to be cured in 3.1 by Subrata_Sircar
``Subject: JPEG compression bug in NXBitmapImageRep
The following two files [omitted here, available from Subrata_Sircar] contain a simple program to apply a color filter to a TIFF image.  When run on some JPEG-compressed images (I have a sample, but it is rather large) the one using initFromFile: produces the following console error:
 Image server went away; can't complete JPEG request
and the output file is corrupted, while the other one seems to work fine.''
``Certain images cause the problem more often with one file than the other [Raf_Schietekat: the errors aren't strictly reproducible].  [The problem occurs] on a NeXTstation, a NeXTstation Turbo Color, and a NeXTcube.''
KBNS.11.0.005_o3.0o Reported by Dale_Amon on NeXT-prog@cpac.washington.edu on 1993-07-24, not verified
``If you subclass NXImage and within your subclass set a delegate to be yourself and if an init method then fails, you will eventually crash unless you have your own free method called to get rid of the delegate. It appears that NXImage delegate id's are not held in the object you created. From the list of methods called leading up to the crash, it appears that they are hashed into a class owned list and it does not remove that entry when the associated image is freed.''

/Object/Responder/Application
KBNS.10.2.053_o3.0o Bug with the Windows menu. Here's the situation: document1 ``owns'' window1 and will free it along with itself. In a method invoked from a Control in window1: [NXApp delayedFree:document1], document2 is created, and window2, with the same title as window1. What happens is that the Windows menu gets two items with the same title (a path, rendered from the initial slash). The window has been freed, however (I checked with AppInspector). When I click the phony item, the application crashes. Workaround (short of reorganising everything): [NXApp removeWindowsItem:window] first of all (oddly, the item is removed after the new one has been added, but it does prevent a crash).

/Object/Responder/View
KBNS.00.0.021_o3.0o Very annoying old display bug (Requires one to close the window, possibly also to relaunch the application.) All hysteresis should be eliminated from the resizing of Views in a Window. It is still possible to resize a window to naught, and when dragging it out again, see (parts of) some Views out of the Window's area. This is an easily reproducible bug: make a new module, drag in a Window, drag in a vertical Slider to about the middle, make it vertically resizable and test the interface, resize the window to nothing, drag it out, and there you have the Slider off at the top. I suspect View is the guilty party: if the original arrangement isn't remembered somewhere (apparently it isn't), carelessly wandering near to instable configurations can damage limited-precision information. Proposed cure: rewrite superviewSizeChanged: to be very careful about losing precision in the frame instance variable (don't round to screen-specific magnitudes, don't collapse anything to 0.0: use a small non-zero quantity). That should do the trick, I guess (the other solution would be to keep a frameForResizing variable, but this adds extra baggage). Workaround: specify a minimum window size in Interface Builder.
KBNS.10.3.036_o3.0o dragFile:fromRect:slideBack:event: returns [self window] for success, not self as documented

/Object/Responder/View/Control/Button
KBNS.00.0.022_o3.0o Tiny and harmless but consistently reproducible bug, reported by Mark_McCallum. Verified and reformulated by me. Further information welcome.
When /NextDeveloper/Demos/CDPlayer.app is launched early in a login session without a disk in the CD-ROM drive, and one clicks Cancel in the panel that asks to insert one, the Cancel button just highlights. Subsequently, any mouseDown in the panel does nothing else than unhighlighting that button. Mark states that this kind of erratic Button behaviour occurs elsewhere too, but he gave no details and this is the only such phenomenon I have seen. If you have just (re)booted, and if the program is launched with -NXAutoLaunch YES (either naturally by registering it for autolaunch with WM Preferences/Dock and logging in, or manually from a shell), you can't miss to see it (it always occurred under these circumstances for me). However, once I think it happened when I launched the program by double-clicking it in the dock, and it may happen later on, too (as I have tested).

/Object/Responder/View/Control/Matrix
KBNS.00.0.023_o3.0±3.1o Reported by Subrata_Sircar, who reraised it for 3.1, from Eric_Scott who c/wouldn't confirm it for 3.0, so I did so myself and found out some more. This is the result of my investigation. Primo: hitting shift-tab on a TextField which is bidirectionally (!) setNextText:-linked with a Matrix of TextFieldCells selects the top-left Cell (easily reproducible with InterfaceBuilder in test mode); not a bug strictu sensu (can be inferred from the docs), just poor design. Secundo (the thing Eric_Scott found): if shift-tab is hit on a one-cell Matrix which isn't the nextText of a TextField or so, this will just deselect the Matrix' Cell; Eric_Scott mentioned two workarounds (programmatically issuing setPreviousText: doesn't work, he writes), the first reproduced below (the second was considered better by Eric_Scott but I thought it was less clear at least).
What does seem to work is setting the Form's nextText to an object containing:
- setPreviousText:anObject {
    [anObject setPreviousText:self];
    return self;
}
- selectText:sender {
    [sender selectText:self];
    return self;
}
KBNS.10.2.034_o3.0o Bug in mouseDown: for NX_LISTMODE. When the only selected Cell is shift-clicked so that it is deselected, the Matrix apparently forgets to note that fact in its own administration (selected... instance variables), somehow. Try ScrollDoodScroll's up and down arrow buttons; methods nextItem: and previousItem: use nil==[matrix selectedCell] to decide whether a Cell is currently visible, and in this case, the Cell that was deselected is returned!

/Object/Responder/View/Control/NXBrowser & NXBrowserCell
KBNS.00.0.028_o3.0o Bug with reuseColumns:YES. With reuseColumns:YES and using setImage:, those images will reappear somewhere else where they shouldn't (I've only tested non-lazy browsers). Workaround: setImage:nil everywhere, or taking reuseColumns:YES out.
KBNS.10.2.011_o3.0o Bug with getPath:toColumn: [browser getPath:pc_path toColumn:column] doesn't include column itself, one has to give [browser lastColumn]+1 as an argument to get the full path. This is silly, all the more so because it makes no sense if the last selected Cell is a leaf: a leaf never leads to another column. Because the method doesn't work as common sense indicates, and because the documentation gives no warning about that whatsoever, I consider this a bug. Proposition: add a method getPath:forColumn:.
KBNS.00.0.025_o3.0o Bug. The documentation says that addColumn shouldn't be invoked explicitly because doClick: and keyDown: do that. But keyDown: doesn't. Trying to invoke it explicitly anyway as a workaround just causes trouble. Solution, anyone? SavePanel and the File Viewers work correctly¼
KBNS.00.0.026_o3.0o Bug. Even with setEmptySelectionEnabled:YES, a left arrow on the leftmost column doesn't unselect it. Again, SavePanel and the File Viewers work correctly¼
KBNS.00.0.024_o3.0o Nuisance. Doing setTitle:ofColumn: inside browser:fillMatrix:inColumn: works for the first column, but not for the others. The docs say that the column has to be loaded for this method to have any effect, but inside this fill method, the intention is quite clear, right? So fix or motivate. Workaround: setting a variable to the title in browser:fillMatrix:inColumn:, and implementing browser:titleOfColumn: to return just this value (preferable to maintaining the two browser:... methods to mirror each other).
KBNS.00.0.027_o3.0o Suggestion. Give the defaults in the setSomeAttribute: documentation.
KBNS.11.1.003_o3.0o Tiny harmless display bug, reported by Robert_Nicholson, verified by me An NXBrowser's vertical size changes by even amounts only. Test by resizing Mail.app's Mailboxes window, or any Open Panel; look at the top of the NXBrowser.

/Object/Responder/View/Control/Scroller
KBNS.00.0.029_o3.0o And for the icing on the cake (old little bug)¼ Here is apparently the only obvious off-by-one problem inherited from the previous release. It can be detected as follows:
position cursor some 5 pixels below top of scroller bar in this window;
while(!(you're getting tired || you're getting bored) && !(you have understood)){
  press mouse button;
  drag bar some two pixels and scroll this algorithm back into view;
  release mouse button;
  } // hold the mouse still between button up and button down, you... human!
You'll gradually move up until you drop off the bar and the next pressing action on the left mouse button will let the bar jump underneath the cursor. Very harmless, but a real-life situation if reading a long text, always occurs, and now you know.
KBNS.00.0.030_o3.0o Suggestion. If the user slides the Scroller (or Slider!) out of reach so that it blocks, and the cursor comes back into the reach, the bar should move immediately, and not wait until the cursor has reached the original mouse-down position relative to the bar, i.e., more like the way a View in an Interface Builder Window moves if one drags it around. That gives a more natural feeling: the user has frictional contact with the bar, not some abstract idea that requires learning (oh well), is more cumbersome to use regardless of practice (a bit), but is just easier to program. Except for digitising tablets in absolute mode.

/Object/Responder/View/Control/Slider See /Object/Cell/ActionCell/SliderCell

/Object/Responder/View/NXLiveVideoView
KBNS.00.0.034_o3.0o Reported by Subrata_Sircar (XXX my summary not confirmed by him yet), corroboration/refutation/clarification anyone? When displaying a video source, an NXLiveVideoView doesn't respect sibling Views (subviews are treated correctly) that partly cover it, unlike what a textfield does when updating from the value of a slider. To test, use IB's test mode for an NXLiveVideoView, a Button's target for the start: action, and a TextField, a Slider's target for the takeFloatValueFrom: action. Let the start button partly cover both views, start the video view. Even when the slider is moved, the button's integrity over the TextField is preserved, while the part that covers the video view has disappeared.

/Object/Responder/View/NXSplitView
KBNS.00.0.035_o3.0o Like to have. A default setting should be provided for these objects to control whether they continuously change, or exhibit the current behaviour (drawing a shadow). Somewhat like drawing window outlines vs. drawing them as NeXTSTEP does (this could also use a default setting, to demonstrate the difference to the uninitiated). Preferences would provide control over this default value in the GLOBAL domain. Don't say ``subclass'', because that gives no control over existing applications.

/Object/Responder/View/ScrollView
KBNS.00.0.036_o3.0o Like to have. ScrollView should provide a button, that, when clicked, provides a panel that is always proportional to the View it displays, with a subsection that indicates the part that shows through. The panel might display the whole View in miniature if this can be cheaply done. Then this can be dragged instead of the sliders only, giving two-dimensional control other than repeated corrections to the two sliders. Or else at least provide a joystick on the screen between the two fields of scroll buttons.

/Object/Responder/View/Text
KBNS.00.0.037_o3.0o Bug. If isMonoFont (try a non-RTF Edit window, any TextField), Text apparently doesn't look at the charSet value of a keyboard event to determine if it can display that character (test: a non-rich Edit window and alternate-b or something, should be å and is NeXTSTEP encoding å but in Symbol font). When unable to represent it correctly, a Text should refuse such a character.
KBNS.00.0.038_o3.0o Strange little bug. [Moved here from Preview.] If I Print/Preview a file with light grey in it (e.g., this file, maybe not in this incarnation), the previewed grey is rendered using dithering of dark grey spots in light grey letters. Why? We now have colour calibration, haven't we? (monochrome display) When converting the black to dark grey from version 5 to version 6 (editing in the RTF source) and from 6 to 7, I have seen that there were all sorts of colour information specifications: a colour table with six entries, and various \gray669s, for a file with just light grey (always the same swatch) and black! I tried to convert all to just \grey333 and \grey666, now all rendering defects have gone. Is this a Text bug, maybe? Or is it an NXColorPanel bug (too), because of the limited resolution and bad rounding (see there)?
KBNS.00.0.039_o3.0o Shortcoming. Hypertext facilities very limited and not very well conceived: special purpose for NXHelpPanel. Numerous faults to be named. Probably too soon to mention this as a feature. Example: Trying to prevent breaking ``hypertext links'' in a special case. When the filename is unspecified, the current file should be meant. Now this produces the directory containing the file, which can be specified using a period also. This will prevent many link breaks when a file is renamed.
KBNS.00.0.040_o3.0o Bug with RTFD Text and workaround. Reported by Scott_Hess on comp.sys.next.programmer 1993-01-21, NeXT-prog@cpac.washington.edu 1993-01-22 (replication) and my summary for this compilation approved by him: ``Asking a Text object to -readRichText: new RTFD data (that is with attachments, not just ordinary RTF data) while there is currently RTFD data (same remark) in the Text object is a recipe for disaster in 3.0 (up to dumping core sometimes, and, though tested only with a program compiled under 2.1, doubtlessly also applicable to NS_3.0-compiled programs). As a workaround, first do [theText setText:""].'' Corroboration/refutation welcome. For more information, consult the postings and their author.
KBNS.00.0.042_o3.0±3.1o freed unmalloced pointer, reported and verified by Subrata_Sircar (also for 3.1), from Errol_Ginsberg,  Bug_NeXT.39964, published on comp.sys.next.bugs, error message on the shell verified by me (my editing didn't change anything about this), I edited the test program slightly, the rest (apart from a little formatting) literally from Subrata_Sircar
Once the paragraph style on a Text object is set using setParaStyle:, the Text object's free method will attempt to free an unmalloced pointer within the NXTextStyle structure.  This can lead to a crash under certain circumstances.  The following test program, if linked against MallocDebug, will cause a warning to appear (freed unmalloced pointer: 0xc91d8)if the window is closed before the terminate: message is sent.
*****
// compile with cc -g -Wall -o TestStyle TestStyle.m -lMallocDebug -lNeXT_s

#import <appkit/appkit.h>

@interface Delegate:Object
{
  Window *window;
}
- openMainWindow;
@end

@implementation Delegate
- openMainWindow
{
  NXRect  contentRect = {{0.0f, 0.0f}, {200.0f, 200.0f}};

  window = [[Window alloc] initContent:&contentRect
	    style:NX_TITLEDSTYLE
	    backing:NX_BUFFERED
	    buttonMask:(NX_CLOSEBUTTONMASK | NX_MINIATURIZEBUTTONMASK)
	    defer :YES];

  // [window setFreeWhenClosed:YES]; this is the default anyway
  [window center];
  [window makeKeyAndOrderFront:self];
  return self;
}

- appDidInit:(const id)sender	/* app delegate */
{
  Text   *text;
  int     timeout = 30000;
  NXRect  contentRect = {{0.0f, 0.0f}, {200.0f, 200.0f}};

  [self openMainWindow];

  text = [window getFieldEditor:YES for:window];
    [[window contentView] addSubview:text];
    [text setFrame:&contentRect];
    [text setText:"Free me by clicking the close button and then look at"
        " the error message. Be quick, or my app will terminate errorlessly"
	" after 30 seconds."];

    [text setParaStyle:[text defaultParaStyle]];

  [NXApp perform:@selector(terminate:) with :self afterDelay:timeout cancelPrevious:NO];
  return self;
}
@end

/*
 * This is correct, but gcc will give a warning because methods can't be
 * qualified.
 */
volatile int
main(void)
{
  Delegate *const delegate = [[Delegate alloc] init];

  NXApp = [Application new];
  [NXApp setDelegate:delegate];
  [NXApp run];
  printf(
    "This line will only be output if stop: is used instead of terminate:\n"
    "because terminate will exit() the process.\n"
    );
  [NXApp free];
}
*****
The pointer being freed when the Text object is freed is (deep breath)
((*(text->_info)).cache.curRun)->paraStyle->tabs
where _info is a pointer to an NXLayInfo structure, cache is a NXTextCache structure, curRun is a pointer to an NXRun structure, paraStyle is a pointer to an NXTextStyle structure, and tabs is a pointer to an NXTabStop structure, with (presumably) several others following.
The workaround is to set a style which doesn't contain any tab stops before freeing the Text object (if the Text object is being freed as part of a window, from windowWillClose:).  If necessary, one could subclass the Text object, implement the free method to set an NXTextStyle with no tabs, then call [super free] and have this class poseAs: the Text object.
KBNS.10.2.009_o3.0o Suggestion, copying from an empty selection NXBeep() when a Copy (or its derivative Cut) is done from an empty selection (just the insertion bar visible): the pasteboard contents have not been affected.
KBNS.11.1.019_o3.0±3.1o Funny harmless bug, reported by Johan LorrÝ Just try the up and down arrow keys while in a portion of text of size 1: they won't have any effect. The left and right arrow keys work fine.

/Object/Responder/Window
KBNS.10.2.013_o3.0±3.1o appIcon as a destination doesn't work, reported by Jeremy_Slade in a 1993-03-31 comp.sys.next.(bugs/programmer) posting KBNS.11.1.rev (confirmed for 3.1 black by Subrata_Sircar)
When launched from WM (whether that be from a file viewer, the dock, or from open), an application's appIcon's PostScript window belongs to the same context as all other such windows, which is the same as that of the dock itself. Every event is channeled to Workspace. Command-dropping things onto such an appIcon invokes Workspace's file opening mechanism app:openFile:type: with the appIcon's application (instead of the application associated with the file's extension), whether the application is currently running or not (appIcon in the dock): any event is channeled to Workspace. The downside: apart from drawing onto it, the appIcon is dead as far as the application itself is concerned (it cannot accept any drag-drop items, it cannot implement any active GUI elements).
When launched from a shell, including from gdb, the appIcon's window belongs to the application's context. Any event on it is channeled to the application itself. No provision was made in 3.0 (can anyone verify this; 3.1 works correctly) for emulating the command-dropping behaviour of ``normal'' appIcons, which can be considered a bug. The upside: NXDragging works as expected if the appropriate methods are implemented by NXApp or [NXApp delegate] (I'm not 100 % sure of that, I should check it).
For both cases, the appIcon's delegate is nil (in the cases I tested), and cannot be set: although this is not explicitly documented (Õ la NeXT), setDelegate: is implemented to refuse this message for NX_MINIWINDOWSTYLE, NX_MINIWORLDSTYLE and NX_TOKENSTYLE windows (an appIcon is NX_TOKENSTYLE). So this is another aspect that inhibits accepting drag-drop materials, for applications launched the NeXTSTEP way (there are ways to cheat, like temporarily changing the style of the window, directly accessing the Window's memory, object_setInstanceVariable([NXApp appIcon],"delegate",(void *)self), but these don't appear to fix things and they are certainly not supported).
Bummer. Why would it be against NeXTSTEP guidelines to accept other materials than just command-dropped files, one at a time (another limitation/bug)? There was a /NextDeveloper example in NS_2.1 which demonstrated just this ability, with an animated appIcon.
So far my analysis.
Further symptoms: Jeremy_Slade even says (for registering ``normal'' appIcons for NXDragging) that ``after quitting the first time I started it, and restarting, WM gives the erorr 'window xxx already registered' '', but I did not experience this (we both unregistered at appWillTerminate: time). I furthermore experienced that command-dragging didn't work anymore (I didn't check yet whether this is reversible by unregistering during program execution).
Jeremy_Slade's workaround (he calls it a ``kludge''): use another window on top of the appIcon. Charles_d'Harcourt posted some code that could help (on NeXT-prog@cpac.washington.edu, 1993-08-12, where this matter was also raised by Subrata_Sircar).
KBNS.00.0.045_o3.0o tryToPerform: bug, not verified.
Date: Thu, 8 Apr 1993 18:35:17 GMT
From: greg@afs.com (Gregory H. Anderson)
Subject: tryToPerform: with: bug in Window class

There is a subtle bug in the Window implementation of tryToPerform:with:
when a Window is acting as its own delegate. Here's how we found it:

We have noticed for a long time that if a user performs a keyboard save
operation (Cmd-s) when the window is not in a savable state (missing data,
etc), they get an error panel twice. We never figured out why until this
week. Here's what's happening:

1) The user presses Cmd-s, and the menu looks for a -save: responder by
starting a tryToRespond:with: sequence.

2) When it gets to our Window, the delegate (where delegate == self) is
given a chance to act. It accepts the action, but the window is not
savable. The user sees a warning panel with a message about what's missing
or wrong. We indicate the "bad or missing data" status programmatically by
returning nil.

3) The Window interprets the nil return from the delegate as meaning "I
cannot (or do not wish to) respond", instead of the intended "I am
responding, and the operation cannot be performed." Therefore, it gives
self an opportunity to respond, which causes a repeat of step 2, including
another error panel for the user.

This problem has existed as far back as we can test. The fix is simple: if
a Window is acting as its own delegate, it should NOT give the delegate a
chance to respond, it should simply go straight into self. Since we
override the Window class anyway, we did this:

- (BOOL)tryToPerform:(SEL)anAction with:anObject
  {
  if (delegate &&
      (delegate != self) &&
      ([delegate respondsTo:anAction]) &&
      ([delegate perform:anAction with:anObject] != nil))
    return YES;
  else if (([self respondsTo:anAction]) &&
      ([self perform:anAction with:anObject] != nil))
    return YES;
  else
    return [nextResponder tryToPerform:anAction with:anObject];
  }
	
This preserves the existing behavior without the bug. If you do not
override Window, you could implement this in a category.

--
Gregory H. Anderson          | "History, despite its wrenching pain,
Commander-in-Chief           | Cannot be unlived, but if faced
Anderson Financial Systems   | With courage, need not be lived again."
greg@afs.com  (Nextmail OK)  | -- Maya Angelou, "On the Pulse of Morning"
KBNS.00.0.044_o3.0o KBNS.11.1.rev (XXX include some more information) setTrackingRect:inside:owner:tag:left:right: design bug
This method should return a tag instead of taking one as an argument: now the burden of avoiding DPS tag clashes (the matter should have been solved at this level, really) is laid on the users of the AppKit. In case of a clash, the newer tracking rectangle wipes out the older one. For cursor rectangles, Window does the administration by itself, so why not for tracking rectangles? Now the programmer has to devise an ad-hoc workaround, but what if the particular class is not available in source form? General workaround: not found (I considered riding piggyback on cursor rectangles, but I couldn't find a way to get mouseExited: events; a defaults ``dipswitch'' wouldn't work for multiple instances of the same class, ¼). Cure: (int)setTrackingRect:inside:owner:left:right:.
KBNS.00.0.043_o3.0o KBNS.11.1.rev Suggestions about clicking on Windows and double-clicking on appIcons.
A click in the contentView of a key Window it shouldn't bring it to the front anymore: this way auxiliary Windows can be kept (partly) in front of the key Window. For clicking in a Window's title bar, no modifier keys is makeKeyAndOrderFront:, or just dragging for Panels (as in NS_3.0) and all other Windows that are nearer to the user than the key Window (extension of the concept); command is makeKeyWindow (not orderBack: as in NS_3.0), there is no such thing as make key and order back. The three modifier keys on the left don't affect Window status, only the order, in the same way as the keys are laid out on the keyboard: control for orderBack:, shift for no change (so Windows can be freely dragged about), alternate for orderFront:. The present distinction between clicking and dragging for Panels should be extended for all Windows partly obscuring the key Window.
As for double-clicking on an appIcon (XXX not definitive):
no key: make active, orderFront:keyWindow only (as before NS_3.0)
command: make active, don't rearrange Windows (this and cmd-n would create a new document without disturbing the screen otherwise)
alternate: make active and bring all Windows to the front (as in NS_3.0 without modifier key)
alternate+shift: as alternate, plus hide other applications
control+shift: hide this application
control: move all Windows to the back, activate frontmost app
KBNS.11.0.006_o3.0o Suggestion, resizing. Luckily, making a Window very wide is not disallowed like on X-Motif (purpose: trying to visualise something that is very wide, like a complicated formula, in an application that does not provide a horizontal scroll bar, like Edit, which doesn't even allow to switch wrapping off for RTF); making a Window very high is unfortunately not possible, not even with a tool like VirtSpace, although this is understandably the result of a provision to recapture the drag bar (aka title bar) of unfortunately resized Windows (purpose: using the Mandelbrot demo to make screen background images). For horizontal rezising, ultimately the Window will exceed some DPS window size limit. At that time, something like the following appears on the console:
Jul 30 10:41:45 flexus Edit[3895]: DPS client library error: PostScript program error, DPSContext 7c25c
Jul 30 10:41:45 flexus Edit[3895]: %%[ Error: rangecheck; OffendingCommand: placewindow ]%%
and the dashed outline disappears (no harm is done). It would be more elegant to prevent this in the AppKit, windowWillResize: style.

/Object/Responder/Window/Panel
KBNS.00.0.046_o3.0o Suggestion. In any modal Panel, hitting the Esc key should have the effect of searching down the View hierarchy for a Button with the text NXLocalString("Cancel", ¼) and performClick:ing it. If Panel is adapted, this will immediately update all existing apps.

/Object/Responder/Window/Panel/FontPanel
KBNS.00.0.047_o3.0o Suggestion, detail. Font Panel Set button should be disabled whenever the font currently selected is the font that's also currently used. Previously, this was indicated by the Preview View actually displaying that font, but now, if Preview is shift-clicked, there is no distinction anymore, and from habit one expects the previewed font to be also used.
See also in category Unix, subcategory /usr/bin/buildafmdir.
KBNS.00.0.048_o3.0o Suggestion, detail. The FontPanel's preview TextField surely should put NXRTFPboardType material too on the Pasteboard, not just the bare characters¼ From Bug_NeXTec 1897.

/Object/Responder/Window/Panel/Menu
KBNS.00.0.049_o3.0o Suggestion, important. When a menu is called up with the right mouse button and the mouse is dragged to the title bar of any submenu and released there, that submenu should remain on the screen. This will enable the user to keep the menu off-screen and make it unnecessary to drag it first onto the screen and back off again to temporarily get a detached submenu.
KBNS.00.0.050_o3.0o Suggestion, detail. Aha, the Services menu is now not only determined at launch time (a big relief). Still, the Services command has to be touched to reflect any changes. And if the Services menu also resides on the screen somewhere (detached), and if a submenu is selected, this submenu is popped off at the change. Repair: apply changes at all times, and make sure any selected submenu stays on. It would be nice if the WM carried an indication ``Making Services'' or something while any application is not fully updated, and the console warning ``Some other application is also making services'' should be omitted.
KBNS.00.0.004_o3.0o A bug? XXX If you have experienced inconsistent (non-)appearance of Services you define, confer with Beth_Katz to come up with a clearer description of the problem. You might first read her contributions to NeXT-prog@cpac.washinton.edu of 1993-01-26 and 1993-02-01: Providing multiple services. If you can describe a consistent bug, tell me.

/Object/Responder/Window/Panel/Menu/PopUpList
KBNS.11.1.016 Small design error Even with Menu's new feature of scrolling into view, a PopUpList should still appear with as much as possible of its surface immediately visible: minimal action. Now the user is required to do some physical action just to acquire information (``What are my options?'') that should be immediately apparent. (BTW, I've read the entry in the ReleaseNotes.)

/Object/Responder/Window/Panel/NXColorPanel
KBNS.00.0.051_o3.0o
Dropping an colour swatch with alpha in the swatch bar of a non-alpha application should work, to allow the user to rearrange the bar. Now, whatever location such a swatch is dropped on changes to black (even if the swatch originated from that location).
It would be clearer if the cursor would indicate whether the accepting View or Window will accept the alpha information from the swatch or not.
Also, what happens to the colour swatch when a copy is dragged out differs between non-alpha and alpha applications and is very difficult to understand. It is probably caused by some lack of care by whoever programmed this.
KBNS.00.0.052_o3.0o Smallish bug. In the preselections of greys, 83.333333¼ is rounded to 84. That gives a dithering defect for black with 5/6 opacity on the non-colour Megapixel Displays at least. It should be rounded to the maximum PostScript resolution (a beautiful hint to the user of how much precision can be specified), or to 83 (also in other places). See also with Text.
KBNS.00.0.053_o3.0o Reported by Johan LorrÝ. If one selects a colour (grey) elsewhere, and if one then goes to the CMYK inspector, this colour (grey) is generated by (equal) values of C, M and Y, with Black always zero (even for pure greys)! This is not how one should print colours with low saturation: it's expensive in colour ink, and blacks become a dirty smudge. The problem is printing, in this case, on a DeskJet 500 or something colour printer: he has to always reset the colour to CMYK with only the Black selected in an RTF'ed version of his document, to print with reasonable speed. It should not be the printer driver's (Dots or something) responsibility to compensate for this (to avoid misunderstanding: it doesn't!).
KBNS.00.0.054_o3.0o Little tiny bug, moved here from Edit.app. If a Brightness value is typed in the TextField associated with the ScrollBar and a text window is selected, the panel is left in an incongruous state. I consider this a bug because the TextField loses its first responder status: if the panel is made key again, and a number is keyed in, only NXBeep()s can be heard! Use a TextField subclass with resignKeyWindow defined to refuse (preferably?) or to process the value.

/Object/Responder/Window/Panel/NXHelpPanel
KBNS.00.0.055_o3.0c Littly bug, reported by Subrata_Sircar and verified by Raf_Schietekat, reported to be cured in 3.1 by Subrata_Sircar
In a help panel in a self-produced application (not WM and Mail at least), tested with minimal additions (just dragging in the IB Info menu and ``Add Help Directory'' from PB, the first page, ``Getting Started'' is disabled. Invoking the panel starts with the first subpage, and returning to the main page from the ``Adjust brightness and volume'' page's ``Getting Started'' button doesn't work either.

/Object/Responder/Window/Panel/SavePanel
KBNS.00.0.056_o3.0o Bug. Some methods (like -directory) produce false results when this panel is running a modal session. More details expected, e.g., from Montgomery_Zukowski.
KBNS.10.2.021_o3.0o Shortcoming, runModalForDirectory:path file:filename This method shouldn't hide the contents of a directory like a .nib if it is specified in path, only if that bundle is specified in filename (regardless of doesTreatFilePackagesAsDirectories). Furthermore, .app and .debug contents are always exposed, and that is probably a bug.

/Object/Responder/Window/Panel/OpenPanel
See KBNS.10.2.023

Compiler
Header Files
KBNS.00.0.064_o3.0±3.1o Reported, and verified (also for 3.1), by Subrata_Sircar, from Mark_Adler, Bug_NeXT.37670, KBNS.00.0.066_o3.0o Possible cure proposed by Robert_Brown, Bug_NeXT.40280
-traditional causes <stddef.h>, <math.h> and several other header files to fail.
flexus> cat > prog.c
#import <stddef.h>
flexus> cc -traditional prog.c -o prog
/NextDeveloper/Headers/ansi/machine/stddef.h:11: #include expects "fname" or <fname>
flexus>
Here is part of a comp.sys.next.programmer posting from Kate_Smith (Kate_Smith@next.com) explaining the problem, and giving a machine-dependent workaround which might help:
From: Kate Smith <Kate_Smith@NeXT.COM>
Date: Wed, 30 Dec 92 14:43:55 -0800
Subject: [37670] @!compiler problems - something about the comments in math.h

We have a bug with our machine-dependant include files when using the  
-traditional flag.  We have an include file that is used to build the name of  
the machine dependant include file that really needs to be included.  This  
file uses an ansi directive that is invalid in traditional mode.

So in order for you to get the math.h file included, you need to specify  
the fullpath in your program, or modify math.h to include the proper file.

So your program would look like this:
 	#include </NextDeveloper/Headers/ansi/m68k/math.h>
 	main()
 	{
 		double x;
 		x=cos(1.2); 
 		printf("%f\n",x);
 	}

 Or you could change math.h to include  
/NextDeveloper/Headers/ansi/m68k/math.h instead of doing the machine  
dependant stuff.
This workaround will fail for headers which include others, thinks Subrata_Sircar.
Robert_Brown:
``The file /usr/include/architecture/ARCH_INCLUDE.h should conditionalize the definition of the ARCH_INCLUDE macro on __STDC__.  If this is not done, then one can't compile traditional C code.
Here is my corrected version of the relevant part of ARCH_INCLUDE.h.
#ifdef __STDC__
#define	ARCH_INCLUDE(prefix, suffix)	\
	#prefix __TARGET_ARCHITECTURE__ "/" #suffix
#else
#define	ARCH_INCLUDE(prefix, suffix)	\
	"prefix" __TARGET_ARCHITECTURE__ "/" "suffix"
#endif'' Quoted literally from Robert_Brown, except for a little formatting. I guess you can try this yourself. Reports on whether this is a good thing to do are welcome.
KBNS.00.0.065_o3.0c Reported and verified by Subrata_Sircar, from Antonio_Pascoa's 1993-01-15 comp.sys.next.bugs posting, reported to be cured in 3.1 by Subrata_Sircar
From: apf%io.fct.unl.pt@Princeton.EDU (Antonio Pascoa)
Subject: HZ
Date: 15 Jan 93 17:49:31 GMT

The header <bsd/sys/param.h> fails to include <bsd/m68k/param.h> where the  
definition for HZ is. BTW the manual says 60 when in fact it's 64.
Subrata_Sircar: ``This is quite true.  I'm not sure what the significance is, though since I've got no idea what HZ would be good for.''
KBNS.00.0.067_o3.0c 2 non-ANSI comments in /usr/include/ansi/m68k/stdarg.h, reported by Robert_Brown, Bug_NeXT.36045, reported to be cured in 3.1 by Subrata_Sircar This seems not to be caught by -ansi -pedantic, although it isn't ANSI C. So, also a bug in NeXT C compiler? These are the only such comments under /usr/include/ansi. A list of troublesome "//" in other headers that can reasonably be used in an ANSI-C program, anyone?
KBNS.00.0.068_o3.0o -ansi -pedantic (should be conditionalised on __STRICT_ANSI__, not __GNU__, right?)
One warning from compiling <ansi/ansi.h> with these options: /NextDeveloper/Headers/ansi/stdlib.h:62: warning: ANSI C forbids const or volatile functions
The following errors may be errors in their own right, but they would not have occurred if mc68000 weren't undefined by -ansi, on line 59 of /NextDeveloper/Headers/bsd/sys/wait.h (__mc68000__ should be used instead or also):
In file included from /NextDeveloper/Headers/bsd/libc.h:14, from [...]:
/NextDeveloper/Headers/bsd/sys/wait.h:65: warning: bit-field `w_Termsig' type invalid in ANSI C
/NextDeveloper/Headers/bsd/sys/wait.h:66: warning: bit-field `w_Coredump' type invalid in ANSI C
/NextDeveloper/Headers/bsd/sys/wait.h:67: warning: bit-field `w_Retcode' type invalid in ANSI C
/NextDeveloper/Headers/bsd/sys/wait.h:81: warning: bit-field `w_Stopval' type invalid in ANSI C
/NextDeveloper/Headers/bsd/sys/wait.h:82: warning: bit-field `w_Stopsig' type invalid in ANSI C
/NextDeveloper/Headers/bsd/libc.h:151: warning: ANSI C forbids const or volatile functions
KBNS.00.0.069_o3.0o Comments about comments in <mach-o/nlist.h> ``Only symbolic debugging entries have some of the N_STAB bits set and if any of these bits are set then it is a symbolic debugging entry (a stab).'' This would be a fine joke (stating an equivalence by giving two implications, but forgetting to reverse the direction in the second part; well, it would be a very irresponsible joke), but more likely the author was trapped himself. Workaround: rather than trying to be smart with logic, say something simple like ``Non-zero values of the N_STAB field are reserved for symbolic debugging entries, with values of the entire n_type field given in <mach-o/stab.h>.'' We'll understand. While I'm at it, the possessive form of it is its, not it's, the possessive form of who is whose, not who's. More useful would be to explain the world of n_type values more clearly (why the weird values of the constants), or give a pointer to some proper documentation. A good start is to say ``Values of n_type&~N_EXT for non-N_STAB entries.'' rather than ``Values for N_TYPE bits of the n_type field.'', and to move the part about n_sect to before the dichotomy.
KBNS.00.0.074_o2.1±3.0o Macros that look like functions. The MACRO_BEGIN/MACRO_END stuff in cthreads is often very useful, because this allows macros to be followed by a semicolumn and behave correctly in an if-else tree (I don't know where this is documented, it was in 2.1 anyway). But it is not possible to use the comma operator on such macros! Use ``inline'' instead, or explain why this is not an option (if not).
KBNS.10.3.031_c3.1o NCARGS in <sys/param.h>, ARG_MAX in <ansi/limits.h>, reported by Charles_Fu on NeXT-prog@cpac.washington.edu, I verified that things are OK on 3.0, Charles_Fu isn't entirely happy with this report and I'm waiting for his changes KBNS.11.0.rev Subrata_Sircar says that 3.1 black ``supports 40960 as defined'', I don't know what Charles_Fu tried XXX
These constants are used with execve(2). <ansi/limits.h> is machine-dependent on NS_3.0 at least, but that may be irrelevant. Charles_Fu found that execve(2) only supports NCARGS=39762, not 40960 as defined. ARG_MAX is defined as the same value that NCARGS has, but:
``[¼] ARG_MAX is the POSIX equivalent for NCARGS, although under HP-UX ARG_MAX = NCARGS-2 so there may be some slight difference in the technical definition.
I tested for the correct value of NCARGS under 3.1 Lightning 4H on my Motorola NeXTstation color (non-turbo). I would think it unlikely that the value would be different on an Intel but have, admittedly, not confirmed this.'' (additional information)
Charles_Fu's test program, modified by me to give a meaningful output for correct implementations (by introducing TRYNCARGS):
#import <libc.h>
#import <errno.h>
#define TRYNCARGS (NCARGS+10)
#define MAX_SINGLE_ARG_SIZE     1024
#define ROUNDUP(i,j)    ( ( (i) + (j) - 1) / (j) )
#define NUM_ARGS        ROUNDUP(TRYNCARGS, MAX_SINGLE_ARG_SIZE)

int
main(void)
{
  int     i;
  unsigned int j;
  char  **testArgv;
  const char *testEnvp[] = {NULL};

  /* Include space for terminating null. */
  testArgv = malloc((NUM_ARGS + 1) * sizeof(char *));

  /* This is not as efficient as it could be. */
  for (i = NUM_ARGS - 1; i >= 0; i--)
  {
    testArgv[i] = malloc(MAX_SINGLE_ARG_SIZE);
    memset(testArgv[i], '0', MAX_SINGLE_ARG_SIZE - 1);
    testArgv[i][MAX_SINGLE_ARG_SIZE - 1] = '\0';
  }

  for (j = TRYNCARGS - 1; j; j--)
  {
    testArgv[j / MAX_SINGLE_ARG_SIZE + 1] = NULL;
    testArgv[j / MAX_SINGLE_ARG_SIZE][j % MAX_SINGLE_ARG_SIZE] = '\0';
    execve("/bin/echo", testArgv, testEnvp);
    fprintf(stderr, "execve(): %s, NCARGS=%u\n", strerror(errno), j + 1);
  }
  return 1;
}

Preprocessor
KBNS.00.0.059_o3.0c Reported and verified by Subrata_Sircar, from Gerben_Wierda, reported to be cured in 3.1 by Subrata_Sircar
From: wierda@ltb.ltb.bso.nl (Gerben Wierda)
Subject: Watch out for this preprocessor bug in 3.0:
Date: 24 Sep 92 08:50:01 GMT

The smart preprocessor in 3.0 mistreats:

#if X

if X is something with the lowest 8 bits zero (like 256, 1024 etc) but not
zero itself. It will produce a false anyway.

This bug has been reported to NeXT.

Remedy for now:

Use the gnu preprocessor, so -cpp-traditional (or whatever, I am not at my
NeXT now), or write your stuff as

#if X != 0
KBNS.10.2.012_o3.0c Preprocessor, reported by Alexander_Lehmann in a 1993-04-22 comp.sys.next.(programmer/bugs) posting, and this is just my verification of it (reported as cured in 3.1 by Subrata_Sircar):
flexus> cat > LehmannTest.c
#define INCLUDEFILE "stdio.h"
#include INCLUDEFILE
flexus> cc LehmannTest.c
cc: Internal compiler error: program cpp-precomp got fatal signal 10
flexus> 
KBNS.10.2.048_o3.0±3.1o -MM flag doesn't work correctly, reported for 3.1 by Robert_Kedoin in a 1993-06-14 c.s.n.(bugs/programmer) posting, not verified
XXX Hey, -MM is supposed not to look at files included with <>!
Robert_Kedoin: ``I've run into the problem that Thomas Funke(thf@zelator.in-berlin.de) mentioned. Under 3.1, it seems that "cc -MM" fails to generate dependencies correctly for files which import precompile headers (eg. <appkit/appkit.h>)''
Actually Thomas_Funke referred to Art_Isbell, who said, among other things: ``Under NS 3.0, cc -MM was overzealous in creating dependencies by including all the static NEXTSTEP header files in dependency lists thus slowing compilation.'' (I verified this), and also described a different sort of failure for 3.1 PR1.
Some workarounds were discussed. Anyone to wrap this all up in a neat report?
KBNS.11.1.030_c3.1o From Douglas_Scott's 1993-10-06 c.s.n.p message
Douglas_Scott reported to NeXT that /usr/local/include isn't searched for system header files, and got a reply that this will probably be fixed in 3.2. Workaround: add -I/usr/local/include to flags. Urgent suggestion: include ~/Developer/Headers in the search path. And allow at least an admistrator to alter it.

Compiler proper
KBNS.00.0.057_o3.0c Reported and verified by Subrata_Sircar, from Henry_Flurry, reported to be cured in 3.1 by Subrata_Sircar
An optimisation error? Henry_Flurry: ``-O in compilation incorrectly optimizes assignment and then comparison of floats.''
Date: Tue, 8 Sep 92 16:28:11 -0400
From: henryf@imagine.com
To: Next Prog <next-prog@cpac.washington.edu>
Subject: Optimization bug (??) in 3.0 (RTF)

I've come across what we think is an optimization bug in 3.0.

Included is a directory.  The README briefly explains the bug.  The test shell script compiles the code and demonstrates the problem.

Please let me know if we've made an error.

A uuencode version follows this message. [Raf_Schietekat: flattened and using normal text.]

- Henry Flurry
- Imagine Multimedia, Inc.

README:
>>>>>
NextStep 3.0 release

-O in compilation incorrectly optimizes assignment and then comparison of floats.

Run the test script within this directory:  It compiles the source with and with out optimization, and then demonstrates the improper execution of the code on the opimized version.

It's fairly clear in the generated assembly where the compiler generates the wrong jump for the optimization.

- Henry Flurry
- Imagine Multimedia, Inc.
<<<<<

stuff.c:
>>>>>
int main (int argc, char *argv[])
{
    char	amEditing;
    float	tx,
    		ty;

    amEditing = (argc > 1 ? 1 : 0);

    printf("Argc: %d; amEditing: %d\n", argc, amEditing);

    if (amEditing)
    {
	tx = ty = 0;
    } else
    {
	tx = strlen(argv[0]);
	ty = tx * 2;
    }

    if (tx || ty)
    {
	printf("TRUE: tx:%f; ty:%f\n", tx, ty);
    } else
    {
	printf("FALSE: tx:%f; ty:%f\n", tx, ty);
    }

    return 0;
}
<<<<<

test:
>>>>>
#
	echo "# compiling without Opimization"
	echo "#	cc stuff.c -o stuff.opt"

cc stuff.c -o stuff.noOpt

	echo ""

	echo "# executing:"
	echo "#	stuff.noOpt"
	echo "# should be TRUE"
	echo ""

stuff.noOpt

	echo ""

	echo "# executing:"
	echo "#	stuff.noOpt arg1"
	echo "# should be FALSE"
	echo ""

stuff.noOpt arg1

	echo ""

	echo "# compiling with Opimization"
	echo "#	cc -O stuff.c -o stuff.opt"
	echo ""

cc -O stuff.c -o stuff.opt

	echo "# executing:"
	echo "#	stuff.opt"
	echo "# should be TRUE"
	echo ""

stuff.opt

	echo ""

	echo "# executing:"
	echo "#	stuff.opt arg1"
	echo "# should be FALSE"
	echo ""
	
stuff.opt arg1

	echo ""
	echo "# NOTE that this last one executes incorrectly"
<<<<<
KBNS.00.0.058_o3.0±3.1o Reported, and verified (also for 3.1), by Subrata_Sircar, from Ivo_Welch
Floating point comparison error?
From: ivo@NEXT.AGSM.UCLA.EDU (Ivo Welch)
Subject: cc problem and cure: comparison among doubles can produce wrong results
Date: 17 Oct 92 00:21:33 GMT


There is a floating point comparison problem with the C compiler, resulting
from the  interaction of compiler switches  with the 68040 CPU. If  you run
this program through /NeXTStep_3.0/bin/cc (July 21, 1992):

	#include <stdio.h>
	int main() {
	  double omega;  double decay= 0.02, rev=0.05;
	
	  fprintf(stderr, "Code Starts");  omega = (rev)/(decay);

	  fprintf(stderr, "\n OMEGA = %f ==> %d\n", omega, omega!=omega);
	  fprintf(stderr, " OMEGA = %f ==> %d\n", omega, omega!=omega);
	  fprintf(stderr, " OMEGA = %f ==> %d\n", omega, omega!=omega);
	}

the output is

	Code Starts
	 OMEGA = 2.500000 ==> 1
	 OMEGA = 2.500000 ==> 0
	 OMEGA = 2.500000 ==> 0

If you use #define isNaN(x) ((x)!=(x)), chances  are your  code may produce
incorrect results.

The cure is to use the compiler switch -m68040-only (on  the C compiler) or
-ffloat-store (either on the C or the C++ compiler).   (I believe the cause
of  the    problem  is  how  differences in   internal  and external/stored
precisions interact with  compiler optimizations.)  Of course, your  MFLOPS
rating may go down...

/ivo welch
KBNS.00.0.060_o3.0c Memory access exception, and a variable that disappears. Reported by James_McKelvey to Bug_NeXT (#38580), on comp.sys.next.bugs (copy), NeXT-prog@cpac.washington.edu (subset, case unsuccessfully discussed on this list before) all on 1993-01-26; summary of it and of results I obtained from James_McKelvey's test case follows (reported to be cured in 3.1 by Subrata_Sircar). A local variable of type int, depending on where it's declared (after some arrays if these aren't an integer number of longs in size, but apparently independently of permutation with some other adjacent int variables!), does not get included in the symbol table, and an address register for it is used without being properly initialised so that a memory access exception occurs. All of this with -g and without -O, and for both Obj-C (the verified example) and pure C (as stated by James_McKelvey in a subsequent communication). For more information and the test case, consult the comp.sys.next.bugs posting and its author.
KBNS.00.0.070_o3.0o Suggestion Don't let the compiler generate a -Wall warning for this:
  [...]
  #define CASE break;case
  #define DEFAULT break;default
  [...]
  switch(switchvariable){
    CASE 1: block1;         ----> unreachable code at beginning of switch statement
    CASE 2: block2;
    DEFAULT: blockother;
    }
  [...]
OK, I can use an ordinary case at the beginning. Still, a small correction to an excellent idea¼
KBNS.00.0.071_o3.0±3.1o Bug? Verified for 3.1 by Subrata_Sircar (single lines extracted from code)
#define BYTE unsigned char
#define CARDINAL unsigned int
  /*var*/ BYTE *message=NX_MALLOC(message,BYTE,PAGESIZE),digest[20];
  { /*var*/ CARDINAL i; for(i=0;i<20;i++) printf("%02x",digest[i]); }
shafile.c:51: warning: unsigned int format, int arg (arg 2)
I would think that digest[i] is unsigned char, which is more like unsigned int than like int¼ This workaround works:
  { /*var*/ CARDINAL i; for(i=0;i<20;i++) printf("%02x",(unsigned)digest[i]); }
    //!! (unsigned) to appease a buggy(?) compiler
KBNS.00.0.072_o3.0o Why? In a string constant (the things between " characters), this compiler accepts any byte but newlines, unescaped ", unescaped \ (although it gives some warnings for a NUL character). It should give warnings for all non-isprint and certainly non-isascii bytes too. (I haven't tested what happens outside ``character constants''.)
KBNS.00.0.073_o2.1±3.0o Consistency¼ If the compiler gives a warning for a comparison c<128 where c is a char on the basis that this always evaluates to true, it should also do this for c<256 if c is an unsigned char. Verification: see test program for KBNS.10.2.051. Other data types?
KBNS.10.2.051_o3.0c Bug with optimisation, reported by Uwe_Meyer-Gruhl in a 1993-06-15 c.s.n.(bugs/programmer) posting (NeXTPR-D 137), verified by me, reported to be cured in 3.1 by Subrata_Sircar
This source is adapted by me from Uwe_Meyer-Gruhl's report, and also illustrates KBNS.00.0.073:
This is optimising.c, the source:
#include <ansi/ansi.h>

int main(int argc,char argv[]){
  /*var*/
    char c;
    int i;
  c=126; c++; c++;
  /*all "unsigned" results indicate a bug*/
  printf((126<c)?"  c: unsigned\n":"  c: signed\n");
  i=(126<c);
  printf(i?"  c: unsigned\n":"  c: signed\n");
  #ifdef WITHPRINTINGTHEVALUES
  /* this is all right, it's just the tests on c above */
  /* and -O2 is affected by the presence or not of this statement */
  printf("c=%i\n",
          c      );
  #endif
  /*verify KBNS.00.0.073*/{
    /*var*/ unsigned char c_uns;
    if(c    <128) i=0;
    if(c_uns<256) i=0; /*why doesn't this produce a warning?*/
    }
  return 0;
  }
with this Makefile for your convencience:
all: optimising    optimising.O    optimising.O2 \
     optimising.pr optimising.O.pr optimising.O2.pr
	optimising
	optimising.O
	optimising.O2
	optimising.pr
	optimising.O.pr
	optimising.O2.pr
optimising:   optimising.c
	cc -Wall     optimising.c -o optimising
optimising.O:  optimising.c
	cc -Wall -O  optimising.c -o optimising.O
optimising.O2: optimising.c
	cc -Wall -O2 optimising.c -o optimising.O2
optimising.pr:   optimising.c
	cc -Wall -DWITHPRINTINGTHEVALUES     optimising.c -o optimising.pr
optimising.O.pr:  optimising.c
	cc -Wall -DWITHPRINTINGTHEVALUES -O  optimising.c -o optimising.O.pr
optimising.O2.pr: optimising.c
	cc -Wall -DWITHPRINTINGTHEVALUES -O2 optimising.c -o optimising.O2.pr
clean:
	rm optimising    optimising.O    optimising.O2
	rm optimising.pr optimising.O.pr optimising.O2.pr

ANSI C
KBNS.10.1.001_o3.0c -Wall -ansi -pedantic [Refined, thanks to Subrata_Sircar, who also reports it cured in 3.1.] One of the warnings of the -Wall family (warning: control reaches end of non-void function) is spuriously triggered for main() with exit(0); as its last instruction if exit() is declared as just extern void exit(int status); instead of extern volatile void exit(int status);. This is the case when -ansi is specified, because this defines __STRICT_ANSI__ in <stdlib.h>. -pedantic really has nothing to do with this.

Objective-C
KBNS.10.2.029_o1.0±3.1o @encode(long long) and @encode(unsigned long long) become just "", from Eric_Scott's 1993-06-03 c.s.n.(bugs/programmer) posting, verified for 3.0 by myself, for 3.1 by Subrata_Sircar
``[¼] a nasty ol' bug (verified for 1.0 and 2.1) that wasn't fixed in 3.0.''
KBNS.11.0.011_o3.0o Nasty bug that doesn't manifest itself if some style conventions are followed, reported by Dale_Amon on NeXT-prog@cpac.washington.edu on 1993-08-05, verified by me
``I uncovered the following while tracking down an interaction of a free class with some of my own stuff. The author had violated a standard, ie used Upper case for the start of a portion of a method name. This caused the compiler some confusion. Basically, Class names and each individual part of a method name are in the same name space. So "Text" Class will interfere with a method named mumble:moremumble:Text:mumblecube:
Here is a very short program that will not compile correctly. Just for giggles for those of you who are compiler freaks :-)
#import "objc/Object.h"
@interface aName : Object
{
}
@end
@interface Foo:Object
{
}	
- aName;
@end''

Objective-C++
KBNS.11.1.013_o3.0±3.1o Bug_NeXT.38347 Objective-C permissiveness rebuked when part of a cc++ compile, from a 1993-09-14 NeXT-prog@cpac.washington.edu message by Don_McGregor
Things like the following in an Objective-C header declaration are apparently allowed by the compiler
@interface ObjcObjectHeader:Object{
  short	dirty:1;
  short	storedInWarehouse:1;
  short	storedInDesk:1;
  int otherStuff;
  }
but they violate ANSI-C syntax, and that becomes apparent when part of a cc++ compile (if the header is included, inclosed in brackets and all). Simple correction:
@interface ObjcObjectHeader:Object{
  struct{
    short	dirty:1;
    short	storedInWarehouse:1;
    short	storedInDesk:1;
    } flags;
  int otherStuff;
  }
Cure: don't allow the style before the correction, not even in plain Objective-C (at least some headers in the NeXTSTEP dbkit distribution also use this style and they should then be corrected), or adapt cc++ (probably less preferred).

Not classified yet
KBNS.00.0.061_o3.0±3.1o Compiling with -pg for profiling breaks atexit(3) functionality. Reported by Henry_Flurry on NeXT-prog@cpac.washington.edu 1993-02-01 and a test case provided by him for this compilation, verified by me. Verified for 3.1 by Subrata_Sircar. The problem is that with -pg, exit(3) doesn't call atexit(3)-registered functions. Here's Henry_Flurry's test case, only slightly edited. Name the program test.c and execute the indicated commands in a shell, in test.c's directory. To work around it, ``subclass'' exit(3) to call both the normal exit(3) and, if gprof's special flag is defined, the undocumented _atexit(). Henry_Flurry has a less timid approach. Maybe someone could produce a script to easily patch gcrt0.o's exit()?
#include <ansi/ansi.h>
void myExitFunc(void)
{
    printf("Exit function was called\n");
}

void main(void)
{
    printf("Registering exit func\n");
    atexit(myExitFunc);
    printf("About to exit\n");
    exit(0);
}
--- Now the commands:
%cc     -Wall test.c -o testnopg
%cc -pg -Wall test.c -o testwithpg
%testnopg
%testwithpg
KBNS.00.0.062_o3.0o Reported by Subrata_Sircar, from Paul_Verket's 1993-02-15 comp.sys.next.bugs posting, not verified.
From: verket@venice.sedd.trw.com (Paul Verket - NeXTMail OK)
Subject: cc -fno-asm broken under 3.0
Date: Mon, 15 Feb 1993 02:48:27 GMT

In 3.0 the "-fno-asm" flag to cc does not allow one to use the name "inline" as  
a variable name as the man page states. The option performs as documented under  
2.0.
KBNS.00.0.063_o3.0c From Gerben_Wierda's 1993-03-22 comp.sys.next.(bugs/programmer?) posting, reported to be cured in 3.1 by Subrata_Sircar
Any comment? Verification?
Date: Mon, 22 Mar 1993 21:26:00 GMT
From: gerben@rna.indiv.nluug.nl
Subject: On request, the NS 3.0 cc bug (gcc 1.93)

/* As requested, this program shows a bug in gcc 1.93 */

/* This demonstrates a bug in gcc 1.93. (see below) */

/* The bug is gone in gcc 2.3.3 */

typedef unsigned long	OID;
typedef long		int32;
typedef unsigned long	uint32;
typedef short		int16;
typedef unsigned short	uint16;
typedef unsigned char	Boolean;

struct	attribute {
	OID	attrelid;
	char	attname[16];
	OID	atttypid;
	OID	attdefrel;
	uint32	attnvals;
	OID	atttyparg;		/* type arg for arrays/spquel/procs */
	int16	attlen;
	int16	attnum;
	uint16	attbound;
	Boolean	attbyval;
	Boolean	attcanindex;
	OID	attproc;		/* spquel? */
	uint32	attnelems;
	int32	attcacheoff;
/*	char	*attlock; */
};

/*
 *	SHORTALIGN(LEN)	- length (or address) aligned for shorts
 */
#define	SHORTALIGN(LEN)\
	(((long)(LEN) + 1) & ~01)

/*
 *	LONGALIGN(LEN)	- length (or address) aligned for longs
 */
#define	LONGALIGN(LEN)\
	(((long)(LEN) + 3) & ~03)


#define fetchatt(A, T) \
((*(A))->attlen < 0 ? (char *) (LONGALIGN((T) + sizeof(long))) : \
 ((*(A))->attbyval ? \
  ((*(A))->attlen > sizeof(short) ? (char *) *(long *) (T) : \
   ((*(A))->attlen < sizeof(short) ? (char *) *(T) : \
	(char *) * (short *) (T))) : (char *) (T)))

/* the "attlen < sizeof(short)" branch is `optimized to oblivion'. */

char *
testje(att, tp)
struct attribute *att[];
char *tp;
{
    return fetchatt(att, tp);
}

/*

*** COMPILER DIAGNOSTICS: ***
Reading specs from /lib/m68k/specs
gcc version 1.93 (68k, MIT syntax)
 /lib/m68k/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNU__ -Dmc68000 -Dm68k -DNeXT
-Dunix -D__MACH__ -D__BIG_ENDIAN__ -D__ARCHITECTURE__="m68k" -D__mc68000__
-D__m68k__ -D__NeXT__ -D__unix__ -D__MACH__ -D__BIG_ENDIAN__
-D__ARCHITECTURE__="m68k" tupbug.c /usr/tmp/cc001529.cpp
GNU CPP version 1.93 (68k, MIT syntax)
 /lib/m68k/cc1obj /usr/tmp/cc001529.cpp -quiet -dumpbase tupbug.c -version -o
tupbug.s
GNU C version 1.93 (68k, MIT syntax) compiled by GNU C version NeXT
devkit-based CPP 3.0.
tupbug.c: In function `testje':
tupbug.c:57: warning: cast to pointer from integer of different size
tupbug.c:57: warning: cast to pointer from integer of different size

*** COMPILER OUTPUT: ***
#NO_APP
.ext
	.align 1
.lobl _testje
_testje:
	link a6,#0
	movel a6@(8),a0
	movel a0@,a0
	tstw a0@(36)
	jge L2
	movel a6@(12),d0
	addql #7,d0
	moveq #-4,d1
	andl d1,d0
	jra L3
L2:
	movel a6@(8),a0
	movel a0@,a0
	tstb a0@(42)
	jeq L4
	movel a6@(8),a0
	movel a0@,a0
	cmpw #2,a0@(36)
	jls L6
	movel a6@(12),a0
	movel a0@,d0
	jra L7
L6:
	*** ?? Where is my other branch ?? ***
	movel a6@(12),a0
	moveb a0@,d0
	extbl d0
L7:
	jra L5
L4:
	movel a6@(12),d0
L5:
L3:
	jra L1
L1:
	unlk a6
	rts
*/
--
Gerben Wierda    [NeRD:7539]        Tel. (+31) 35 833539
  "If you don't know where you are going, any road will
  take you there." From the Talmud(?), rephrased in
  Lewis Carroll, "Alice in Wonderland".

Crashing These events are not reproducible (by definition of this category: the reproducible ones are classified elsewhere (also)), so I don't know how useful this all is¼ It may be interesting to note that I have only 8 MB in my system. Note that I reserve this category to myself.
Librarian.app
KBNS.00.0.148_o3.0o Generally. Still infuriatingly shaky, although in different ways¼ It still crashes sometimes. Still searching in the same thread sometimes, leaving the user with no control but killing the application altogether¼ and then I was still faced with Librarian and Librarian.app, both of which were dying forever in the Processes panel.
KBNS.00.0.149_o3.0o Specific occurrence of crashing. Oct 17 13:21:15 flexus Librarian[896]: objc: FREED(id): message isIndexed sent to freed object=0x18cb08
No more entries because I just don't use this anymore.

Installer.app
KBNS.00.0.075_o3.0o A crash¼ The application disappeared suddenly. I am writing this in the same login session: everything else is working fine (and this is no criticism!). Somehow the program made the wrong diagnosis. But then, it should not have failed at all¼ I was just expanding NeXTTeX.pkg from a compressed form in /NextLibrary/Receipts.
flexus# /NextAdmin/Installer.app/Installer &
[2] 1418
flexus# DPS client library error: Error while writing to connection, DPSContext 2c1e4, data -110
Exiting due to Window Server death
Oops, just now WM reported an Internal Error 1000. Maybe these two events are connected¼ But I must log out now !

Mach
It's nice that things now get saved in RAM and then recorded in /usr/adm/messages. But that should also apply to booting with a disk that is not in a clean state (for a system panic, that will almost always be the case, right?), so that one can check what files might possibly be affected. If it would then also be automatically presented on the console¼ Well, a better filesystem is welcome too¼
KBNS.00.0.076_o3.0o 1992-12-08.
Nothing extraordinary was happening. I was just using Digital Librarian.
Dec  8 21:04:43 flexus mach: panic: (Cpu 0) vm_page_activate: already active
Dec  8 21:04:43 flexus mach: NeXT ROM Monitor 2.4 v65
Dec  8 21:04:43 flexus mach: panic: NeXT Mach 3.0: Wed Jul 29 19:43:28 PDT 1992; root(rcbuilder):mk-127.15/BUILD/RELEASE_M68K
Dec  8 21:04:43 flexus mach:
Dec  8 21:04:43 flexus mach: Killing all processes rebooting Mach...
Dec  8 21:04:43 flexus mach:
Dec  8 21:04:43 flexus mach: NeXT ROM Monitor 2.4 v65
Dec  8 21:04:43 flexus mach: NeXT Mach 3.0: Wed Jul 29 19:43:28 PDT 1992; root(rcbuilder):mk-127.15/BUILD/RELEASE_M68K
Dec  8 21:04:43 flexus mach: FPU version 0x40
Dec  8 21:04:43 flexus mach: physical memory = 8.00 megabytes.
Dec  8 21:04:43 flexus mach: available memory = 6.96 megabytes.
Dec  8 21:04:43 flexus mach: using 16 buffers containing 0.12 megabytes of memory
KBNS.00.0.077_o3.0o 1993-01-15. While I was testing if an old bug was still present (about sort -u, featuring in this file too), a program was producing a file that was large beyond expectation (due to an error I made while trying to be smart), and it used up all my [¼] free disk space. When I saw trouble coming, I tried to find the window that contained the shell with the program, but it was too late. Suddenly, in the midst of window swapping, everything froze, except the mouse cursor. I could do cmd-cmd-~ (msg showed me a repeated "vnode-pageout: failed!\nIO error on pageout: error = 28\n"), but this would not even let me reboot or halt, I had to mon, which is as bad as alt-cmd-*, I think. I don't know what other systems do, but this calls for freezing user programs and giving root a shell to work in, like a monitor, bypassing PostScript. Why can't the swap system avoid failure by using the 10% space available to root only on a hard disk, and immediately freeze all user processes? Root could then free disk space, and nothing bad would have happened. Of course, other limits, and setting quotas would be even better.
KBNS.00.0.078_o3.0o 1993-03-16. Now I've had a total system stop, with two reports of uart overrun in the kernel messages. I was just dialing out with SoftPC. halt didn't work anymore, I had to mon. Nice. Real nice.

Mail.app
KBNS.00.0.079_o3.0o 1992-12-20.
I was innocently browsing through a (rather large) mailbox when the ``app'' suddenly decided it had had enough, while all the rest happily continued working. Nothing on the console (no core image of course). dwrite Workspace CoreLimit 25165824 (or some other size) can be used to generate core images for applications launched from WM, but how difficult can it be to automatically attach such a process to gdb before a core is generated?
KBNS.00.0.080_o3.0o 1993-01-17.
I was composing a message and Mail had just crowed about the availability of new Mail, when suddenly the app disappeared. Not only had the WS not died, no other program was affected.
Jan 17 08:39:36 flexus Mail[638]: DPS client library error: Error while writing to connection, DPSContext 7a288, data -102
Jan 17 08:39:36 flexus Mail[638]: Exiting due to Window Server death
Jan 17 08:39:53 flexus sendmail[5820]: netinfo sleeping: RPC: Timed out
Jan 17 08:39:58 flexus sendmail[5820]: netinfo waking
KBNS.00.0.081_o3.0o 1993-01-21. Just like that, no comment.
KBNS.00.0.082_o3.0o Mail.app sometimes corrupts Outgoing.mbox and crashes when trying to open it afterwards 1993-02-27 Mail has now managed to produce an Outgoing.mbox which will let it crash immediately when it tries to open it (Mail crashed immediately after successfully sending out a message). I've thrown it away since¼ Letting Mail crash under gdb (I'm saving space by not including the backtrace) shows that Mail crashed because of a memory exception in tm_to_gmt, 41 frames deep. Frames 41, 25 and 19 are all in main()!!! I don't think any program will call its own primary function recursively, so there must be something very wrong here. KBNS.00.0.083_o3.0o 1993-03-13 Same thing (I didn't investigate nor keep this mailbox, though)! KBNS.10.2.015_o3.0o Except for the circumstances of producing the corrupt file (I now had some trouble with hiwat being reached), the exact same thing happened, including the numbers mentioned.
KBNS.10.3.009_o3.0o Now Mail.app keeps crashing at launch time, because it has corrupted Active.mbox and can't live with it (after I deleted table_of_contents, things were OK again). This is with gdb (no appIcon visible):
Program generated(1): Memory access exception on address 0x0 (protection failure).
0x15fb8 in main ()
(gdb) bt
#0  0x15fb8 in main ()
#1  0xc742 in getLongName ()
#2  0xcc6c in getResourceDir ()
#3  0x13974 in openMbox ()
#4  0x166cc in main ()
#5  0x602e35a in -[Application run] ()
#6  0x156a4 in main ()

NetInfoManager.app
KBNS.00.0.084_o3.0o A crash. I was trying to create a New... domain, got a panel that I couldn't clone a domain with the same name as the tag on the server or something I didn't really understand. Split-seconds after that (I don't remember what I did next) the application disappeared.
flexus# /NextAdmin/NetInfoManager.app/NetInfoManager&
[1] 268
flexus# /NextAdmin/NetInfoManager.app/NetInfoManager &
[2] 5040
[1]    Done                 /NextAdmin/NetInfoManager.app/NetInfoManager
flexus# *** HashTable: count differs after rehashing; probably indicates a broken invariant: there are x and y such as isEqual(x, y) is TRUE but hash(x) != hash (y)
ps -aux | grep Edit
root      6280   2.2  2.5 1.52M  208K p1 S     0:00 grep Edit
rfschtkt   158   0.0 14.6 6.02M 1.16M ?  S     1:12 /NextApps/Edit.app/Edit -NX
[2]  + Bus error            /NextAdmin/NetInfoManager.app/NetInfoManager
flexus#
Attempting to reproduce this was very adventurous too. I started the program from a su root shell (to circumvent the nonsense that, according to the manual, a new domain can only be created by logging in as root: it's a lie (I did it this way), and it should not be necessary), created a New... domain as a clone of the local domain¼ and the program crashed with a core dump. Subsequent attempts intercepted my mistake gracefully. But then (actually I had my 1993-01-15 crash once again by generating more core files than shown here; more on that after this excerpt which was generated after I rebooted):
flexus> gdb
[¼]
(gdb) symbol-file /NextAdmin/NetInfoManager.app/NetInfoManager
[¼]
(gdb) target core /cores/core.6220
0x500c34c in clnttcp_call ()
(gdb) bt
#0  0x500c34c in clnttcp_call ()
#1  0x10d4c in ?? ()
#2  0x10a98 in ?? ()
#3  0xaf76 in ?? ()
#4  0xc92a in ?? ()
#5  0xcb1e in ?? ()
#6  0x502ec0e in -[Object perform:with:] ()
#7  0x605dd7e in -[Application sendAction:to:from:] ()
[¼] Maybe this is enough info to fix?
(gdb) quit
flexus> gdb /cores/core.6220
IOT trap (core dumped) This shouldn't happen! It's a reproducible bug.
flexus>
This was yet another time that I had to put knownbugsin3.0v7.rtf back on my shelf (I've not yet logged out normally between the crashes I've experienced), hint, hint, see elsewhere! And when I logged back in in single-user mode to secure my core.6220 (my rc.local script cleans out /cores), and just exited the root shell that was started, the boot process proceeded without having fschk'ed the disk! So I had to cmd-cmd-~ and reboot, to force a fschk. I don't think every system administrator should have to know or not forget not to complete the boot process by just exiting the single-user shell, without at least a clear warning, or better a question, or better an automatic fschk, or better¼ a replacement for this fschk trouble should be developed (like in Windows NT¼ grumble grumble).
KBNS.00.0.085_o3.0o Hanging. I opened a domain by tag, entering respectively nothing and rootdomain (the name of an existing domain on my machine) in the textfields. After one minute, NetInfoManager was still hanging, so I had to kill it.

Window Server
Keeps crashing while running 3View.app and the 3DReality demo. Probably any RenderMan stuff.
KBNS.00.0.086_o3.0o 1992-11-06.
[1] 1763
xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server "unix:0.0"
[1] 1781
xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server "unix:0.0"
XIO:  fatal IO error 32 (Broken pipe) on X server "unix:0.0"
      after 3764 requests (3762 known processed) with 0 events remaining.
      The connection was probably broken by a server shutdown or KillClient.
XIO:  fatal IO error 32 (Broken pipe) on X server "unix:0.0"
XIO:  fatal IO error 32 (Broken pipe) on X server "unix:0.0"
      after 24 requests (23 known processed) with 0 events remaining.
      The connection was probably broken by a server shutdown or KillClient.
      after 7766 requests (7745 known processed) with 17 events remaining.
      The connection was probably broken by a server shutdown or KillClient.
login:  fatal IO error 32 (Broken pipe) or KillClient on X server "unix:0.0"
Nov  6 16:25:32 Workspace[855]: Exiting due to Window Server death
Nov  6 16:25:29 flexus WM[855]: DPS client library error: Error while writing to connection, DPSContext c42c0, data -102
Nov  6 16:25:29 flexus co-Xist[2239]: DPS client library error: Error while writing to connection, DPSContext 138264, data -102
Nov  6 16:25:29 flexus co-Xist[2239]: Exiting due to Window Server death
Nov  6 16:25:30 flexus Monitor[859]: DPS client library error: Error while writing to connection, DPSContext 8e248, data -102
Nov  6 16:25:30 flexus Monitor[859]: Exiting due to Window Server death
My other programs too.
This is the output on the console. I was starting the co-Xist demo by double-clicking it (it had run once shortly before that, so some of the entries may stem from that session), and before the example programs had appeared on the screen I was trying to start some from a shell. I saw some outlines on the display, and when I started mousing around on the display, the mouse disappeared, the screen froze, and I was kicked out and presented the login panel.
KBNS.00.0.087_o3.0o Crashes again and again and again. (For those who know Ross Perot better than Multatuli.)

Workspace Manager
KBNS.00.0.088_o3.0o Crashing. I've had to bail out just now because of an internal error 1000. Why offer the option to continue by default? I was just opening an irresponsible (because of the performance dip involved, that is!) number of .tiffs. This sort of error happens very often, bringing everything down with it. It might be related to available RAM. This is a top-priority bug!

DBKit NS_3.0 only with indication whether 3.1 cured the problem, please.
/Object/DBModule
KBNS.10.3.019_o3.1o Compound relationship in DBValue crashes app upon fetch, reported by Art_Isbell, Bug_NeXT.?????, not verified.
``Using DBRecordList's getValue:forProperty:at: method to store the value of a compound relationship (comprised of more than one attribute pair) for use in DBModule's fetchContentsOf:usingQualifier causes an application crash with the following error message and partial stack frame dump:
Program generated(1): Memory access exception on address 0x1 (protection failure).
0x5007194 in strlen ()

#0  0x5007194 in strlen ()
#1  0x500c7f2 in NXCopyStringBufferFromZone ()
#2  0xb016e56 in _DBcoerceToString ()
#3  0xb0105d2 in -[DBGenericRecord stringValueForProperty:] ()
#4  0xb01c4f2 in -[DBValue(Private) _takeValueFrom:usingProperty:andType:]
#()
#5  0xb01c0ee in -[DBValue(Private) _setFromProperty:ofObject:] ()
#6  0xb015814 in -[DBRecordStream(Private) _prepareQualifier:] ()
#7  0xb0127a6 in -[DBRecordList fetchUsingQualifier:empty:] ()
#8  0xb0126ea in -[DBRecordList fetchUsingQualifier:] ()
#9  0xb02198c in -[DBFetchGroup fetchContentsOf:usingQualifier:] ()
#10 0xb024564 in -[DBModule fetchContentsOf:usingQualifier:] ()
The only workaround I have found is to create a DBQualifier using undocumented DBRelationship methods which I consider unacceptable for production code.''

/Object/DBValue
KBNS.11.1.022_o3.0o -copyFromZone does not account for subclasses, reported by Ivo_Rothschild on NeXT-prog@cpac.washington.edu on 1993-09-21, verified by me
The present implementation:
-copyFromZone:(NXZone *)zone{
  return [[[DBValue allocFromZone:zone] init] setValueFrom:self];
  }
should probably be:
-copyFromZone:(NXZone *)zone{
  return [[[[self class] allocFromZone:zone] init] setValueFrom:self];
  }
Workaround: include the second definition in the subclass or as a category of DBValue.


Devices Broadly: these topics just have so very much to do with devices that this is the best way to group them.
Removable volumes
KBNS.10.3.029_o3.0o Design bug or just poor implementation? Mounting removable media should be done with extreme care, because the device drivers reside in the kernel. They should be rock-solid, and be able to handle all kinds of error conditions. As implemented in NS_3.0 (and before), inserting a corrupted NeXT-format floppy causes a Mach panic, which is unacceptable.
KBNS.00.0.327_o3.0±3.1o Bug, reported on comp.sys.next.(bugs/programmer) on 1993-01-25, verified by Subrata_Sircar (who reraised it for 3.1) and myself for floppy (does it apply to floppies only or to all removable media?)
From: rhess@consilium.COM (Richard L. Hess)
Date: 25 Jan 93 09:35:44
Subject: Re: /etc/mtab permissions

>>>>> "Robert" == Robert Davis <davisre@sage.cc.purdue.edu> writes:
Robert>         This may have been mentioned before (I recently upgraded to
Robert> 3.0), but is there a workaround or fix for this: ejecting a mounted
Robert> floppy changes the permissions of /etc/mtab so that you can't do a df.

  I had the same problem.  It took me a while to figure it out, but I'd bet
that you have very tight permissions set on your "File Creation Mask".  If
you just use "Expert Preferences" (Unix) in the Preferences tool to open up
your permissions to allow "Group" & "Others" Read access, then you won't have
any problems with the permissions changing on /etc/mtab.  Evidently when the
eject script/program executes it runs as root and uses your default
permissions and so if your permissions are too "tight" you can't read
/etc/mtab after the floppy get's ejected.
KBNS.00.0.090_o3.0o Suggestion. Unify the man pages into one, treating the drivers somewhat as an object hierarchy.
KBNS.00.0.089_o3.0o Suggestion.
Every user should be able to eject a disk at any time the way disk -e <a device or any file or folder on that device> now does it, unfortunately available to root only. Doing cmd-e in WM, dragging a volume to the recycler, pressing the eject button on the CD-ROM drive (this now corrupts the operation of the device involved), a button on all new drives (floppies too), should do this: provide the user with a panel to choose whether to unmount the file system, or to just eject the disk, disk -e style.
Instead of presenting panels that query for a volume (often not specifying it, so that the user has to try different disks!), and not allowing any other disk to be used in the meantime (a big nuisance, the user has to keep swapping disk for tiny incomprehensible accesses, and has no control at all), there should be one panel, Processes style, that indicates all removable volumes with their status (physically present, processes waiting for it to be inserted, requests for a particular volume to be inserted). This panel should be presented whenever a particular volume is desired. Particular requests should be suspendible, not only cancelable (this now returns an error message to the accessing process), so that the driver can safely handle other volumes, even hitherto unknown volumes that are inserted and properly mounted. Volumes should get priorities: volumes of lesser priority are ejected first (maybe only after the user agrees in an alert panel).
I don't know if a volume is associated with a particular drive or not, but if it is, loosen that restriction so that it can be inserted in any drive that can handle the medium.

CD-ROM
KBNS.00.0.091_o3.0o Performance (not verified) A colleague copied the 600-MB Q2_92 demo software CD-ROM to his hard disk, and he says this operation lasted about 24 hours (theoretical limit at the CD-ROM's 150 kB/s: a little over 1 hour), with no other load on the system.

Floppy Drive
KBNS.00.0.092_o3.0o When the floppy won't eject¼ check out DiskEjectFix.compressed in /pub/Binaries at NeXT.COM (129.18.1.2). It expands into an RTFD document containing a description and workaround for this 3.0 bug: an executable with installation description. See also KBNS.00.0.011.
KBNS.00.0.093_o3.0o When a file is dragged from the NeXT file system to a DOS floppy, and it has a name with an initial capital letter, the copy operation is refused because of ``File error for /unlabeled/Capital: Invalid argument'', with ``unlabeled'' the floppy's label, and ``Capital'' the name of the source file. When multiple files are copied, names with an initial capital are singled out, and the rest is copied normally. This didn't use to be a problem. Cure: use panels that propose an adapted name that the user can edit.
KBNS.00.0.094_o3.0o DOS. Just save a file to a DOS disk and look at it in the Attributes Inspector. Chances are the date is way way off (I just saved a file and the calendar indicated 1961).

Keyboard
KBNS.00.0.095_o3.0o ADB problem, from NeXTWORLD EXTRA 1992-12. The new ADB keyboards have a different key-code interface, and mainly emulators (which want to map their codes to physical key positions and are not yet adapted to the new layout) have problems (Executor, SoftPC, co-Xist, WordPerfect). Did they ignore the keyData field maybe, or is it NeXT's fault? The respective firms should be consulted for patches and/or updates.

Serial Ports
KBNS.10.3.016_c3.1FIPo VERY SERIOUS PROBLEM which crashes the system, reported by Ian_Bainbridge on c.s.n.(bugs/programmer) on 1993-06-22, confirmed by two other people the same day (though maybe not the details)
``Since I use the NS/FIP machine I am on to access a larger system using SLIP it is [excruciatingly] frustrating when the entire system decides to just freeze up ever couple of hours for no apparent reason.
This never happens when the serial ports are not in use. I know this is listed in the Release Notes, but how about a FIX sometime soon, this renders the entire system I am using nearly useless since I can't connect it to remote networks using a modem, without making it hang.
To top it off, once hung it is REALLY hung, typing alt-numlock as suggested does nothing, the only thing to do is hit the reset button, which is getting a little hard on the hard disk after doing it two or three times a day.
Running fsck after this circumstances produces this message whenever I try to reboot or log out of the root account:
Raise RDP exception 6, code 3, subcode 0, C to continue
of coures typing C or c, produces an endless scroll of the above, with the only way to break out of it, again, hitting the reset button.''

Where things should go
KBNS.00.0.096_o3.0o Wish. Ultimately, it should be possible to use fixed writable media to cache other, slower media. Slower includes removable, because inserting a volume is a slow process. Then it would be possible to mount the operating system from a CD-ROM (just like that: mount the CD-ROM), and allowing the superuser (there are some integrity constraints), to specify which parts must be cached at all times, and for other parts, with what priority they must be cached. That would allow for graceful decay in performance in return for more disk space available to other purposes. The same should be available for data kept on network servers, so that a cache can reduce network traffic for heavily used data, without the superuser having to continually fine-tune. In the long run, this would include file systems mounted from remote sites, even over e-mail access. But there are lots of other things to be implemented first, sigh!

Distributed Objects
KBNS.11.1.005_3.0±3.1o Incremental memory leak, reported by Bradley_Head on NeXT-prog@cpac.washington.edu on 1993-08-24, Bug_NeXT.49040 (Thomas Burkholder of NeXT called it bug #21973 on NeXT-prog@cpac.washington.edu on 1993-10-05), verified using his test program (available from him and included in the original report) by me for 3.0, by ``a friend of [Bradley_Head's]'' for 3.1
IntroDistObjects.rtf says:
In both the useAnIntByReference: and useAString: methods, a pointer is dereferenced on the client side, and the resulting data is sent to the server.  On the server side, space for the data is allocated, and a pointer to the local data is received.  The server's allocated copy of the data is local in scope and will be freed by the system when the server's method returns.
This isn't true on 3.0 at least for strings: they are leaked in the server. Bradley_Head said that the leak occurs at the next invocation of the server's method, but I found that the leak is immediate.

Generally
Technically Speaking
KBNS.00.0.098_o3.0o Hey, this is supposed to be a multitasking operating system!
``Your inspector operates within the main thread of execution of the Workspace Manager application, so errors occurring with the inspector can crash the Workspace Manager, bringing with it all applications launched from the Workspace. '' (from NeXTSTEP documentation, no comment necessary)
KBNS.00.0.099_o3.0o Dynamically linking code.
It's nice to be able to link things into an application, but the catch is that they can only be unloaded in reverse order (FILO, or should that be LIFO?). Sometimes it's even worse (probably this won't change because of the FILO, which makes it difficult to reload one particular inspector only): ``Once an inspector has been loaded, it can't be unloaded without restarting the Workspace Manager (that is, logging out and back in again).'' Another catch is that there is no protection of Objective-C name space. This means that if 2 pieces of code use the same name for some purpose, neither one may function correctly (NeXT says as much in the documentation for Preferences). Two IB Palettes sharing some source files can't be loaded together: IB will crash (not refuse the second, crash), says Jonathan_Hendry (probable workaround: dynamically loading that code if it isn't already loaded, in both Palettes, not verified yet).

Around the File System
KBNS.00.0.101_o3.0o Little harmless bug flexus> od -x /NextLibrary/Literature/Shakespeare/.dir.tiff , reported by Robert_Brown, Bug_NeXT.33739
0000000  4d4d 2a08 09ff 0301 0101 0301 3001 0103 A TIFF should start with 0x4d4d002a or 0x49492a00, says version 6.0 documentation. This one is messed up and not displayed.
KBNS.00.0.100_o3.0o Little harmless error, /NextLibrary/Literature/Shakespeare/Plays/foo, reported by Robert_Brown, Bug_NeXT.33817 Should disappear.
KBNS.00.0.102_o3.0o Suggestion about wasted disk space. The right solution of course is to make a driver that mounts the NeXTSTEP_3.0 CD-ROM and caches the actually used parts, possibly also compressing things, and with some parts hardwired to the cache. But in the meantime, these are some disk space leaks (I'm sure there are many more):
/odmach: should be a link to /sdmach, because these are about 0.8 MB of identical bytes
/usr/lib/NextStep/Displays/NeXTdimension.psdrvr: who needs this 0.9-MB driver?
KBNS.00.0.103_o3.0o Suggestion, /NextLibrary Shouldn't contain writable parts, like Receipts, Documentation/ManPages, so that a system administrator can easily decide to NFS-mount it.

Suggestions
KBNS.00.0.104_o3.0o This is quite elementary. It should definitely be implemented. KBNS.10.1.014_o3.0o modification. Command-Volume Down shouldn't toggle, it should just Mute (that's what the indication says anyway). Use cmd-louder to unmute (ordinary clicks are not appropriate for this). Any click on a button should produce a panel flash (0.5 seconds or so) to indicate the current volume and mute status. And, of course, whenever the sound is muted, switch to using Visual System Beeps automatically, and make them noticeable! On the brightness buttons, make cmd-darker trigger screen saving.
KBNS.00.0.105_o3.0o Much more difficult. Provide status information on what the microphone is doing/has been doing, in the WM icon (less involved than introducing a LED). This includes the Public Sound Server status. BTW, a distinction should be made for listening on the microphone. That way it becomes easy to provide permission to play sounds and do computations without the danger of someone listening in. Intercom programs can still be developed: there just has to be a part that's launched by the receiver which can respond to the caller. Of course, this program should provide extensive protection to ensure that the receiver is always aware of anyone listening in. Likewise, there should be limited allowance to let somebody else use one's screen, like limited to some part of the workspace, or in a window or something. And sufficiently protected, of course.
KBNS.00.0.106_o3.0o Crowded home folder. Why not make it a guideline to create files named ~/.Apps/<application name> or ~/.Apps/<application name>/<whatever> instead of just ~/.<whatever> (or ~/.NeXT/.<whatever>, as some now seem to do)? Give the example with .commanddict, .pipedict, .mailalias, Terminal.svcs.
KBNS.00.0.107_o3.0o Booting with NIS¼ missing. It should be made as easy to proceed as with a NetInfo server missing, by presenting a panel that asks to continue by simply entering the letter 'c'. Editing a file in single-user mode is extremely unpleasant. (I remember this from 2.1, and the documentation doesn't indicate any change; I haven't tried it again, though.)
KBNS.00.0.108_o3.0o Release notes. Don't give extensive release notes for new items (only a pointer to the documentation), only for the ones that have only partly changed. Now, Distributed Objects and 3DKit require double reading, the former even duplicating a lot of stuff.
KBNS.00.0.109_o3.0o Very dubious. I don't think it should be possible to start up multi-user mode without being sure that the file system is clean. However, if one starts up in single-user mode with a dirty file system (which would cause a fschk normally) and just exits the shell presented, this is exactly what happens.

Hardware Specific
KBNS.00.0.017, KBNS.00.0.095, KBNS.00.0.213 and possibly others

IndexingKit
/Object/IXStore/IXStoreFile
KBNS.10.3.027_3.0o The promise of integrity is broken. Just try the StoreFile example, make some changes, and Quit the application. Then relaunch the application and try to reopen the file. No go¼

Lies
Misleading marketing. And there is so little marketing to be careful about :-(.
KBNS.00.0.110_o3.0o SCSI. Don't say NeXT has a SCSI-2 connector. Say NeXT has SCSI-1 with a SCSI-2 plug.
KBNS.00.0.111_o3.0o WYSIWYG. Don't present the MegaPixel screen as high-resolution WYSIWYG. It's just a shrunken 72-dpi screen: the PostScript engine isn't aware of its pixel pitch. It's impossible to assess the final printed page's fonts on most applications, even Preview.app doesn't allow for rescaling to true size.

Just carelessness?
KBNS.00.0.112_o3.0o ASCII. There are several places where NeXT apparently takes ASCII to be synonymous with its own NeXTSTEP encoding vector (NXAsciiPboardType, etc). This mess should be cleaned up: ASCII is from 0 to 127 and nothing more.
KBNS.00.0.113_o3.0o RTF. Make clear that NeXT doesn't implement RTF according to the Microsoft specification. Many control words aren't recognised, others are NeXTSTEP-specific, NeXT doesn't use the character set \ascii that it announces (I'm curious how a document that uses all NeXTSTEP encoding characters will be rendered on other systems). And Edit doesn't even issue a warning if a real RTF document is read, containing control words that it doesn't understand (every application should warn about loss of information).

MachKit
/Object/NXInvalidationNotifier
KBNS.10.3.010_3.0o Archiving NXInvalidationNotifier Objects, reported by Dan_Brown, Bug_NeXT.????? on 1993-06-20, c.s.n.b and c.s.n.p on 1993-06-18, verified by me.
Whoever programmed NXInvalidationNotifier forgot to reimplement write: and read:, not even as [self notImplemented:_cmd] (verified by looking at /usr/shlib/libsys_s.B.shlib, where this object resides; this illustrates a deficiency of inheritance for which I can't immediately think of any cure). The effect is that unarchived instances are just like newly instantiated ones, and freeing them raises the (undocumented!) NX_referenceAlreadyFreeException, which, if not caught by one's code, aborts the rest of the processing for the current event (right?). Dan_Brown's workaround:
-write:(NXTypedStream *)typedStream{
  [super write:typedStream];
  NXWriteTypes(typedStream, "ic", &refcount, &isValid);
  NXWriteObject(typedStream, funeralList);
  // RS: Dan_Brown found that listGate shouldn't be archived
  /* Archive object specific instance variables here. */
  return self;
  }
-read:(NXTypedStream *) typedStream{
  [super read:typedStream];
  NXReadTypes(typedStream, "ic", &refcount, &isValid);
  funeralList = NXReadObject(typedStream);
  listGate = [ [NXLock alloc] init];
  /* de-Archive object specific instance variables here. */
  return self;
  }

NetInfo
KBNS.10.3.034_o3.0o Grave security leak
The design of NetInfo does not provide security for the owner of a machine who temporarily becomes a network client (a student at university who brings his machine with him, the owner of a portable who wants to use the network's printer, ¼): the administrator of the network can easily create an account ``breakin'' with a password that he knows and the uid of the root account, to fully control all clients. The mistake is that NetInfo is conceived as a means to ease the life of a network administrator, not of some individual in that network. Workaround: don't become a network client (don't print, don't fax, don't ¼). Other workaround: nidump information from the network, filter it (with Edit), and niload it into a higher-level domain that you install on your machine for this purpose only (does this work, has anyone made any tools to ease this?). But then, what do I know about NetInfo?

/NextAdmin/Installer.app
Bugs (found in 3.0)
KBNS.00.0.114_o3.0o Bug. I just installed the clients of the Q2-92 eXodus demo (or tried to do so), and the check revealed no errors, so installation started. The package wanted to install some files in /usr/man/man*. These folders were present, but only as symbolic links to /NeXTSTEP_3.0/man/man*, so that they are only available when the 3.0 upgrade disk is inserted. If I am correct, Installer had no way of knowing they even pointed to folders instead of files. (What would it have done if they were files?) Anyway, whatever the reason, now the installation has failed, but there is no automated way to uninstall what is already installed. I will have to look at the log and laboriously delete everything. The thing to do is to make the check more robust, and allow partial installations to have a Receipt.pkg (with proper warnings), so that they can be properly deleted right after failure is detected or at any time after installation, i.e., even if the installer decides he can for the moment live with only the actually installed files. I consider this a bug because there is a check phase and it failure occurs without there having been any change to the file system in the meantime. (I will of course change the level of symbolic links to the individual man pages, but that changes nothing about this being a bug that can cause other failures.)
I checked, and Installer doesn't even care that folders it needs to write into are indeed folders. They can be symbolic links¼ and ordinary files!
KBNS.00.0.115_o3.0o Bug. I have just deleted the Q2-92 eXodus demo (or tried to do so) and only the not-absolutely-specified files were properly removed, i.e., the eXodus.app folder in /LocalApps. All the other files are still present, and I will have to remove them all by hand, in the case of the man pages (not collected in an X11 folder) a tedious affair. No warning was even issued. WHY?
KBNS.00.0.116_o3.0c Reported and verified by Subrata_Sircar, from Andrew_Athan, reported to be cured in 3.1 by Subrata_Sircar
No comments¼
Date: Thu, 8 Oct 92 22:54:18 -0400
From: athan@object.com (Andrew Athan)
Subject: Just to save you headaches (chunkPackage blues)

I've just sent this to bug_next:

chunkPackage does not work correctly when the argument to  "destDir" parameter within the script is a relative path.  This means that

/NextAdmin/Installer.app/chunkPackage some.pkg 100 -d ../chunked

will not correctly work.  It also means that the -d parameter must *always* be given and must *always* be an absolute path reference.

The cause of the problem is the

cd ${bigPackage}

line near the bottom of the script (above the while which moves the .Z chunks into .pkg directories...).  the $destPkg variable in the while loop is relative to the path before the "cd."  The while loop's boolean expression is thus relative to the path before the cd, but it in fact executes AFTER the cd.  This means that the while loop never executes.  That causes the code after the while loop to immediately execute, with $destPkg unset (causing the shell to complain).

From: doug_wiebe@next.com (Doug Wiebe)
> This bug occurs when the -d switch is not passed to chunkPackage or when
> "-d ." is passed. A workaround is to use the -d switch with an absolute
> pathname.
>
> Here are diffs for a fix:
>
> 117c117
> <     set destDir = .                   # OLD
> ---
> >     set destDir = `/bin/pwd`          # NEW
>
KBNS.00.0.117_o3.0c Very small bug, reported by Subrata_Sircar, Bug_NeXT.39689, reported to be cured in 3.1 by Subrata_Sircar
``There's an extra .pkg extension on Installer alert panels.''

Suggestions
KBNS.00.0.118_o3.0o A small change. How about two folders /NextLibrary/Receipts/Installed and /NextLibrary/Receipts/Compressed? A small change for a small gain. Well, that should be /LocalLibrary/Receipts/¼, of course (see KBNS.00.0.103).
KBNS.00.0.119_o3.0o Question, suggestion. Why does a compressed package have its formerly relative pathnames fixed upon the folder where it was first installed? If it would regain its virginal state, this would be a simple method to move it to a different location. Now it has to be deleted and reinstalled from the original distribution medium. Maybe I have missed something, if deleting a package is not the same as deleting its compressed Receipt¼ but I don't see any objections on the part of impeding illegal copying or anything. So?

/NextAdmin/UserManager.app
Bugs (found in 3.0)
KBNS.10.3.038_o3.0o Little harmless bug. Programs that try to be smart¼ It is possible to create an account ``breakin'' with a uid of 0 (see KBNS.10.3.034), so why should the program refuse to delete it (``Cannot delete the root account'')? In cases like this, explaining the ramifications of a decision before proceeding (if approved) is the way to go. Workaround: use NetInfoManager.

Suggestions
KBNS.10.3.037_o3.0o Network/Local panel for New User is merely confusing. New Group doesn't ask this question, so why would New User? Local is just the default choice in the network hierarchy.


/NextApps/Edit.app
Bugs
KBNS.00.0.120_o3.0±3.1o Little bug, window title, confirmed for 3.1 by Subrata_Sircar. Just do command ``ls /dev'' to see a very inappropriate window title.
KBNS.00.0.121_o3.0c Annoying ``feature'' (?) and bug, window title, reported to be cured in 3.1 by Subrata_Sircar. Moved here from AppKit Window. An Edit window's title bar should not interpret symbolic links, at most this could be a Preferences... setting. If I open /NextLibrary/Documentation/NextDev/ReleaseNotes/Contents.rtf where /NextLibrary/Documentation/NextDev is a link to /CD-ROM/NeXTSTEP_3.0/NextLibrary/Documentation/NextDev and /CD-ROM/NeXTSTEP_3.0 to /NeXTSTEP_3.0, I want to see the path I opened, not /NeXTSTEP_3.0/NextLibrary/Documentation/NextDev/ReleaseNotes/Contents.rtf. Together with the bad documentation of what happens when a file is saved (see with Documentation), this makes me very insecure about what will happen, especially since this is not consistent behaviour (if a file is itself a link, it is not parsed: /usr/lib/crontab opens as /usr/lib/crontab, but I don't know what happens in mixed cases). Another place where this goes wrong is /usr/adm/monthly.log, for example: this gives /adm/monthly.log, a non-existent file! [¼] The following, reported and verified by Subrata_Sircar, from Moises_Oliveira, sheds more light on this last matter:
From: oliverm@nevada.edu (Moises Oliveira )
Subject: Re: Pathname bug in Edit 3.0
Date: Tue, 13 Oct 1992 01:31:38 GMT

There is a set of three known bugs involving

/usr/bin/open
/usr/bin/openfile
and /NextDeveloper/Apps/ProjectBuilder.app

The bug is basically this: Someone decided that the /private
directory is something you shouldn't have to ever see.  If you try
to open a file under /private, the /private is stripped from the
name of the file you are opening.  Thus if you try to open a file
named /private/tmp/foo, it will munge the name to /tmp/foo.  Which
will work for things like /tmp, but not for other directories.

>For Example:
>% cd /usr/adm
>% open daily

/usr/adm is really /private/adm.  Thus it strips it down to
/adm/daily, which doesn't exist.  You also can't open stuff in
/usr/spool, /usr/preserve, /private/tftpboot, or /private/vm.

Again, Edit is not the problem, nor are the shared libraries. Raf_Schietekat: Maybe not here, but Edit exhibits this problem too! Just look in the __TEXT/__cstring section, open(file) and Edit have a string /private or /private/. NeXT, cut this meddling right now. It doesn't work without errors, and you're making it even more difficult to administer a system.

As far as /usr/bin/open and /usr/bin/openfile go, the easiest task
is to probably replace them with the 2.0 versions.  The 3.0 versions
have no new features, just new bugs. If you don't have 2.0 versions,
you can use a sector editor to patch out the /private string.
KBNS.00.0.122_o3.0o Bug, workaround. Edit isn't able to save its Page Layout... selections. Workaround: use dwrite Edit NXPaperType A4 or something. For other applications a similar thing probably. Maybe the easiest is dwrite GLOBAL NXPaperType A4. (See also under Preferences.app.)
KBNS.00.0.123_o3.0o Bug. It has now become possible to include other attachments than TIFFs and EPSs, but saving is another matter. Flat files are no problem, but for included folders (both ordinary folders and wrappers), a panel always comes up: NXRunAlertPanel("File System Error","Unable to save %s. File system error: no such file or directory","OK",NULL,NULL,<thefile.rtfd>). I always have to Save As... to a new name.
KBNS.00.0.124_o3.0±3.1o Annoying Utilities>Pipe... bug, confirmed for 3.1 by Subrata_Sircar. If the filter returns a non-0 exit value, the selection should not be replaced. Example: unexpand -6 | expand -2 when a silly person (me) thinks that unexpand has the full reverse capabilities of expand (why not?). This bug seems related to the size of the selection: for small selections the selection is replaced with the error message, for larger selections Edit tends to behave correctly (although the error message should appear in a Panel rather than on the console).
KBNS.00.0.125_o3.0o Harmless display bug. When some contraction arrows appear in a selected portion of text, and if one of the former arrows is expanded so that the portion below moves down, the arrows stay in place until the Text is refreshed because of scrolling (the false arrows appear in the window's Buffer!).
KBNS.00.0.126_o3.0±3.1o Document administration bug, confirmed for 3.1 by Subrata_Sircar. When saving a file to the same path as another window it has open, Edit doesn't take any special action. It should at least warn, and possibly automatically remove one window. Why would it behave differently than for a Load...? Similar precautions for a Save To...
KBNS.00.0.127_o3.0±3.1o Save All (pretty harmless, though disturbing), reported to be cured in 3.1 by Subrata_Sircar but I have still experienced it (XXX test again). With this command, Edit gets confused: when a file is saved later, Edit will report that it has been edited by someone else. Furthermore, is such a file is saved because its dirty window is closed by cmd-w, and if the Windows submenu is on screen, the Close Window command stays highlighted. Disclaimer: this diagnosis may be wrong, I have not put in the time to accurately verify my definition of the problem yet (which files are affected: only those that were dirty at Save All time, or all of them, or something else, and what is the influence of other history of Edit?). If you want to do this, please send me the results (of course, NeXT itself can do this best, with the source at hand, and fix at the same time¼).
KBNS.00.0.128_o3.0o Harmless display bug. I haven't been able to find out when this happens, but on various occasions, the Close Window command stays highlighted (I believe KBNS.00.0.127 describes a reproducible example).
KBNS.00.0.129_o3.0±3.1o Utilities bug, found by Johan LorrÝ (no e-mail), confirmed for 3.1 by Subrata_Sircar. If .commanddict or .pipedict has three tabs after a command (sufficient), then Edit thinks the middle tab is the key equivalent, and cmd-tab will invoke that command (the first command with this situation gets the cmd-tab equivalent). This is silly, of course, and should be corrected: multiple tabs should be allowed to make for a clean .Xdict file (well, this is the wrong user interface, of course).
KBNS.10.2.004_o3.0o Replace All. In an RTF document, doing Replace All will use the font of the first character of the first hit for all replacements, rather than the font of the first character for each individual hit. This is very disturbing: the user (if aware of this before the document is spoiled!) may have to click Search and Replace repeatedly.
KBNS.10.2.020_o3.0±3.1o Harmless though disturbing bug about File>Open..., confirmed for 3.1 by Subrata_Sircar When a range of files is opened, of which one is a camouflaged directory (e.g., a .nib or a .draw), the files that come after that directory are each spuriously reported not to exist (NXRunAlertPanel("File system error","Unable to open %s. File system error: No such file or directory",NULL,NULL,NULL,filename);).
KBNS.10.2.031_o3.0o Bug with ``Make ASCII'' (a misnomer, see elsewhere). An ellipsis (¼) is converted into oblivion () rather than to three dots (...) as NXToAscii() advertises.
KBNS.11.0.009_o3.0o Minute harmless bug. When a new file is saved to, e.g., a .m file, and subsequently miniaturised, the miniwindow doesn't get the appropriate icon (it does at Revert to Saved time).
KBNS.00.0.130_o2.1±3.1o Known to Bug_NeXTec as #2028 since 1992-06-26, REALLY BAD BUG, confirmed for 3.1 by Subrata_Sircar. If one uses a Pipe from the Utilities menu on a selection which is (partially) contracted, the contracted portions are excluded from the input to the pipe. This feature is mostly used for program text, which is also the most vulnerable to mutilation. The curious thing is that Services work correctly.
KBNS.00.0.131_o2.1±3.1o Bug, confirmed for 3.1 by Subrata_Sircar. When something is piped through Services, the text window doesn't realize it has changed (the close button displays an unbroken cross) (known to Bug_NeXTec as #1899 since 1992-05-08). Also when the colour of a selection is changed.
KBNS.00.0.132_o2.1±3.0o Using a Pipe Utility which calls open(file)(1). When piping a portion of text through a pipe which ends in open or openfile, a form of deadlock occurs, after an annoying (or alarming, for panicky situations) timeout solved by the display of a panel indicating failure. Unless a deadlock cannot occur, a separate thread should be used. Ad-hoc solution: to allow Command Utilities to use a selection as stdin.
KBNS.00.0.137_o3.0o KBNS.11.1.rev Undelete bug
Contracted portions that are part of a selection being deleted are irretrievably lost: they are not included in the text that is brought back into the document.

/NextLibrary/Documentation
KBNS.00.0.134_o3.0o NextDev/DevTools/04_Edit
The exported Services aren't documented!
KBNS.00.0.135_o3.0o NextDev/DevTools/04_Edit/_InteractingWithUnix.rtf $stripped still isn't documented. Clearly indicate that Utilities are executed in a sh, not a csh, that has first been cd'ed to the file's directory. I was really puzzled by some strange behaviour until I laboriously found out that this was the cause.
KBNS.00.0.136_o3.0o NextDev/DevTools/04_Edit/_SettingPreferences.rtfd
When the ªDelete backup fileº option is selected, Edit automatically deletes the previous version of a file when the current version is saved.  Click ªDon't delete backup fileº to retain the previous version of a file when you save the current version (if the previous version of a file is saved).  This backup file is saved under the original file name, but with a tilde (~) appended to the name.

If you try to save a file that's write-protected, you can do so by responding affirmatively to the confirmation panel that appears (as long as you own the file).  Check ªSave Files Writeableº if you want such write-protected files to lose their write-protected status when they're saved.
Lies, lies, lies!
When ªDelete backup fileº is selected, Edit possibly deletes two versions: the one on disk, and the one on disk with a tilde appended to it.
And it is very important to know when these previous versions are deleted or not. What happens exactly if the machine crashes (power failure or otherwise) during a save operation? The present implementation apparently protects exactly one version, ``Delete backup file'' or not.
And it is very important to know that Edit does not change the contents of the present file, but makes a new one: file ownership (one has to manually reset ownership of /etc/uucp/L.sys to uucp after one edits it with an Edit with root euid) and integrity of hard links and symbolic links (e.g., editing /usr/lib/crontab instead of what it points to: /etc/crontab).
Edit allows one to ``save'' a write-protected file if the user has write access to the folder containing it, not ``as long as you own the file'' as stated here.
 [The following is more likely than a previous hypothesis, but was not fully tested, so I may still be too optimistic here :-(. Yes: there's still some explaining to do about how Edit handles symbolic links, and (see above) stranger things happen to .rtfd structure, with the use of .rtfd# (sic) intermediate files. Anyway, this comment is just about documenting the present implementation, with which I certainly don't agree.]
When a file file is ``saved'', Edit does the following. If file already exists, Edit moves it to file~ for safety, overwriting any currently existing file by that name. Then a new file is created, with the Edit Window's contents. This new file is writable, unless there was a file that was not writable (the user agreed to overwrite it and has write access to the folder containing file) and Preferences.../Global Options/Save Options has ``Save Files Writeable'' not selected. Finally, if ªDelete backup fileº option is selected, file~ is deleted.
Suggestions.
The present Save Options should be removed, and replaced by the following functionality (the documentation could recommend to just use one level of backup, or even just one level might be implemented; but why such an arbitrary limitation¼), because the present (application,user)-wide choice of backup level is a curse. A file has a backup level based on the existence of files named file, file~, file~~, file~~~ etc. This should be indicated in the Title Bar, and Edit should check if they are all there (asking the user what to do if an intermediate level isn't there). It should also check file ownership and protections, and see that they are all the same. When a file is edited, Edit should first make sure that it can save it with the same ownership and protections, and ask the user for advice otherwise (one option would be to create a new unnamed file instead). When actually saving, all files should be moved to one higher level (creating a new level), except file, which should be copied to file~. Then the new contents are saved to file using a write(2) system call. Finally, if Save was used (rather than Save New Version), the newly created highest backup level is removed.

Suggestions
KBNS.00.0.133_o2.1±3.0o Known to Bug_NeXTec as #1446 since 1992-01-27. Make a selection established from matched delimiters use the smart copy-cut-paste features too.
KBNS.00.0.138_o3.0o Alter a misleading name. Don't say ``Make ASCII'', say ``Make Non-RTF''. [¼] ``Make ASCII'' should be provided also (or instead), transforming to real ASCII, i.e., to bytes with their highest bit zero, and get/keep the R shortcut.
KBNS.00.0.139_o3.0o Use a good idea. Instead of using a Preferences.../Temporary Settings setting to decide about the next window to be opened, do this Terminal's Preferences... style, maybe without the Set Default button.
KBNS.00.0.140_o3.0o Thing that applications should do in general. Move .commanddict and .pipedict to ~/.Apps/Edit/.commanddict and ¼/.pipedict and provide access to them from within Edit. That will remove those odd files from the home directory, give an example to other developers of what they should do. Closing such a window after editing it should also do what one now needs to relaunch Edit for: give one access to the new commands and pipes (hack until one can register for delegate messages from the file system).
KBNS.00.0.141_o3.0o There probably was no time to do this before the 3.0 release. When a document changes status (normal, .rtf, .rtfd) panel support should be provided to make the necessary changes to the file system, instead of producing a new, untitled document.
KBNS.00.0.142_o3.0o This would be useful. In the Print... panel, a button should be provided that will resize the current window's width to what was selected in the Page Layout... panel if appropriate (allowing for margins too). That way, one can be sure that the printed version won't be unexpectedly shrunken because the lines were too wide for true size, since the user can't measure the window on the screen with a normal ruler because this is not really WYSIWYG and all (it's too small on a 92-dpi display). A button to view a document at true size would be nice too.
KBNS.00.0.143_o3.0o A nuisance. If I type something in a particular font and in a particular size, and then pipe it through a Terminal Service (say, tr a-z A-Z to convert to uppercase), the result is always Helvetica 12, regardless of any preference setting anywhere, it seems. Proper behaviour is to return NXAsciiPboardType instead of NXRTFPboardType, so that the font at the beginning of the selection is automatically used.
KBNS.00.0.144_o3.0o Emacs. Provide splitview access to one Text object. Text should be extended to support this, and the renewed object could then be used in groupware too.
KBNS.00.0.145_o3.0o Emacs. Get rid of these silly Delete and Undelete commands that don't work as expected anyway, and implement infinite Undo/Redo.
KBNS.00.0.146_o3.0o Emacs. When searching, do the same as what emacs does (per character typed scrolling the text to the right place and reporting failure as soon as possible). And do a beep or something before wrapping around (it's tiresome having to keep an eye on the scroll bar, especially as contracted portions are expanded, resizing the scroll bar), and another before passing the starting point of a round trip. These three features should probably get a check box setting in Preferences...
KBNS.10.1.012_o3.0o Don't insert tabs when doing cmd-] or starting a new line at the same indentation level as the previous, or make this a preference setting.
KBNS.10.1.020_o3.0o Don't scroll the document window to the beginning of the selection when dropping a color swatch on it.
KBNS.10.2.043_o3.0o Reverse the meaning of cmd-[ and cmd-] to what standard text correction marks signify (respectively indend and unindent; I presume that's an international convention).

Spelling
KBNS.00.0.147_o3.0±3.1o Verified for 3.1 by Subrata_Sircar The following pairs have been constructed by duplicating the first using copy-paste and correcting the copy in the spelling panel. (For clarity: anytime you have them in a text and use the ``English (NeXT)'' dictionary, these will be highlighted as errors and the indicated alternatives will be suggested.)
commercialise commerckialise (one of the possibilities)
encodable enkodable
executability axecutability
fivefold fiveuold
uninstall unsnstall
Furthermore, I wonder what dictionary is used and where it is located. A spelling facility that finds errors in /usr/dict/web2 is a strange animal. What's the meaning of using both ~/.NeXT/LocalDictionary (from previous release) and ~/.NeXT/dictionaries/English? And then I'm not even talking about what I'd really like for functionality¼

/NextApps/Librarian.app
KBNS.11.0.013_o3.0_3.1o Reported for 3.0±3.1 by Subrata_Sircar, not verified, Bug_NeXT.47288
``I opened a new bookshelf, did a search, read some documents and closed the shelf again, leaving the new documents open.  When I went to resize the window of one of these documents, Librarian crashes with the following message:
Jul 17 17:24:05 starblazer Librarian[197]: objc: FREED(id): message isIndexed sent to freed object=0x123cdd0
This is completely reproducible.''
KBNS.00.0.150_o3.0c Reported and verified by Subrata_Sircar, from Dan_Brown, reported to be cured in 3.1 by Subrata_Sircar (``IndexingKit is now a shlib.'' (?))
From: dbbrown@eastrg2.cray.com (Dan Brown)
Subject: Re: Digital Librarian and nroff files.
Date: 29 Sep 92 00:33:28 CDT

dbbrown@eastrg2.cray.com (Dan Brown) writes:
>I think someone has mentioned this before. I am having problems with
>Digital Librarian indexing my man pages (nroff format). Is there a
>work around for this? Is there something special I should do that
>I should be aware of?

I just found the answer to my own question thanks to an alert I just got.
It turns out that if you don't have the "/usr/lib/indexing" directory.
You lose out on a lot of support programs for DL. I didn't have this
directory because I did a 2.0 builddisk and then upgraded to 3.0. To fix
the problem I just copied the directory from my 2.1 disk to the same
directory on the 3.0 system.

Sorry, forgot to add one more thing. The 3.0 upgrade does not contain this
directory. So if you do a build from scratch with the CD rom you should
experience the same problem.

/NextApps/Mail.app
Bugs (found in 3.1)
KBNS.11.0.012_c3.1o Annoying but apparently harmless bug reported by Windflower_Gilbert on NeXT-prog@cpac.washington.edu, on 1993-08-10, not verified
``I recently upgrade my machine from 3.0 to 3.1. Now I get this annoying Mail error. Frequently, when I click on Delete in Mail, the Delete button stays highlighted, and the message doesn't delete until I click somewhere else. When this happens, I get the following error message on my Console.
Has anyone else seen this error? Does anyone know how to fix it?
PostScript program error, DPSContext 6c844
Aug 10 13:33:31 flower Mail[2873]: %%[ Error: undefinedresult;
OffendingCommand: bin obj seq, type=128, elements=5, size=44 ]%%'' Formatting changed.

Bugs (found in 3.0)
KBNS.00.0.151_o3.0o Bug with Undo. Undo doesn't work as expected, even the first undo produces unexplicable results. Other than that, Delete and Undelete seem to be never enabled.
KBNS.00.0.152_o3.0o Detail, to fix at leisure. (Warning: I couldn't easily reproduce this, will try again later. XXX) When mail is received and the user just deletes what has arrived by dragging and clicking the Delete button, Mail still indicates new mail, and can't immediately be convinced otherwise except by generating new mail to oneself and reading that. It's probably an unusual condition (just because I was testing the sound feature).
KBNS.00.0.153_o3.0o Bug with receipt sound. It seems not to be possible to turn the receipt sound off. The text disappears when Cancel is clicked, but the sound remains in effect.
KBNS.00.0.154_o3.0o Mail.app changing Reply-To: in Preferences, from Michael_Ross in a 1992-12-11 message, not verified
In Mail.app, under NS3.0, changing the Reply-To: field and clicking on Set does not modify the field on the next outgoing piece of mail. However, if another setting in the Preferences dialog is changed along with the Reply-To field (e.g. checking a check box), then the change to the Reply-To field takes effect.
KBNS.00.0.155_o3.0±3.1o Reported by Subrata_Sircar (also to comp.sys.next.programmer, a whole discussion followed), who reraised it for 3.1, Bug_NeXT.39767 What I think is the real problem as I tested it follows. Mail.app allows NXASCIIPboardType (part of copies from a rich Text; if it isn't on the NXGeneralPboard Mail.app just NXBeep()s) to be pasted into the upper part of a .mbox window's NXSplitView (this part is only first responder when the mailbox is newly opened, or when a message is selected (clicking in the top part if that is empty does nothing: an extra bug)). If the text is a properly delineated portion of a mailbox (starting at the ``From'' line, as produced when copying from a mailbox), this selection is immediately included as an extra message (I exclude rich messages from now on: copy-pasting these between mailboxes works fine, but don't make much sense in other cases). The problems occur when the text (copied from outside Mail.app) doesn't start at a ``From'' line: Mail.app crashes because of an Illegal Instruction (see below for additional adventure). Here on our findings diverge: After Mail is relaunched, if there was no ``From'' line in the selection, nothing is inserted into the mailbox (Subrata_Sircar: there's always an ``Appended message''); if there was one, these messages are normally included, and any preceeding material is included with a subject ``Appended message'' (both from root shell (Subrata_Sircar: Mail run as root never crashes) and Workspace). The problem is obviously that Mail.app makes certain assumptions about the pasted material, but doesn't parse it to make sure they are valid. Subrata_Sircar has done a lot of testing to find consistency or correlation with hardware, preferences, root (here he found something, see above)¼ For the whole picture, ask Subrata_Sircar. The problem seems intractable unless much effort is invested, and there is sufficient information here for NeXT to reproduce and cure the problem.
Trying to examine the core file (running directly from gdb gives one item more than this: the app crashes because of an illegal instruction) is strange too. I've emphasized some entries in italics to indicate that they do stay the same between tries, in bold to indicate that they differ. This comes from comparing my original try with two I got from pasting into a mailbox of a Mail run from a root shell. Well, Subrata_Sircar also reports crashing in the same place everywhere, but for him this location differs from mine! Go figure¼
flexus> ls /cores
core.191
flexus> gdb /NextApps/Mail.app/Mail
Reading symbol data from /NextApps/Mail.app/Mail...
(no debugging symbols found)...done.
Reading symbol data from /usr/shlib/libIndexing_s.A.shlib...done.
Reading symbol data from /usr/shlib/libMedia_s.A.shlib...done.
Reading symbol data from /usr/shlib/libNeXT_s.C.shlib...done.
Reading symbol data from /usr/shlib/libsys_s.B.shlib...done.
(gdb) core-file /cores/core.191
0xa002016 in libIndexing_s.A.shlib_jmp_table ()
(gdb) bt
#0  0xa002016 in libIndexing_s.A.shlib_jmp_table ()
#1  0x67be8 in goodDate ()
Cannot access memory: address 0x6167650a out of bounds.
(gdb) quit
flexus>
If anyone has an explanation, I'd like to know. I then tried to examine the core file by loading it into Edit. I made the window as large as my screen, searched for the word mail, dragged the Edit menu off to the right¼ and then every click of the left mouse called the menu underneath it! Keyboard shortcuts didn't work, and I couldn't select any other app. Because mine is a standalone configuration (otherwise: rlogin and so), I couldn't kill any application. I had to reboot!!! NeXT should definitely provide a shell interface that bypasses the DPS server like the monitors do.
KBNS.10.2.016_o3.0o Bug, only visible when receiving mail with something else than Mail.app (or looking at spool files), from a report by Gerben_Wierda and verified by me. When sending non-uuencoded NeXT mail, Mail.app normally encodes non-explicit line breaks (caused by wrapping around in the Compose Window) as space-break pairs, indicating to a receiving Mail.app that this break is to be removed, and doing no harm for naive recipients. When trailing spaces are explicitly entered, Mail.app chooses to duplicate the break, and this is a wrong choice: it will cause a spurious empty line on a naive recipient mail program (the intended recipients of non-uuencoded mail!), and one trailing space to be lost for a receiving Mail.app. The right choice would be to detect this situation ASAP, and to ask the user whether these trailing spaces should be deleted or a real Non-NeXT format used (without the soft-break trick).
KBNS.10.2.030_o3.0o Bug when reverting to Non-NeXT. An ellipsis (¼) is converted to a period (.) rather than to the three dots (...) that NXToAscii() advertises.
KBNS.10.3.020_o3.0o Bug with Lip Service panel, reported by Nicolas_Dore on c.s.n.bugs on 1993-06-24, verified by me. When the waveform display is selected, a resize bar appears which operates normally for horizontal resizing. But if the user accidentally changes height, the subviews are repositioned in a chaotic manner, and Mail doesn't seem te stop sending DPS error messages to the console, even after the panel is closed. The panel should have a delegate which implements windowWillResize:toSize: to constrain it to constant height. BTW, this message appears on the console any time waveform display is (de)selected: ``Assertion failed: You removed a View from the View hierarchy that had been lockFocus'ed''.

Bugs (found before 3.0) Embarrassing number of bugs still present after all that time to salvage a central NextApp.
KBNS.00.0.156_o2.1±3.0o Small correction. It's good that Private Groups are now always ordered, but when one is added, it should also be immediately selected.
KBNS.00.0.157_o2.1±3.0o Bug with symbolic links. Dragging in links is still not detected, and the recipient will only get the dangling link without any content. If something that one owns is dragged in (as I understand it from early impressions), the content of it is not protected against changes before the message is sent, if I understand correctly. Furthermore (really found this in NS_3.0), unreadable files are treated as normal files, but will show up as NeXT icons at the receiver's end, without content.
KBNS.00.0.158_o2.1±3.0o REALLY UGLY BUG. Is harmful off the Internet proper, like on bitnet. It is still possible to send non-uuencoded NeXT Mail. This serves no purpose at all except that when a non-NeXT Mail recipient inadvertently receives such NeXT Mail he may be able to read the content off the screen. But everyone suffers: non-ASCII characters mutilated (inclusion related to other bugs), lines truncated or badly broken off, etcetera. There should be an equivalence between uuencoded and NeXT Mail, obviating the triangle in the Deliver button. People don't understand Mail at present, I see all those questions and mistakes on NeXT-L@brownvm.brown.edu related to this.
KBNS.00.0.339_o2.1±3.0o It's still possible to paste non-ASCII characters into a Compose window without this changing the status to NeXT Mail (BTW, it's not possible anymore to type such characters, but this is a matter of choice, I guess, and there's good feedback¼). Services does the same thing.
KBNS.00.0.340_o2.1±3.0o If an attachment is dragged into a Non-NeXT Compose window, its path is added as text.
KBNS.00.0.341_o2.1±3.0o If cmd-u is done on an empty mbox, Mail crashes (reproducible like this: make sure Active.mbox is empty, and launch Mail by double-clicking, then do cmd-u on Active.mbox).
KBNS.00.0.159_o2.1±3.0o Design error. Abandon this Next-Attachment: line in the envelope. Use X-Next-Attachment: like everybody else (I've included a quote from NeXT's own ``Tricks'' file in the sendmail documentation to back that up). Better yet, move this line to the body. That will make a lot less mail systems ((all?) bitnet list servers, at least the late NeXT-L@brownvm.brown.edu) mangle the format (serving everyone, including those who receive mail on a NeXTSTEP computer, an unintelligible uuencode letter soup). If they do now, it's entirely NeXT's fault.
Preceding the name of a nonstandard header line with X- follows mail header format conventions, and makes sure that your message complies with all relevant standards.
KBNS.00.0.160_o2.1±3.0o Receipts. Let the user have control over the receipt mechanism. The user should be able to switch (Preferences¼) between generating receipts transparently and requiring confirmation in an attention panel (default). As another matter, what good is a timestamp if one doesn't get the timezone? (Very naively: a good receipt mechanism would attach the receipt to a return message unless a timeout is reached, and only negative acknowledgement would be given to the user, if his Mail sees a timeout on receipt confirmation.)
KBNS.00.0.162_o2.1±3.0o Bug. When searching through a .mbox's addresses and subject lines, the particular message still has to be clicked before its content are displayed (i.e., the Mailbox can temporarily be in an incongruous state).

Suggestions
KBNS.00.0.164_o3.0o [Reformulated.] Instead of NXRunAlertPanel("Close","This is an undelivered Compose window. Closing it will destroy its contents.","Close Anyway","Cancel",NULL), something like NXRunAlertPanel("Close","Discard partially composed message or save in NotSent.mbox?","Discard","Save","Cancel").
KBNS.00.0.163_o3.0o From Bug_NeXTec #1897. Services/Mail/Selection should open a new Compose Window, not replace the selection in an existing Compose Window. Once the Compose Window is on the screen, copy-paste will do the trick. Or ask first.

/NextApps/Preferences.app
Localization Preferences
KBNS.11.0.007_o3.0o Design error. Why does the login window ignore both NetInfo's /localconfig/keyboard.keymap and root's loginwindow/Keymap default (I tried, because it seems logical), and instead use root's NeXT1/Keymap default? Now, root cannot choose a dvorak layout without effectively locking everyone else out (except those that know it too, of course). (Classified here because it's the least nonobvious location.)
KBNS.00.0.165_o3.0o Like to have. Add the option Millimeters (often preferable over Centimeters). Or call this Metric, or SI.

Date & Time Preferences
KBNS.00.0.166_o3.0o Little bug. Fix at leisure. When the year is changed, the month stays the same, but the display of dates on weekdays under the year setting always shows the month that is then set, not what is indicated above!
KBNS.00.0.167_o3.0o KBNS.11.1.rev Suggestion. This method of kicking the privileges out from under a user who wants to change time is very ugly, causing strange messages on the Console, no indication on the user interface beforehand, a timezone which doesn't jump back properly (even jumping to settings the user never selected: according to the little world map, all non-root users on my system are in Iran). Being able to play with the eternal calendar should not depend on whether or not the network time service applies: the synchronisation should not replace the whole display, only the Set button. Suggestion: add 24-hour clocks, that's what we, in Belgium (and the rest of continental Europe?) at least, are used to on digital displays (solved in 3.1). Why call MET (DST) Poland?
KBNS.00.0.168_o3.0o Suggestion. Add the possibility to change the time by using adjtime(2) instead of settimeofday(2), for adjustments only, of course. Now, every time I update the clock (it seems to run slow when the computer is powered down), DPS gives errors on the console. [¼] But then, I use Preferences because the front to adjtime(2) that I developed can adjust the time, but every reboot seems to undo all adjtime(2)'s work!?

Expert Preferences
KBNS.00.0.169_o3.0o Suggestion. If there really has to be a ``Large File System'' setting (a better way is to make sure the File Viewer is always as swift as can be by itself and for all situations), it should make a difference. I have some folders with some 2500 (two thousand five hundred) files in them, and getting them displayed in the File Viewer takes forever (blocking my WM in the order of a minute or more) even with this item checked (it has been for a long while now).

General Preferences
KBNS.11.0.008_o3.0o Imperfection. For the Fixed Pitch Font, the application should check the user's choice before installing it, if not disable non-fixed-pitch fonts in the font panel.

Services Preferences
KBNS.00.0.170_o3.0o Bug. The browser apparently uses slashes to decide about paths. If there is a service ``open /usr/include/%s'' in Terminal (I have one), only ``open'' appears where it belongs, the rest stretches out three columns to the right.

Others
KBNS.00.0.171_o3.0o Page Layout.
[Rewritten because I heard that dwrite does something.] A graphical way to express a GLOBAL paper size, rather than dwrite GLOBAL NXPaperType A4 or something in a shell, would be nice.

/NextApps/Preview.app
Bugs (found in 3.0)
KBNS.00.0.172_o3.0c Crashing, reported to be cured in 3.1 by Subrata_Sircar. When opening a corrupt TIFF (maybe even just truncated), Preview disappears without a word, even when attached to gdb (The program you were attached to has exited or terminated.). Maybe this is a bug of the AppKit? On another occasion I dragged a corrupt tiff to the WM's Icon, Preview was started, and immediately crashed with this on the console:
TIFF Error: Can not read TIFF directory.
Feb 21 19:30:16 flexus Preview[2788]: objc: FREED(id): message free sent to freed object=0x20fec
A program should never trust the integrity of files, and in this case Preview should at worst refuse to open a file, with a warning panel.
KBNS.00.0.173_o3.0o Reported by Subrata_Sircar (``it looked like he was right''), from Anthony_Heading's 1993-02-20 comp.sys.next.bugs post, not verified.
From: heading%signal.dra.hmg.gb@Princeton.EDU (Anthony J.R. Heading)
Subject: Preview buggers %%Page... (3.0)
Date: 20 Feb 93 01:09:58 GMT

[context diff omitted]
Entirely contrary to both normal practice and the official spec,
Preview reversed the label and the page numbers on
all the %%Page lines.
KBNS.10.1.011_o3.0c When asked to open a file, Preview doesn't look whether it has that already opened that file, and opens another window, reported to be cured in 3.1 by Subrata_Sircar

Suggestions
KBNS.00.0.174_o3.0o Like to have. Let the user move the image by direct manipulation (like TeXView), and use a ``hand'' cursor to indicate the possibility for this manipulation (TeXView lacks this special cursor).

/NextApps/PrintManager.app
KBNS.11.0.003_o3.0o Reproducible application crash
Try the niload printcap example in /NextLibrary/Documentation/NextAdmin/11_MixedNet/00_MixedNet.rtf, and click Queue or Modify on this printer. The application will crash immediately.
This application should also be able to create this type of printer entries!

/NextApps/Terminal.app
Bugs (found in 3.0)
KBNS.00.0.175_o3.0o Providing Services (potentially dangerous!). When I have a file in Edit that contains \0 bytes, it gets processed correctly when I pipe it through any Service but Terminal's: Terminal ignores any input from the \0 on. If the first byte is a \0, the selection just blinks; otherwise, the result of the processed characters (those before the \0) replaces the selection. (The service was set to behave like a pipe.) Test example: try ``cat'', command cat, no key equivalent, plain text only, as input, in background, return output, no shell. The behaviour of that is not what one expects, because cat doesn't care about \0 characters.
KBNS.00.0.176_o3.0o More on Services. I have a Service that accepts plain text, uses the selection On Cmd Line, runs in the background, discards output and uses a Fast C-shell, but has only a %p, no %s. Every time I use it, Terminal adds the selection at the end of the command, and the Service fails because of this. The bad behaviour wouldn't go away with relaunching Terminal. I now use an Edit window to type myÐformerly %pÐstrings, and use the command with %s instead of %p.
KBNS.00.0.177_o3.0o Bug. When a background process is running from a Terminal shell, and background processes aren't considered ``clean'' so that the broken cross is displayed, closing the window prompts the user for confirmation (telling which processes will be closed), but the background processes aren't closed.

Suggestions
KBNS.00.0.178_o3.0o Services. Don't unhide Terminal when a ``Run Service in the Background'' is used (this means a general Services mechanism to delay unhiding applications until user interaction is mandated).
KBNS.00.0.179_o3.0o And this. Paths dragged in should be surrounded with double quotes if they contain spaces. Paths that contain strange characters like Ý and the like should be refused, or, if that's possible, converted to a format that the shell will accept (if that's possible, I don't know).
KBNS.00.0.180_o3.0o For pre-ADB keyboard users at least. In the VT-100 Emulation Preferences, add the note ``(not normally desirable)'' to generating VT-100 codes from the keypad too: the vertical bar is located there!
KBNS.11.0.004_o3.0o Misleading Panel When the application is started from a shell as just Terminal, with path containing /NextApps/Terminal.app, this happens: NXRunAlertPanel("No Wrapper","Terminal must be run from the Workspace Manager.",NULL,NULL,NULL). This is nonsense of course, the only requirement is that Terminal be started with a full path for argv[0].

/NextApps/Webster.app
Bugs (found in 3.0)
KBNS.00.0.181_o3.0±3.1o Bug, confirmed for 3.1 by Subrata_Sircar. Try resizing the window: first wider, then narrower. The Text apparently doesn't know the width of the ScrollView's opening: it doesn't fit. Or maybe it's not about hysteresis, just about a minimum width of the Text. Anyway, it's a reproducible bug.
KBNS.00.0.182_o3.0o Reported and verified by Subrata_Sircar, from Kate_Smith
About printing definitions containing pictures.
From: kate_smith@next.com (Kate Smith)
Subject: Webster's in 3.0
Date: 7 Oct 92 23:46:21 GMT

smprove@lerc.nasa.gov writes:
> When trying to print out a definition using Websters under 3.0, the
> message "Some or all of the pages in your print request couldn't be
> printed" pops up. Does anyone know what the problem is?

There is a known bug in Webster in 3.0 that causes errors when printing
some definitions which contain pictures.  It seems to be a problem with
pictures that are stored as EPS.

The workaround is to copy the text of the definition into an rtf document
and print that.  Note that you can't copy the picture because that also
results in an error when you paste it.  Of course, this workaround doesn't
get the picture printed.  You might be able to save the PS output and
fiddle with it so that you can print that, but I wouldn't advocate that
unless you were comfortable fiddling with PS code.  If you are interested,
the offending command is the currentpoint command after the picture.

Kate Smith
NeXT Developer Support
KBNS.00.0.183_o3.0±3.1o Crashing, confirmed for 3.1 by Subrata_Sircar. Webster invariably crashes when asked to explain 5.
KBNS.10.1.019_o3.0o Both EPS and TIFF illustrations disappear whenever the text size in Preferences is changed.
KBNS.11.0.016_o3.0±3.1o Reported for 3.0±3.1 by Subrata_Sircar, from Robert_Brown, Bug_NeXT.43680, verified for 3.0 by Raf_Schietekat
``Click on the lowercase letter "a" in this message and select "Services->Define In Webster".  Webster comes back with "word not found".  All the other letters seem to have an entry ...
NOTE:  In 3.0 this crashes Websters [3.1 black too]!''
KBNS.11.0.017_o3.0±3.1o Reported for 3.0±3.1 by Subrata_Sircar, from Robert_Brown, Bug_NeXT.34464, verified for 3.0 by Raf_Schietekat
``Type "nexis" into the Digital Weber and click on define.  It suggests the correction "newyorkcofenvironmentalsciencea"  -- totally strange!  Enter "newyorkcofenvironmentalsciencea" and click on define.  Webster doesn't define the word and suggests "newyorkcofenvironmentalsciencea" as the correction.''

Suggestions
KBNS.00.0.184_o3.0c Alphabet. Look it up, and try to read the fine print at the bottom of the illustration: EPS illustrations need to be scalable (with text size, probably). Subrata_Sircar about 3.1: ``[No more pictures :<(]''

Editorial I've already submitted a set of editorial comments, still available for people at NeXT or at Webster.
Subrata_Sircar reported that the contents didn't change from 3.0 to 3.1 (actually he confirmed all the items below for 3.1).
KBNS.11.0.001_o3.0±3.1o affine This definition neglects the 1-dimensional case, and the formulation of the examples gives the impression that they're a complete set (they're not).
KBNS.10.3.030_o3.0±3.1o Cartesian coordinate Neglects to mention orientation, and this term applies from dimensions 1 to infinity, not just 2 and 3
KBNS.10.1.013_o3.0±3.1o diarrhoea Presents only a subset of what diarrhea calls up (the thesaurus information is omitted). Spelling should not affect the amount of information presented, as long as it is correct. KBNS.10.2.007_o3.0±3.1o From Michael_Shaler's 1993-05-17 comp.sys.next.bugs posting, verified by me: same thing for prospects vs. prospect (Webster doesn't hang as he says).
KBNS.00.0.185_o3.0±3.1o fathom Look up this word: fatom is used everywhere.
KBNS.00.0.186_o3.0±3.1o Natl Ge(o?)graphic¼ Try corpse.
KBNS.10.1.024_o3.0±3.1o Skidmore Spelling error, incoherent usage of bold type. Sidmore C. Saratoga Springs, N.Y. 12866; 1911 
KBNS.10.3.013_o3.0±3.1o Stanford How about adding Leland Stanford, of the railroads (didn't he also found Stanford University?).
KBNS.11.0.018_o3.0±3.1o theor, reported by Subrata_Sircar for 3.0±3.1, from Dion_Dock Try empirical.

/NextDeveloper/Apps/IconBuilder.app
Bugs (found in 3.0)
KBNS.00.0.187_o3.0o Reported by Dylan_Kohler, from Linus_Upson (in the README.rtf of his public-domain Scale.pfilter tool, should be available with ftp from geom.umn.edu, 4 items), verified by me
Item 1. When I start IconBuilder, choose the Selection Tool, call up the inspector and use the PopupList to set to a different operation (not in Linus_Upson's report, but is necessary to get a manifestation of the bug on my host), and then try to load a tool (Scale.pfilter in this case), nothing happens (probably the tool is successfully loaded but the PopupList isn't adapted). At a second and later attempt, I get NXRunErrorPanel("Error","An error has occurred while loading %s",NULL,NULL,NULL,theToolBundle), but nothing on the console or anything to clarify the error (name clashing?), while Linus_Upson gets something like
Feb 16 12:08:15 minkowski IconBuilder[4982]: Error loading /usr1/lupson/tmp/Scale.pfilter/Scale
Feb 16 12:08:15 minkowski IconBuilder[4982]: rld(): multiple definitions of symbol .objc_class_name_ProgressView
Item 2. (I cannot verify this on my colour-blind configuration but it's fairly probable, as NS_2.1's Icon malfunctioned in this aspect too. Verification, anyone? You'll need to draw Pantone on a monochrome host and verify on a NeXTdimension, to be sure.) ``By default, IconBuilder will not correctly manipulate images that are deeper than the framebuffer (despite what the page layout panel claims).  To fix this, go into a shell and type dwrite IconBuilder NXWindowDepthLimit TestTwentyFourBitRGB.''
Item 3. ``If the Apply or Revert buttons in the selection tool inspector are clicked while there is no open document, IconBuilder will scribble in the Button's cell.'' I've seen this even with an open (though UNTITLED) document.
Item 4. ``The selection tool will not draw properly if a document is converted from one with alpha to one without alpha and the background color well is not kicked.'' Further specification:
This is the bug:
Launch IconBuilder.
Type cmd-n.
Type cmd-P. (The Document Layout panel will come up.  My Preferences look like
this: width:48 height:48 background color:(0, 0, 0, 0) depth:24bit&has alpha)
Click the "Has alpha" box turning alpha off.
Click OK.
Click the selection tool (the dashed box).
Drag out a selection rectangle in the document.
The selection rectangle won't clean up after itself.
Verification, anyone? I could see nothing strange on my NeXTstation ``Classic'' with  dwrite IconBuilder NXWindowDepthLimit TestTwentyFourBitRGB (except that the application icon tile was ``coloured'' for some Preferences... settings of the default set of TIFF depths, and changed back to monochrome after a fraction of a second for others!).
KBNS.00.0.188_o3.0o Possible bug. It seems that IconBuilder puts tiffs with alpha on the Services pasteboard even if the image being edited has no alpha, for a selection. I verified this (OCR Assistant Demo's complaint about alpha), by trying the same Service from a Grab selection, and then OAD complained only about a non-lineart image (the same as for a File Service on an IconBuilder document when saved). Corroboration/refutation, anyone?
KBNS.00.0.189_o3.0o ObeseBits window. Paint tool isn't visible or usable over ObeseBits' representative on top of the document window, is usable but not visible over ObeseBits window.

/NextDeveloper/Apps/InterfaceBuilder.app
Bugs (found in 3.0)
KBNS.00.0.190_c3.0±3.1o Bug, confirmed for 3.1 by Subrata_Sircar. When a class is parsed after it has got a new place in the inheritance hierarchy, IB does not recognise this change. The class stays in the same position in the browser, even if it does not belong there, and, e.g., a Control subclass does not get a ``target'' instance variable. Version 2.1 worked correctly.
KBNS.00.0.191_o3.0o Making Palettes, from a 1992-09 NeRD Mailing. ``#25247: The IB palette Makefile doesn't pay attention to OTHER_LIBS so you can't link a library into a palette. As a workaround, you can add your library to OTHER_OFILES.'' Reported and verified by Subrata_Sircar, from Tim_Dawson
Date: Fri, 18 Sep 92 08:04:32 -0500
From: prism!mspboss!tdawson@is.com (Tim Dawson)
To: next-prog@is.com
Subject: Re: make, make debug, and Project Builder

My second question: "why can't I have a palette linked with libraries", brought an interesting reply which I think should be shared:

> As for palettes linked with libraries, this is actually a
> bug (#25247)  You can add the library as an OTHER_OFILE,
> and I think that will work ok.
>
> One of the dangers of linking a palette against a library
> is if attempts to load another palette which has been
> linked against that library and contains some of the same
> symbols, the load attempt will fail.  This means you
> couldn't have 2 palettes built around same library.  The
> first one will load, but the second one will not because of
> the duplicate symbol name.
>
> Julie Zelenski
> Developer Support
KBNS.00.0.192_o3.0o Reported and verified by Subrata_Sircar, from developer support
Slight memory leaks with .nib files, might interfere with diagnosing substantial ones.
Bug of the Week

This bug posting is devoted to some newly introduced memory leaks in nib file unarchiving for 3.0.  You might see these with MallocDebug, and I'd like to let you know so you don't waste time trying to track and fix these leaks that are our bugs.  The amount of memory leaked is not substantial, the worst part is that it clutters up MallocDebug sessions.  To workaround the latter problem, rather than using "Show all Leaks" everytime, use "Show all Leaks" once, and then from then on just show "New".

#29719  -- When you load the nib file without names, Malloc Debug will show you that all of those name strings were leaked.  This can be a lot of strings if the file was a 2.x converted file because every object had a name back then ("Button1" "Button2", etc).  In 3.0 NIB, all objects don't have a name until you explicitly "Set Name.." from the Edit menu.  If you aren't using names and want to stop leaking those strings, you can remove the object names from 2.x-converted nib files.  Unfortunately there is no way other than the tedious modal "Set Name..." panel.  Here's the MallocDebug for a leaked object name:

Zone:     Address:    Size:     Function:
 default  0x0066dcbc     18     NXCopyStringBufferFromZone, _NXDecodeString, ReadValues, NXReadTypes, -[IBObjectData read:], InternalReadObject, NXReadObject, loadObjectData

-- There is a leak of 16 bytes for each target/action connection that you made in the nib file.  There is no way to avoid this leak.  Here's the MallocDebug for a leaked control connection:

Zone:     Address:    Size:     Function:
 default  0x001387ec     16     class_createInstanceFromZone, InternalReadObject, ReadValues, NXReadArray, -[List read:], InternalReadObject, ReadValues, NXReadType
KBNS.00.0.193_o3.0o Size To Fit bug. Just try this on a Box that contains two large Buttons arranged diagonally (first make the Box too large): the size will be right, but the location will be wrong.
KBNS.00.0.194_o3.0o Temporary workaround for a problem mentioned in the ReleaseNotes.
``Cannot connect (or select) a custom view that is grouped within a scrollview.  You'll need to use Ungroup to make it accessible.''
You can take, e.g., a TextField with the CustomView when grouping, and remove that TextField afterwards, or copy-paste or drag a CustomView into an existing ScrollView. It is not clear to me what the designers intended to be possible with a ScrollView in Interface Builder, or it should be that various strange phenomena are actually bugs.
KBNS.00.0.195_o3.0±3.1o Reported and verified by Subrata_Sircar (also for 3.1), from Daniel_LaLiberte's 1993-02-03 comp.sys.next.bugs posting
From: liberte@cs.uiuc.edu (Daniel LaLiberte)
Date: Wed, 3 Feb 1993 16:41:18 GMT

>This seems like an obvious bug that someone would have 
>reported previously. Creating new sounds in IB (NeXTSTEP 
>3.0) has the problem that the names of the sounds want to 
>be generic like "Sound", "Sound1", etc. It lets you rename 
>the sounds, but they don't stick. 
Subrata_Sircar: ``Verify by dragging a new sound into IB.  Rename it.  Click on the Objects suitcase, then back to Sounds.  It's gone back to its original name.  It doesn't seem to be just new sounds, but any sound at all ...'' I tried to reproduce this and found the following. IB refuses any dragged-in sound on (~/, /Local, /Next)Library/Sounds. This is silly, because on a different host only /NextLibrary/Sounds has a fair chance (if the NeXTSTEP version matches) of having the same sounds. I then respectively moved, copied and linked 3 sound files from ~/Library/Sounds to ~/_. Only the first was accepted by IB, with the name of the file taken as the name of the sound, not a generic name (I created a local sound, I guess IB means local to the .nib). I couldn't change that name, as stated. Subrata_Sircar: ``Further, if I open the IB file in Workspace, rename the sound, and then open the nib in IB, it has the changed name.''
KBNS.00.0.196_o3.0o From Dimitri_Tischenko's 1993-03-10 comp.sys.next.programmer posting
-getInspectorClassName doesn't get called for Windows and subclasses.
Thomas_Burkholder of NeXT: ``Sadly, due to implementation details of IB, it isn't possible to write an attributes inspector for a custom subclass of Window.''
KBNS.00.0.197_o3.0±3.1o Save As..., confirmed for 3.1 by Subrata_Sircar If a document is renamed to something that InterfaceBuilder has already open, two documents with the same name stay on the screen. No warning panel before or after, nothing.
KBNS.10.2.052_o3.0o Parse When a header file is parsed and an action message to it suddenly is not sensible anymore, IB removes it without first giving the programmer a chance to Cancel the operation, or even telling what has happened. (Other things: if the argument isn't exactly ``sender'', maybe ``senderIgnored'', IB won't recognise it as an action message.)
Search the rest of this file for ``Palette''.
KBNS.11.1.007_3.0±3.1o Wrong font default for palette menu items Items dragged in from the standard menu palette have ``As selected above'' instead of ``From user's system font'', and this is applied like that when the app is running, so the cure should be in the palette (and maybe a warning by IB for any palettes that make the same mistake so that the programmer can correct it immediately). Oddly, these mistakes are corrected (without warning, though!) when a .nib is opened in IB, and that a save will consolidate that. So a workaround is to save, close, reopen, and save again (while the present revert to saved remains in effect (now always puts up an alert panel even if the document is clean, and does a crazy jump that indicates that the document is just deleted and opened again) you can use that as a shortcut for the close and reopen).

Suggestions
Various things¼
KBNS.00.0.198_o3.0o The Miniaturize command is in a non-standard location.
KBNS.00.0.199_o3.0o There is no inspector for the names of objects let alone get a list of them, there is no mode to see all connections or generate a ``net list''.
KBNS.00.0.200_o3.0o For a Prototype Inspector: omit the buttons (a close button should be enough), and make this a non-modal window, so that the user can test the prototype in its well (to test behaviour of different Button types). See also KBNS.00.0.211.
KBNS.00.0.201_o3.0o Either operate the matrix of palette icon buttons in select mode or make this scroll like a Text would in a ScrollView, when the mouse, while dragging out a selection, leaves the visible area.
KBNS.00.0.202_o3.0o Make clicking on a Window's title bar or resize bar select that window for the inspector (shorter than finding the .nib's document window and selecting the window there, for windows whose contentView is entirely covered).
KBNS.00.0.203_o3.0o In a Window's Size Inspector, add a selector to decide whether the inspected frame is the Window's (now), or the Window's contentView's (added option).
KBNS.00.0.204_o3.0o Don't say ``Don't Delete'' in the panel that allows the programmer to reconsider about deleting a window, say ``Cancel''.
KBNS.00.0.205_o3.0o When control-dragging a connection from an object on the screen to the Window with Objects, Images, ¼, this should temporarily switch to the Objects display. After the connection has been confirmed or revoked, the display should switch back to what it was.
KBNS.00.0.206_o3.0o There should be an Unzoom command to back out by 1 level at a time in case there is no superview screen real estate (when it is fully covered by subviews).
KBNS.00.0.207_o3.0o (4 items: nuisance, pain, bug, distraction.) I have seen that when I double-click in a Box in my .nib, the document becomes dirty (the Close Button gets the broken cross). When I center the title strings, the height of individual FormCells increases. If scrollability and centeredness are mutually exclusive, coordinate the inspector to reflect the situation (do a revert: for safety). When I Revert to Saved, the .nib document panel jumps to a different location.
KBNS.00.0.208_o3.0o In the Layout panel, it should be possible to set any of the four sides or center (this one excluding the others) to obey the grid independently, not just one of two pairs of sides or the center in mutual exclusion.
KBNS.00.0.209_o3.0o In a CustomView, the class name should be displayed on multiple lines if the View is too narrow for it to appear completely on one line.
Etc.
KBNS.00.0.210_o3.0o Grouping. There should be a general interface for using hierarchical Views, not just Boxes (does nothing, really) and ScrollViews (not a very intuitive interface at present), but also, e.g., SplitViews, SelectViews (several displays controlled by a PopupList), special retiling or elastic Boxes. Proposed format: remove the ``Group'' and ``Group in ScrollView'' commands, but leave the Ungroup command there as a shortcut for more laborious unpackaging: when Ungrouping a grouping View that has more than one non-empty documentView, the various documentViews should change to Boxes, otherwise the contents replace the grouping View; anything ungrouped is selected. Grouping occurs as follows. When dragging in a grouping View the mouse pointer location is continuously examined using the exact same criteria that, when not dragging, determine whether a selection will be picked up for moving or a rubberbanding selecting rectangle will be started, only this time the outcome decides respectively between wrapping the grouping View around the selection (indicated by the cursor changing from two white squares to an image indicating grouping, and the selection constituting the primary documentView), and doing the normal inserting operation. The programmer should of course be able to select the documentView he wants to edit and manipulate its contents, etc.
KBNS.00.0.211_o3.0o IBInspector. The API lacks a message to notify the IBInspector that it is no longer active. Possible uses: cure KBNS.00.0.200¼ this alone is enough reason to add -resignActive: or something similar. A workaround at present is probably to drag a CustomView among the inspector elements, set to a class which will transmit windowChanged: messages to its inspector instance variable; the IBInspector should do something sensible with that.
KBNS.10.3.018_o3.0o Custom Views. It would be better to dynamically load the .o files that already implement particular objects, from the debug_obj and/or obj directories (some objects don't warrant the effort of making a palette out of them). Of course, this clashes with the limitation of dynamic loading and unloading (has to happen on a FIFO basis), so that would have to be cured first. But it would be pretty¼

/NextDeveloper/Apps/MallocDebug.app
KBNS.00.0.212_o3.0o The meaning of words, and the usability of this program (it is not conservative)¼ Two limitations in finding leaks are mentioned in the help panel: false alarm (if the program doesn't keep a reference to the beginning of the region, but still knows what to free), and MallocDebug may ignore leaks because, e.g., some integer has as its value the location of a mallocated region. The help panel states the second limitation as a reason for calling this garbage detection facility ``conservative''. Actually, from the point of view of someone who wants to find leaks (the purpose of this program), ``conservative'' applies to the first limitation (being too prudent, and leaving it up to the user to interpret everything), while the second is just the opposite of conservative. Probably the author just didn't think carefully when adapting this algorithm from use for garbage collection rather than detection: for garbage collection, if the programmer using this algorithm always keeps a pointer to the beginning of a mallocated section to avoid disaster and live peacefully with the first limitation, the second limitation is indeed a conservative one (merely preventing some memory to be made available again, but not causing the program to fail). In any case: always account for the possibility that there are leaks that the algorithm didn't find, because the algorithm used is principally unsafe (not conservative) for garbage detection. This program can only differentiate between regions that are leaks unless the programmer knows better, and regions that are probably no leaks. That's why finding leaks should only add a property (style < or >) to the displayed regions, and order them accordingly, not radically filter out those that the algorithm merely guesses to be no leaks (those are good guesses, statistically speaking, but not perfect).
Ways to improve accuracy: do something with the symbol table information that is likely to be available to any program linked for MallocDebug, if only for the sake of gdb (of course, a programmer may still abuse data fields and confuse the algorithm, both in the conservative direction and otherwise); check neigboring longs to see if they too seem to point to mallocated regions; involve the compiler, to do dataflow analysis.

/NextDeveloper/Apps/ProcessMonitor.app
KBNS.00.0.213_o3.0o Bug_NeXT_38618: Reported by Dylan_Kohler, verified by Linus_Upson and Raf_Schietekat
On a NeXTdimension (verified by Dylan_Kohler and Linus_Upson) and not on other systems (verified by Linus_Upson and Raf_Schietekat), ProcessMonitor will hang (and needs to be killed) when Mach Memory is (re)selected for an application which has dynamically loaded code, like IconBuilder for a tool provided from outside (the tools that come with it have their code linked into the main executable, maybe even for a reason) or the Workspace Manager (on any host).
KBNS.10.3.040_o3.0o Control Inspector (design?) bug Clicking Play should not reset Resume Count to zero, just decrement it if the Pause button is currently highlighted, and the application should not start up with that Pause button selected for a non-zero suspend count: in short, it should do the same as AppInspector. There should be an extra Decrement Suspend Count button to work around, e.g., AppInspector crashes (see KBNS.10.3.039).
KBNS.11.0.014_3.1o Tiny and harmless display bug, reported by Subrata_Sircar, Bug_NeXT.46196, not verified
``If the Build Options panel is already open and located somewhere on the screen, clicking the "Options" button not only brings it forward but moves it to the initial location (kind of strange if you generally want to keep it somewhere else).''

/NextDeveloper/Apps/ProjectBuilder.app, Makefiles
Bugs
KBNS.00.0.214_3.0±3.1o Reported, verified and reraised for 3.1 by Subrata_Sircar, from Mark_Mendel
This is uncommon behaviour that isn't warranted by anything: any user who wants just orderFront: to happen has alternate-click available, even if the display shouldn't change. The reason why this is so dangerous when the Files display comes up (not reproduced here from Mark's original message), is that one might cmd-r to remove something from the Files view, and¼ destroy an important directory in a File Viewer that had remained key (at warp speed, while the system is lagging on the user, one goes straight from the click to the keyboard without waiting for the title bar to turn black)! It is obvious that this design decision should be revised, with at the most a Preferences... setting. Anyway, the documentation isn't clear: the ReleaseNotes talk about becomeKeyOnlyIfNeeded Windows, while the Window documentation doesn't talk about this, only the Panel's. If I'm mistaken, tell me.
Date: Sun, 4 Oct 92 11:55:39 -0500
From: Mark G. Mendel <radical!mgm@is.com>
Subject: Project Builder: DANGER!

Project Builder is designed so that clicking on a Project window when its in Build mode brings it to the front, but does not make the window key. This behaviour is somewhat useful while fixing compiler errors.

However, if you click on the 'Files' button, the Project  window comes to the front and switches to the File display, but does not become Key. This is a bug and can be disasterous!
KBNS.00.0.215_3.0o Reported on comp.sys.next.programmer on 1993-04-04 by myself, supported by Charles_Spitzer.
Make install of a bundle fails miserably.
NotTheSourceLanguage.lproj folders aren't copied into the target (maybe just for a bundle). If this was meant to be like that, the programmers probably only know English and cannot imagine another programmer knowing more than one language and not having to take recourse to a translation service anyway. (Michael_Pizolato entertained a similar discussion on c.s.n.p around 1993-09, and the workaround suggested by someone from NeXT was to add these folders to Resources by drag-dropping (double-clicking wouldn't work).)
KBNS.10.1.009_3.0o Protections of included materials This is a suggestion that is so urgent that I want to classify it as a bug. The NeXTSTEP make procedure should take care of checking whether the user who receives a program will be able to execute it (now it is possible that only user has read privileges for something). This should be done as follows: chmod -R o=rX appWrapper, and to avoid some ugly and confusing uid/gid infections: chown -R nobody.nogroup appWrapper; chmod -R ug-rwx appWrapper. Exceptions should be specified in Makefile.postamble. Maybe it's safer, for each file that doesn't already, to do NXRunAlertPanel(NULL,"OK to give the world %s privileges to %s?",".app only",".app and source","Stop",X,Y) or something.
KBNS.10.3.041_3.0c Project Builder can create a faulty makefile if several libraries are specified, from a discussion on NeXT-prog@cpac.washington.edu around 1993-07-20, Bug_NeXT.29595. This is from 3.1's ReleaseNotes, which report the problem cured (verified by Subrata_Sircar):
``Description	If many libraries are specified in Project Builder, the LIBS line in the resulting makefile can contain an extra space. Here is an example of the LIBS line generated in such a case:

	LIBS = -lcommon_g -lipc -lMedia_s -lNeXT_s -l\
       	 MallocDebug

	The space between the "-l" and "MallocDebug" will cause an error at link time.

Workaround	Manually edit the makefile to eliminate the extra space. [Note - this workaround applies only to those not running 3.1.  To repeat, 3.1 does indeed fix the problem. -- MKT]''
[] belongs to the quote. The example does not clearly illustrate the exact problem as described, it seems to me, maybe the original formatting was better.
KBNS.11.0.015_3.1o Bug with Help.store, reported by Subrata_Sircar, not verified
``Project Builder in 3.1 has a problem with building Help.store files from the Help directories - it chooses the wrong directory.  Here is what happens when you select "app" as the target and click the Build button (if there is no Help.store file already) in the error message window:
/usr/bin/compresshelp English.lproj/Help -o ./CJ-Scans.app/English.lproj/Help
Building store file info...
365 files in file info
Collapsing common files...
Writing files...
Writing TOC (table of contents)...
Saving store to: './CJ-Scans.app/English.lproj/Help.store'...
fastcp: Cannot access
'/home/projects3/NeXT/CJ-Scans_3.1/Alpha_Release/Source/Help.store' : Operation
not supported on socket
*** Exit 255
Stop.
*** Exit 1
Stop.
Note that first sentence - it builds Help.store directly into the app wrapper, then later tries to copy it from the source directory?  Makes no sense, but it is obviously confused about directories.  The fix is to after it has saved the .tore file, to copy it into Source/English.lproj, and try again - this time it will work.'' Only formatting altered.
KBNS.11.1.004_3.0c Bug with Build clean for a palette The palette itself isn't removed.
KBNS.11.1.029_3.1o Bug with Continue after Error. If a build fails with this option set, PB will merrily announce ``Build succeeded'' and launch the program even while `` `project' not remade because of errors'' (this is only visible in the log part of the splitview). This cannot be the intention of this option: compare with make -k.

Suggestions
KBNS.00.0.216_3.0o Dependencies. Why require the developer to explicitly make depend sometimes (if that option is discovered at all)? This should be done automatically, as it is the only way to maintain the project when only a header is changed. This might not cause trouble, but it also may (it most likely will if the Objective-C inheritance hierarchy is changed!).
KBNS.00.0.217_3.0o Makefiles. And can you change things so that files that were compiled with a warning get recompiled on a new make, if such a preference is set? This can most easily be done by touching the sources after they were compiled, I presume. Or some other solution.
KBNS.00.0.218_3.0±3.1o Quitting, confirmed for 3.1 by Subrata_Sircar. The app should ask for confirmation before quitting while building an application.
KBNS.00.0.219_3.0o InterfaceBuilder, Edit. ProjectBuilder should communicate with these applications at least to see if any document isn't saved yet. IconBuilder too.
KBNS.10.1.010_3.0o Why are some warnings only given with -O? There should be an option to get flow-control warnings without having the compiled image optimised, to combine the advantages of getting all useful warnings and still being able to gdb without being confused. Actual optimising really has be done only after debugging is finished.
KBNS.10.2.044_3.0o Run button When a Build is in progress, ProjectBuilder shouldn't ignore clicks on the Run and Debug buttons.
KBNS.10.2.045_3.0o Generate Main File on Save Setting this option should immediately generate the file, and the comment in it should mention this option rather than bluntly state that the file should not be altered.

/NextDeveloper/Apps/Yap.app
KBNS.00.0.220_o3.0o Tiny bug, reported by Dylan_Kohler, behaviour verified by me, Bug_NeXT.41816. When one does Save As..., the SavePanel's browser goes to the same location it had last time, and the full path of the affected document window is displayed in the TextField. ``In short, it doesn't properly use the runModalForDirectory:file: method of SavePanel.''

/NextDeveloper/Demos
Contents
KBNS.00.0.221_o3.0o Put all those 2.1 demos back, especially Guided Tour. There's plenty of room on a CD-ROM. And ShowAndTell still has a pointer from the NXJournaler documentation.
KBNS.00.0.222_o3.0o Developer apps. Why put AppInspector.app and HeaderViewer.app in Demos? They're vital developer applications!

AppInspector.app
KBNS.10.1.003_o3.0o Booby trap? When used on Interface Builder, this application dumps core. This is consistent over sessions on my machine, but Subrata_Sircar can't reproduce it on 3.0 or 3.1. Your votes, please¼ KBNS.10.2.001_o3.0o On WM too, the two times I tried it¼
KBNS.00.0.223_o3.0o Isolated functionality. This application can't follow non-ObjC information paths, and the Edit Gdb... panel can only use the stack frames and what emerges from them, and won't expose the objects in a List. It is obvious that both should be merged to one more powerful facility, together with ProcesMonitor.
KBNS.10.2.002_o3.0±3.1o Inconvenience that is probably not intended (read: a bug), confirmed for 3.1 by Subrata_Sircar (``[3.1 loses track of boxes and what goes where.]''). When the Inspector is resized while it is in the Memory display, the starting address is reverted to some value that the program apparently likes better.
KBNS.10.3.039_o3.0±3.0c Crashes the application, reported as cured in 3.1 by Subrata_Sircar (``[3.1 loses track of boxes, etc. but no crash.]''), see KBNS.10.2.002 When the inspector is resized to its minimal width (memory display, at least), the application crashes.

Bug-NeXT.app
KBNS.11.1.008_3.1o Crash on launch, reported by Bruce_Gingery, Bug_NeXT.?????, not verified
``Bug-NeXT.app sets its own icon-identified .btsubmit files, but does NOT successfully autolaunch to open them. [¼]'' When the app is already running, double-clicking one of its files opens it successfully, but if the application has to be launched, it will crash immediately, Bruce_Gingery further says. Ten to one that there is some code in appDidInit: which has to be executed before a file can be opened, say I. Why oh why is app:openFile:type: sent before appDidInit:? (XXX make a separate report for this)

HeaderViewer.app
KBNS.00.0.224_o3.0c Bug. This program crashes if, e.g., /usr/include/ansi/ansi.h is opened and the Precompile panel is closed instead of its button pressed. Subrata_Sircar about 3.1: ``[No more precompile button.]''
KBNS.00.0.225_o3.0c Bug. If a window is closed, the Services>HeaderViewer>Open in <that file> menu item isn't removed in other applications, but it does nothing anymore. Subrata_Sircar about 3.1: ``[Can't close the window anymore.]''
KBNS.00.0.226_o3.0o Suggestion. When something is indeed control-clicked (to obtain a flat list), provide the reverse hint too.
KBNS.00.0.227_o3.0o Suggestion. Provide this option to get a flat Macros list, and to get a flat list of everything too.
KBNS.00.0.228_o3.0o Suggestion. Display values of predefined macros (__VERSION__ seems to be a macro with a value).
KBNS.00.0.229_o3.0o Suggestion. Allow long lines to wrap, or provide a horizontal Scroller (e.g., <objc/hashtable.h>, second line).

Keyboard.app
KBNS.00.0.230_o3.0o From comp.sys.next.programmer, 1993-03-10, verified by me. goldly@u.washington.edu (Lloyd P. Goldwasser) responding to andylee@oahu.cs.ucla.edu (Andy Lee). A user who wants to remap the keyboard to Dvorak or something has to drag capitals at least twice (maybe with an intermediate save) over locations were previously was a non-character, otherwise it will, like that non-character, not produce the uppercase version when only capslock (cmd-shift) is on. The sonata.cc.purdue.edu version of the Dvorak mapping, when I fetched it, still exhibits the problem. I haven't checked whether the reverse problem applies too.

Sound.app
KBNS.00.0.231_o3.0o Reported by Robert_Brown, verified by me, Bug_NeXT.33874, quoted literally.
``The application /NextDeveloper/Demos/Sound.app sometimes refuses to pause or stop playing a sound.  I think the problem is related to the signal view window that pops up when one hits the downward pointing arrow button in the Sound main window.  Pop up the signal view, start playing the sound, make the signal view disappear ... now try to stop the sound ... it won't stop.  If the signal view is brought back to the screen again, then the stop button starts to work again.  You'll need a long sound to test this with, so you can do all of the above while the sound's playing.  [¼]''

3View.app
KBNS.00.0.232_o3.0o Bug. Provide a panel advising the user to first save all his stuff, ``because your whole environment will come crumbling down with very high probability''. Don't fix this program otherwise: fix the Window Server to survive these assaults, and keep the demo around to test its strength. :-| Well, running the 3DReality demo also often crashes the Window Server. Tested on an 8-MB NeXTstation.
KBNS.00.0.233_o3.0o Generally. This is a very ugly demo, and should be immediately removed, or (see point above), hidden somewhere. The controls don't work properly, if I print the Elephant I just get errors on the Console and the saved PostScript file only contains the black background with the movement controlÐno elephant.

/NextDeveloper/Examples
AppKit/Backspace
KBNS.00.0.234_o3.0o False security. If an innocent user wants to change the password on this application, he has to give the old password first. But a knowing intruder can get around this by just deleting BackSpace/encryptedPassword from the defaults database. He can even distract someone for half a minute, delete his password, and have all the time in the world to do anything he likes on the account when the deceived user (he doesn't even think there might be a password problem: if you want to change it you have to give the old one, right?) goes out to lunch and activates the screen locker¼ which is not a locker anymore! Don't expect this to be corrected by the author.

AppKit/Draw
KBNS.00.0.235_o3.0o Confusing. There is a remark somewhere about editView being a workaround for an NS_1.0 Text limitation. Update that remark: Text still can't have a non-flipped superview (if it must be growable?). BTW, this editView should be isolated to TextGraphic (this can be done cheaply and easily).
KBNS.00.0.236_o3.0o Bug. In GraphicView.m's mouseDown:, the Graphics are given a chance to handle the event, but if they do (Image.m does), the window will thenceforth send mouseDragged: and mouseUp: events, because the event mask is not restored. Result: (some?) performance wasted. Right?
KBNS.00.0.237_o3.0o Various things. Don't use initClassVars(), use +initialize (should have been just +init, or +initClass, and a +free, or +freeClass, should be provided also, for releasing auxiliary files and stuff without having to export a Class's dirty laundry to +appWillTerminate:).
KBNS.00.0.238_o3.0o flushWindow Shouldn't flushWindowIfNeeded be used instead after reenableFlushWindow?
KBNS.10.2.005_o3.0o Multiple Files When multiple files are dragged into a document, they all land on top of each other (oh well), and each has the ``hand of cards'' icon (bad).
KBNS.10.3.005_o3.0o Leak In DrawApp.m's msgVersion:ok:, *aString is leaked (compare with msgDirectory:ok:).
KBNS.10.3.006_o3.0o app:powerOffIn:andSave: question In DrawApp.m, the third argument is interpreted, but it is documented as ``The argument aFlag has no particular meaning at this time, and can be ignored.'' Which is it?

AppKit/Graph
KBNS.00.0.239_o3.0o Reported by Johan LorrÝ, verified by me. With the default object (a revolving paraboloid or something, I don't know the proper English term), rendering set to Smooth and the x function changed from u to ln(u), after changing the slider for A a bit, the whole environment will hang. I don't know what level crash this is, but on a standalone machine only NMI halt will help. Maybe this can be cured at the Graph level, but the real thing to cure is at the RenderMan or PostScript level: no application bug should be able to have that much of an impact.

AppKit/ScrollDoodScroll
KBNS.10.2.033_o3.0o Tiny error. In Controller.m singleClick:, the test should also provide for no Cell being selected (replace multipleCellsSelected by symbolicCountOfCellsSelected, returning 0, 1 or 2). Also see KBNS.10.2.034.

IndexingKit/StoreFile
KBNS.10.3.024_o3.0o Bug in StoreManager's open: The application crashes if Cancel is clicked: the entire method should be conditionally executed.

UNIX/Floppy
KBNS.00.0.240_o3.0o Maintenance? Apart from not being updated to NS_3.0's include file structure, this file hasn't been compilable since 2.1 or earlier because of a ``*/'' too many.

/NextLibrary/Documentation Chapters should be ordered as in printed version instead of alphabetically, either by introducing a .places or what is it that can also specify arbitrary orderings of files instead of just strategies, or by assigning numbers at all levels.
NextAdmin/11_MixedNet/01_UNIX.rtfd
KBNS.11.0.002_o3.0o Typographic error, the niload printcap example fails because of a space after the backslash on the third line
This is the example:
PrinterName|alias:\
    :lp=:rm=remotehost:rp=remoteprinter:\
    :sd=/usr/spool/NeXT/PrinterName:\ 
    :ty=printertype:
and this is the result (with nidump printcap):
PrinterName|alias: \
	:lp=:rm=remotehost:rp=remoteprinter:sd=/usr/spool/NeXT/PrinterName: \
	:\ :
    : \
	:ty=printertype:
I presume niload is not to blame here?

NextAdmin/12_UUCP/02_SettingUp.rtf
KBNS.00.0.241_o3.0o 
5.	Make sure that there is an entry in /etc/uucp/L.aliases for every remote site. If there is a site that your computer doesn't call, but calls your system, you need a special entry for that remote site. Add an entry to L.aliases similar to the following, replacing remote with the host name of the remote computer and 19200 with the appropriate baud rate: 

remote Never none 19200 none
L.aliases should be changed to L.sys here (twice). L.aliases will seldom need to be altered, most sites will not have to touch it at all. This point is valid after the correction is applied, however.
KBNS.10.1.017_o3.0o Can be very painful If L.sys contains host names, sendmail.*.cf (whatever the status: mailhost, (shared)subsidiary) will directly mail to that host. Errors will be made (I have heard from somebody who just switched mailhost with a (shared)subsidiary and forgot to adapt L.sys on the old mailhost, and a whole bunch of mail was never delivered). Something should definitely be done to warn the postmaster automatically about uucp stuff that just sits there, a test invoked from /usr/adm/daily or something. See also KBNS.10.1.018.

NextAdmin/12_UUCP/03_OngoingManagement.rtf
KBNS.00.0.242_o3.0o 
1.	Open /etc/syslog.conf and add the following line:

auth.debug  /usr/adm/auth.log

Remote logins will now be recorded in /usr/adm/auth.log. For additional information, see the UNIX manual page for syslogd.
You forgot to mention that /usr/adm/auth.log should be created as an empty file. Otherwise syslogd will only print a line stating that the file does not exist (only visible if one watches the boot process!), and ignore it further. The syslogd manual page says that a file will be opened in append mode: I don't know if this implies failure for a nonexisting file (anyone?), but even if it does, it would be at least a good idea to explicitly state it. Unless of course it is a syslogd bug¼
4.	Open /etc/crontab.local (or create it, if it doesn't exist), and add a line like the following:

20 23 * * * su uucp -c /usr/lib/uucp/uucp.day.sh

This will run the script every evening, and the activity report will be stored in /usr/spool/uucp/STATS.
This is what it should look like (also change in uucp.day.sh): ``20 23 * * *	uucp	/etc/uucp/uucp.day.sh''. (And this is really another example of the stupid functionality of cron: if your host isn't running at that time, your job won't be executed. Doesn't anyone have anything better? And will the statistics be correct if a day is missed or if the script is run manually?)
KBNS.00.0.243_o3.0o Costs. To get communication cost information, an administrator will need to examine uucp.day.sh for what to do about a file L-costs. This should be mentioned in the .rtf file, or more appropriate, uucp.day.sh should be adapted to warn someone that L-costs should be created, in addition to use /dev/null for once.
Also see /etc/uucp/uucp.day. sh, especially for the item KBNS.10.1.018!

NextDev/Concepts/ExceptHandling.rtfd
KBNS.11.1.014_o3.0o Lie, or ``merely'' carelessness? What happens if you define a structure that can occur several times as ``theName'', and define a substructure as ``local theName''? Confusion and accidents. Well, it's a remarkable feat that the authors fell into their own trap only once:
Besides transferring execution to the local exception handler, a call to NX_RAISE() initializes the variable NXLocalHandler of type NXHandler, as defined in objc/errors.h.  This variable is defined only within the local exception handler and contains those structure members that correspond to the arguments passed to NX_RAISE():  NXLocalHandler.code, NXLocalHandler.data1, and NXLocalHandler.data2.  These members transfer information about the exception to the code within the local exception handler.
Actually, NXLocalHandler is defined ``only within the present exception handler''. But why not spare the reader a whole lot of checking the documentation for errors and make it easier on everyone, by choosing different names¼
Another thing: ``For exception types that it recognizes, the local handler responds and then calls NX_RERAISE() to pass notification of the exception to the handler above it, in this case, the handler in Function2().'' (about nested exception handlers). What nonsense! If the ``local handler'' responds, it will most likely not call NX_RERAISE and just fall off the end of the ``local exception handler''; it's only if it cannot respond that it has to reraise the exception.
The strategy proposed for defining exception codes breaks down in the presence of one of the main purposes of NeXTSTEP (using externally written objects and palettes) and is another example of the neglect towards possible conflicts/clashes by the authors of NeXTSTEP. The cure is for the programmer to dynamically allocate error code space, but this can only be done if there is a central registrar, i.e., a function that can only be provided by NeXT, that will take a range size and return a base (this of course makes an error reporter essential)¼
The strategy for defining error messages isn't usable with localisation. Furthermore, it's a bad example because this wastes a container for occurrence-specific information: messages should be generated at the ``local handler'' level, or better yet in the error reporter itself.

NextDev/Concepts/Installer.rtf
KBNS.00.0.244_o3.0o Suggestion Doesn't mention Package.app (which is, BTW, not included in /NextDeveloper/Apps¼ why not?).

NextDev/Concepts/Localization.rtfd
KBNS.00.0.245_o3.0o Points to a file CLibLocalization.rtf in the same folder for the documentation of strftime() etc., but there is no such file! See strftime under subcategory ``C Functions''.

NextDev/Concepts/Performance/ImprovingResponseTime.rtf
Some accuracy for the sake of those who don't know already anyway, please?
KBNS.10.3.004_o3.0o Optimal Panel and Menu Updating. ``If you send a setAutoupdate:YES message to NXApp, updateWindows will be sent after every event.'' Really? Also for events handled with getNextEvent: in a modal loop? Nah! This must be ``after each iteration of the main event loop''¼ And with what priority?
KBNS.10.3.003_o3.0o Optimal Window Flushing. This is an unfortunate place to make the mistake of suggesting flushWindow rather than flushWindowIfNeeded after a reenableFlushWindow. But then, what's the cost of flushing a window with an empty dirty rect (is ¼IfNeeded really needed)?

NextDev/Concepts/Pre3.0_Concepts/07_ProgDynam.rtfd
KBNS.00.0.246_o3.0o
Flipped coordinates are an inherent property of the View, not a transient feature that can be turned on and off.  A View should receive only one setFlip: message during its life, before it's first displayed, preferably in the class method that creates it.  All of the View's drawing should assume its flipped coordinates.
First, the method is called setFlipped:, and second, the documentation for View doesn't mention this limitation. If it isn't a limitation (anymore), adapt this text, else explain (also in the documentation for View). It's always nice not to have to experiment while writing a ``mission-critical application'' :-|.

NextDev/Concepts/Pre3.0_Concepts/09_UIObjects.rtfd
KBNS.11.1.015_o3.0o Obsolete information should be updated
The Text class doesn't write the \pard control word; instead, it manipulates groupings to restore paragraph default values when needed.  [¼]
This is not true (anymore?): Text uses \pard frequently now (at least, the RTF generated by Edit does).

NextDev/DevTools/01_PuttingTogether/_BuildingAnApp.rtf
KBNS.10.2.050_o3.0o
debug	Compiles and links a debuggable, optimized version of the executable file with the extension .debug.  
That should be ``non-optimized'', of course. Same for the output of make help. This file also doesn't match what make help says, and, although the latter seems more up-to-date, it lacks the option ``diff'' that this file mentions. Furthermore, the app.make actually used isn't the one in /usr/lib/nib as this file says but the one in /NextDeveloper/Makefiles/app (and why are there two versions?).

NextDev/DevTools/11_Compiler/_CommandOptions.rtf
KBNS.10.2.047_o3.0o Suggestion for -M(M)(D) Either mention that this applies for #import too, or emphasize the contrary. Probably the same for the man page.

NextDev/DevTools/14_MachO/_LoadCommands.rtf
KBNS.10.2.049_o3.0o Mistake #define SG_NORELOC  0x3: that's not what the header file says¼

NextDev/GeneralRef/02_ApplicationKit/Classes/NXBrowser.rtf
KBNS.10.2.032_o3.0o Typesetting errors.
Besides, as most NeXTSTEP documentation, being generally imprecise (a contradictory overlap between sentences 2 and 3 (even if easily resolved), no stress on the nonintuitive fact that theTarget is ignored if theAction is null as the text literally says (or is that an error?), sentence 4 speaking about theAction only (what if that is null?)), twice  theTarget is erroneously replaced by theAction. This is the right text:
If both theAction and theTarget are non-null, sends theAction to theTarget.  If theAction is null, sends the action of the Matrix to its target.  If theTarget is nil, sends theAction to the target of the Matrix.  Returns nil if no target that responds to theAction could be found;  otherwise returns self.
Why not just reproduce the source code to avoid any misunderstanding? In this case, nothing needs to be abbreviated to pseudo code.
-sendAction:(SEL)theAction to:theTarget{
  // <<Explain the defaults for the arguments...>>
  return  [NXApp sendAction:(            theAction ?theAction:action)
                         to:((theAction&&theTarget)?theTarget:target)
                       from:self
            ]?self:nil;
  } // Return value indicates whether an action was successfully delivered.

NextDev/GeneralRef/02_ApplicationKit/Classes/NXBrowserCell.rtf
KBNS.10.2.010_o3.0o, Bug_NeXT.45393
·	NXBrowserCell

	The following methods have been added to NXBrowserCell to set an image that is displayed on the left side of the cell.  The alternate image is used when the cell is hightlighted.
	
	- setImage:backgroundImage;
	- image;
	- setAltImage:newAltImage;
	- altImage;
These methods aren't documented yet, although they are announced in ReleaseNotes/AppKit.rtf. Don't forget to mention that the NXBrowserCells won't make a copy of the NXImage, they will use the very instance provided in setImage:. In fact, the application will crash if the same NXImage is assigned to multiple NXBrowserCells, so a copy must be provided each time. Is this the same behaviour as for other setImage: methods?

NextDev/GeneralRef/02_ApplicationKit/Classes/NXDataLink.rtf
KBNS.10.2.026_3.0o Typo 1 ``dependent'', 1 ``dependant'' (the typo) in this document

NextDev/GeneralRef/02_ApplicationKit/Classes/OpenPanel.rtf
KBNS.00.0.247_o3.0o Small detail¼ or is it?
runModalForDirectory:file:types:
Loads up the directory specified in path and optionally sets filename as the default file to open.  If filename is NULL, no default file is set.  fileTypes is a NULL-terminated list of extensions (not including the period) to be used to filter candidate files.  If the first item in the list is a NULL, then all ASCII files will be included.  
Now this explains a lot: NeXT really believes that ASCII stands for arbitrary byte stream! They should try man ascii. In this case, ``ASCII'' should be removed.

NextDev/GeneralRef/02_ApplicationKit/Classes/Pasteboard.rtf
KBNS.10.2.025_o3.0o English It's ``extension'', not ``extention'' (3 times). For the convenience of the documenters, I tried to find all occurrences in /NextLibrary using WM's Finder, but none were found, not even the three in this file. Now what does that tell?¼

NextDev/GeneralRef/02_ApplicationKit/Classes/SavePanel.rtf
KBNS.10.2.023_o3.0o A recipe for crashes and spurious behaviour
I have investigated only OpenPanels, but since all runModal¼ methods ultimately derive their result from this one¼
runModalForDirectory:file:
- (int)runModalForDirectory:(const char *)path file:(const char *)filename

Initializes the panel to the file specified by path and name, then displays it and begins its modal event loop.  Invokes Application's runModalFor: method with self as the argument.  Returns the constant returned by that method, depending on the method used to stop the modal event loop.  
The only significance of this reference to runModalFor: is if the programmer is allowed to stop the session from within a delegate method or so (who has tried this already, please tell me?). But vital information on the values returned by the SavePanel (or a subclass) itself is missing. Here's a piece of code to make that clear; it was obtained from the source of a working program (can be copy-paste'd to other programs), and the diagnostic output always matched what happened so I'm quite confident about this. (Another possibility to explain all I found so far is a bug in filenames only, but then why the different results from runModal¼? Anyone to try this on a SavePanel? NeXT?)
/*a more elegant multi-clause selector*/
#define SELECT       if(0){
#define   IF(d)        }else if(d){
#define   IFDEFAULT    }else{
#define   ENDSELECT    }

/*overriding fall-through as the default in a switch statement*/
#define CASE      break;case
#define DEFAULT   break;default

switch([openPanel runModalForDirectory:filename file:NULL]){
  case 0:{ // that's 3.0's way of telling Cancel was clicked
    #ifdef BUGVERIFICATION
      /*var*/ const char* const * ppc=[openPanel filenames];
      SELECT
	IF(ppc==NULL)
	  fprintf(stderr,
	    "BUGVERIFICATION: Cancel was clicked on an OpenPanel that\n"
	    "BUGVERIFICATION:   had never returned other than through\n"
	    "BUGVERIFICATION:   Cancel before. (This would have crashed\n"
	    "BUGVERIFICATION:   your application.)\n");
	IF(*ppc==NULL)
	  fprintf(stderr,
	    "BUGVERIFICATION: This is what I would have expected, but\n"
	    "BUGVERIFICATION:   it has never happened.\n");
	IFDEFAULT
	  fprintf(stderr,
	    "BUGVERIFICATION: Cancel was clicked on an OpenPanel that\n"
	    "BUGVERIFICATION:   has returned the following selection before.\n"
	    "BUGVERIFICATION:   (The program would have spuriously\n"
	    "BUGVERIFICATION:   (re)opened some files, or got non-existent\n"
	    "BUGVERIFICATION:   paths if another directory was selected\n"
	    "BUGVERIFICATION:   (the directory method is always\n"
	    "BUGVERIFICATION:   up-to-date).\n");
	  for(/*ppc already initialised*/;*ppc!=NULL;++ppc){
	    fprintf(stderr,"BUGVERIFICATION:   %s\n",*ppc);
	    }
	ENDSELECT
      #endif
    return NO;
    }
  CASE 1:{ // that's 3.0's way of telling one or more files were selected
    /*some declarations in my code*/
    #ifdef BUGVERIFICATION
      fprintf(stderr,
	"BUGVERIFICATION: 1 was returned.\n");
      #endif
    /*my code did something useful with filenames here, including a return*/
    }
  DEFAULT:
    #ifdef BUGVERIFICATION
      fprintf(stderr,
	"BUGVERIFICATION: runModal... returned something else than 0\n"
	"BUGVERIFICATION:   or 1. This has never happened before.\n");
      #endif
    SHOULDNTHAPPEN return NO;
  }

NextDev/GeneralRef/02_ApplicationKit/Classes/ScrollView.rtf
KBNS.11.0.019_o3.0o Flipped unannounced As part of its -initFrame: method, a ScrollView does a [self setFlipped:TRUE], but this is not documented. Nevertheless, it is important to know this for anyone who wants to override -tile, as in the ScrollDoodScroll example. Workaround for this kind of poor documentation: use things like (![self isFlipped])?NX_YMAX:NX_YMIN, or anything you can think of to speed this up if needed, like macros.

NextDev/GeneralRef/02_ApplicationKit/Classes/Text.rtf
KBNS.00.0.041_o3.0o KBNS.11.1.rev RTF coding.
The documentation doesn't mention \gray, while this codeword is clearly used, and \tx (``tab position in twips from left margin'' according to the MS RTF spec, where ``a twip is one twentieth of a printer's point'' (do they really mean 1/72.27 in., or just the modern point which is 1/72 in.?)). The documentation should also clarify that \fc is for backward compatibility with previous versions of the Text object which mistakenly wrote and read this instead of \cf, and is therefore always used together with the correct \cf. And then there is the strange \cf0 (or \fc0\cf0): this is inserted into the RTF code for no reason at all, and the weird thing is that it is a no-op if it follows a \gray codeword, but it does change the text (to black) if it is the only colour indication on its line (found because of the special preparation of previous versions of KBNS¼). Furthermore, \gray167 is changed to \gray166 (this is no way to round 1/6). And I didn't see a pointer to the official RTF spec, or some form of relevant summary in the on-line docs (I didn't look closely, though)?
The RTF spec is ``reproduced'' (more like massacred) in the pre-3.1  Supplemental Documentation (only in printed form), and is also available on-line as indri.primate.wisc.edu:/pub/RTF/RTF-Spec.rtf according to Bruce_Gingery.
KBNS.11.1.031_o3.1o
For all other properties, it performs the setFont:parastyle: method.
That should be setSelFont:paraStyle: (verified).
KBNS.11.1.032_o3.1o
A paragraph ends in a Return character; the first paragraph is paragraph 0, the second is paragraph 1, and so on.
Shouldn't that be a ``newline'' character? I think so!

NextDev/GeneralRef/02_ApplicationKit/Classes/View.rtf
KBNS.00.0.249_o3.0o Error.
View is an abstract class that provides its subclasses with a structure for drawing and handling events.  Most of the classes defined in the Application Kit are direct or indirect subclasses of View.
An abstract class is one that cannot be (meaningfully) instantiated, like an Object or a Responder. Most contentViews or docViews are plain ordinary Views.
KBNS.00.0.248_o3.0o Change this, it is not clear for readers who don't know already (the text does not suggest that this is a method to be overridden if different behaviour is wanted rather than just to consult the behaviour of the class). Just an example of the general quality of the documentation.
acceptsFirstMouse
- (BOOL)acceptsFirstMouse

NOW: This returns YES if an initial mouse-down event in the ViewÐan event that causes the View's Window to become the key windowÐis sent to the View (through a mouseDown: message).  If only those mouse-downs that occur when the View's Window is already key are sent, this returns NO (the default).  The only way to change the default behavior is to implement this method in a View subclass.

FOR EXAMPLE: Every time an initial mouse-down occurs in a View (a mouse-down that causes the View's Window to become the key window), the AppKit consults this method to know whether the event should be further handled as any mouse-down event, or ignored (except for having made the window key [well, there's something else to be considered: makeKeyOnlyIfNeeded or something, and others]). As inherited from View itself, this method returns NO: the event does nothing but making the window the key window. [¼]
KBNS.11.1.001_o3.0o Inaccuracy.
mouse:inRect:
- (BOOL)mouse:(NXPoint *)aPoint inRect:(NXRect *)aRect

Returns whether the cursor hot spot at the point specified by aPoint lies inside the rectangle specified by aRect.  aPoint and aRect must be expressed in the same coordinate system. [Should be: ``in the receiver's coordinate system''; the whole point is that this method automatically evaluates NXPointInRect's third argument, which is what View's own [self isFlipped] also returns.]
KBNS.11.0.010_o3.0o A lie.
setOpaque:
- setOpaque:(BOOL)flag

Sets the View to be opaque or transparent as flag is YES or NO.  The entire area of an opaque View is automatically covered (white) when the View is displayed.  By default, a View is opaque.  Returns self.
Actually, the default is not opaque, and neither is an opaque View automatically covered (white) when it is displayed. Verified in a custom View instantiated from a NIB, but I guess this is just doing [[ClassInNIB alloc] initFrame:&frameInNIB], so¼ Minimal cure: ``Sets the View to be opaque or transparent as flag is YES or NO.  By default, a View is not opaque.  Returns self.'' (the actual behaviour is correct, the documented one is no good (use as contentView in a Box¼)). Better: information about what this method is used for (displayFromOpaqueAncestor:::, but what else?), and a remark about how it should be treated in a subclass (but that's something that can be said for the bulk of the documentation).

NextDev/GeneralRef/02_ApplicationKit/Functions/AppKitFuncs.rtfd
KBNS.00.0.250_o3.0o Suggestion. Why are the macros that deal with memory allocation not in the same place as the functions that they use (``Common'' instead of ``AppKit'')? Goes for the header file too (<objc/zone.h> instead of <appkit/nextstd.h>). There's no reason not to make the change: any program that uses one of the macros has to import <objc/zone.h> to use them anyway; programs that only import <objc/zone.h> will benefit too. Other functions and macros belong in Common as well (NXLogError, NX_ASSERT, ¼).
KBNS.10.2.039_o3.0o Obscure, NXLogError(), see also KBNS.10.3.025. The description should become
If the application was launched from a shell <<explain how NXLogError() knows this, maybe it's something with a controlling terminal (what if an application launched from a shell divorces from its controlling terminal?)>>, NXLogError() writes a sprintf()-formatted <<that, or something more elaborate?>> string to stderr. If the application was launched from the Workspace Manager instead, NXLogError() gives that same string aString (right, syslog()'s %m does not work with NXLogError()) to syslog(LOG_USER|LOG_ERR,"%s",aString), with syslog() configured to mention the process' name and pid. Depending on /etc/syslog.conf, this means that the message will normally end up on the console, preceded by the time of occurrence, the name of the host, the process name and process number. See the UNIX manual pages for syslog() and syslogd() for more information.
KBNS.10.3.011_o3.0o A lie (or a mistake, or obsolete truth) about NXReportError From the verification process of KBNS.10.3.010, it is obvious that NXReportError delegates to NXLogError rather than ``If no matching error code is found, an unknown error code message is written to stderr.'', and probably the same change should be applied to ``These three functions set up an error reporting procedure, which typically includes writing a message to stderr.''. Here is some further evidence: a partial disassembly of NXReportError (doesn't compile).
#define _ISELEMENTOFRANGE_TO_(x,y,z) (((y)<=(x))&&((x)<=(z)))
void NXReportError(NXHandler *errorState){
  /*var*/
    unsigned int d0;
    struct{int min;int max;NXErrorReporter *proc} *a0;
  for(d0=0,a0=_Ranges:l;d0<_NumRanges:l,signed;++d0,++a0)
    if(_ISELEMENTOFRANGE_TO_(errorState->code,a0->min,a0->max))
      (a0->proc)(errorState);
      return;
  NXLogError(0x6115da5,errorState->code);
  }


NextDev/GeneralRef/02_ApplicationKit/Protocols/NXDraggingInfo.rtf
KBNS.10.3.001_o3.0o Obvious little mistake. Return type should be Window*, or nothing (for id, the default).
- (NXPoint)draggingDestinationWindow

NextDev/GeneralRef/02_ApplicationKit/Protocols/NXWorkspaceRequestProtocol.rtf
KBNS.00.0.251_o3.0o A LIE! ``Even if this method isn't invoked, Workspace will note changes to the file system relatively quickly if it is the active application.'' Just try doing a delayed file creation (an at command in a shell), then activating the Workspace Manager. Don't wait for the change to show through, it will take for ever and a day (don't touch the mouse or the keyboard, that would be cheating)! Well, I didn't test it for longer than five minutes¼ When will you enhance the file system to report changes to applications registering themselves with it? All this polling mess is nauseating. findApplications here, fileSystemChanged there, didDefaultsChange another place¼ yuck!

NextDev/GeneralRef/02_ApplicationKit/TypesAndConstants
KBNS.10.3.026_o3.0o NXArgv Isn't documented. The only documentation is in NextDev/Concepts/Pre3.0_Concepts/06_ProgStructure.rtfd.
KBNS.11.1.021_o3.0±3.1o Bug_NeXT.49878 NXSystemDomainName mystery, reported by Bruce_Gingery for 3.1, my explanation
What nonsense to name this constant like this and document it as ``The name of the host's domain.'', when in fact it is the owner name (``System'') of such default properties as "NXWindow Frame NXSavePanel"¼ It led Bruce_Gingery to complain that it doesn't give the same result as getdomainname(), and I merely stumbled on the truth while examining /usr/shlib/libNeXT_s.C.shlib. There's another called _NXAppKitDomainName, that probably stands for ``NeXT1'', another owner (this is speculation).

NextDev/GeneralRef/05_DisplayPS/SingleOpFunctions/IntroSingleOpFuncs.rtf
KBNS.10.3.007_o3.0o A LIE! ``For each operator, there are actually two C functions:   One that takes a context argument and another that assumes the current PostScript context.  The functions that take a context argument have a ªDPSº prefix; those that assume the current context have a ªPSº prefix.'' This is not always true: for example, PSsetwindowlevel has no DPS equivalent. Provide proper indications about this.

NextDev/GeneralRef/07_Preliminary_IndexingKit/Classes/IXRecordManager.rtf
KBNS.10.3.035_o3.0o setComparisonFormat:andContext:forAttributeNamed: How very funny¼

NextDev/GeneralRef/09_MachKit/Classes/NXSpinLock.rtf
KBNS.10.3.014_o3.0o English. ``acquired'', not ``aquired''.

NextDev/GeneralRef/ApA_DataFormats/DataFormats.rtf
KBNS.00.0.252_o3.0o
All formats should be documented (NXFileContentsPboardType, NXColorPboardType).
Also, an NXBytestreamPboardType should be provided for binary data, so that NXAsciiPboardType doesn't have to be abused for this (this type should never contain a byte with a MSb that's not 0), and NXNextstepEncodingPboardType to stop this dirty business of appropriating standards while not implementing them properly (like with RTF too). NXAsciiPboardType would be derived from NXNextstepEncodingPboardType by the NXToAscii() function, this from NXRTFPboardType. And of course, NXUnicodePboardType later on¼
KBNS.10.2.037_o3.0o NXTIFFPboardType Rather than 5.0, NS_3.0 supports 6.0 of the TIFF standard, say the ReleaseNotes. Which should I believe? Making statements like this, if not supported by a strategy to update them (same for NCARGS in execve(2)), is very unprofessional.

NextDev/UserInterface/03_Mouse/_ImplementingInput.rtfd
KBNS.00.0.253_o3.0o The following is a lie: ``For example, double-clicking an icon in a Workspace Manager window picks out that icon just as a single click would.  It then goes on to open the application associated with the icon.'' What really happens here (on the shelf anyway) is that WM waits for either the double-click time window to elapse before selecting the icon on the path, or for a double click to occur to open or activate it.

UserGuide
KBNS.00.0.254_o3.0o Where is the updated version (rhetorical)? There are several references to it from NeXT's NXHelpPanels about items that aren't mentioned in the 2.X User's Reference.

Various typographical errors
KBNS.00.0.255_o3.0o NextDev/GeneralRef/02_ApplicationKit/Classes/View.rtf
dragImage:at:offset:event:pasteboad:source:slideBack:
KBNS.00.0.256_o3.0o NextDev/GeneralRef/08_InterfaceBuilder/Protocols/IB.rtf
The explanation for unregisterDocumentController: is entered with a header copy-pasted from registerDocumentController:, but the author forgot to add two letters (twice)¼ Reported by Subrata_Sircar.
KBNS.00.0.257_o3.0o NextDev/GeneralRef/02_ApplicationKit/Protocols/NXDraggingDestination.rtf
perfromDragOperation

Suggestions
KBNS.00.0.258_o3.0o Obsoleted API The documentation for obsoleted objects and functions should be kept even after the include files and/or the shlibs cease to support them, maybe collected in an entirely different folder, for those who have to adapt old code written by others, that contains such obsoleted entities. They should not be forced to obtain the old documentation somewhere. It would be nice if this documentation were written in terms of converting to the new situation, and included a description of why the entity was obsoleted. For instance, the include file <appkit/obsoleteBitmap.h> to document this obsolete object is not very instructive.

PostScript
Suggestions
KBNS.10.3.042_o3.0o The DPS server should coalesce instructions that affect window order, by not executing them until either 500 ms after they were received or until the maximum delay of a previous instruction has elapsed or until no further instructions await execution: at that time the result of all these instructions together should be computed and then executed. Motivation: on systems with enough resources, responsiveness will be achieved because the DPS server will often be waiting for further instructions; on other systems, listening to the disk while it is getting from swap, windows that will be displayed briefly before getting removed themselves, is very frustrating. There are other uses, and probably other cures.

RenderMan
Use the Find facility on this word (some very ugly Window Server crashes happened in 3.0, not tested yet in 3.1).
KBNS.11.1.025_3.0c An exchange on NeXT-prog@cpac.washington.edu
Dale_Brisinda: ``In NEXTSTEP release 3.0 there was a problem with the RiPointsPolygon Renderman interface for rendering a polyhedra. If you passed it more than a certain number of polygons (can't recall how many, but it was under 1000) then the window server would die (or something like this). Does anyone know if this problem has been fixed in NEXTSTEP release 3.1?''
Jeff_Martin: ``Yep, this was fixed and released in 3.1.''
Does this mean that we can now safely use RenderMan, or is it just part of the solution?

Security
See KBNS.00.0.234, KBNS.00.0.280, KBNS.00.0.285, KBNS.10.2.036, KBNS.10.3.034 (there may be others)

SoundKit
SNDConvertSound()
KBNS.10.1.016_o3.0±3.1o From a 1993-05-04 comp.sys.next.(bugs/programmer) posting by Eric_Scott, NeXTPR-D 89, verified by me, reported for 3.1 by Subrata_Sircar.
Eric_Scott provides an example (available from him) that shows that SNDConvertSound(), for microphone sound files to 16-bit 22-kHz mono at least, apparently isn't able to handle a negative SNDSoundStruct.dataLocation for the source sound, or a non-sizeof(SNDSoundStruct) value (not pinned down yet). It returns an error SND_ERR_CANNOT_ALLOC (says he, I only saw the result of SNDSoundError() and they seem to match). Eric_Scott furthermore says (these I didn't verify) that when compiled on 2.2 things work fine when run on 2.2, and die with SIGSEGV and an ``amazing'' backtrace when run on 3.0, and that an attempt to get around the problem using SND_FORMAT_INDIRECT didn't work.
(I also found that the quality of a conversion with SNDConvertSound like this, and then playing it, is less than playing microphone sound files directly¼ should the intermediate step really make the sound audibly duller?)

/Object/Sound
KBNS.00.0.260_o3.0c Reported by Henry_Flurry, verified by me, reported to be cured in 3.1 by Subrata_Sircar
[theSound writeSoundfile:thePath] may/will produce a damaged sound file. On my one test trial, this program changed my sound file such that it was broken off after a fraction of a second, although it was still longer than a minute as indicated in the WM's Contents Inspector (try this only on a discardable copy of your sound!). The code was slightly altered from the version provided by Henry_Flurry, to facilitate the choice between the erroneous method and the workaround. Compile with cc -Wall program.c -lNeXT_s -o program, where program.c follows:
#import <soundkit/soundkit.h>
#import <appkit/appkit.h>

int main(int argc, char *argv[])
{
    Sound *sound = NULL;
    SNDSoundStruct *	soundStruct;
    NXStream *	stream;

    printf("initFromSound\n");
    sound = [[Sound alloc] initFromSoundfile:argv[1]];

    if(!(1<argc-1)){ // give more (ignored) arguments to use the workaround
        [sound writeSoundfile:argv[1]];
      }else{
	[sound compactSamples];
	
	soundStruct = [sound soundStruct];
	
	stream = NXOpenMemory((void *)soundStruct,
			soundStruct->dataLocation + soundStruct->dataSize,
			NX_READONLY);
	
	printf("writeSoundfile\n");
	NXSaveToFile(stream, argv[1]);
	
	NXCloseMemory(stream, NX_FREEBUFFER);
      }
    return 0;
}

Third-party applications
Some phenomena that are known to be a consequence of 3.0 bugs, in a non-trivial way, with workarounds.
Mathematica
KBNS.00.0.261_o3.0o Reported by Eric_Guichard
If you have problems with Mathematica crashing (e.g., Jan 20 18:44:19 mauss WindowServer[149]: IPCFlushOutput: failed to flush output  for stream 0x3752a8.), try to remove your .mb files manually, or using
$ find ~ -name Defaults -prune -o -name '*.mb' -exec rm {} \;
Unfortunately, .mb files are meant to increase performance¼ The (unspecified) bug has been identified and is known to both Wolfram and NeXT, the trouble applies to versions M_2.0 and M_2.1 (earlier too?), the above workaround was suggested by Robby Villegas of Wolfram, and M_2.2 will supposedly work around NS_3.0's bug.

SimonSays
KBNS.10.3.017_c3.1o NS_3.1 for NeXT hardware breaks SimonSays, reported by two people on c.s.n.(bugs/programmer) on 1993-06-22
The program doesn't work anymore, and a continuous repetition of these error messages ensues (syslog extras stripped):
DPS client library error: PostScript program error, DPSContext 30988
%%[ Error: invalidaccess; OffendingCommand: put ]%%
DPS client library error: PostScript program error, DPSContext 30988
%%[ Error: invalidaccess; OffendingCommand: aload ]%%
Is this because of NeXTSTEP, or because of HSD (in which case this item doesn't belong here)?

Unix, Mach, Libraries
Administration
KBNS.00.0.262_o3.0o Suggestion. Trim log files using another solution than running shell scripts from crontab. This won't work for hosts that are powered down for the night. (A workaround is to run the scripts manually or change crontab.) Use at or something.

Manual Pages.
KBNS.00.0.263_o3.0o (c)sh(1) Where is the information to explain ``if [ -r $i ]'' in /usr/adm/weekly, a sh script? There is a command /bin/[, but it is not explained in a separate man page. KBNS.10.1.004_o3.0o David_Koski tells me that /bin/[ is a ``synonym'' for /bin/test (confirmed by diff). Well, there's still nothing in the documentation to find that out, even in the reverse direction¼
KBNS.10.3.022_o3.0o (c)sh(1) The manual page for csh still talks about sbrk(2): is limit datasize now meaningless or merely implemented differently? The man page for (s)brk is very uninformative too: it should explain what these calls normally do, explain whether this is because of Mach, state whether this limitation is temporary or unavoidable, and suggest a workaround, if any.
KBNS.10.2.027_o3.0o copy(1) confusing detail¼ Don't say paste removes the data from the pasteboard, because paste just reads the data.
KBNS.00.0.264_o3.0o flexus> /usr/ucb/man mf (underscores lost because of copying from Terminal)
Reformatting page.  Wait...
/usr/man/man1/mf.1: line 124: no specification
tbl quits
 done

MF(1)               UNIX Programmer's Manual                MF(1)

NAME
     cmmf, inimf, virmf  - METAFONT, a language for font design
[¼]
     5.0.  A listing of gf numbers for 118-dpi, 240-dpi and 300-
     dpi fonts is shown below.

flexus> (the problem is that the manual page's representation is apparently cut short)
KBNS.11.1.027_o3.0o ptroff(1), with help from Charles_Fu
-l555 doesn't work, it should be -l 555 (e.g.). The program doesn't even complain, it just ignores the flag if a user believes the SYNOPSIS documentation and doesn't include the space. Besides, the default, in 3.0 at least, is clearly not 11in (more like 10.5 in), so that troff and PS page breaks aren't synchronised.
KBNS.00.0.265_o3.0o flexus> rm /usr/man/cat1/tbl.1; /usr/ucb/man tbl, reported by Robert_Brown, verified by me, Bug_NeXT.37941
Reformatting page.  Wait...
/usr/man/man1/tbl.1: line 50: no specification
tbl quits
 done

TBL(1)              UNIX Programmer's Manual               TBL(1)
[¼]
          Far Hills\t240\t3.19
          .TE

     yields

flexus> 
KBNS.00.0.266_o3.0o getfh(2) man page missing, reported by Robert_Brown, Bug_NeXT.34131
From the official Berkeley man page: ``Getfh returns a file handle for the specified file or directory in the file handle pointed to by fhp. This system call is restricted to the superuser.'' Robert_Brown says it is functional on the NeXT.
KBNS.10.3.033_o3.0±3.1o execve(2), reported for 3.1 by Charles_Fu, verified for 3.0 by me
     [E2BIG]        The number of bytes in the new process's
                    argument list is larger than the system-
                    imposed limit.  The limit in the system as
                    released is 20480 bytes (NCARGS in
                    <sys/param.h>.
Actually, on NeXTSTEP, NCARGS is defined to be 40960 (it's very dangerous to give actual values for constants if there is no safe update policy). Also see KBNS.10.3.031: execve(2) does not correctly implement NCARGS in 3.1.
KBNS.00.0.267_o3.0o hostid(2) gethostid(2) tells that the last three bytes are the last three bytes of the ethernet address, so this Internet thing is nonsense (for other reasons as well).
DESCRIPTION
     The hostid command prints the identifier of the current host
     in hexadecimal.  This numeric value is expected to be unique
     across all hosts and is commonly set to the host's Internet
     address.
KBNS.00.0.268_o3.0o stat(2), from a report by Robert_Brown. Should explicitly state that st_blocks expresses a size in 512-byte blocks (see the macro STAT_BSIZE in the header file), otherwise the device's physical block size will be assumed by some/most users.
KBNS.00.0.275_o3.0_3.1o fflush(3) The following is a lie. If NULL is used as an argument, the program crashes. [¼] Known to Bug_NeXTec as #2100 since 1992-08-13, reraised for 3.1 by Subrata_Sircar
     Fflush causes any buffered data for the named output or
     update stream to be written to that file.  The stream
     remains open.

     If stream is a null pointer, the fflush function performs
     this flushing action on all output and update streams.
KBNS.10.3.028_o3.0o stdarg(3) Missing (it is mentioned in the manual page for vprintf(3))!
KBNS.11.1.018_o3.0±3.1o memmove(3) and friends Why don't these ANSI C functions have a man page?
KBNS.10.2.017_o3.0o gettytab(5), from a report by Gerben_Wierda, my interpretation not yet verified by him.
     If a non-zero timeout is specified, with to, then getty will
     exit within the indicated number of seconds, either having
     received a login name and passed control to login, or having
     received an alarm signal, and exited.  This may be useful to
     hangup dial in lines.
The author's dangerous use of English here, totally unsuited for a manual page, camouflages a third possibility (if the author has at all recognised it): for /dev/ttyd*? (the device used for the ``dial in lines'' mentioned!), getty will block on open(2)ing the device (that is until DCD has been detected) and no signal will be accepted in the meantime (just look at the possibilities for errno in open(2)). If the timeout is reckoned from the start of getty, the first attempt to call this system after the timeout has expired will fail, wasting the caller's money. More likely (this is for Gerben_Wierda to verify yet), the timeout starts after the device has been opened. Unless this whole third case is no more than a bug. Who will tell me?
KBNS.11.1.020_o3.0±3.1o hosts.equiv(5), reported by Bruce_Gingery from a discussion on c.s.n.bugs around 1993-09, verified by Bruce_Gingery for 3.1 and by myself for 3.0 When network terminals are set to be secure, doing rlogin to such a system from root works, but not without giving a password. I put the line ``flexus root'' in /etc/hosts.equiv, ~root/.rhosts and /.rhosts (or is that another mistake?), but no go. Well, I'm not worried, it's as good an idea as setting network terminals not secure by default (perhaps more important is conformance with other Unix implementations; what is common there?), but it should be documented! Bruce_Gingery also reports (not verified) that when root is equivalenced in /etc/hosts.equiv, an rlogin can be done from root to any non-root user (not necessarily equivalenced) on the other machine without giving a password, which is not a security hole by the original specification, but it is at least strange that this root capability now does not require a password to be confirmed (root's, that is).
KBNS.00.0.269_o3.0o hier(7). Hey, don't patronise us! NeXTSTEP is Unix-based and many people buy it as a Unix solution. Give us the information!
KBNS.00.0.270_o3.0o flexus> /usr/ucb/man crontab, reported by Robert_Brown, verified by me, Bug_NeXT.39936
Reformatting page.  Wait...can't open file man8/cron.8
 done
flexus> 

Path
KBNS.00.0.271_o3.0o [¼] Changed to just this question: considering that having ``.'' in front is such a security risk (being in /tmp and accidentally executing a mischievous /tmp/ls), why did Kernighan&Pike make it an exercise (3.13) to explain why the current directory had to be in front, and why was putting it at the back done as late as at the transition from NS_2.X to NS_3.0? Maybe because in front is the only location available at an extremity if you want to easily change the path using something like set path ($path newdir) (newdir should definitely come after the others)?

C functions (system calls, ANSI¼)
KBNS.00.0.272_o3.0o execve(2) Give a better description of what an interpreter-style executable should look like: how many characters can there be on the first line (apparently limited), what happens to flags on that line, etcetera. Now we know nothing. Bug_NeXTec.2101.
KBNS.10.1.005_o3.0o execve(2) ignores setuid for a script, with the cooperation of Gerben_Wierda, Johan LorrÝ and David_Koski (who corrected an erroneous assertion by Gerben_Wierda). I hope it's somewhat true now.
(Probably similar comments apply to the setgid bit.) Gerben_Wierda says (not verified) that System V ignores the setuid bit for scripts, BSD doesn't, NeXTSTEP (an otherwise BSD compatible) does (actually this is just for csh, as David_Koski pointed out: ``Actually csh itself ignores this bit.  It refuses to switch users.  The bourne shell, on the other hand will work just fine.''), and that this is to avert attacks by intruders who would otherwise be able to execute any program they like with the effective user identity of the owner of such a script (ask him for how this is done). The need for setuid is the same as for any executable, says Johan LorrÝ. The following is what I think of the matter: The risk of setuid exists only if the script uses an interpreter (the identity of this cannot be tampered with) that does not check the script's stat information again after opening it and if an intruder can make path mean something else than the script that was executed. But rather than disabling setuid, the cure should be to properly document this danger (its two conditions), and to change the standard interpreters (like sh, csh) to safely work with setuid scripts. A better solution is to automate the check in the kernel. The ultimate: store the content of the script at execve() time, so that it can be updated or even removed at any time, even before the interpreter opens it, like any executable, without bothering anyone who is currently executing it.
Also see KBNS.10.3.031: execve(2) doesn't correctly implement NCARGS on 3.1.
KBNS.10.3.015_o3.0o mutex_lock(2) doesn't block as stated in the documentation
Discovery inspired by documentation of NXLock and NXSpinLock, proved by disassembling mutex_wait_lock (see my c.s.n.p 1993-06-(23-24) posting: ``mutex_lock(): quest with a sad ending...''). Here are the quotes from NextDev (pay special attention to ``a busy-waiting version of mutex_lock() could be written''):
/NextLibrary/Documentation/NextDev/OSSoftware/Part1_Mach/01_Concepts/Concepts.rtf
``If any other thread tries to use the counter in the meantime, it will block when it tries to lock the mutex.  If more than one thread tries to lock the mutex at the same time, only one will succeed; the rest will block.''
``Attempting to lock a mutex that one already holds is another common error.  The offending thread will block waiting for itself.''
``You must be careful to avoid deadlock, a condition in which one or more threads are permanently blocked waiting for each other.  The above scenarios are a special case of deadlock.  The easiest way to avoid deadlock with mutexes is to impose a total ordering on the mutexes, and then ensure that threads only lock mutexes in increasing order.''
/NextLibrary/Documentation/NextDev/OSSoftware/Part1_Mach/04_MachFunctions/MachFunctions.rtf
``In particular, a thread blocked in mutex_lock() or condition_wait() should be viewed as referencing the object continually; freeing the object out from under such a thread is erroneous, and can result in bugs that are extremely difficult to track down.''
``The macro mutex_lock() attempts to lock the mutex m and blocks until it succeeds.  If several threads attempt to lock the same mutex concurrently, one will succeed, and the others will block until m is unlocked.''
``The function mutex_try_lock() attempts to lock the mutex m, like mutex_lock(), and returns true if it succeeds.  If m is already locked, however, mutex_try_lock() immediately returns false rather than blocking.  For example, a busy-waiting version of mutex_lock() could be written using mutex_try_lock():''
Here's the disassembled code:
void mutex_wait_lock(mutex_t m){
  /*const*/ char *pc_m=(char *)m;
  /*var*/ int counter;
  #define GOFORTHELOCK                                                        \
    if(!pc_m[0]){      /*if lock is up for grabs (only to avoid a futile tas?)\
      pc_m[1]=0;       /*Why? These locking methods all do it...*/            \
      if(!tas(pc_m[0]))/*if the lock has been acquired*/                      \
	return;   /*tas is an MC680x0 instruction which constitutes*/         \
      }           /*an atomic test-and-set that returns the previous value*/
  for(counter=0;counter<_mutex_spin_limit;counter++      ){ GOFORTHELOCK }
  for(         ;/*infinite loop*/        ;cthread_yield()){ GOFORTHELOCK }
  #undef GOFORTHELOCK
  }
KBNS.10.1.015_o3.0±3.1FIPo select(2), reported by Matthew_Dillon, known to Bug_NeXT (I don't know the log numbers), not verified
``[¼] If you have a program which uses select() and the select() is broken by a signal (example: SIGINTR, SIGPIPE, etc..), operation will continue as per normal but when the process exits it will become a pid -1 <mach-task> until the machine is rebooted.'' Matthew_Dillon said that it seemed that 3.1FIP hasn't cured this.
KBNS.10.1.027_o3.0o select(2), reported by Matthew_Dillon, known to Bug_NeXT (I don't know the log numbers), not verified
``select() screws up with descriptors set to non-blocking. I had a UDP socket set to non-blocking I/O and select() could get into a mode where it would block even when packets are pending on the socket.  This could be a bug with the networking stuff.''
Formatting mine. I hope Matthew_Dillon is right here, it sounds like some rather complicated stuff.
KBNS.00.0.273_o3.0o (l)stat(2) Reported by Robert_Brown, Bug_NeXT.36475.
``[¼]
Whenever lstat(2) is invoked on a symbolic link that resides in a directory that's on [a ROCKRIDGE CD-ROM], it returns a stat structure whose st_size field is zero.  Instead, the st_size field should be set to the length of the file path that the symbolic link points to.  This is the behavior one sees when lstat(2) is passed symbolic links that reside on hard disks or optical disks or NeXT floppies or the NeXTSTEP_3.0 upgrade CD-ROM.
Several Unix utility programs, like even plain old /bin/ls -al, are confused by this bug when they encounter symbolic links on CDROM disks, so fixing this bug is important.'' Italicised parts mine (ROCKRIDGE: from a follow-up that Robert_Brown sent.)
KBNS.00.0.274_o3.0o (l)stat(2) Reported by Robert_Brown.
For ISO-9660 CD-ROMs, stat() fills st_blocks with the number of actual 8-kB blocks rather than the 512-byte ones stat()'s header file indicates (with the macro STAT_BSIZE). du and ls -s apparently use this block count, and are fooled into reporting a size 16 times too small (somehow WM is not put off track). Also note that the manual page for stat(2) should state this 512-byte block size, or else one would assume that the actual, physical block size is meant.
KBNS.11.1.017_o3.0±3.1o bcopy(3) Is documented as taking char * arguments, but implemented using a method that accepts void * arguments so that the compiler won't do the proper checks.
KBNS.11.1.024_o3.0±3.1o getpwent(3), from a summary by Harvey_Dueck on NeXT-prog@cpac.washington.edu on 1993-09-23, not verified The cache that this facility uses is not refreshed in a timely fashion, and the user of it may get stale information. Use the netinfo calls instead.
KBNS.00.0.276_o3.0c getwd(3) Reported by Robert_Brown, Bug_NeXT.39778. (KBNS.10.1.rev), reported to be cured in 3.1 by Subrata_Sircar (``Attachs the private but returns correctly.'') XXX what does Subrata_Sircar mean here?
This function says it ``returns a pointer to the result'', but this is very misleading: the result in private storage, as is evidently but erroneously the case in NeXTSTEP_3.0 (verified by me), or its copy in the storage pointed to by the argument? This ambiguity should be cleared up, probably in favour of the latter case, in which case the NeXT implementation should be cured: ``on Sun machines'' and on ``BSD Inc.'s  BSD/386'' (!) the pointer returned is the one given by the programmer, and Robert_Brown also provides source code from the GNU bash shell to indicate that this supposes that the pointer returned is the one given.
KBNS.10.2.022_o3.0o malloc(3) A question, I don't know if this is harmful
malloc(3) has always been documented as returning NULL if no space is available. In NeXTSTEP, the underlying vm_allocate can service all requests without actually allocating this memory. It becomes now possible to get, say, 80 MB of mallocated memory, with 20 MB of free disk space and the swapfile already grown beyond its lowat. But if the application actually touches too much of this memory, the machine will crash (horrible things will happen if the swapfile or the disk are exhausted, these are doubtlessly bugs). Workaround (this should work?): use calloc and take the performance hit. But should malloc promise more than it can deliver?
KBNS.00.0.277_o3.0±3.1o printf(3) Reported and verified by Subrata_Sircar (for 3.1 also), from Eric_Norum
From: eric%skatter.usask.ca@Princeton.EDU
Subject: printf g format still broken under NeXTSTEP 3.0
Date: Wed, 11 Nov 1992 01:22:28 GMT

I reported this bug in December 1989, and when NeXTSTEP 2.0 came out,
and when NeXTSTEP 2.1 arrived, and now that NeXTSTEP 3.0 has arrived ...
IT STILL ISN'T FIXED!!!!!

Here's an example program:

#include <stdio.h>
int
main (int argc, char **argv)
{
	int i, d;
	double x, y;

	y = 3.141592654;
	for (i = 0, d = 1 ; i < 5 ; i++, d *= 10) {
		x = y / d;
		printf ("%12g %12.1g %12.2g %12.3g %12.4g\n", x, x, x, x, x);
	}
	return (0);
}

Here's what *should* print (according to the ANSI standard).  And it *does*
print this on our SUN 4.1.2, and HP-UX V8, systems:
     3.14159            3          3.1         3.14        3.142
    0.314159          0.3         0.31        0.314       0.3142
   0.0314159         0.03        0.031       0.0314      0.03142
  0.00314159        0.003       0.0031      0.00314     0.003142
 0.000314159       0.0003      0.00031     0.000314    0.0003142

And here's what the NeXT produces:
    3.141593          3.1         3.14        3.142       3.1416
    0.314159          0.3         0.31        0.314       0.3142
    0.031416            0         0.03        0.031       0.0314
    0.003142            0            0        0.003       0.0031
    0.000314            0            0            0       0.0003

For the umpteenth time, NeXT:
1. The precision specifier for %g format is supposed to set the number of
   significant digits in the printed number.

2. Non-zero digits to the left of the decimal point *do* count towards
   the number of significant digits (see the first line of the tables).

3. Leading zeroes do not count towards the number of significant digits,
   even when they are to the right of the decimal point (see the last
   three lines of the tables).
KBNS.11.1.002_o3.0o printf(3), reported by James_Moosmann on NeXT-prog@cpac.washington.edu on 1993-08-18, verified by me
According to K&R's ``The C programming language, 2nd ed.'', which is the authority on ANSI C (right?), the printf() family of functions should return the number of characters printed, or a negative value if an error has occurred. James_Moosmann has found that printf() normally returns 0 on his version of NeXTSTEP, and I could reproduce that on NS_3.0. The man page doesn't talk about any return value either. Workaround: use %n.
KBNS.10.2.046_o3.0o putenv(3), setenv(3) These are totally absent from the system (actually I don't know for certain if they're supposed to be there, tell me if this is a bug rather than a mere fact). Whoever feels a need for these can probably get them from Brian_Glaeske, who also posted them (as source) to comp.sys.next.programmer on 1993-06-14 (NeXTPR-D 135).
KBNS.00.0.278_o3.0o strftime(3) Reported by Howard_Smith and verified by me. Function doesn't have a man page (it does in 3.1, says Subrata_Sircar). Isn't documented in any file CLibLocalization.rtf (contrary to what /NextLibrary/Documentation/Concepts/Localization.rtfd says). %j returns incorrect value (e.g., 53 for today, should be 54). %h and %e aren't supported, says Howard_Smith, but I don't see them documented in K&R edition 2, so¼ (Everything in Howard_Smith's little test program (a few kB), available from him, does work ``under SGI 4.0.5 system'', including %h (same as %b?) and %e (same as %d?).)
KBNS.10.3.023_o3.0c tmpnam(3), reported ``cured'' in 3.1 by Frank_Thomas XXX ANSI says nothing about NULL
Unlike what its manual page specifies, NS_3.0's tmpnam() always tries the same sequence of 25 (=TMP_MAX) filenames /tmp/t.0XXXXX, /tmp/t.aXXXXX, ¼, /tmp/t.xXXXXX, where XXXXX is the process' pid, and returns the first one that doesn't exist (not a different string each time it is called), or NULL if all are occupied (and that may be, although unlikely, the first time this function is called, not more than TMP_MAX times). Furthermore, TMP_MAX=25 is far too low in itself. Here is the disassembled code:
char *tmpnam(char *arg1){ // compiles
  /*static*/ static char _tmpfilename[L_tmpnam];
    // L_tmpnam==strlen("/tmp/t.XXXXXX")+1, <stdio.h>
  /*var*/ long unsigned int i0,i2; char *a2;
  i0=getpid();
  bcopy("/tmp/t.XXXXXX",_tmpfilename,L_tmpnam);
    //inline and unrolled: how ridiculous with all these wasted access() calls!
  for(a2=&(_tmpfilename[L_tmpnam-1-1]);*a2=='X';--a2){
    *a2=i0%10+'0';
    i0=i0/10;
    } // write the pid on the X's, decimally
  ++a2; // go back to what was the first X
  for(i2='a';i2<='y';*a2=i2,++i2) // far too few choices!
    if(0!=(i0=access(_tmpfilename,F_OK))) // if file doesn't exist
      return (arg1!=0)?strcpy(arg1,_tmpfilename):_tmpfilename;
    // this loop tries TMP_MAX==25 times, for the first X position
    // taking values 0,a,b,...,w,x (what a silly range)
    // Starting from 0 each time violates ANSI and is not very smart with
    // regard to performance: suppose file 'x' is repeatedly deleted...
  return (char*)i0; // will always be NULL in this implementation
    // fell through, all filenames occupied
  }
And it would also be useful if tmpnam(3), tmpfile(3), mk(s)temp(3), NXGetTempFilename() would contain full references to each other, and have better explanations overall (e.g., mktemp and tmpnam should warn that they only provide a name and don't reserve the file, that the programmer is responsible for solving the race condition, especially since mktemp() and tmpnam() are highly uninspired in choosing names, and suggest how to do that).
In NS_3.1 this function has been made to comply with its man page and the ANSI specification (as Frank_Thomas points out). If it still can fail before TMP_MAX calls because of lack of inspiration (it only tries /tmp/t.YXXXXX where Y runs from 'a' to 'z') either through sabotage or byÐrather unlikelyÐaccident (maybe the process that previously had the same pid crashed and couldn't clean up its temporary files), this can be considered to be an internal contradiction in the ANSI spec: a limited L_tmpnam implies this kind of failure. Still¼
Of course, TMP_MAX is still very low. This forces a programmer to cache the filenames returned by tmpnam into an array from which they can be recycled, but this still doesn't allow for more than TMP_MAX simultaneous files. But how to cure? If the limit is raised, code might be written that won't compile and run on other systems (so what? other limits were raised by NeXT as well), and otherwise, an alternative should be provided. Anyway, L_tmpnam can't be raised without causing already compiled programs to possibly crash.

NMI Monitor
KBNS.00.0.097_o3.0o Bug? I have experienced that, when I reboot from the NMI monitor with the command ``reboot'' instead of ``halt'' and booting from the ROM monitor, the file system check is not skipped. Has there been some change since 2.1? There doesn't seem to be anything wrong: only some statistics on file count, fragmentation, etc., not the bad stuff that shows up after a cmd-cmd-* reset. Or is my hard disk degenerating or something? I have encountered this problem because I often reboot my system to clean up the swapfile (see elsewhere), sigh¼ And give a better diagnostic, preferably in /usr/adm/messages, not just keeping it a second or so on the screen.

Mach
KBNS.00.0.280_o3.0±3.1o System crash condition, reported by Robert_Brown, verified by me (total crash, only hardware reset helps), Bug_NeXT.34939, reported for 3.1 by Subrata_Sircar
``The following program reliably crashes my system.  [¼]
main()
{
    asm volatile(".word 0xf233");
    asm volatile(".word 0xec1b");
}''
From my 68020 manual (I don't have anything else handy), the first word is a general MC68881 (read FPU) instruction, ea something indexed on a3, and the second is the actual coprocessor command. After this 0 or more words will be gobbled up as coprocessor-defined extension words and 1 to 5 more as ea extension words. Comparing a hexadecimal dump of the program with disassembly of main() (it turns out to be a valid instruction: fmovemx d1,a3@(0x5e:b,d4:l:8)) indicates that these numbers are 0 and 1, and the one casualty is unlk a6 (this is not the cause of the error, though, because Robert_Brown's original program crashed with this FPU instruction somewhere else). Mach should isolate the crash to its task or thread.

VM
KBNS.00.0.281_o3.0o The swapfile won't shrink, a reboot is required for that. This is very annoying.
KBNS.00.0.282_o3.0o Reported by Douglas_Scott on comp.sys.next.(bugs/programmer) on 1993-04-19, NeXTPR-D 69. malloc(3) ignores /etc/swaptab's hiwat values. KBNS.10.2.014_o3.0o Whether this is a bug depends on your perception: it could be useful to be able to reserve a large address space, write stuff here and there, and have only the places touched swapped to disk, and compressed too; on the other hand, how should a program know when to restrain from using any more memory, especially since this invariably crashes a NeXTSTEP computer? I've tried to verify this, and I've found that indeed malloc does not initialise the memory, and does not reserve the swap space required (not touching the memory is a feature, you can touch bytes here and there, mostly NULL pages will be very much compressed too; not reserving it can pose this problem), so I could allocate 512 MB on a 400-MB disk. When trying a program that fills a buffer from stdin by repeatedly increasing it using realloc() (probably a bad technique?), messages appeared on the console saying something about the front becoming full, then available again, then full again (a couple of times). I set the hiwat to 32 MB, and my test program uses realloc() with increasing sizes. After a while, everything frose, and on one occasion I was presented the login panel again, on another, only an alt-cmd-* reset helped. Strange.

TCP/IP
KBNS.00.0.283_o3.0o Reported by Subrata_Sircar, from Thomas_Funke
The thing is that a bug/error in a user-level program crashes the whole machine, which is never acceptable.
From: thf%zelator.in-berlin.de@Princeton.EDU (Thomas Funke)
Subject: SYBASE crashes 3.0  - and SOLUTION !
Date: Sat, 10 Oct 1992 14:04:19 GMT

It's almost 1 year ago since several people have noticed, that Sybase would
eventually crash the NeXT. It happened always after about 1000 logins into
the server. I had some discussion with 'ask_next' and it came out, that it
was a bug in NeXT-networking software. Anyway, nobody at NeXT could give a
solution, so I waited for 3.0. Now, running the crash program showed the
same behaviour: after 1000 logins the NeXT would come to a complete stop.

Because several people have reported this bug, it is not understandable,
nor acceptable that the responsible people at Next didn't care about it at
all, even if I had given them my short program which verified the crash.

Because the DB-Kit is one of the big improvements of 3.0, it's a major
annoyance. Today I have tried again to find out what happens. And the
solution is so simple:

Sybase (in the standard installation) uses port numbers 3696 and 4696 for
communication with the server. NeXT internally assignes portnumbers
1024-5000. This is standard BSD behaviour, btw.

And a 'netstat' just before crash-time showed: The NeXT tries to assign the
same port Sybase is using !

So after changing the Sybase-installation to use portnumbers greater than
5000, everything worked fine !

So for every tcp/ip-User/Programmer:

	NEVER USE PORT-NUMBERS <= 5000 !

Perhaps this should become part of the FAQ ! (Will this do, Thomas? :-))

NFS
KBNS.10.1.006_o3.0o, not yet verified, reported by Robert_Brown, verified by Ronald_Antony, modification by David_Koski () not yet verified, Bug_NeXT.33796.
Robert_Brown:
``The Next (with both release 2.1 and release 3.0 of the OS) seems to have a problem at shutdown time if the machine has automounted a file system from a computer that is already down.
I have a Next and Sun which automount each others disks.  If I turn the Next off first, and then the Sun, things work fine.  As the Sun shuts down, it prints a notice that the Next is not responding to NFS requests, but after a minute it times out and completes the shutdown.
When I shut off the Sun first, and later power down the Next, the screen eventually goes gray, but the Next never powers off.  I have to hit the power key again, at which time the Next does turn off.  Unfortunately, by hitting the power key a second time, the Next does not mark the hard disk with the "clean shutdown" flag.  The next time I power up, I have to wait while the Next runs fsck on the disk.''
David_Koski: ``This is due to the ridiculous timeout that NeXT uses.  Various fixes are possible.  Just change the timeout to something reasonable.''
KBNS.00.0.284_o3.0o Reported by Robert_Brown, verified by Marc_Elvy, Bug_NeXT.42795.
When mounting a file system onto a Sun Sparcstation 2 running SUNOS 4.1.1 from a NeXTSTEP_3.0 computer (not between identical machines or the other way around), touching a file from the Sun side produces always the same file date: 1969-12-31. This makes software management using make impossible. It is not known whether the NeXTSTEP server or the Sun client is the culprit (I bet against the NeXT¼).
KBNS.00.0.285_o3.0o Reported by Robert_Brown, from a 1993-04-09 comp.sys.next.sysadmin message by Christian_Baur. There's a problem with file ownership if NeXTSTEP mounts a Solaris 2.1 file system: setting privileges from the NeXTSTEP side will corrupt them in the direction of less security. Christian_Baur seems to understand the problem, and has a patch which you could use at your own risk.

/bin/chgrp
KBNS.10.1.025_o3.0o Bug with -R, reported by Hermann_Lauer in a 1993-05-10 NeXT-L@antigone.com message, verified by me chgrp -R apparently does a depth-last walk, and stops immediately before changing the children in a directory it doesn't own. KBNS.10.2.003_o3.0o  Hermann_Lauer reported that chgrp -fR isn't reliable either (I proposed it as a workaround because it solved things in my test case), so you'd better use his solution (\! -group other just speeds things up): find /Internet \! -group other -exec chgrp other {} \;). Here's a verification session for the bug:
flexus# chown -R root.staff /Internet  
flexus# chown rfschtkt.staff /Internet/edu/purdue
flexus# chmod a+w /Internet/edu/purdue
flexus# chgrp -R other /Internet      
chgrp: You are not the owner of cc
flexus# ls -lga /Internet/edu/purdue  
total 3
drwxrwxrwx  3 rfschtkt other       1024 May  1 21:03 ./
dr-xr-xr-x 48 root     other       1024 May 10 16:04 ../
dr-xr-xr-x  3 root     staff       1024 May 10 15:36 cc/
flexus# 

/bin/diff
KBNS.00.0.286_o3.0±3.1o Bug. diff(1) will ignore anything past the last newline in its comparison. Make two files, one with content ``a'', another with content ``b'' (no newline, file length 1), to verify it. (Previously I had written that diff will incorrectly process long lines. That diagnosis was faulty, and exposed as such by Subrata_Sircar (who also reported that it isn't cured in 3.1). Anyone who knows some examples of Unix commands failing on long lines, please tell me (again).)

/bin/gdb
KBNS.00.0.287_o3.0_3.1o Reported by Subrata_Sircar and verified by me, from Arrigo_Benedetti, reraised for 3.1 by Subrata_Sircar (``It's worseÐwatchpoints crash gdb!'')
From: arrigo@cube.sublink.org (Arrigo Benedetti)
Subject: Bug in gdb watch command with 3.0?
Date: 20 Nov 92 14:07:27 GMT

It seems to me that a bug prevents the gdb watch command to be of any use.
After I issue a watch command on, let's say, a variable expression, my
program gets interrupted after EVERY machine code instructions (or, at
least, this is what I suspect):

(gdb) watch j
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /arrigo/tmp/a.out

Program received signal 5, Trace/BPT trap
0x3dca in start ()
(gdb) c
Continuing.

Program received signal 5, Trace/BPT trap
0x3dcc in start ()
[and so on ... FOREVER]
KBNS.00.0.288_o3.0o Reproducible crash. I've tried this on four core files (two original ones, two recursively from the second), and gdb dumped core for all. Issue a warning instead.
flexus> gdb /cores/core.6220
IOT trap (core dumped)
flexus>
KBNS.00.0.289_o3.0±3.1o Bug when working with applications, verified for 3.1 by Subrata_Sircar. It seems that applications don't register their port when started from gdb, even though they do when started just from the shell. A workaround is to launch normally and attach to gdb, but this excludes some possibilities (tracing appDidInit: and so).
KBNS.00.0.290_o3.0o English. Error occured processing command from Edit. That should be occurred.

/bin/kill
KBNS.00.0.291_o3.0o Reported by Subrata_Sircar, from Matthew_Dillon's 1991-11-22 comp.sys.next.bugs posting, David_Koski says that this is normal behaviour, and a direct discussion between both didn't resolve the issue: who brings the solution?
From: dillon@overload.berkeley.ca.us (Matthew Dillon)
Date: 22 Nov 92 11:20:16 PST
>Another problem that I've found... you can't kill a 
>process that is blocked in device-open (e.g. blocked on a 
>dialup tty). That is definitely a bug, when you kill a 
>process (kill -9 pid) it's supposed to die, period.
``Try cat'ing something out the serial port with hardware handshaking then negate CTS while it is dumping.  You cannot kill the process.'' Not yet verified.

/bin/login
KBNS.11.1.010_o2.1±3.1o Accounting problems, reported by Bruce_Gingery for 3.1 (he also approved the final incarnation of this report), Bug_NeXT.?????, verified by me for 3.0, but probably already the case since 2.1 at least (if my memory serves me rightly)
/bin/login between non-root users doesn't update /etc/utmp about who is currently logged in on the system (/etc/utmp directly determines the results of who (am i), finger, the talk daemon; whoami isn't mislead because it looks at the process directly and is also affected by su (why shouldn't su affect utmp?)); /usr/adm/wtmp seems to be correctly maintained, but we didn't look closely.
Another thing that I noticed: after doing su (to root) and /bin/login an ordinary user (which doesn't overlay the current process!), then doing eof twice, who still reports that other user!
Situations where no problems occur: Doing login from root (doing su and either launching a new Terminal from there or doing /bin/login as a subprocess), or from any user to root (on a secure terminal). Logins directly from /etc/init (including rlogin, telnet, rsh), but that's actually a case of doing login from root (init runs as root).

/bin/make
KBNS.00.0.292_o3.0c? Revision from NeXT not welcomed Reported by Subrata_Sircar, from John_Stockwell, and Subrata_Sircar thinks it is cured in 3.1. There's a problem with make not obeying the usual meaning of .c.a something suffix rule. Maybe if I put the time into it I might understand and know what to quote, but I guess those who run into the problem will recognise this. According to John_Stockwell, it seems that NeXT meant to follow the latest AT&T version of make, but received many protests; a re-revised version is available upon request from Bug_NeXT(ec).

/bin/otool
KBNS.11.1.011_c3.1o From some disassembled code provided by Frank_Thomas from a black 3.1 system, works correctly on 3.0
otool now apparently reckons the offset of a bcc instruction to be from the word before the instruction word instead of the word after it, for a total error of 4 bytes (this is all MC680x0 talk). For the bsr case, the label is correct (only tested for 32-bit bsr jumps), so it's probably just the numerical output.

(/usr)/bin/(gnu)tar
KBNS.00.0.293_o3.0o Bug: gnutar cannot read all tar files
gnutar: only read 8202 bytes from archive Peter Pan.tar
This is /pub/next/Literature/working/PeterPan.tar.Z at sonata.cc.purdue.edu version 1991-12-10, as fetched using BITFTP@PUCC.Princeton.edu. Theirs is a very strange format (they add \0s and use a strange uuencode), but the old tar could handle it (even when not detecting what was strange).
KBNS.00.0.297_o3.0o Errors in tar(5)'s man page (quotes from my submission to Bug_NeXTec, #2064 of 1992-07-11)
In tar(5), it says that there are ``w-2 digits'', but in fact, the leading zeros become spaces.
The last character in the size field seems to be a null if the entry is about a symbolic link (at least in the one case I looked at).
The linkname field has only NAMSIZ-1 characters, instead of NAMSIZ (now the header block as documented has 257 characters).
KBNS.00.0.296_o3.0o Document. Provide a manual page, and explain what's the relation to /bin/tar and about Posix and stuff.
KBNS.00.0.294_o3.0o Suggestion: gnutar should use tar format if possible If gnutar compresses anything, it should use the old tar format if possible (unless there are some fantastic new features about the new format for all directories), and the new only for the ones with long file names etcetera.
KBNS.00.0.295_o3.0±3.1o Suggestion: use proper extension, verified for 3.1 by Subrata_Sircar. The extension .gnutar should be used for things that can't be handled by the normal tar. Compress from the workspace should use the extension .gnutar.Z (or .tar.Z) instead of .compressed: there's no need to introduce this new extension. Same for Installer packages, even though they are sort of private (actually they are in a format handled by bigtar inside the Installer.app wrapper, which should be abandoned in favour of gnutar).

/cores
KBNS.10.2.036_o3.0o Security leak. When this directory exists, core files will be dumped in it rather than in the current directory (I think that's the rule, I can't find it documented but it works for me). This directory obviously has to have all permissions for everyone, although, if there is documentation, it should advise that it be assigned a ``sticky'' bit, so that only the owner of a core file (or root) can remove it. But these core files are dumped with privileges -rw-r--r--¼ readable by all! That means that your secure information, that you always encrypt before saving it to disk, and contains your secret swiss bank account number, is readable to the whole world!

/etc/mtab
See KBNS.00.0.327

/etc/rc
KBNS.11.1.009_o2.1±3.1o /etc/rc.local invoked too soon, reported by Bruce_Gingery for 2.1, 3.0, 3.1, Bug_NeXT.?????
``The invocation in distribution /etc/rc (boot script) file of the LOCAL conventions file (/etc/rc.local) is before the UUCP Lock file cleanups.  Thus if any utilities are launched from rc.local, such as SLIP, PPP, or even a uucp poll, they will NOT find the LCK semaphore status correct, and if any are created by processes run from rc.local, they will be improperly removed by subsequent /etc/rc processing.''

/etc/sendmail/sendmail.*.cf
KBNS.00.0.298_o3.0o English. Don't say ``Canonicalization'', say ``Canonization''. Look it up in Webster! to make canonical = to canonize
KBNS.00.0.299_o3.0o Just a question¼ Are addresses like ``user at host'' not allowed anymore? This sendmail.cf doesn't seem to be equipped to handle them. But my mailhost (which has other quirks) doesn't allow me to send mail to bogususer@minor.major.at (in Austria), because its sendmail reads minor.major.at!bogususer as user ``minor.major.'' in domain ``!bogususer'' (probably fixable in ruleset 2). Who's fault is this? How acceptable/widespread is NeXT's pseudo-uucp transformation of Internet-style addresses for use on the Muucp mailer?
KBNS.10.2.008_o3.0o Suggestion, style of writing Change ``on error replies I generate'' to something like ``on error replies generated by sendmail'' (don't use the first person for the computer or a program).

/etc/ttys.installer
KBNS.00.0.300_o3.0±3.1o Verified for 3.1 by Subrata_Sircar Shouldn't this be the same as /etc/ttys on a distribution medium? For NS_3.0 this file is clearly older than ttys.

/etc/uucp/uucp.day.sh
KBNS.10.1.018_o3.0o A very dangerous bug! $UUCLEAN -p -n${HOURS} -d${i} will silently (no -m) delete everything that is older than 30 days (HOURS is defined to be 720). First of all, old uucp transfers should never be automatically deleted, and second, the thing to do is to warn somebody. This code should be taken out, and something put into /usr/adm/daily (yes, should not depend on uucp.day.sh being used) to warn the postmaster about anything older than three days or so. Any other dangerous stuff in here?
KBNS.00.0.302_o3.0o Bug. I get reports with the line ``Tue Apr 13 DST'', where the year should appear in place of ``DST''.
KBNS.10.1.008_o3.0o Bug/limitation The cost estimate is unacceptably low for short connection times (normally, for individuals) wherever the phone company uses indivisible call units (everywhere?).
KBNS.10.1.023_o3.0o Annoying Why would anyone want to know the sum of the costs incurred by those polling and the amount to pay instead of just the latter? Workaround: setting the cost for the systems that mainly poll to 0, and not calling out to those systems too much¼
KBNS.00.0.303_o3.0o Suggestion, international significance. ATT shouldn't be mentioned (isn't the monopoly broken in the USA as well)? $ shouldn't be assumed as the currency: there should be a file to configure that.
KBNS.00.0.301_o3.0o English. It's received, not recieved.
KBNS.10.2.040_o3.0o Bug. uucp.day.sh doesn't clean up after itself in /tmp.
KBNS.10.2.041_o3.0o Suggestion. Why putting something in the queue for all uucp connections, so that uucico will call those systems, wasting a connection charge?
If there are no more bug reports from me, it's because I've decided this facility is so crippled that it isn't of any use to me, so I switched it off.

/etc/yp/Makefile
KBNS.00.0.304_o3.0o Why executable? Known to Bug_NeXTec as #1358 since 1992-01-10.

/usr/bin/buildafmdir
KBNS.00.0.305_o3.0o Reported by Lorin_Rivers, not verified
``buildafmdir barfs with more than 250 fonts. To fix, replace the bogus NS 3.0 buildafmdir with the one from NS 2.X. Symptom of this problem is randomly disappearing fonts from Font Panel.''
KBNS.00.0.306_o3.0o Reported by Subrata_Sircar, from Glenn_Reid's 1993-01-14 comp.sys.next.bugs posting, verified by me (about Garamond).
From: glenn@rightbrain.com (Glenn Reid)
Subject: Re: My old Font-Problem with NS3.0
Date: 14 Jan 93 01:54:41 GMT

Borris Balzer writes
> NS2.1 installed, I used without problems fonts with the following names:
> - Garamond (the ITC Garamond)
> - AdobeGaramond
> - StempelGaramond
> - Garamond Three
> After installing NS3.0 the AdobeGaramond and StempelGaramond disappeared  
> from the font panel.

There is a known bug in NS 3.0 related to the Garamonds, and you have
hit it squarely on the head.  I have been in correspondence with NeXT
about it, and a fix should make it into the next release, whenever that
may be.

In the interim, your only choice is to edit the AFM files for fonts
that are disappearing to change the FamilyName property to add
some extra characters, so it won't sort into the same pile as the other
Garamonds.  This won't affect anything except the way the fonts are
displayed in the font panel.
Glenn_Reid (not verified, but not very informative either): ``No, this can't be fixed by running buildafmdir on a 2.0 system, unfortunately.  It's an inherent problem [afterwards he says bug] in the way the system sorts the fonts for display in the font panel.'' To make the new .afm files effective, e.g., move the changed fonts to a non-Fonts directory, (close and) open a font panel, move the fonts back again, (close and) open a font panel (there are other possibilities).

/usr/bin/calendar
KBNS.10.2.028_c3.0o Reported by Bradley_Head, replicated literally (except for formatting), verified by doing ``calendar -'' from a shell
``[¼]  Check this out.  calendar fails when trying to interface with /usr/ucb/Mail.
Prior  to 3.0, I had an entry in crontab.local like this:
30 1 * * * 		root 		/usr/bin/calendar -
Now I need an entry like this to do sort of what the dash option allows:
(I hate it)
30 1 * * * 		brad cd /Users/brad; /usr/bin/calendar | mail brad
30 1 * * * 		brad cd /Users/glen; /usr/bin/calendar | mail glen''

/usr/bin/dc
KBNS.10.3.021_o3.0o Bug, reported by Robert_Brown, Bug_NeXT.46400, verified by me.
``This one was reported in an SGI newsgroup and also affects Next's version of dc and bc.'' Robert_Brown's verification example:
% dc
10 k
4999499 9998 / p
400.0299059811    Should be about 500, of course¼
4999500 9998 / p
500.0500100020
% 

/usr/bin/open(file)
KBNS.00.0.309_o3.0±3.1o Bug, confirmed for 3.1 by Subrata_Sircar. If open doesn't get an argument or stdin input of nonzero length, it does cmd-shift-n in the Workspace Manager (i.e., it opens a New Viewer). Fix or explain (if this is intended behaviour, which I doubt).
KBNS.00.0.311_o3.0o Bug. See under Edit, something to do with /private, in a contribution from Moises_Oliveira.
KBNS.10.3.012_c3.1o Terrible mistake, reported by Carl_Edman on c.s.n.programmer on 1993-06-21 (NeXTPR-D 146) open -a theApplication (not specified whether this is only without a further argument) now requires Public Window Server status to function. This makes it totally useless for everyone on a network who is even the least bit concerned with security.
KBNS.11.1.023_o3.1±3.1o Probably a bug, reported by Bruce_Gingery for 3.1, verified by me for 3.0 When a program is launched like this: open (-NXHost theHost) /NextApps/Edit.app, the effect is different from double-clicking /NextApps/Edit.app in a File Viewer: each time another instance of the program is launched, rather than activating the present one. Probably a related phenomenon: open -NXHost localhost -a Edit does not work, if I recall correctly, and open -NXHost localhost someFileThatWillOpenInEdit will connect to another Edit instance than the one that opens documents launched from a File Viewer or opened locally with open (someone to verify that? I've just switched public access to my Window Server off again).
KBNS.00.0.307_o3.0o Urgent suggestion. [Rewritten.] /usr/bin/open(file) should understand a flag -w(ait) to force synchronous execution, making things like open(file) -w file; rm file possible. Or maybe this should be the default behaviour, and a flag -n(o)w(ait) should be defined. Anyway, clearly indicate default behaviour in the man file. Another flag that would be useful is one to specify that the document should be opened, but the application should not make this window key. That way files can be opened as they are produced without taking keyboard control away.
KBNS.00.0.308_o3.0o Suggestion. Have openfile launch Edit if Edit isn't running. Better yet, make this a hard link to open(1), doing exactly the same as open -a Edit. Its use would then be phased out, unless there is some non-NeXTSTEP reason to have this program. Besides, stdin to open is not documented yet (it can automatically open EPS (PS also?) into the right program if none is explicitly mentioned), why? I just discovered (version 7 of this collection): open -a anything doesn't read stdin anymore (well, this was never documented, but¼), so there's no way to open any output of a pipe in Edit if Edit is not yet running.
KBNS.00.0.310_o3.0o Suggestion. If stdin is opened, open an UNTITLED window, by communicating with the program directly.

/usr/bin/playscore
KBNS.10.2.006_o3.0o Mistakes in remedial notice.  For futher details, see the playscore MAN page. Spelling error, and manual page isn't there anymore.

/usr/bin/sort
KBNS.00.0.312_o3.0o Fails for long lines. I don't remember what the failure was and how long the lines could be, but some lines were just omitted from the output.
KBNS.00.0.313_o3.0±3.1o And¼ sort -u is not the same as sort | uniq .
Reported by Subrata_Sircar (also for 3.1), from Corey_Satten
From: corey@milton.u.washington.edu (Corey Satten)
Subject: bug/fix for sort !!!
Date: 27 Aug 92 20:25:30 GMT

As hard as it is to believe, after all these years of use, I found a bug
in /usr/bin/sort when used with the -u flag.  The bug only shows up for
relatively large inputs and causes a few of the last lines of output to
be omitted.  Below is a script you can feed both to /bin/sh to test your
sort and to "patch" to (hopefully - but as always, no guarantees) fix
your sort.c.  The context diff is for BSD 4.3 sort.c, however the exact
same code exists (at different line numbers) in Ultrix 4.1 sort.c so
you can still apply the patch verbatim.

--------
Corey Satten, corey@cac.washington.edu
Networks and Distributed Computing
University of Washington

#!/bin/sh
#
# Test for sort -u bug.  The bug causes a small number of lines to be
# omitted from the sort -u output for relatively large sort inputs.
#
# It is caused by the merge code not handling EOF properly in the next-to-last
# temp-file generated by sort.  In order to trigger the bug, enough input
# must be presented that sort merges a larger number of tempfiles into a
# smaller number and then merges the smaller number.  Alternatively,
# the uninitialized memory which is compared against the last value
# could accidently contain that value.
#
# This bug is known to be present in:
#	BSD 4.3 Tahoe
#	Sequent Dynix V3.1.4
#	NeXT version 2.1
#	Ultrix version 4.1, 4.2a
#	AT&T 7300/3b1 version 3.51
#
# It appears not to be present in SunOS 4.x, OSF/1 however this may only
# be because the size of the input required to trigger the bug has been
# raised (the size of the tempfiles and memory arrays has been raised).
#
# A context diff of what I hope is a fix to the 4.3BSD version is
# appended at the end of this script.  Use at your own risk.
#
# Corey Satten, corey@cac.washington.edu, July 31, 1992
[The rest of the message, including a sh fancy script and a proposal for a patch, not reproduced here, to save space.]

Reproduce this session and judge for yourself. The program was extracted verbatim (except for changing $COUNT to 45) from Corey_Satten's message.
flexus> cat > data.c
#include <stdio.h>
#define r(x) ("qwertyuiopasdfghjklzxcvbnm"[pos(x)%26])
#define pos(x) ((x)>0?(x):5-(x))

main() {
    int lines = 0;
    int i,j,k;
    for (i=0; i<45; ++i) {
        for (j=0; j<45; ++j) {
            for (k=0; k<45; ++k) {
                if ( (++lines & 63) == 0) printf("zzzzzzzzzzz - OK\n");
                printf("%c%c%c%c%c%c\n",
                    r(k), r(j+k), r(j-k), r(i+k), r(i-k), r(i+j+k));
                    }
                }
            }
        }
flexus> cc -Wall -O data.c -o data
[...]
flexus> data | sort | uniq | tail -2
zznznz
zzzzzzzzzzz - OK
flexus> data | sort -u | tail -2
zznziz
zznznz
flexus> data | wc
   92548   95394  662066
flexus> data | sort | uniq | wc
   56715   56717  397015
flexus> data | sort -u | wc
   56714   56714  396998
flexus>

/usr/etc/getty
See also KBNS.10.2.017

/usr/etc/talkd
KBNS.11.1.012_o3.0±3.1 Reported by Bruce_Gingery for 3.1, verified by me for 3.0 (to the extent that you can prove a negative¼)
talkd never considers /dev/console for talk connections. Not preferring console to page a user is fine, but not using it if it is the only available device or if it is requested explicitly, without warning either side, is certainly not acceptable (the current user can respond from any terminal, so there's no hard reason not to request communication on console). Workaround: always have a terminal floating around.

/usr/etc/syslogd
KBNS.10.2.024_o3.0o Bug, from a 1993-05-28 c.s.n.(bugs/programmer) posting by Bradley_Head, refined for this collection by Bradley_Head, not verified
syslogd is launched from /etc/rc before either NetInfo or NIS (that's how it should be). The problem is that it sort of locks to /etc/hosts for its host information (either to the file or to its contents at the time of syslogd's start), even through -HUP signals (which cause it to reread its configuration file). syslogd should probably really use gethostbyname(3) instead: this will use /etc/hosts only if no other source is available. This should be documented in the manual pages of both syslogd and hosts. Workaround: kill and restart syslogd in /etc/rc.local, and add any host information that needs to be available to syslogd before that moment to /etc/hosts. BTW, NOTE: This file is never consulted if NetInfo or Yellow Pages is running. should be changed to a reference to gethostbyname(3) which more accurately describes what really applies: it's very annoying to continually have to doubt the truth of statements like these (it's not enough that this statement is internally inconsistent if examined carefully).

/usr/lib/fastps
KBNS.00.0.314_o3.0o English. /usr/lib/fastps: Couldn't get host priviledge port. That should be ``privilege''.

/usr/lib/uucp/uucico
KBNS.10.2.042_o3.0o Bug. When this is invoked as /usr/lib/uucp/uucico -r1 -R -shostname, and if there is nothing in the queue of system hostname to the local system, uucico ends the session right there, and doesn't deliver outgoing files.

/usr/shlib/libNeXT_s.C.shlib
KBNS.10.3.008_o3.0o Guess what I discovered by accident in this shared library, section __TEXT/__cstring?
TouchType, PresentationBuilder, Improv. What are these doing here? (But then, what is this entry doing in this file?)

/usr/shlib/libsys_s.B.shlib
KBNS.10.3.002_o3.0o English.
``cummulative'' should be ``cumulative'' (2 times)
``can't dynamicly load fixed VM shared library'' (should be ``dynamically'')

/usr/ucb/gprof
KBNS.11.1.006_o3.0o XXX Still to be included.

/usr/ucb/man
KBNS.00.0.315_o3.0o Suggestion. Couldn't things be arranged so that man something in a shell would open the manual page in Edit or Preview and as fancy as the manual pages included in the System Administration manual (in Librarian too)?

/Upgrade_X.X.app
KBNS.00.0.259_3.0c About installing the languages wasting a lot of disk space, on comp.sys.next.(bugs/programmer), verified by Subrata_Sircar, who also reported it to be cured in 3.1.
``Date: Mon, 5 Apr 1993 07:44:36 GMT
From: gad@eclipse.its.rpi.edu (Garance A. Drosehn)
Subject: Re: NS3.0: Installed packages bug?
otto@epr.jyu.fi (Otto J. Makela) writes:
When I installed NS3.0 on our mono NeXTstation, I noticed that it did not keep correct track of which packages had been installed. I seem to remember this being talked about in the news, but now I can't remember the solution.  I'd like to uninstall some of the sillier language choices and some such from our system, as we're running a bit low on disk space (even with a 600M drive).
I mentioned it in one of the NeXT newsgroups at some point, but I don't know if it's on any of the official "bugs" lists.
The mixup is that the NS3.0 install sets up /NextLibrary/Receipts as if all the languages are installed, even for those languages you have not in fact installed.  What's worse is that each of those receipt files (well, it's really a ".pkg" directory) is over a megabyte.
The problem is that these receipt directories for uninstalled languages include the tar file which would be used to install that language.  The second problem is that the tar file is completely useless, because the .pkg directory does not include the information which would tell package how to install that language.
So, the thing to do is to double-click on each of the language packages in /NextLibrary/Receipts (except the english one, or whatever your primary one is, I would guess), which will start up the installer.  Then delete the package.  For any language you *do* want installed, go back to the CD-ROM and install it from wherever it is on the CD-ROM (I'm on vacation or I'd look it up for you...).
It would probably be good to cross check each of those packages before deleting it.  Any package which was installed correctly should have a ".pkg" file in /NextLibrary/Receipts which is under 200K.  In fact, the ones for languages will probably be under 100k.  Ones that are mixed up will be over 1meg.  I vaguly remember that there was one other (non-language) package which was goofed up this way, but I don't remember which one it was.''

Workspace Manager
Bugs and such (new?)
KBNS.00.0.316_o3.0o Suggestion and bugs
          read    write   execute
jdoe        V       V        -
students    V       V        -
world       V       -        -
inspector window should unify the matrix of permissions with the indications of owner and group in the Attributes Inspector and omit the Access Control Inspector (that's eliminating one subpanel and two TextFields), but now it splits the information over two inspectors, with weird behaviour of revert and ok, no control over executability of home folder, and recursive setting of executability also applying to files (shouldn't)? The unified display should also reflect the setuid, setgid and sticky bits! There should be the option of recursively adding an executability bit for folders only (chmod uses X here, instead of x). Now the panel is more a nuisance than anything else. Of course, ultimately something better than standard Unix permissions should be used.
KBNS.00.0.317_o3.0o Little harmless bug As far as I understand, wheel users don't get the others' home directory icon, just a plain folder icon (the home folder of the user himself is properly indicated!). Please give a reason for this or fix or provide preferences control.
KBNS.00.0.318_o3.0±3.1o Reported by Mark_McCallum, rephrased by me, confirmed for 3.1 by Subrata_Sircar In 2.X, the Console was editable, now it isn't anymore. Since the Edit menu has its commands Cut, Paste and Delete still enabled, you either forgot to adapt these (I wonder if this is an AppKit or a Workspace Manager bug?), or making the Console non-editable was a mistake. Mark holds that the situation should be reverted to an editable Console.
KBNS.00.0.319_o3.0±3.1o More console trouble, reported and verified by Subrata_Sircar (also for 3.1), from David_Griffiths, verified by me When doing echo <string> > /dev/console with an open Console Window, where <string> is some 1319 characters enclosed in quotes (the length is the issue, I don't know what the minimum length for failure is), this works the first time, but then the Console Window doesn't give any more messages until it has been closed and opened again.
KBNS.00.0.320_o3.0o WM reentrancy (why should this be a source of deadlocks in this multitasking environment?). [¼] The WM should provide dragging support in its own thread, so that WM is still available to service requests like launching filters and applications. Another example: if an application normally sets a Speaker port to some other application when it is starting up, and if it is launched by dropping a file on it with both applications not running yet, the WM should obey the request to launch the second application, because this needs to be done before the drop can be serviced. [¼]  In a 1993-01 Developer mailing from NeXT, some encouraging sound (italics mine): ``#30427 -- You can't use the method of Workspace protocol from within a WMInspector subclass. The Workspace contends for its own resources, the primary symptom of this is that the Workspace hangs for long periods of time, waiting for timeouts. You're reduced to using the old speaker/listener methods which unfortunately aren't as full-featured as the new protocol until we address this limitation in some later release.'' Hopefully this address will apply not just to inspectors¼
KBNS.00.0.321_o3.0o Small bug: a race condition in the miniaturisation of windows. I cmd-m'ed the File Viewer and a Terminal window very closely together in time, early in the session (there hadn't been any miniaturised windows before), and the Terminal window, which was clicked first, landed on top of the File Viewer's icon. Happened again a couple of times.
KBNS.00.0.322_o3.0±3.1o Find Panel blues, confirmed for 3.1 by Subrata_Sircar. This panel seems unable to find anything in a mailbox, it just says ``0 found''. Test procedure: copy any word from any message in a Mail mailbox, paste it in the Find Panel, have the Mailboxes folder selected as the target, and click Find. After a few seconds, the ``search'' ends, without result. What else is it incapable of? For instance, finding a file that contains a left bracket ``['', in any directory. And it appears cleared when summoned with cmd-f (when the user wants to investigate the results of a time-consuming query!). KBNS.10.2.035_o3.0o Or this: when instructed to Find items with contents that match ``core'', it will give ``08_BackUp/03_WaysToBackUp.rtf'' for target /NextLibrary/Documentation/NextAdmin, but only ``ManPages/cat1/csh.1'' and ``ManPages/whatis'' for target /NextLibrary/Documentation (remark that Manpages/cat* is changed as man pages are requested by users). Why no hit in ``ManPages/man1/csh.1''? Why aren't the hits for the latter a superset of those for the former? KBNS.11.1.rev And another thing: for target /NextLibrary/Documentation and request getpwent, only ManPages/whatis is returned, while the man page is present (I tried man getpwent in a shell afterwards). On the console appears something about attempt to remove unrecognised exception handler, and a notice about how many times this message has been repeated.
KBNS.00.0.323_o3.0o GUI hassle. When someone tries to move a file by putting it on the shelf and then dragging it to its destination, and the operation can't proceed because the user does not have write access to the item's directory, then the Generic dragging pointer should not be used even with the command key pressed, only the Copying pointer. Now the icon is lost and has to be retrieved.
KBNS.00.0.324_o3.0o Addresses. If a selection of users is dragged from the shelf to a group with the command key held down, the Generic dragging pointer is used, and the users are removed from their position¼ but they never arrive at their destination!
KBNS.00.0.325_o3.0±3.1o File size, confirmed for 3.1 by Subrata_Sircar. The File Viewer doesn't reexamine a file's size when this file is selected after another file in the same folder: the user has to click the file's folder and then the file itself again. Don't assume a file stays the same size!
KBNS.00.0.326_o3.0c Tiny bug about command-double-clicking an icon, reported by Robert_Brown, verified by me, Bug_NeXT.39862, reported to be cured in 3.1 by Subrata_Sircar
If the Workspace Manager is not hidden, command-double-clicking its icon in the dock hides all applications, rather than just the others.
KBNS.00.0.329_o2.1±3.0o Irritating bug. The shelf (and dock) configuration should be saved periodically, or better yet, triggered by changes, or, if it's safe to do so, at least also at Window Server crash time, which is a disturbingly frequent occurrence. It's no more trouble to implement than something like
[self perform:@selector(saveShelfAndDock:) with:self afterDelay:5000 cancelPrevious:NO]; 
[¼] In any case, if the user logs out with no space available, the shelf and dock settings should not be saved by just overwriting the old file, because this now ruins the whole configuration, resetting it to nothing at all.
And another thing: if HostManager reboots the machine, it tells to first save work in all applications, but there is no way to save the shelf!
KBNS.11.1.028_o3.1o Harmless funny bug. When I insert a CD-ROM into the drive such that it is automounted, a message like this appears on the console (font variation mine): ``Oct  2 09:55:42 Workspace: Mounted floppy disk at /NEXTSTEP_3.1''.

Suggestions
KBNS.00.0.330_o3.0o Applications' icons should be in the dock's window tier, so that they can't be obscured. When an application's icon is double-clicked, its miniaturised windows should be put in front of its other windows.
KBNS.00.0.331_o3.0o Small detail. When analysing applications in known folders, these folders are now descended recursively. Nnly the real path names should be used in this case so as not to use an application more than once if, e.g., /NextApps is reachable as a symbolic link /LocalApps/AAA_NextApps. This also applies to launching applications from the Workspace Manager: the same application can be launched more than once, if there are several paths leading to it. E.g., I can have /NextApps/Edit.app launched at login time in the dock, and launch another copy by double-clicking ~/Apps/AAA_LocalApps/AAA_NextApps/Edit.app. There, now you know it, and there's no excuse to leave that like it is anymore.
KBNS.00.0.332_o3.0o Or not that small a detail, and more like a bug? Related problem: somehow WM has managed to register the normal Preview path for .eps files, and the path with links for .ps files. So, whatever I do, these files go always to these ``different'' applications which really are one and the same, launching two instances of the same application. I haven't touched these links for ages¼ or maybe this situation gets inherited from session to session? I don't know if I will be able to reproduce it; I won't try anyway.
flexus> ps -auxww | grep Preview
rfschtkt  7917   0.6  2.5 1.52M  208K p2 S     0:00 grep Preview
rfschtkt  7913   0.5 10.4 4.09M  848K ?  S     0:01 /NextApps/Preview.app/Preview -NXOpen /Users/rfschtkt/_/_/Level2Stars.eps -MachLaunch 38 752
rfschtkt  7912   0.0  7.2 4.27M  592K ?  SW    0:01 /Users/rfschtkt/Apps/AAA_LocalApps/AAA_NextApps/Preview.app/Preview -NXOpen /Users/rfschtkt/_/_/knownbugs.ps -MachLaunch 37 751
flexus>
KBNS.00.0.333_o3.0o Suggestion. Provide WM support to view folders in ~/¼, /Local¼ and /Next¼ (and their subdirectories) at once in a merged tree, grouping vertically by origin. Having to insert countless symbolic links and reserve shelf space to place the folders at the ends of the chains is tedious. Same for open and save panels.
KBNS.00.0.334_o3.0o This becomes the time to extend functionality a bit. When copying, moving or linking to a folder where that name exists already, two rename options should be added to Stop and Replace (``You can stop the operation, replace the existing file, rename the existing file or choose a different target name.''). Now the operation has to be stopped, the original file or the name in the destination folder renamed, the operation redone, and in case of a copy or link, the renaming reversed). Same functionality for copying to a file system that doesn't support long file names (DOS disk, e.g.), see this problem described under Bugs and such (new?).
KBNS.00.0.335_o3.0o Wrong word¼ Don't say ``Proceed'' if a file operation fails if there are no other files involved. Omit that button in such a case, and name it ``Skip'' or something when there are other files still to be processed: ``Proceed'' sounds more like ``Retry'' after an explanation like ``file system error: file exists''. Why not give the old DOS triple with a slight variation: Retry/Skip/Abort? For that last option, provide a panel to inform whether the part of the operation that had been done was rolled back, and how exactly.
KBNS.00.0.336_o3.0o Working with the slow CD-ROM. [Reformulated.] When browsing through the file tree makes it necessary for symbolic links to CD-ROM to be displayed, the File Viewer slows down terribly, and browsing becomes a pain, certainly if something on the shelf is clicked that is located deep in the file tree, with such links at various levels. This is because the File Viewer wants to obtain knowledge about whether the links point to files or folders, and also the icons in View>Icon. This should be rewritten to service the user's request first, and use a different thread to draw the rest afterwards. (Maybe as a favour for those poor people like me with less than a GB of hard disk space, who have to leave the documentation on CD-ROM¼) Also, for links that dangle, an icon with a question mark should be used even if the extension is registered to carry a special icon.
KBNS.00.0.337_o3.0o Like to have. The user should be able to edit a symbolic link as a path name in the Inspector TextField, certainly if it is dangling. And linking in the File Viewer should default to linking the shortest relative path rather than an absolute path.
KBNS.00.0.338_o3.0o Enhance (for 4.0, probably). Make logging out and logging back in a non-event. Running applications, open windows, everything should be the same, only real-time problems should require user advice (being logged in to a remote computer, etc.), but edited text (even not saved) and pasteboard contents should be preserved. With the necessary hardware (an active badge or something) it should be possible to walk away from a '486 to a NeXT AlphaStation on the same network (yes, different CPU) and be required only to unlock the screen (to prevent accidents caused by just sitting near to a computer) to be able to continue working. Issues involved: applications should survive Window Server disconnects (this would make them capable of surviving Window Server crashes, probably) and reconnects elsewhere with different characteristics (from monochrome to 24-bit colour, e.g.), they should never require a relaunch to incorporate any new information, mach port name server should continue to work in this environment, maybe applications should be able to migrate to a different host to save on network traffic and take advantage of additional computing power, or save state to disk to survive reboots (including power down)¼ Anyway, NeXTSTEP is lagging in this area!

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.