I didn't update this thread for a while due to lack of time, and maybe I forgot one thing and another. So here is another tiny change that will make live hopefully easier: The icon.library.
This is a version derived from the 3.9 version, but with two small changes. For 3.9, the icon.library allowed to configure the "maximum file name size" so it knew where to cut off names in case a ".info" for the icon has to be attached. This feature is gone.
Why?
Well, actually, it is no longer required, and it was a bad idea. It is a bad idea because the user can hardly know how long the file names are allowed to grow, and even worse, this maximum size depends on the file system the icon.library is working with, so it cannot be "correct" for all combinations. If you had an (old) CrossDOS version in the system, then the file name limit would be "8" (the .info is mapped to .INF by the 3.1 version of CrossDos). You surely don't want to set this limit to 8 just to be able to use CrossDos.
So, new rules apply. The icon.library does not limit the file name size at all. Instead, it now always checks whether it could create icons correctly under the name you gave them, and it checks before writing a .info file whether this file name possibly conflicts with somthing that is already on disk - conflicts because the file name of the icon and the file name of something else become identical after truncating to the maximal length. And this truncation is the job of the file system.
So what is the "maximum file name size" in the workbench dialog good for? It is really only cosmetic. The only thing this does is that it limits the maximum size the input dialogs of the workbench take, nothing more. If a program attempts to create a longer file name, that's all good, all provided the icon.library can create such a file and the file is different from the base (i.e. non-icon) file.
When renaming files, the workbench has a heuristic how to truncate file names for the "Copy_Of_" renaming of files. It also tests whether it can create a unique name by prepending "Copy_Of_", and since it cannot test all possible lengths of file names, it checks for some typical maximal file names. 30 characters for DOS\1 through DOS\5, 54 characters for DOS\8 and 106 characters for DOS\6 and DOS\7.
So no need to fiddle with the maximal file name size at all - it's all automatic.
Another change is this "put icons to fast" setting of Os 3.9. That's also gone for good. Again, because the user cannot know whether the graphics system of the screen the workbench is running on supports this option, as it may depend on the screen mode as well. It is an unwise idea to delegate a decision to a user for something the user, in general, cannot know, so the switch went away. Instead, the workbench runs a small test when opening (or re-opening) its screen whether icons can be put into fast memory - and if so - it simply does it. No need to configure anything, it's automatic.
Finally, how do you move icons to fast memory? Well, for graphics cards, this is what happens already automatically. For native systems, I *do not* recommend FBlit as this program is known to cause multiple problems as its patch set is incomplete and has defects. There are two options: Either, you run the native (AGA) driver of Cybergraphics, or you run the native driver of P96.
There is a P96 driver for the ECS/AGA chipset? Yes, there is. Check Aminet. A relatively recent P96 version is sufficient. With P96 and this "driver" installed, icons will go to fast memory.
Frankly, it's not much of a driver, but it does exactly what you want it to do.
