tneff@bfmny0.BFM.COM (Tom Neff) (02/22/91)
One thing that drives PROGMAN batty is short icon files. Make sure all yours are the same size. I think ICONDRAW has some bugs. Occasionally it will write a short file. Occasionally it'll stop recording changes to the small-size icon indicator or to the file. You'll work on something, save it, come back later and the last 10 minutes of your changes are missing. Very frustrating. Also the fill-box operator often doesn't update on the small icon. Another way to make icons is with Paintbrush's ZoomIn feature, followed by a capture with PBIcon, another shareware utility. PBIcon lets you grab about 100x100 raster from anywhere on the screen, then scroll around in it to pick the exact 32x32 you want. With Paintbrush's ZoomIn you get fine pixel control (and reliable saving) -- when you're done, capture with PBIcon and save to whatever you wanted.
nelson@bolyard.wpd.sgi.com (Nelson Bolyard) (02/22/91)
The WIN3 Program Manager (PM) gets an Unrecoverable Application Error (UAE)
when I try to change the icon (.ICO) file to a particular icon file for an
application. When PM dies with UAE, I can continue to run the other windows
(that were already open) normally, but cannot start any new programs
(because PM is gone). When I close all the windows, WIN3 goes away, and
then I can restart it.
This icon file is for use with a DOS application that I frequently run
under windows 3.0. I got it from the Customer Support BBS belonging to the
company that developed the DOS application. I use the properties box (I
think that's the name, I'm typing this at work from memory, WIN3 is at
home) and the change icon button, and type in the name of the icon file in
place of PROGMGR.EXE, then click OK, and PM gets a UAE right then.
There's something about this particular icon file that makes PM blow up
(UAE). I have this problem with NO other icon file beside this one. The
problem is not related to the particular application whose icon I'm trying
to change; I have tried using this .ICO file for Windows applications, for
applications run via .PIF files, for DOS .BAT files, and for ordinary .COM
and .EXE DOS applications. The problem is the .ICO file.
Now, as far as I can tell, there is NO executable Intel code (80x8x)
anywhere inside the .ICO file. The .ICO file contains only DATA, not
instructions. So the code that is doing the bad thing (that causes the UAE)
is in PM itself, not in the ICO file. Even if the ICO file contains
absolute cruft, PM should detect bad data, and complain via some dialogue
box, NOT take a UAE. This problem occurs even when there is NO other window
open on the screen (besides PM), so I am confident this is not caused by
some OTHER program (i.e. other than PM itself) running concurrently that is
writing into reserved memory (e.g. A000:0000-FFFF:000F).
The .ICO file is the same length as all my other .ICO files, and seems to
have a header that looks very similar (byte for byte) to the other .ICO
files. Perhaps if I had a WDK, I would have access to some document that
explained the format of a .ICO file, and I could find out what's wrong by
inspection, but I don't want to drop several hundred dollars just to get
this darned icon file to work.
I called Microsoft customer support twice about this. The first time, I
got some guy who insisted that an .ICO file is a program, and that my
particular .ICO file must contain some instructions that write into the
reserved area above A000:0000. His postition was that Microsoft could not
be responsible for bugs in software from other companies. I tried to talk
to another support person, and he wouldn't let me. He was VERY sure of his
answer. I tried to talk to his supervisor, but to no avail (super was
supposedly in a meeting). Finally, I just said good-bye, and called back
and spoke with somebody else (after another 11 minute wait on hold).
This second person was MUCH more reasonable. He agreed that the icon file
was not a program, and that if PM took a UAE when no other programs were
running, (no other windows open) then the offending code was probably
Mircosoft code. He said that he had made several icon files of his own,
and agreed that PM ought to be robust in the face of a bad .ICO file.
His only suggestion as to how I might get something done about it was to
put the offending .ICO file onto a diskette and snail-mail it to him.
When I really pressed him for an alternative that involved electronic
communications (you know, modems, networks, email) he suggested I could fax
him a copy of the file printed out using DEBUG. (really!)
So now I'm hoping someone on the net can help. I just want to get this
darned icon file to work with the application it was intended for. Any
clues about the format of an .ICO file would help. I'll gladly uuencode
the .ICO file and e-mail it to anyone who asks. (Hint hint)
Oh, configuration information: 386-DX, 8 Megs RAM, run in 386-enh mode.
Problem occurs same way whether under HIMEM.SYS or QEMM.SYS (5.11). No
SMARTDRIVE (because I have a compatibility problem with DISKMGR). Display:
SVGA in 1024x768x256 mode. I have a 1 Megabyte RAMDRIVE, using the
ramdrive program (I forget the name) that came with WIN3.
Thanks in advance to all who reply!
-----------------------------------------------------------------------------
Nelson Bolyard nelson@sgi.COM {decwrl,sun}!sgi!whizzer!nelson
Disclaimer: Views expressed herein do not represent the views of my employer.
-----------------------------------------------------------------------------magid@sandstorm.Berkeley.EDU (Paul Magid) (02/23/91)
I had the exact same problem as you. I had an ICO file that would cause Program Manager to give me a UAE and terminate. AS you I had to close all my windows in order to exit. After many long frustrating hours I managed to trace the problem to an icon file named wp5.ico. (Extremely frustrating since I should have been studying for a midterm) On a whim I did the following: 1: made the file inaccessible to progman. 2: ran the offending file through IconDraw 1.2 and made one change to the icon. 3: I then saved the icon file and made it accesible to progman. This solved my problem I hope it solves yours too. I have a sneaky feeling that progman is extremeley finicky when it comes to ICO files, whereas IconDraw may be able to read them. If one makes a change to the icon and then saves it it seems to be saved in a way that progman does understand. Paul
nelson@sgi.com (Nelson Bolyard) (02/27/91)
Several of those who responded to my complaint about the bad .ICO file offered to try to repair the file. Some offered to use the SDK paint program to fix it, but it caused the paint program to crash also! One respondent, who had written his own paint program, was able to fix the file. Here is his reply: >Date: Sat, 23 Feb 91 17:04:39 EST >From: nee@cf_su10.sbi.com (Robert Nee) >Subject: Re: Bad .ICO file >I took a look at the file you sent me. Sure enough, it causes the PM >to crash. It also made SDK paint crash (the icon painter in the SDK). >Oddly though, it didn't make my program crash so I took a look at the >file in more detail. Icon files have what's known as an icon resource >directory at the beginning that describes the number and types of icons >in the file. There is also a length specifier. It turns out that this >was causing the problem. It claimed that the icon portion of the file >was only 728 bytes long rather than the correct value of 744. PM and >SDK Paint must use this value to allocate memory rather that calculating >the proper value themselves. When they go to read in the pieces of >the icon file they write past the end of this memory, and BOOM! >When I repaired the IR header, the file worked fine. Here it is and I hope >you find it helpful. I know I found this interesting and informative. >The file formats are in the SDK docs. The reference manual has a section >with a number of file formats listed. You can buy this book in the >stores too. >Robert F. Nee <nee@cf_su20.Sbi.Com> Thanks, Robert! ----------------------------------------------------------------------------- Nelson Bolyard nelson@sgi.COM {decwrl,sun}!sgi!whizzer!nelson Disclaimer: Views expressed herein do not represent the views of my employer. -----------------------------------------------------------------------------