"Use"d settings: application behaviour

This forum is for general developer support questions.
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: "Use"d settings: application behaviour

Post by xenic »

nbache wrote: Remember that env variables are supposed to be changed by using SetEnv, with the SAVE switch if you want to change it permanently, and without if you only want to change it for the duration of your session. The behaviour of modifying the saved value by direct manipulation is not necessarily defined.
That's another reason why programs shouldn't be saving their prefs in the ENVARC: directory. You can't use GetENV to retrieve multi-line prefs (try getenv ContextMenus.cfg) because you only get the top line. Programs that are saving multi-line prefs in ENVARC: and reading those prefs upon program startup are doing so by direct manipulation. I only directly manipulated variables to prove that most of the ENVARC: data is being copied to ENV: when the system boots (Somewhat confirmed by Colin).[/quote]
And why would you? If you respond "For curiosity", then all is forgiven, otherwise, I'd like to see a practical case where this would be useful to do.
I'm not sure I need forgiven for trying to prove to the people who always jump in and tell me that I'm wrong when I mention that most of the ENVARC: contents are copied to ENV: when the system boots.


Here is yet another method of demonstrating that most of the ENVARC: files are copied to ENV: when you boot your system:

Insert a bootable CD in your CDROM drive.
Turn on your computer and wait for the system to boot.
Open a shell and enter the following:

copy C:Copy TO ram:
copy C:Dir TO ram:
cd ram:

Remove the boot CD from the drive.
Enter the following in the shell you opened:

copy ENV:ContextMenus.cfg TO RAM:
dir ram:
Clipboards (dir)
T (dir)
AmigaAMP.prefs Copy Dir

How did I copy AmigaAMP.prefs from ENV: with the CD removed if it wasn't copied from ENVARC: to ENV: when I booted?? If you are opposed to directly manipulating ENV: then you can enter "GetENV ContextMenus.cfg" instead of "copy ENV:ContextMenus.cfg TO ram:" and you will see a single line of the ContextMenus.cfg (unless it's a blank line).

I'm not trying to insult anyone. As I mentioned above, I'm just tired of people jumping on me when I mention that most of ENVARC: is copied to ENV: when you boot OS4. I only mention it as another reason why 3rd party programs shoudn't be saving their prefs files in the ENVARC: directory.
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
nbache
Beta Tester
Beta Tester
Posts: 1714
Joined: Mon Dec 20, 2010 7:25 pm
Location: Copenhagen, Denmark
Contact:

Re: "Use"d settings: application behaviour

Post by nbache »

xenic wrote:That's another reason why programs shouldn't be saving their prefs in the ENVARC: directory.
Absolutely, I agree about that.
I only directly manipulated variables to prove that most of the ENVARC: data is being copied to ENV: when the system boots (Somewhat confirmed by Colin).
No, Colin said that a directory which is accessed by something in the startup will get loaded (not the files/env var contents in it). EDIT: On re-reading, and after reading subsequent posts, I must correct this: Yes, also the files/env vars, but only on that particular directory level. Hope I understood it correctly now :-).
I'm not sure I need forgiven
Of course not, it was just a joke from my side.
Here is yet another method of demonstrating that most of the ENVARC: files are copied to ENV: when you boot your system:
I'll leave that to Colin, he knows what goes on, where I'm just guessing.

Best regards,

Niels
Last edited by nbache on Sun Nov 02, 2014 1:36 pm, edited 1 time in total.
User avatar
trixie
Posts: 409
Joined: Thu Jun 30, 2011 2:54 pm
Location: Czech Republic

Re: "Use"d settings: application behaviour

Post by trixie »

ssolie wrote:I don't see any need for Hyperion to be involved.
xenic wrote:3rd party programs shoudn't be saving their prefs files in the ENVARC: directory
I have one or two problems with these statements :-)

There is a system component called PrefsObjects (part of Application Library), which represents a general mechanism for handling application preferences. It lets you read, manipulate and save settings using a "prefs dictionary", an object that physically (= on disk) takes the form of an XML file. Based on the existing documentation (autodocs, includes), it is quite beyond dispute that the default places from which the application settings are retrieved, and to which they are saved, are ENV: and ENVARC:

