AmigaOS 3.x improvements

[kolla]

I just did a test - it works perfectly as I want in OS 3.1.

* I booted from Workbench3.1 in DF0: and have Extras3.1 in DF1:
* I copy WBStartup from Workbench3.1 to RAM Disk by pulling it over
* I rename WBStartup in RAM Disk to "Project"
* I open IconEdit from Extras3.1:Tools, I open RAM:Project.info
* I go to "Type" menu and set it to "Project", I save the icon and exit IconEdit
* I double click the Project icon in RAM Disk
  - Screen flashes and the screen bar says "The icon(s) have no default tool"
* I click "Project", and open Information, sets "Default Tool:" to "Multiview".
* Again I double click the Project icon in RAM Disk
  - Multiview opens and shows content of "RAM Disk:Project" - as I expected.

At some point on the way from OS3.1 to 3.9 this behavior vanished.

This turns out to be not true - it works just as well with 3.9BB2 as with 3.1.
I just tried with last official icon.library from BB1 (45.1, 8.Feb.2001), and with that installed it behaves just like in OS3.1 - yay!

The problem is solely due to PeterK's icon.library which I must have started using at some point very early on. I also noticed this does not work in MorphOS.
Also, PeterK admits on EAB that it is a feature in his icon.library, or as I see it, a compatibility blunder that has has had me confused for years!

MIST is great for having a whole load of setup to test this stuff with, hehe

[kolla]

I use 3.1 with MultiCX, and IIRC the WINREMEMBER tooltype or similar remembers the position of windows within the session. So obviously this doesn't survive reboots, but still a nice feature.

Instead of the link for the ram disk icon, I suppose it would be possible to write a script that automatically copies over the disk.info if it changes, either from referring to datestamp or a file change, or even easier just make it copy every so often, or just write the script to copy it and have it executable from the tools menu or something.

There are background daemons on Aminet that does this, people waist CPU cycles on running dedicated process to monitor RAM:Disk.info to copy it back to envarc: or S: or wherever. There are scripts that run in loops, there are all kinds of work-arounds - but that is all they are - work-arounds. RAM Disk is part of the OS, dealing with the icon is also part of the OS - RAM Disk is special, it is different, it should be dealt with by the OS without the need for third party work-arounds.

As for surviving the "session" until next boot - isn't that default behavior?

[kolla]

Unfortunately, no. The Ram-Handler of 3.9 was done by Heinz, not me.

Aha, ok, I see. http://se.aminet.net/util/boot/PatchRAM.readme looks very much like you, Heinz is not even mentioned.

[kolla]

It is important. What if you have read-only media and you want to change its icon position permanently? Or a volume without icon?

RAM disk solution would be one shot fix for one case but what about other cases?

What about them? RAM Disk is the obvious one, since it affects everyone. You could have Deficons itself take care of everything, storing meta data normally stored in Disk.info files somewhere else for all kinds of volumes and devices, keeping def_icons.info files clean for all meta data - but you would still need somewhere to write that information down for it to survive reboots. You could have ENVARC: in nonvolatile RAM if you want to. I really don't understand your argument - because fixing icon handling for RAM Disk would not be a general solution also working for CD drives, it is better to not fix it at all?

[kolla]

Because in the software industry you don't do shortsighted "fixes" and workarounds. You have to look at a bigger picture.

Developer should find a solution that fixes RAM disk and CD drives and other RO/temp drives in general.

:roflmao::roflmao::roflmao:

Software industry?

[kolla]

Of course it is a joke in Amiga land.

Yes - that is the bigger picture here!

[kolla]

Anyways, having the soft link RAM:Disk.info is way more elegant than any other solution I have seen, any changes done to ram disk icon are instantly saved to envarc:sys/def_RAM.info without any background process or silly script running, no special interaction on my part, and it of course survives reboots.

[kolla]

More annoying quirks - c:date again, and locale - how do I tell c:date to accept English input even when my locates are Norwegian? And how lame is it, that it insists on "local" language input, when the error message it spits out, is always in english? It is kinda hopeless to use c:date in scripts, since what it spits out and accept as input, depends on locale settings. I have tried to set both local and global variable "language", but it doesn't care.

[kolla]

It is probably using dos.library/StrToDate() with FORMAT_DEF to parse input. With that option it is always using localized parsing. Other options are international format (whaaat...), Canadian (eh?), American (USA) and AmigaDOS format.

Yes, and C:Date should have option flags to support more formats, and it should very well be localized itself too.

There is something missing in the API and it is consistency...

Indeed.

[kolla]

I have ended up reverting a lot of the BB3+4 package, it goes a bit beyond just getting in the latest updates.

[kolla]

Did you also revert to Windows 95 because Windows 7 "went a bit beyond just getting in the latest updates"? :lol: :lol:

No, I would revert to Windows 98SE.

My point is just that BB3+4 pulls in third party libraries and things that sometimes are incompatible with original software, and that can be annoying - for example PeterK's icon.library, for example latest KingCON, for example THE which I don't even want in the first place, and much more. Also, it did not check if I had Genesis installed or not before it "updated" my non-existing installation, creating an Internet folder without any icon, and with some useless binaries in it. And yeah, I hate it when installer scripts mess around.