icon.library 46.4 test versions

[PeterK]

You probably have to call IconControlA() with ICONCTRLA_GetImage2 just to generate the delayed image2 and the mask2, except for WB 3.0/3.1 where Blt(Mask)BitMapRastPort() is patched by icon.library to generate the true image just in time.

(On WB 3.5+ this is done automatically by a call to DrawIconState(). Or you could use my command NoDelayedImage2, but that would be a decision of the user, I think.)

@Akira
All clear signal:
Don't worry about the delayed image2 or mask2. The delay is only activated for the Workbench task, not for other programs.

My assembler code for converting an image structure in A0 into a 40 byte bitmap in A1, but this code may only work for color icons, because they always use real planes. For old-style images you also have to take PlanePick and PlaneOnOff into acount.

preparebitmap       ADDQ.W         #4,A0                    ; image width etc
                    MOVEM.W        (A0)+,D0-D1              ; width, height
                    ADDQ.L         #8,D0
                    ADDQ.L         #7,D0
                    LSR.L          #4,D0
                    ADD.L          D0,D0                    ; plane bytes/row
                    MOVE.W         D0,(A1)+                 ; bytes/row
                    MOVE.W         D1,(A1)+                 ; row count
                    MULU.W         D0,D1                    ; total plane size
                    MOVE.W         (A0)+,D0                 ; depth
                    MOVEA.L        (A0),A0                  ; planar image data
                    CMPI.W         #8,D0
                    BLS.S          .depthok
                    MOVEQ          #8,D0                    ; limit to 8 planes
.depthok            MOVE.W         D0,(A1)+                 ; flags, depth
                    CLR.W          (A1)                     ; clear pad word !!
                    ADDA.W         #30,A1
                    CLR.L          (A1)                     ; plane 7
                    CLR.L          -(A1)                    ; plane 6
                    CLR.L          -(A1)                    ; plane 5
                    CLR.L          -(A1)                    ; plane 4
                    CLR.L          -(A1)                    ; plane 3
                    CLR.L          -(A1)                    ; plane 2
                    CLR.L          -(A1)                    ; plane 1
                    CLR.L          -(A1)                    ; plane 0
                    BRA.S          .countdowndepth

.nextpointer        MOVE.L         A0,(A1)+                 ; image data offsets
                    ADDA.L         D1,A0                    ; add planesize
.countdowndepth     DBRA           D0,.nextpointer
                    RTS

[kolla]

Looks to me that the new RAM: icon feature only works when RAM: is labeled "Ram Disk", I tend to name my RAM: something more Norwegian, so I am back to soft link

[PeterK]

Yes, I should have mentioned this in my readme:

There are some restrictions for the supported volume names for the device RAM:

1.) the name may have up to 10 characters including the ":", plus the Null terminator of the string.
2.) it could be "ram:", upper or lower case are allowed.
3.) it could be "ram "...... like "Ram Disk:", upper or lower case allowed.
4.) it could be "RamD"...... like "RamDisk:" or "RamDrive:", first 4 chars must match exactly.

So, names like "Rambo:", "Ramses:" or "Ramazzotti:" are not supported because that could also be possible volume names of a floppy disk, CD or HDD. The name length is limited because I don't want to get in conflict with other disk icons in RAM:Env/Sys.

It's impossible to suppport localized names for the volume "Ram Disk:". (Btw, what is the Norwegian name?)

[kolla]

I use a variety of names, in Norwegian typically "Minne", but even with English I tend to call it "Memory" rather than the long (and somewhat cumbersome) "Ram Disk". To be honest, I took it for granted that label was irrelevant, and the only thing mattering was device name RAM, and was a little baffled when I found out (SnoopDOS) that the label made a difference when trying to save position.

[PeterK]

The problem is that it's not so easy to get the device name of a volume name. Or can you tell me how? Functions like NameFromLock() always return the volume name. "Memory:" could also be the label of a floppy disk and your floppy should not get a Ram Disk icon.

I really don't want to do something like this:
http://www.amiga.org/forums/showthread.php?p=835753

[kolla]

Yeah... well, I only have superficial knowledge about how things are meant to work, but I don't quite understand why labels are used at all in this context. Def_icons, from what I understand, should only relate to device drives, and not volume labels. RAM: can have tons of labels, but it will always be RAM:. Even if I relabel the RAM: drive during startup-sequence, ENV:Sys/def_RAM.info is still used, so _something_ knows that it still is RAM:

Btw, at some point I asked ThoR if he could implement handling of RAM:'s Disk.info in ram-handler (where I think it belongs), but he declined.

[Gorf]

How does the "which" command do this?

> which RAM:

should return the volume name ...

Many this could be used in SS to fill a ENV variable, that gets checked by the icon.library?

[PeterK]

Good idea, thank you Gorf!

I could make a Lock() on RAM: and then use NameFromLock() to get the volume name in the Init() part of icon.library. After storing that volume name I could compare it later with the path names for Disk.info instead of comparing with "ram " or "RamD".

Nevertheless, I'm not sure anymore if I should support random volume names for RAM: like "Memory", because it makes the name comparisn even more complex since it would need exact compares to distinguish between "Memory" and "Memories" for example. I can not just test for "Memo". And I have to do these checks 3 5 times in my code. Too much extra code just for kolla ...

[Romanujan]

I have ReLabel RAM: "RAM Disk" command in my Startup-Sequence - will this be compatible?

[PeterK]

"Ram Disk" is already the default name for RAM:.

