icon.library 46.4 test versions - Page 116

PeterK · 13 April 2018, 13:12

Update to icon.library 46.4.483:

Added support for the OS 3.1.4 function BumpRevisionLength() to make copies of icons with long file names under the new WB possible, like it could already be done internally since WB v45.130 with the help of WBCTRL MNL=102.

Fixed some bugs under DOpus5. The icon.library detects the task name of DOpus5 correctly now, even if it's started by its icon with a different name than "dopu"..., like DirOpus or DirectoryOpus. -- Furthermore, the first icon in a lister won't get invisible anymore when a disk (floppy, CD) without an icon is inserted.

Michael · 13 April 2018, 18:40

Nice.... And no Friday 13 surprises so far.

PeterK · 20 April 2018, 22:18

Update to icon.library 46.4.484:

Icon.library now replaces the second image of any preview icon that is generated by Image2Icon with a darker copy of the first image and a glowing effect. I didn't like the second images as they were created by Image2Icon-Capsule, a GUI for Image2Icon.

PeterK · 30 May 2018, 14:36

Update to icon.library 46.4.485:

It's now possible to install an alternative CPU version of icon.library into a subdirectory of LIBS:. If your LIBS:icon.library is compiled for the 68000 then you can add the alternative version in LIBS:68020/icon.library. If your LIBS:icon.library is compiled for 68020+ then you can add the alternative to LIBS:68000/icon.library. The correct version will be loaded automatically by icon.library. On OS 3.0/3.1 this feature only works with RemLib from Thomas Rapp, not with LoadModule, LoadResident and probably not with BlizKick, too. If you don't need this feature then just install Libs:icon.library as usual.

kolla · 30 May 2018, 22:00

First step towards a "fat" binary?

PeterK · 30 May 2018, 23:08

Don't worry, just a super lite new feature (needs 28 - 44 bytes). Nothing compared to HAM or vector icon support.

PeterK · 31 May 2018, 09:05

Update to icon.library 46.4.486:

Nearly the same as 485 again, but a little safer. If a resident module "icon.library" exists, no efforts to load an alternative version are made, because that would cause a recursive loop. The alternative version is only supported by using RemLib or SetPatch v44.

Updated the two IconDemo ADF images with icon.library 46.4.486, too. The A500 disk supports the loading of the alternative CPU version now. Unfortunately, there was not a single byte left on the A1200 floppy for another library.

kolla · 01 June 2018, 13:58

Oh, I was thinking of a library that as binary on disk is combined 68000 and 68020

PeterK · 01 June 2018, 17:58

No, I don't want to create a "fat" binary for the icon.library. That would combine the worst of both worlds. The poor performance of the 68000 code would even get lower due to the additional overhead and the memory consumption will be much higher than required. And also the 68020+ systems would suffer from many 68000 related compromises, which can't be optimized efficiently, since the overhead for CPU depended code on single instructions is bigger than the possible gain. You can only optimize some hotspots like time critical routines.

With my method both CPU versions are always optimal in size and performance and it's the users decision to install an alternative binary or not. Unfortunately, the ramlib process is a party-pooper, since it never loads an alternative library as long as it finds it as a resident module.

indigolemon · 04 June 2018, 22:10

Quote:

Originally Posted by PeterK

Update to icon.library 46.4.486:

Nearly the same as 485 again, but a little safer. If a resident module "icon.library" exists, no efforts to load an alternative version are made, because that would cause a recursive loop. The alternative version is only supported by using RemLib or SetPatch v44.

Installed and no issues at all so far

hexaae · 11 July 2018, 03:25

@PeterK
I think I've found an incompatibility with MCP (1.30 or 1.33b1 from Aminet) and its ToolAlias patch. MCP seems to relay on a mysterious "IconPrivate3" patch to make ToolAlias option work:

Mmmh, just tried previous icon.library versions starting from OS3.9 45.1 and they also broke MCP compatibility. Do you think you can investigate and maybe make your excellent v46 compatible again? Would be a must since that MCP's feature is so useful.

Tested on a WB3.1 HDF and ToolAlias did work fine with icon.library 40.1.

PeterK · 11 July 2018, 08:50

MCP 1.30 and 1.33 are obviously for OS 2.04 up to OS 3.1. The original authors could not know anything about OS 3.5/3.9 a the time when the original MPC was written. The old ToolAlias feature patches the old GetIcon() function of OS 3.0/3.1, which was responsible for loading icons. OS 3.5/3.9 don't use GetIcon() anymore, because there is the new GetIconTagList() function as a replacement now. So, patching a function that is never called on OS 3.5/3.9 should have no effect. In icon.library v44/45 the GetIcon() function was simply removed and disabled. My own icon.library supports it again for OS 3.0/3.1. Thus, the ToolAlias patch may work, but only on OS 3.0/3.1. Just try your WB 3.1 HDF with my library.