So there is an existing application settings framework in place, which is an official OS component and which is apparently ENV(ARC)-centric, yet
  • programmers seem to be convinced ENV(ARC) is not the place to use, and
  • the developer Team Lead claims Hyperion are not involved at all.
I think we need to try a little harder and discuss that :-)
The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
chris
Posts: 562
Joined: Sat Jun 18, 2011 11:05 am
Contact:

Re: "Use"d settings: application behaviour

Post by chris »

xenic wrote:
nbache wrote: Remember that env variables are supposed to be changed by using SetEnv, with the SAVE switch if you want to change it permanently, and without if you only want to change it for the duration of your session. The behaviour of modifying the saved value by direct manipulation is not necessarily defined.
That's another reason why programs shouldn't be saving their prefs in the ENVARC: directory. You can't use GetENV to retrieve multi-line prefs (try getenv ContextMenus.cfg) because you only get the top line. Programs that are saving multi-line prefs in ENVARC: and reading those prefs upon program startup are doing so by direct manipulation. I only directly manipulated variables to prove that most of the ENVARC: data is being copied to ENV: when the system boots (Somewhat confirmed by Colin).
I don't think this is a problem, and if it's not allowed then Commodore have been getting it wrong since they introduced 2.0. The system prefs files aren't even plain text!
I'm not sure I need forgiven for trying to prove to the people who always jump in and tell me that I'm wrong when I mention that most of the ENVARC: contents are copied to ENV: when the system boots.
The old versions of env-handler absolutely did not copy the contents of ENVARC: to ENV:. I know this because it used to be the case that listing ENV: would only show files that had been accessed previously.

What has happened is that Colin(?) has modified the directory scan so it causes files to be copied as they are scanned. This means a list of ENV: looks complete, but also something in boot is doing this so the root of ENVARC: is being fully copied.

There shouldn't be much other than tiny text files in the root. Programs are supposed to save to a subdirectory if they are using ENVARC: for saving settings.

I wouldn't call this "most" but I will concede it means "some" of ENVARC is being copied at boot.
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 207
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: "Use"d settings: application behaviour

Post by colinw »

chris wrote: There shouldn't be much other than tiny text files in the root. Programs are supposed to save to a subdirectory if they are using
ENVARC: for saving settings. I wouldn't call this "most" but I will concede it means "some" of ENVARC is being copied at boot.
So, all you need to do now is find out who is scanning the root directory of ENV: and make them use a sub-directory instead,
then nothing in the ENV root will be copied other than the variables being accessed.

They might be using the directory scanning function or more likely IDOS->ScanVars(), as people have been warned off from
accessing ENV(arc) as a filesystem since V50+, instead they should always use the dedicated VAR functions provided by DOS.
User avatar
nbache
Beta Tester
Beta Tester
Posts: 1714
Joined: Mon Dec 20, 2010 7:25 pm
Location: Copenhagen, Denmark
Contact:

Re: "Use"d settings: application behaviour

Post by nbache »

colinw wrote:So, all you need to do now is find out who is scanning the root directory of ENV: and make them use a sub-directory instead,
I made an experiment on my public 4.1u6+AmiUpdates setup. In a copy of the Startup-Sequence, I added "echo >ENVARC:MYVAR 1", "echo > ENVARC:MYVAR 2" etc. in between all the statements. Then after booting, I did a "getenv MYVAR". The value it gave me (in my case 20), was the one I had echoed into it just before the P96LoadDefaultMonitor line.

This would seem to be good news, since that particular command is not used any more as of Final Edition.

However, it must not be the only culprit, as I can also reproduce the behaviour on my beta setup, where P96LoadDefaultMonitor is already not used.

I will have to do some more investigation.

OTOH, seeing this evidence already confirms what Colin explained is actually going on. :-)

Best regards,

Niels
User avatar
nbache
Beta Tester
Beta Tester
Posts: 1714
Joined: Mon Dec 20, 2010 7:25 pm
Location: Copenhagen, Denmark
Contact:

