@Hans That's strange. The env-handler.kmod on my SAM is exactly the same size as the one in my ?A1 and has the same version numer with a version date of 12/30/2006. It doesn't exibit the behavior I so desperately want. Is this another case of updates that were supposed to be included with a release but actually weren't?? Maybe we've been comparing apples and oranges.
xenic wrote: @Hans That's strange. The env-handler.kmod on my SAM is exactly the same size as the one in my ?A1 and has the same version numer with a version date of 12/30/2006. It doesn't exibit the behavior I so desperately want. Is this another case of updates that were supposed to be included with a release but actually weren't?? Maybe we've been comparing apples and oranges.
I just checked. The ENV handler on the Amiga OS 4.1 disk is version 52.2, with the same date that you quoted. However, that's the ENV handler; ENV variables (not def icons) are accessed via the DOS library, and the A1 Amiga OS release's dos library is version 53.3 (08/02/2008, in US date order, i.e., mm/dd/yyyy). We assumed incorrectly that the changes were made to the ENV handler, which is apparently wrong.
I still maintain that we know nothing about how these variables are stored/accessed internally. I also see the speed advantage in loading the (small) ENV vars in at once, or at least caching the file descriptors in memory. Most ENV variables are 10-50 bytes each, so loading them on-demand isn't the most efficient thing to do.
Either way, the change in behaviour that you observe is deliberate, not accidental.
I apologize I just check again my OS4.1 on my A1 and it *is* running the way Xenic is describing it works on the SAM. So there is no functional difference between the two, OS 4.1 for A1 & for SAM are working in the same way : doing a listing of ENV: lists every variable name there is in ENV-ARC:.
Although I agree with Hans : the fact env variables names are listed when doing a List ENV: does not necessarily means they are loaded in memory (but we have no way to say the contrary either). Xenic just think to FTPMount : when you are doing list FTP:ftp.freefr/ you *are* getting filenames lying on the remote ftp server ftp.freefr *but* it does not mean they have been loaded locally in whole, it might well be the same with env-handler.
@abalaban Actually, I think you can get a good indication of whether env-handler is maintaining a list or copying the files. Run Snoopy with all options activated and then request a variable that isn't listed in ENV: (In a shell enter something like "getenv xxyyzz). You will see in the Snoopy output that ENV looks for the variable in ENVARC:. Close Snoopy and reassign ENVARC: to an empty directory. Request a variable that is listed in ENV: (like Charset or Language) or copy a larger prefs file like "OpenURL.prefs" to ram: (copy ENV:OpenUrl.prefs TO ram:). If ENVARC: is assigned to an empty directory, the variable that was obtained or the file that was copied must have actually existed in ENV:.
OS4 ENV is not some magical mysterious black box; it's an AmigaDOS DEVICE with a custom filesystem handled by env-handler that responds to AmigaDOS commands like other DOS devices. Consider the case of programs that place prefs in ENV: when you selet "Use" instead of "Save". Obviously, those prefs must be stored in ENV: since they are usually different than the saved prefs in ENVARC:.
In theory, Hans is probably right when he states that it's more effecient to have small variables readily accessible in ENV:. I don't think that the original AmigaOS authors ever envisioned that so many programs would be storing their entire prefs settings in the environment (ENV:). However, that's what has happened. An extreme example is SuperView witch stores 237 variables and 5 sub-directories in env-archive (ENVARC:). If you own every commercial, shareware and freeware program released for Amiga and have saved prefs for them all, your SYS:Prefs/env-archive directory would probably be larger than the rest of your SYS: partition combined. That's why happyenv and env-handler were written; to allow programs access to their prefs without loading the entire env-archive directory into memory (ram:env) at boot time. The (public) OS4 env-handler no longer serves that purpose if it copies all the env-archive files to ENV: during a boot.
You could argue that programs shouldn't be storing large prefs files in the environment (ENV:) and I would agree. At most they should be storing a variable that points to the location of required files and prefs. In fact, I like programs that do it that way because I can relocate the files to anywhere I want.
I still maintain that we know nothing about how these variables are stored/accessed internally. I also see the speed advantage in loading the (small) ENV vars in at once, or at least caching the file descriptors in memory. Most ENV variables are 10-50 bytes each, so loading them on-demand isn't the most efficient thing to do.
I agree as far as small variables are concerned. Unfortunately, many (most?) programs store their entire set of prefs files in SYS:Prefs/env-archive and they don't really need to be in ENV: if you don't use those programs frequently. Since I'm apparently not going to convince anyone that the current OS 4.x ENV handling should be changed I won't beat this dead horse any longer.
Close Snoopy and reassign ENVARC: to an empty directory. Request a variable that is listed in ENV: (like Charset or Language) or copy a larger prefs file like "OpenURL.prefs" to ram: (copy ENV:OpenUrl.prefs TO ram:). If ENVARC: is assigned to an empty directory, the variable that was obtained or the file that was copied must have actually existed in ENV:.
Good point I agree with you, except if the variable (or the file) was previously accessed it should have been reloaded from ENVARC: which would not be possible if ENVARC: was reassigned to an empty directory.
However if the actual way of functioning is coupled with an adequate (and efficient) caching handling mechanism (able to flush unused things from ENV: in low memory situations) it can be some sort of optimization as Hans, and you spotted accessing multiple small files could be inefficient especially now that we have block size around 1 or 2 KiB...
Contrary to you, I'm all for preferences stored in ENVARC:/ENV: why ? because this might be easily used when/if we get multiuser support to stored user specific settings. I can understand your reticence because IIRC you are using a write protected SYS: partition (using C:Lock command) in order to assure yourself you keep a clean SYS:
EDIT: as far as I saw it's only things located at root of ENVARC: are copied straight forward to ENV: at boot time.
It's mentioned in autodocs that ENV-handler might change in future to use internal lists instead of a directory on a hard drive. I don't know if this is the plan still. Many developers (including myself) are using envarc: to store data and prefs. I've started lately to use progdir: instead but I've so many apps to change. And there's not a suitable dir in dir layout of AmigaOS to store settings files. I want to make all small apps that way that user can just drag the app and its icon to any dir without needing to run any installers or to change any assigns and modifying user-startup. That's why I like personally to use one global place for all settings files.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
TSK wrote: It's mentioned in autodocs that ENV-handler might change in future to use internal lists instead of a directory on a hard drive. I don't know if this is the plan still. Many developers (including myself) are using envarc: to store data and prefs. I've started lately to use progdir: instead but I've so many apps to change.
PROGDIR: isn't the right place either, because it means that you can't have per-user preferences. We've currently got a single-user system, but having multi-user as an option would be nice.
The truth is that ENV: is the best place to put prefs for now. It's already been shown with the deficons that some files can be treated differently from real ENV vars, so this could easily be extended to other file types, or a file-size limit used. Likewise, the files for most commonly used programs could also be pre-cached for speed.
My personal preference would be for a PREFS assign for preferences files.
You dont _have_ to use global variables, local variables also work fine.
Multiuser... I dont know what Hans means with multiuser. Remote shell logins? Graphical logins akin to rdp or xdmcp? Segmentation of security levels for different programs? What? In any case, the good old ENV: as system wide holder of system variables is needed, you cant have ENV: handled on a per user basis, as then there would be no place for system wide variables to go.
The multiuser question brings up so many new problems that would have to be taken care of anyways, it's kind of pointless to even bring it up in this discussion. These days it makes more sense to have OS4 run on virtualized machines anyways, so that each user can get his/her own system to play with. Funny bit is that I can in principle already do this with OS3.9 using Amithlon, UAE, Amiga Forever, and AROS. MorphOS and OS4 are still left out of virtualization party (along with OSX, allthough I do wonder how long Apple will sit on the fence and pretend they can commercially afford to not offer OSX for virtualized environments)
You dont _have_ to use global variables, local variables also work fine.
But programs do use global ENV variables for preferences.
Quote:
Multiuser... I dont know what Hans means with multiuser.
Multi-user as in individuals being able to log in and have their own preference settings used.
Quote:
In any case, the good old ENV: as system wide holder of system variables is needed, you cant have ENV: handled on a per user basis, as then there would be no place for system wide variables to go.
Actually, you could use ENV: as part of a multi-user system and still have global system variables too.
Quote:
The multiuser question brings up so many new problems that would have to be taken care of anyways, it's kind of pointless to even bring it up in this discussion.
Using PROGDIR: for preference files is only going to make the transition more painful, whereas storing prefs in ENV/ENVARC could allow the system to take care of per-user stuff.
Quote:
These days it makes more sense to have OS4 run on virtualized machines anyways, so that each user can get his/her own system to play with.
That's for a multi-user server, not a personal computer. Regardless, you still need to solve a lot of the same issues, whether you're offering simultaneous multiple remote access or not.
In any case, the good old ENV: as system wide holder of system variables is needed, you cant have ENV: handled on a per user basis, as then there would be no place for system wide variables to go.
Back under OS 3.0 and using muFS I managed, using scripts, to acheive this multiuser environnement using assigns to multiple dirs I managed to have a default system wide preferences *and* a user customized one. And even playing with directory order in multiple assign I was able to have the user modifying a default setting to obtain a user customized setting : a user with the default WB backdrop (using the one from SYS:Prefs/Env-Archive/sys/wbpattern.prefs) launching WBPattern would save (automatically) a new configuration into HOME:JohnDoe/Pres/Env-Archive/Sys/wbpattern.prefs) which will then become it's setting at each reboot.
In fact with the env-handler it's even easier : just modify it to first look for a file in a user specific place then if the file is not found look into the default system place (i.e. SYS:Prefs/Env-archive).
The libOpen return value is ignored the second time (and third and so on) that it's called.
This bug appears to affect a number of libraries. I tested several libraries by removing a library opened by them and the result was a crash the second time a program attempts to open the library being tested.
...Workbench doesn't remove the old icon... I think it's a hang-over bug from OS 3.1. I think it was corrected is OS3.9, but 'H' couldn't use that code. The other annoying OS 3.1 bug is the CD icon. You remove the CD, but the icon lingers! Open the CD and close it before removing the CD seems to work. I never noticed and HD and CD icon problems with OS3.9. Did you?
While testing how some libraries react to missing resources/libraries I noticed that Rexxmast crashes if rexxsyslib.library is missing. It should just fail with an error message. It needs be fixed.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