For OS 3.9 you would need to update to the newer versions of MCP, written by Dieter Groppé. AmiKit uses v1.49c already.

hexaae · 11 July 2018, 09:05

I see. Thanks for details.
The problem unfortunately is that MCP versions after 1.33b1 by Groppé are very buggy with features not working etc. and cause also many Enforcer hits. Not sure if he's still supporting it too... This didn't happen with old MCP and that's why I use that (I don't need the extra features of 1.4x either).
Is it impossible to implement a GetIcon() emu/workaround for OS3.9 in icon.library v46?

PeterK · 11 July 2018, 09:34

MCP 1.48: http://mcp.a1k.org/indexe.html
MCP 1.49c is exclusively available for AmiKit.

My icon.library is already redirecting GetIcon() calls to GetIconTagList(). The problem is that nobody makes access to GetIcon() or a patched GetIcon() function on OS 3.9.

Maybe, it's possible to patch MCP 1.30/1.33 to call SetFunction() with another library offset than GetIcon() to be patched, but GetIconTagList() has the additional argument "tags" which should be supplied in A1. This means that the ToolAlias patch has to preserve the contents of the scratch register A1, what it probably will not do. This would need another workaround in the ToolAlias patch. Let me see what's possible ...

Please make a short test with my library on your OS 3.1 HDF to see if it could work at all.

hexaae · 11 July 2018, 09:41

would be great if you can do something and is not too hard to implement…
Testing it on my WB3.1 in the meanwhile…

EDIT: confirmed working nicely on WB3.1, with MCP 1.33b1 from Aminet + your LIBS:icon.library v46 made resident with Loadmodule command (by Thomas Richter)

PeterK · 11 July 2018, 14:02

Sigh, it looks more difficult than expected ...

Is your screenshot from Scout with the patch of iconprivate3=GetIcon() from OS 3.1 or OS 3.9? I can't enable the patch on OS 3.9 yet, although it is switched on in MCPPrefs and in the prefs file in ENV:MCP2 is a line "ToolAlias=ON", but nothing appears in Scout. Do I need to configure the ToolAlias list box in MCPPrefs? It's empty now.

The other problem could be that GetIcon(A0,A1,A2) has different arguments than GetIconTagList(A0,A1). It won't be easy to solve that.

hexaae · 11 July 2018, 15:08

Was a sshot from 3.9.
Copy this one in SYS:Prefs/Presets and load it with MCPPrefs: https://nofile.io/f/DVh3z3htqj1/MCP2_133.config then click Use. Then you can run MCP, if was not already running, being sure you did also:
Assign LIBS: <MCPPath/libs> ADD
I use SaferPatches http://m68k.aminet.net/package/dev/debug/TRSaferPtch or SetMan (before Setpatch in this case)

daxb · 11 July 2018, 15:13

Quote:

Originally Posted by PeterK

I can't enable the patch on OS 3.9 yet, although it is switched on in MCPPrefs and in the prefs file in ENV:MCP2 is a line "ToolAlias=ON", but nothing appears in Scout. Do I need to configure the ToolAlias list box in MCPPrefs? It's empty now.

On A1200 3.1 and MCP 1.48: If I activate ToolAlias and click on Test button then in Scouts patch list there is no entry for icon.library. It seems you need to add some string (ToolAlias tab). Then I see MCP patch iconPrivate3() and GetDiskObjectNew().

PeterK · 11 July 2018, 20:32

Thank you hexaae and daxb, I could activate the ToolAlias patch now in 1.33 and also in 1.48. But after having a look into the disassembled patch code I can't see any chance for a workaround. The 1.33 code has even references to the memory freelist of OS 3.1, which is supplied with GetIcon(), but this is totally different managed by icon.library for OS 3.5+.

It's also not possible to simply snip out the ToolAlias patch code from 1.48 and add it to MCP 1.33. There are too many dependencies to other parts in the spaghetti code and some gordian knots here and there to unravel. Too much pain!

hexaae · 11 July 2018, 21:34

Never mind

Thank you for trying: I'll have to put the ToolAlias commodity (working fine) in my WBStartup as extra

EDIT: using only the MCP 1.35 exe (one of the very first versions by D. Groppé) ToolAlias seems to work fine and there are no Enforcer hits, even though the Test button in MCPPrefs doesn't work anymore (= MCP exe has lost the ENV:MCP2/MCP.config monitoring and can't test changes on the fly. You have to quit and restart MCP1.35+ every time :-\ …)

