English Amiga Board


Go Back   English Amiga Board > Coders > Coders. System

 
 
Thread Tools
Old 13 April 2018, 14:12   #2301
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,385
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.
PeterK is offline  
Old 13 April 2018, 19:40   #2302
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 649
Nice.... And no Friday 13 surprises so far.
Michael is offline  
Old 20 April 2018, 23:18   #2303
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,385
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 is offline  
Old 30 May 2018, 15:36   #2304
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,385
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.
PeterK is offline  
Old 30 May 2018, 23:00   #2305
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,537
First step towards a "fat" binary?
kolla is offline  
Old 31 May 2018, 00:08   #2306
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,385
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 06:11.
PeterK is offline  
Old 31 May 2018, 10:05   #2307
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,385
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 12:54.
PeterK is offline  
Old 01 June 2018, 14:58   #2308
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,537
Oh, I was thinking of a library that as binary on disk is combined 68000 and 68020
kolla is offline  
Old 01 June 2018, 18:58   #2309
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,385
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.
PeterK is offline  
Old 04 June 2018, 23:10   #2310
indigolemon
Bit Copying Bard

indigolemon's Avatar
 
Join Date: Jan 2017
Location: Kelty, Fife, Scotland
Age: 36
Posts: 527
Quote:
Originally Posted by PeterK View Post
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
indigolemon is offline  
Old 11 July 2018, 04:25   #2311
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,116
@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.
hexaae is online now  
Old 11 July 2018, 09:50   #2312
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,385
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.
PeterK is offline  
Old 11 July 2018, 10:05   #2313
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,116
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?
hexaae is online now  
Old 11 July 2018, 10:34   #2314
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,385
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.
PeterK is offline  
Old 11 July 2018, 10:41   #2315
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,116

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 12:05.
hexaae is online now  
Old 11 July 2018, 15:02   #2316
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,385
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.
PeterK is offline  
Old 11 July 2018, 16:08   #2317
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,116
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)
hexaae is online now  
Old 11 July 2018, 16:13   #2318
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 2,098
Quote:
Originally Posted by PeterK View Post
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().

Last edited by daxb; 11 July 2018 at 23:11.
daxb is offline  
Old 11 July 2018, 21:32   #2319
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,385
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 21:43.
PeterK is offline  
Old 11 July 2018, 22:34   #2320
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,116
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 12:27.
hexaae is online now  
 


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

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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 15:13.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.18741 seconds with 16 queries