[comp.sys.mac] Bug in DI package, stray bits in disk icon

maarten@janus.UUCP (Maarten Carels) (08/17/89)

Since I installed system 6.0 on my disk, the icon of the disk in the
'Erase disk' dialog had a little dot beneath it. This little dot showed
up only there, not on the desktop in the finder, not in DiskFit or any
other application. It looked like a pecularity of the Disk
Initialisation package.

So I took a disassembler, and disassembled the Disk Initialisation
Package, and found a little bug in it. The bug occurs in the Disk
Initialisation package (used to initialise disks) in the current system
(6.0.3, but probably also in other version 6 systems). It is not present
in older systems.

Within a 32 * 32 pixel rectangle, the code moves the icon up as much as
possible by skipping blank pixel rows in the icon. In doing so, it uses
the wrong register for counting the pixel rows to skip, and then (as a
result of the bug) copies 32 rows. This includes as many rows of the
mask of the icon as are skipped. If these rows are blank (white), this
has no visible effect, but if they are not (as with the icon of my disk)
some pixels of the mask show up below the icon.

What happens exactly is:
First, a pointer to the disk's icon is obtained from the driver and a
relocatable block is allocated to receive a copy of the icon:

   328: 317C 0015 001A          MOVE    #21,CSCode(A0)
   32E: A004                    _Control
   330: 6642                    BNE.S   ....
   332: 203C 0000 0080          MOVE.L  #128,D0
   338: A322                    _NewHandle ,CLEAR
   33A: 6638                    BNE.S   ....
                                ....Irrelevant code deleted...

Now, a pointer to the disk's icon is in A1, and a pointer to the
relocatable block in A0. The number of rows in the icon (minus 1) is
subsequently stored in D0.

   35E: 701F                    MOVEQ   #31,D0

Now the skipping of blank rows starts, using D1 to keep track of the
number of rows left in the icon. It should of course use D0 (D1 is
initialised)

   360: 4A99           @1       TST.L   (A1)+
   362: 56C9 FFFC               DBNE    D1,@1
                                         ^ Should be D0!!

Since most icons do contain at least one row of non-white pixels, this
loop terminates at the first non-white row. Now, the nonwhite rows of
the icon are copied. As D0 is still 31, 32 rows are copied, starting
from the first nonzero row in the icon. Thus part of the mask may be
copied, which shows up in the dialog below the disks icon.

   368: 5989                    SUBQ.L  #4,A1
   36A: 20D9           @2       MOVE.L  (A1)+,(A0)+
   36C: 51C8 FFFC               DBRA    D0,@2

Code continues with displaying icon by fiddling the dialog.


Why has this bug slipped by through Apple's checks ?? Have their disks
icons with masks not vulnerable to this (my disk runs non-Apple
software)? It seems so.

The solution is simple. Change the 'DBNE D1,@1' into a 'DBNE D0,@1'.
Proceed as follows (Use ResEdit to apply the patch):

* Open the system file.
* Open PACK 2.
* Search for '56C9 FFFC' (at offset 362).
* Change to '56C8 FFFC'.
* Save and quit ResEdit.

CAUTION:
Always patch a copy of your system, don't patch a running system.
Proceed at your own risk (this patch works for me...)

--maarten

In real life:	Maarten Carels
		Computer Science Department
		University of Amsterdam
email:		maarten@fwi.uva.nl
-- 
In real life:	Maarten Carels
		Computer Science Department
		University of Amsterdam
email:		maarten@fwi.uva.nl