30 May 2018, 23:08	#2306
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Don't worry, just a super lite new feature (needs 28 - 44 bytes). Nothing compared to HAM or vector icon support. Last edited by PeterK; 31 May 2018 at 05:11.

31 May 2018, 09:05	#2307
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Update to icon.library 46.4.486: Nearly the same as 485 again, but a little safer. If a resident module "icon.library" exists, no efforts to load an alternative version are made, because that would cause a recursive loop. The alternative version is only supported by using RemLib or SetPatch v44. Updated the two IconDemo ADF images with icon.library 46.4.486, too. The A500 disk supports the loading of the alternative CPU version now. Unfortunately, there was not a single byte left on the A1200 floppy for another library. Last edited by PeterK; 01 June 2018 at 11:54.

11 July 2018, 09:41	#2315
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	would be great if you can do something and is not too hard to implement… Testing it on my WB3.1 in the meanwhile… EDIT: confirmed working nicely on WB3.1, with MCP 1.33b1 from Aminet + your LIBS:icon.library v46 made resident with Loadmodule command (by Thomas Richter) Last edited by hexaae; 11 July 2018 at 11:05.

11 July 2018, 20:32	#2319
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Thank you hexaae and daxb, I could activate the ToolAlias patch now in 1.33 and also in 1.48. But after having a look into the disassembled patch code I can't see any chance for a workaround. The 1.33 code has even references to the memory freelist of OS 3.1, which is supplied with GetIcon(), but this is totally different managed by icon.library for OS 3.5+. It's also not possible to simply snip out the ToolAlias patch code from 1.48 and add it to MCP 1.33. There are too many dependencies to other parts in the spaghetti code and some gordian knots here and there to unravel. Too much pain! Last edited by PeterK; 11 July 2018 at 20:43.

11 July 2018, 21:34	#2320
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	Never mind Thank you for trying: I'll have to put the ToolAlias commodity (working fine) in my WBStartup as extra EDIT: using only the MCP 1.35 exe (one of the very first versions by D. Groppé) ToolAlias seems to work fine and there are no Enforcer hits, even though the Test button in MCPPrefs doesn't work anymore (= MCP exe has lost the ENV:MCP2/MCP.config monitoring and can't test changes on the fly. You have to quit and restart MCP1.35+ every time :-\ …) Last edited by hexaae; 12 July 2018 at 11:27.

13 April 2018, 13:12	#2301
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Update to icon.library 46.4.483: Added support for the OS 3.1.4 function BumpRevisionLength() to make copies of icons with long file names under the new WB possible, like it could already be done internally since WB v45.130 with the help of WBCTRL MNL=102. Fixed some bugs under DOpus5. The icon.library detects the task name of DOpus5 correctly now, even if it's started by its icon with a different name than "dopu"..., like DirOpus or DirectoryOpus. -- Furthermore, the first icon in a lister won't get invisible anymore when a disk (floppy, CD) without an icon is inserted.

13 April 2018, 18:40	#2302
Michael A1260T/PPC/BV/SCSI/NET Join Date: Jan 2013 Location: Moscow / Russia Posts: 839	Nice.... And no Friday 13 surprises so far.

20 April 2018, 22:18	#2303
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Update to icon.library 46.4.484: Icon.library now replaces the second image of any preview icon that is generated by Image2Icon with a darker copy of the first image and a glowing effect. I didn't like the second images as they were created by Image2Icon-Capsule, a GUI for Image2Icon.

30 May 2018, 14:36	#2304
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Update to icon.library 46.4.485: It's now possible to install an alternative CPU version of icon.library into a subdirectory of LIBS:. If your LIBS:icon.library is compiled for the 68000 then you can add the alternative version in LIBS:68020/icon.library. If your LIBS:icon.library is compiled for 68020+ then you can add the alternative to LIBS:68000/icon.library. The correct version will be loaded automatically by icon.library. On OS 3.0/3.1 this feature only works with RemLib from Thomas Rapp, not with LoadModule, LoadResident and probably not with BlizKick, too. If you don't need this feature then just install Libs:icon.library as usual.

30 May 2018, 22:00	#2305
kolla Banned Join Date: Nov 2007 Location: Trondheim, Norway Posts: 1,893	First step towards a "fat" binary?

01 June 2018, 13:58	#2308
kolla Banned Join Date: Nov 2007 Location: Trondheim, Norway Posts: 1,893	Oh, I was thinking of a library that as binary on disk is combined 68000 and 68020

01 June 2018, 17:58	#2309
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	No, I don't want to create a "fat" binary for the icon.library. That would combine the worst of both worlds. The poor performance of the 68000 code would even get lower due to the additional overhead and the memory consumption will be much higher than required. And also the 68020+ systems would suffer from many 68000 related compromises, which can't be optimized efficiently, since the overhead for CPU depended code on single instructions is bigger than the possible gain. You can only optimize some hotspots like time critical routines. With my method both CPU versions are always optimal in size and performance and it's the users decision to install an alternative binary or not. Unfortunately, the ramlib process is a party-pooper, since it never loads an alternative library as long as it finds it as a resident module.

11 July 2018, 03:25	#2311
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	@PeterK I think I've found an incompatibility with MCP (1.30 or 1.33b1 from Aminet) and its ToolAlias patch. MCP seems to relay on a mysterious "IconPrivate3" patch to make ToolAlias option work: Mmmh, just tried previous icon.library versions starting from OS3.9 45.1 and they also broke MCP compatibility. Do you think you can investigate and maybe make your excellent v46 compatible again? Would be a must since that MCP's feature is so useful. Tested on a WB3.1 HDF and ToolAlias did work fine with icon.library 40.1.

11 July 2018, 08:50	#2312
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	MCP 1.30 and 1.33 are obviously for OS 2.04 up to OS 3.1. The original authors could not know anything about OS 3.5/3.9 a the time when the original MPC was written. The old ToolAlias feature patches the old GetIcon() function of OS 3.0/3.1, which was responsible for loading icons. OS 3.5/3.9 don't use GetIcon() anymore, because there is the new GetIconTagList() function as a replacement now. So, patching a function that is never called on OS 3.5/3.9 should have no effect. In icon.library v44/45 the GetIcon() function was simply removed and disabled. My own icon.library supports it again for OS 3.0/3.1. Thus, the ToolAlias patch may work, but only on OS 3.0/3.1. Just try your WB 3.1 HDF with my library. For OS 3.9 you would need to update to the newer versions of MCP, written by Dieter Groppé. AmiKit uses v1.49c already.

11 July 2018, 09:05	#2313
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	I see. Thanks for details. The problem unfortunately is that MCP versions after 1.33b1 by Groppé are very buggy with features not working etc. and cause also many Enforcer hits. Not sure if he's still supporting it too... This didn't happen with old MCP and that's why I use that (I don't need the extra features of 1.4x either). Is it impossible to implement a GetIcon() emu/workaround for OS3.9 in icon.library v46?

11 July 2018, 09:34	#2314
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	MCP 1.48: http://mcp.a1k.org/indexe.html MCP 1.49c is exclusively available for AmiKit. My icon.library is already redirecting GetIcon() calls to GetIconTagList(). The problem is that nobody makes access to GetIcon() or a patched GetIcon() function on OS 3.9. Maybe, it's possible to patch MCP 1.30/1.33 to call SetFunction() with another library offset than GetIcon() to be patched, but GetIconTagList() has the additional argument "tags" which should be supplied in A1. This means that the ToolAlias patch has to preserve the contents of the scratch register A1, what it probably will not do. This would need another workaround in the ToolAlias patch. Let me see what's possible ... Please make a short test with my library on your OS 3.1 HDF to see if it could work at all.

11 July 2018, 14:02	#2316
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Sigh, it looks more difficult than expected ... Is your screenshot from Scout with the patch of iconprivate3=GetIcon() from OS 3.1 or OS 3.9? I can't enable the patch on OS 3.9 yet, although it is switched on in MCPPrefs and in the prefs file in ENV:MCP2 is a line "ToolAlias=ON", but nothing appears in Scout. Do I need to configure the ToolAlias list box in MCPPrefs? It's empty now. The other problem could be that GetIcon(A0,A1,A2) has different arguments than GetIconTagList(A0,A1). It won't be easy to solve that.

11 July 2018, 15:08	#2317
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	Was a sshot from 3.9. Copy this one in SYS:Prefs/Presets and load it with MCPPrefs: https://nofile.io/f/DVh3z3htqj1/MCP2_133.config then click Use. Then you can run MCP, if was not already running, being sure you did also: Assign LIBS: <MCPPath/libs> ADD I use SaferPatches http://m68k.aminet.net/package/dev/debug/TRSaferPtch or SetMan (before Setpatch in this case)

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
ClassicWB Full and icon.library 46.4	Retroplay	project.ClassicWB	8	05 August 2018 13:57
WB library conflict/versions	Amiga1992	support.Apps	3	22 July 2010 18:47
PNG Icon to Color Icon Converter?	Leandro Jardim	request.Apps	1	24 May 2010 04:39
What's the latest version of icon.library for OS3.9?	NovaCoder	support.Apps	3	30 June 2009 15:43
Requesting icon.library v44+...	nikvest	request.Other	2	16 September 2007 01:58