[Coco] OS-9 environment variables?

[Boisy Pitre]

Allen,

As you know, the traditional UNIX environment variables are a per- 
process feature.  A process inherits its parent's environment  
variables and can then change its own copy.  Those changes perpetuate  
down to children that it creates, and so on.

Modeling this feature in NitrOS-9 poses certain challenges.   
Specifically, the designer must determine where per-process  
environment variables are to be stored.

The most logical place to store per-process environment variables  
would be in the system RAM, with the process descriptor holding the  
reference, or pointer, to the memory where they are stored.

One design choice would be to commandeer a one byte page pointer in  
the process descriptor which would hold the 256 byte page in system  
RAM where the environment variables for that process would be stored.   
F$GetEnv and F$SetEnv system calls could be written to allow for the  
setting and getting of these variables.

The downsides to this approach are:

	- it would limit the total storage capacity for all environment  
variables to 256 bytes
	- it would use up 256 bytes for every process on the system  
automatically

Given that most processes probably wouldn't use environment variables,  
and given the amount of memory wasted, I would not recommend this model.

Another approach to consider is the storing of environment variables  
in a file.  This could be done on a system-wide basis like Multi-Vue  
does: one file holds system wide environment variables that anyone can  
change.

Another approach would be to store environment variables on a per- 
process basis, one file per process.  The F$Fork routine could be  
modified to copy its parent's environment variable file over to its  
own, and subsequent calls to F$SetEnv and F$GetEnv would set/get those  
environment variables to/from that file.  F$Exit would be modified to  
delete the file for that process.

The downside of the file-based approach is that it would be slow on  
floppy systems and would require disk access on every F$Fork, F 
$SetEnv, F$GetEnv and F$Exit.

Data modules have been mentioned as a possible candidate; for the per- 
process approach, this would require creating one data module per  
process.  The F$Fork would create the data module, the F$Exit would  
unlink it, and the F$SetEnv and F$GetEnv would set and get variables  
in it.

The downsides to this approach are:

	- 8K of System RAM would have to be free in order to map the  
appropriate data module into system RAM at F$SetEnv/F$GetEnv time.   
That may not be possible in many cases.
	- Potentially, many data modules would show up in the mdir output.

Because of the limited resources, no option is really optimal, and all  
require some degree of compromise.

Regards,
Boisy G. Pitre
--
Tee-Boy
Mobile: 337.781.3570
Email: boisy at tee-boy.com
Web: http://www.tee-boy.com

Regards,
Boisy G. Pitre
--
Tee-Boy
Mobile: 337.781.3570
Email: boisy at tee-boy.com
Web: http://www.tee-boy.com

On Apr 15, 2009, at 5:02 PM, Allen Huffman wrote:

> On Apr 15, 2009, at 11:39 AM, Roger Taylor wrote:
>> Is the data guaranteed to be there after hitting Reset?
>
> No. It would be like environment variables on DOS, etc. where they  
> are just named values you can set and read between programs.
>
> However, due to implementing it in a DATA MODULE on OS-9, there  
> would be the capability to write them to disk, and restore on the  
> next boot.
>
> RESET causes the system to reload, yes?
>
> GENE:
>> Tell me, is this going to be easier that having a file on disk (or  
>> in myram,
>> copied there by the startup script) along with a cron job to check  
>> & see if
>
> I was not planning any such thing. The user would be responsible for  
> saving data if it was important to them. What operating systems  
> provide environment variables that are maintained between reboots? I  
> have not worked with any that did that, so I didn't even know that  
> was an option.
>
> TIM:
>> Don't most OS's keep the environment variables in a file?   
>> like .profoile, .csh, .login .logout etc?
>
> Not that I know of. THose are read-only configuration files, read at  
> startup (like autoexec.bat) or shell start or login. Different  
> creatures.
>
> WILLARD:
>> getenv() and setenv() in the cgfx library read/write "environment
>> variables" from /dd/sys/env.file
>
> Willard shoots and scores! I did not know CGFX had those calls,  
> though during my CoCO days, I have never heard of getenv() and  
> setenv().  INTERESTING!
>
> Is that the stock Tandy version of CGFX, or the third party one?
>
> 			-- Allen
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco