icon.library 46.4 test versions

[hexaae]

@PeterK
The exec v45 + PoolMem trick seems to work: the system is now much more stable even using exec v45
Probably this new rewrite of exec had some (new) bug inside the new AllocMem()/Freemem() (all random GURUs pointed to these two routines). I think I'll use original library in the end just to be safer, if new rewrite in "DEVS:AmigaOS ROM Update" proved to be unreliable.

[PeterK]

CoolMan, this will make ThoR happy. Perhaps it's just the fact that PoolMem sorts memory blocks differently, which may keep trashing away from critical system memory allocations and could avoid crashes.

[hexaae]

Originally Posted by PeterK

CoolMan, this will make ThoR happy. Perhaps it's just the fact that PoolMem sorts memory blocks differently, which may keep trashing away from critical system memory allocations and could avoid crashes.

I think exec v45 is simply buggy (or missing some safety checks, or breaks compatibility with nasty programs…), since there is no need of PoolMem with original exec v40, to grant system stability

BTW, I've just found a bug in your icon.library v46 when closing and reopening WB screen with a NewIcon appicon on WB screen that will appear trashed.
System OS3.9, P96 Z3 RTG, WB prefs set with Use chipmem for icons:
- download FileX (but this happens also with other programs), and CloseWB from Aminet
- add a NewIcon to FileX
- run FileX and iconify it
- close and reopen WB screen with CloseWB (or use any alternative way…)
FileX NI (still iconified) will look trashed.
This doesn't happen using icon.library v45.

EDIT:
even with PoolMem sometimes rarely alert/crashes still happen using exec V45:

-- Guru V37.1 -- Thore Böckelmann <tboeckel@uni-paderborn.de>

Alert Code: 0100000F
Type: recoverable
Subsystem: exec.library
General: general fault
Specified: memory header not located

[daxb]

Have a look at PoolMems guide -> Compatibility section. And if you have enough memory then there is no need for defragmentation. Especially on WinUAE? In worst case do a reset.

[PeterK]

Originally Posted by hexaae

- run FileX and iconify it
- close and reopen WB screen with CloseWB (or use any alternative way…)
FileX NI (still iconified) will look trashed.
This doesn't happen using icon.library v45.

Usually, you can't close the Workbench at all. So, which of these CloseWB hacks should I try?
http://aminet.net/search?query=closewb

[hexaae]

Originally Posted by PeterK

Usually, you can't close the Workbench at all. So, which of these CloseWB hacks should I try?
http://aminet.net/search?query=closewb

UFO AGA and other games or apps (PPaint etc.) can close Workbench screen to save chipmem. http://aminet.net/package/util/cdity/CloseWB_v19 is decent

[PeterK]

Ok, I tried with PPaint and can confirm. But all other AppIcons are recovered without any damage, like SnoopDOS, KingCon, AWeb, EdWord, Scout. The problem does not depend on the memory type or icon type, but maybe on the user type ...

[hexaae]

If you have ENV:Sys/def_programname.info this is a valid workaround against trashed icon after WB close-reopen with icon.lib 46. Is it possible to add fix/workaround? V45 sucks for everything else compared to your lib

[hexaae]

Found also another little (gfx) glitch using your v46 when dragging very long file name icons:

Again this won't happen with v45 for 107chars long file names.

[PeterK]

Could nail down the AppIcon problem to 425b-425c already. Looks like something with disabling palette mapping.

Your other bug looks similar to the graphic glitches (strange characters) or even crashes which I had only with the 040 (not 020) when I tried to scroll my full copy test window some days ago.

Sorry, I'm too tired atm and are going offline for a snooze soon.

[PeterK]

Originally Posted by hexaae

Found also another little (gfx) glitch using your v46 when dragging very long file name icons:
Again this won't happen with v45 for 107chars long file names.

No, can't reproduce that bug. I can drag around as often as want. All ok.
Plz, check your patches or give more detailed instructions.

Btw, the FileX bug is fixed now. I've removed some odd code, but I'm not sure if this has side effects.

[hexaae]

Originally Posted by PeterK

No, can't reproduce that bug. I can drag around as often as want. All ok.
Plz, check your patches or give more detailed instructions.

Btw, the FileX bug is fixed now. I've removed some odd code, but I'm not sure if this has side effects.

The file name must be exactly 107 chars (max allowed, I've set "C:WBCtrl MNL 102 MCM=131072"). If you drag'n'drop files with shorter names there'll be no glitch. If I use icon.library 45.5 I can't reproduce it.
Is there a beta available so I can test the appicon fix for some days? Since you mentioned palette handling code I wanted to test it also with icon editors etc...

[PeterK]

Yes, I've tested with 102 chars (+ .info for the deficon), but as usual with digits and not with "brian-the-lion ...".
Upload your jpeg file, I don't want to type that long string.

No, my fix has nothing to do with palettes for IconEdit. IconEdit is very buggy and does not support TrueColor screens, has incomplete palettes and other bugs.

[hexaae]

I use a filename like this: "239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover789812345678991234567891123.jpg" a char less (102 or less) and I can't reproduce the glitch. 103+ I see the glitch.

[PeterK]

That's more than 102 chars with .jpg, isn't it? 102 is the maximum for the name if you want a deficon with .info appended.

I've copied that string into my editor and it seems to have 103 chars, one too much!

[hexaae]

Please, use exactly that file name: numbers at the beginning and at the end of file name of more than 103chars.
Just tested and replacing first 4 numbers with "copy..." I can't reproduce the glitch, so it seems again numbers are relevant to reproduce a glitch with file names… mmh..

[PeterK]

I could reproduce the glitches with your filename, but .txt at the end. Nevertheless, it's already 1 character too long, which means we get 103 + 5 + Null = 109 bytes for a 108 byte buffer. I will try to truncate a name like that, because it's not allowed. The limit of 108 bytes is hardcoded into the FlieInfoBlock structure of DOS. 1 byte too much and we start overwriting other structure items.

[hexaae]

Mmmh, original v45 allows you to create filename (without .info icon) of 107 chars. If you try to make an icon for it (+5 chars) this icon creation will silently fail, but there is no limitation up to 107 chars for files without icons.

[PeterK]

Yes, that's correct and the same happens with my library if you have a name with 107 chars, you won't get an icon. I have to check why 103 chars are still getting an icon. It should not happen.

Even 106 chars are still displayed with an icon. 107 not. That's indeed a bug.

The glitches, left character parts after dragging the icons around was caused by my restriction for the icon rectangle to allow only space for a label with 102 chars. Only the background under the rectangle can be restored when you drag the icon away.

[PeterK]

Update to icon.library 46.4.487:

Increased the number of Open() calls which do a check whether FBlit is running to 4 now. -- Added the sometimes missing palette mapped data, which caused the FileX appicon to lose its images when the WB was closed and reopened. -- Fixed the handling of long filenames with more than 102 characters, that should never get an icon, because appending ".info" would cause buffer overflows. This update has not been tested very much yet.