Re: "Use"d settings: application behaviour

Post by nbache »

For my next experiment, I used (an RC of) Final Edition, where P96LoadDefaultMonitor (as mentioned) is not used. When I tried the same trick in Startup-Sequence, it pointed towards LoadMonDrvs - but this was actually the line just before P96LoadDefaultMonitor in the current public S-S.

So I'm wondering if I'm being misled.

Colin, can you confirm or correct the premise of my test? Specifically, I'm wondering whether there might be some asynchronous delay between echoing into a file and env-handler reading that same file, so that it doesn't actually necessarily read the very latest contents? If so, I'd need to introduce a Wait 1 SEC or similar between each echo and the following line. And that might redirect our suspicion to the next line in both cases, which would be the AddDataTypes REFRESH QUIET command.

My filesystem in both cases is SFS\0, BTW.

Best regards,

Niels
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: "Use"d settings: application behaviour

Post by xenic »

nbache wrote:So I'm wondering if I'm being misled.
Probably not intentionally. My experiments with removing the boot volume indicates that ENV: is full of files before the startup-sequence is executed. Here is what I did:

Boot from a Flash Drive or CDROM and enter the early startup menu.
In the early startup menu select "Boot With No Startup-Sequence" and boot the system.
In the default shell that opens enter "Copy C:List TO ram:"
Remove the boot volume (Flash Drive or CDROM) so that ENVARC: is unavailable.
In the default shell enter "ram:List ENV: >SYS:listoutput" (or to whatever hard disk file you want).
Reboot and read the "listoutput" file.
My "listoutput" file shows most of the files from ENVARC: (except the default icon files).
AmigaOne X1000 with 2GB memory - OS4.1 FE
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: "Use"d settings: application behaviour

Post by xenic »

trixie wrote:I think we need to try a little harder and discuss that :-)
It sounds like application.library needs an update. Since it appears unlikely that we (everybody--not just us) will come to an agreement on where prefs belong, I would suggest this:

--------------------------------------
Add tags WRITEPREFS_WriteDIR and READPREFS_ReadDIR to application library to the WritePrefs() and ReadPrefs() functions in application library for programmers who choose to save prefs in a home directory.

If ssolie wants to force the issue of not saving application prefs in ENVARC: then we can add a default directory in SYS:Prefs called "app-prefs" to save prefs for programs that don't have a home directory. Then change all the current read/write tags in WritePrefs() and ReadPrefs() to save prefs in that directory. Add new tag names for reading/writing so that ...ENV and ...ENVARC tags can be labeled obsolete.

I doubt if ssolie is going to do that but I'd like to see the "WRITEPREFS_WriteDIR and READPREFS_ReadDIR" tags added for programmers who chose to save prefs in an application's home directory.
--------------------------------------

I have 2 OS4 Amiga systems and after I install a program, test it and want to keep it; I copy the program directory to a Flash drive and transfer the program to my other OS4 Amiga. If I discover that the program prefs were left behind because they are in ENVARC: , I usually get irritated and just delete it instead.
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 207
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: "Use"d settings: application behaviour

Post by colinw »

nbache wrote: Colin, can you confirm or correct the premise of my test? Specifically, I'm wondering whether there might be some asynchronous
delay between echoing into a file and env-handler reading that same file, so that it doesn't actually necessarily read the very
latest contents? If so, I'd need to introduce a Wait 1 SEC or similar between each echo and the following line.
And that might redirect our suspicion to the next line in both cases, which would be the AddDataTypes REFRESH QUIET command.
It depends whether the command spawns (or causes to spawn) a new process or not, loads libraries or devices that may themself
start a new process, da da da, etc... who knows.

You would be much better just doing: "info env: >>ram:temp" preceeded with a marker number and followed by a wait 1.
The log will show when ENV: got substantially bigger, if you can call ~170K big, that will be enough to determine when
something scanned the ENV: root dir. If you want to make it really obvious, put a temp file in ENVARC: that's a meg or so in size.

I still think it not worth all this bother trying to fix something that isn't broken, just to save a hundred K of RAM.
Post Reply