A very kind soul has mailed me this reply for the bugs in CView. Since he isn't in the position to post this himself, he asked me to post it for him, but to leave his name out. So here it comes:  CView has quite a number of bugs.  The one you mention is perhaps the most annoying, but not the most dangerous.  As far as I can determine, it has to do with the temp files that CView creates.  CView gives the user no control over where it places its temp files: it just places them in its "current directory".  The problem you mention occurs (as far as I can tell) when it runs out of disk space for its temp files. It seems as if CView doesn't check properly for this situation.  As Cview decodes a jpeg, it seems  to write out a temp file with all the pixel data with 24 bit colour information. Then, for 8 bit displays, it does the "dithering", again writing another file with the 8 bit colour information.  While it is writing this second file, it also writes the data to your colour card. Then when it does the last chunk of 8 bit data, it recopies all the data from the 8 bit file to your screen again.  (It does this last "recopy" operation for its "fit to screen" feature, even when this feature is not enabled.)   The result of this process is the following:         1) If it runs out of disk space when writing the first 24 bit file, all         you ever see is as much data as it has room for, and the last bit of         data is simply repeated over and over again because CView never         realizes the disk has filled up and disk writes/reads aren't performed.       2) If it has enough room for the 24 bit data, but runs out of room for         the 8 bit data, you see almost all of the picture as it does the         dithering and writes to the screen card.         However, then when it finishes the dithering and recopies the data         from the 8 bit file to screen (for whatever reason it does this)         one again just gets a repetition of the last chunk of data for which         there was room on the disk.  This is just a guess, but probably fairly accurate.  At least the general idea is on track I think, although I have probably made errors in details about file I/O etc.  The way around this is  of course to clear up sufficient disk space.  The temp files for large JPEG's (1200x900 and bigger) can be very large (3 Meg + 1 Meg ).  On some of the largest I have needed in excess of 6 Meg free disk space.   CView has a much more serious bug: if you are trying to display a file from a floppy, and you change floppies while CView has some temp file open on the floppy, then CView in certain circumstances will write the directory (and FAT table? I can't remember) for the removed floppy onto the newly inserted floppy, thus corruptimg the new floppy in a very serious, possibly unrevcoverable way.  SO BE CAREFUL!  It is incredibly poor programming for a program to do this.  On the other hand, when choosing files in the Open Files menu, CView insists on doing a few disk reads every time one moves the hi-lighter square.  Incredibly annoying when it could do them all at once when it gets the directory info.  And really, how much effort does it take to sort a directory listing?