AmigaOS 3.x improvements

[kolla]

The last year I have been away backpacking, and only touched Amiga through UAE on various hostels around in latin America. I finally came back home and at the same time I got my MIST which I have been playing with lots lately. I have it running OS3.9 with one of many custom 3.9 kickstarts I have assembled (including the awesome new layers.library), and it is running very smoothly

Anyways, there are many little quirks with OS3.9 still, and I would like to point out some of them, and knowing that certain people are on this site, maybe something can be done to improve, or simply just clarify things.

[kolla]

First up - C:List

C:List could really need a flag to drop "human readable" terms for days. There are times I want to use output from ´List file LFORMAT "%T"´ as variable in scripts for example, and then having words like "Today", "Friday", "Yesterday" - and even localized - is not at all useful. Pretty please, an update to C:List with a "code readable" option.

(if there are other ways to get timestamp from a file, I'm eager to know)

[kolla]

The icon of Ram Disk:

This is ThoR realm - Ram-Handler has been updated and improved, but still we need tricks and fiddling to make sure the icon - RAM:Disk.info - somehow ends up being saved on disk when we update it (change icon, snap shot). Since one of the updates done by ThoR involves soft links working on RAM:, I have a line in Startup-sequence that says "MakeLink RAM:Disk.info ENVARC:Sys/def_RAM.info", and this works nicely (softlinks are default too with C:MakeLink).

But - would it not be so much better if Ram-Handler also handled the Disk.info issue by itself, using ENVARC:Sys/def_RAM.info by default, updating it when user changes RAM:Disk.info?

[kolla]

I continue with time/date/clock related issues. Since neither of my current main Amiga systems (the Minimig and the MIST) have RTC, I resort to dirty tricks to keep the clocks fairly correct on them.

It would be great if C:Date could take a given file as argument, and use the timestamp of that file to set the time.

(I found a great piece of software on Aminet that is truly useful, "Timekeeper", which updates a timestamp in resident RAM, and on reboot sets the time from that (plus a given number of seconds to compensate for the few seconds of reboot), and when the timestamp in RAM is messing, executes a command that can set the system time using a different method, for example letting user set time).

[kolla]

When AmigaOS boots and no RTC is found, it sets the system time to what creation time of the filesystem it boots from is (at least as long as FFS is used - no idea about PFS and SFS). Does the structures of FFS perhaps contain a "last changed" timestamp too? If so, it would make sense to use that instead. And if not - can I suggest that C:SetDate is updated to not just change the timestamp of a file or directory, but also filesystems?

[kolla]

Just add the "dates" switch. It works with or without LFORMAT for dates but doesn't do anything for your "%T" (time) example.

>List dates LFORMAT "%D"
%&$#?@!%&$#?@!%&$#?@!778;

Huh - I was 99% sure I tried using "dates" option, and only saw it display dates or not on listings. But you are right, it turns those localized strings to standardized dates. And yes, I meant %D, not %T *facepalm* - Thanks :)

Peter K's icon.library will use the ENVARC:Sys/def_RAM.info for ram disk by default and without using MakeLink. In more recent versions of his library, the ram disk icon will be ghosted as there is no real icon in the ram disk but he added a "NoGhost" ToolType which will keep any icon from being ghosted.

http://eab.abime.net/showthread.php?t=64079&page=69

The other option is to copy the ram disk icon to the ram disk on bootup but that uses memory.

I see - I am using Peter K's icon.library, but it does not save back up ENVARC:Sys/def_RAM.info, for example if I move RAM Disk on Workbench, snapshot it, it will just create RAM:Disk.info, but ENVARC:Sys/def_RAM.info is untouched, and on next reboot RAM Disk will be back on it's original location.

With a soft link from RAM:Disk.info to ENVARC:Sys/def_RAM.info, when I do changes to RAM:Disk.info, the soft link will save those changes to ENVARC:Sys/def_RAM.info - which is what I think pretty much everyone wants.

I am not sure which part of the system that should have the task of maintaining ENVARC:Sys/def_RAM.info, but feel ram-handler is an obvious candidate.

[kolla]

Next up - a tip regarding s:startup-sequence

First of all, too much >NIL: in there, hehe

Secondly, Assign and Execute are made resident manually, they could however be made resident simply by making sure they have the "hold" bit set, with which they will go resident the first time they are run.

So, I typically set the H bit on them and remove those lines

[kolla]

Speaking of icons - once upon a time, I had drawers that were projects, their Icons were of type project with an associated default tool, there are programs that take drawers as argument - THIS WAS PRETTY DARN NEAT!

For example - I could turn a drawer full of pictures into a project, give it an appropriate icon and set a picture viewer as default tool, on opening that icon, the image viewer would launch and show slideshow of all the pics in the drawer.

More useful example - I had a rexx script that would take a drawer as argument, and build a GUI based on resources found in that drawer, very much like how !Apps work on RISCOS (I was inspired by RISCOS on this), or OSX.

Today, all drawers are treated as drawers, regardless what the icon type says, I _really_ would love to have project drawers back. I guess it is PeterK's icon.library I can blame for this.

EDIT: I just asked PeterK on that EAB thread.

[kolla]

Hold bit is not supported by SFS (where it has different purpose) and it is often lost when copying files around.

As does the P flag that still needs to be set, so ...

Really, SFS uses it for what?

[kolla]

If using Peter K's icon library, I suppose it's the responsibility of the end user to snapshot his or her ram disk icon and then copy the resultant amended disk.info file from RAM: to ENVARC:Sys/def_RAM.info. It only has to be done once so I personally don't see it as an inconvenience.

Every time you change icon.
Every time you move the icon to somewhere and snapshot it.
Every time you tell Workbench to remember the position and view of open RAM Disk window.

It is not at all obvious that all this information is stored in RAM:Disk.info and that users are expected to copy Disk.info to ENVARC:Sys/def_RAM.info manually.

It could just automatically be saved in ENVARC:Sys/def_RAM.info by ram-handler, in fact RAM:Disk.info would not even need to exist at all.

[kolla]

Are you using 3.1 or 3.9? If 3.9, I think it is related to Workbench. Icon.library does not care about icon type, really.

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.

EDIT: Correction - it works by doing a work-around suggested by Peter K - rename the drawer from shell, set type of icon (that now lacks a corresponding drawer) to project, give it a default tool, rename the drawer back in the shell. Presto, it works!

[kolla]

Well, before MakeLink can work, the underlying filesystem must support it. I do not know ThoR's background for suddenly supporting soft links on RAM: with newer ram-handler, but I sure knew what to do with it.

My main point is that changes to RAM Disk icon should survive reboots - one way would be for the handler to take care of it. Wether it uses ENVARC:Sys/def_RAM.info or something else is not important.

[kolla]

Funny legacy feature that maybe not everyone is aware of - even OS3.9 kickstart respects DEVS:system-configuration from back in 1.x days. If you have the Preferences programs from WB1.3 for example, you can configure crazy colors, interlaced modus, funny mouse pointer etc and have all that configured long before IPrefs, even when booting without startup-sequence.

Sadly, OS 1.3 Preferences easily crash on newer systems, so I booted back to 1.3.4 and with 1.3 kickstart to create the prefs, then switched back to my 3.9 setup, inserted the WB 1.3.4 WB floppy, copied over df0:devs/system-configuration to DEVS:, removed floppy and booted without startup-sequence. :laughing:

[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?