Do you relabel it to "RAM Disk" because you prefer RAM in capitals? However, all upper and lower case combinations are supported for "ram "......, only the first 4 characters are checked.

[Gorf]

Originally Posted by PeterK

Good idea, thank you Gorf!

I could make a Lock() on RAM: and then use NameFromLock() to get the volume name in the Init() part of icon.library. After storing that volume name I could compare it later with the path names for Disk.info instead of comparing with "ram " or "RamD".

Nevertheless, I'm not sure anymore if I should support random volume names for RAM: like "Memory", because it makes the name comparisn even more complex since it would need exact compares to distinguish between "Memory" and "Memories" for example. I can not just test for "Memo". And I have to do these checks 3 times in my code. Too much extra code just for kolla ...

true: once you have the real name of the volume, you would have to check against it completely, with the exact full length.
But by just "allowing" a certain naming schema, you probably make users life hard in the future, once they have forgotten about this restriction and the OS allowing them to change the name to whatever.

so maybe we can somehow reduce the number of checks in your code somehow? why do you need to check 3 times in the first place?

Could in some cases the device name (RAM: ) be enough?

Or could the OS somehow "warn" the library?

[daxb]

I'm using a virus tool called Safe that has an option to rename "Ram Disk:" to "Ram:". IMHO the only useful rename.

[kolla]

I think symlink the cleanest way of doing this anyways, I don't quite grasp what process icon.library 46.4 is going through for saving ENVARC:Sys/def_RAM.info, but it seems complicated.

[kolla]

Originally Posted by daxb

I'm using a virus tool called Safe that has an option to rename "Ram Disk:" to "Ram:". IMHO the only useful rename.

Ewe!

[PeterK]

Originally Posted by Gorf

But by just "allowing" a certain naming schema, you probably make users live hard in the future once they have forgotten about this restriction and the OS allowing them to change the name to whatever.

Probably >97 % of the users don't relabel their "Ram Disk". Myself, I'm using "RamDisk" to avoid a space in path names of files, because some tools, especially shell and Arexx scripts sometimes have problems with spaces. I added 'Relabel >NIL: RAM: RamDisk', 'Assign >NIL: "Ram Disk" DISMOUNT' and 'Assign >NIL: "Ram Disk:" RAM:' to my s-s to support the default name. The volume name "RAM:" is also supported, although I don't like it to be the same as the device name, but "Safe" needs that as daxb has reported (it's used in AmiKit, too).

Nothing will go wrong for those users who prefer to rename the volume to something unsupported. They just fall back to the OS standard.

...so maybe we can somehow reduce the number of checks in your code somehow? why do you need to check 3 times in the first place?

No, there are lots of different ways used by WB, DOpus5 and other tools trying to access "Disk.info" or sometimes even "ENV:Sys/def_Disk.info" by DOpus5. I need at least two four checks for reading and one for writing "Disk.info". Creating a subroutine would make the code worse.

Could in some cases the device name (RAM: ) be enough?

The filename of the Ram Disk icon can be an absolute path or just the file "Disk" relative to the current dir, and the root can be the device RAM: or a volume name like "Ram Disk" or "RamDisk" as I use it. I think I should expand the check for "Ram Disk" from 4 to 8 chars to avoid a possible conflict with a disk named "Ram Test" or "Ram Tools" or similar.

Or could the OS somehow "warn" the library?

The OS does not know anything about the RAM: icon support of the library.

[PeterK]

Originally Posted by kolla

I think symlink the cleanest way of doing this anyways, I don't quite grasp what process icon.library 46.4 is going through for saving ENVARC:Sys/def_RAM.info, but it seems complicated. :)

Yes, it was very complicated to let it go well on all system configurations, like WB 3.0/3.1, 3.5/3.9, DOpus5, AmiKit, AfA_OS, 68000, with or without DefIcons running, and all possible combinations.

The symlink also has some disadvantages. It's not supported on all filesystems like amber-ram-handler, which I prefer to use. And it creates an ugly "Disk.info" directory entry even if RAM: has no icon yet. Some people don't like that. And the symlink won't update "ENV:Sys/def_RAM.info".

[Gorf]

The OS does not know anything about the RAM: icon support of the library.

yes I know, we have got still no resource tracking in our little OS

I think I should expand the check for "Ram Disk" from 4 to 8 chars to avoid a possible conflict with a disk named "Ram Test" or "Ram Tools" or similar.

If you do so anyways, you could use our idea from earlier and check or the actual name - which should now reduce the number of names you have to check

[PeterK]

Originally Posted by Gorf

If you do so anyways, you could use our idea from earlier and check for the actual name - which should now reduce the number of names you have to check

The devil always hides in the details, and I know already, he is there, for sure.

Update: Just noticed that I even have 5 checks for RAM: in my library. I'm working on it now ... the problem is that these checks are all a bit different, no easy way to squeeze a subroutine out of their code.

@Akira
Any progress with your Blitz Basic project? How is it going?

[Tigerskunk]

First off, thanks for your work, Peter..

Now on to my total OS noob questions, which hopefully someone here can answer...

1) is the icon.library included in betterWB the one from PeterK?
2) how would I know if I run the one from PeterK? I tried to run it using the code supplied in Aminet:

Version >NIL: icon.library 46
If WARN
   If EXISTS LIBS:workbench.library
      LoadResident >NIL: LIBS:workbench.library
   EndIf
   LoadResident >NIL: LIBS:icon.library REBOOT
EndIf

But it looks the same as before...

[demolition]

Originally Posted by Steril707

how would I know if I run the one from PeterK?

Typing 'version icon.library' will tell you which version is active.