ENVIRO.ACC & AUTOENVR.PRG (*) ===================================== Freeware by Pascal Fellerich ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PURPOSE: Use it to set the environment strings WHY? Environment strings are used to transfer some information to other programs. The desktop, the original COMMAND.PRG by Atari and the RSRC_LOAD function use these strings. The standard string is: 'PATH=;C:\' if you use a harddisk. Now, if you launch a program from an inactive window, it won't find it's RSC-file. If you had set the environment variable 'PATH=' to the right path, this would not have happened. An example: all your utility programs are in as folder called 'UTILITY', and most of your RSC-files are in a folder called 'RSC' - and now you set the environment the following way: PATH=;E:\UTILITY\;E:\RSC\;C:\ Now if you launch a program or try to find a resource file, the OS will use the paths specified after 'PATH='. Another feature: TOS has some functions to read and set the path for a clipboard-directory. Nowadays, there are some programs that use this feature (e.g. the GEMINI-shell). Simply type SCRAPDIR=X:\your\scrap_dir and ENVIRO.ACC will set this path using the AES-function SCRP_WRITE() IMPORTANT: The first variable must be 'PATH=;' - don't change it to avoid problems... AUTOENVR.PRG: must be in the AUTO-folder as this program installs a special buffer for the AES-environment. ENVIRO.ACC: Allows you to modify the current environment strings and sets the clipboard-path according to the environment variable 'SCRAPDIR='. This ACC runs also as a program, you only have to rename it. * NOTE *: if you want only the scrapdir being set, you do not need ENVIRO.ACC if you use the DESKTOP-BUTLER JAMES v1.5c or higher. DESKTOP.ENV: AutoEnvr searches in the root directory for a file called 'DESKTOP.ENV'. If not available, then he OS-default will be used. Technical Notes: ---------------- * AUTOENVR needs an entry in the 'cookie jar' of the OS. If there's already a cookie jar (TOS 1.6, POOLFIX 3&4 etc...) my program uses it; if there's none, it creates one. (logical, isn't it?) My entry is 'ENVR', and the value is a pointer to a longword-array containing pointers and some other data. DOC for programmers: -------------------- The Cookie: Entry: ENVR Data: Pointer to LW-array Array: ARR[0] = Pointer to the AES-Environment-Buffer ARR[1] = Length of the buffer ARR[2] = Pointer to E_INFO - function ARR[3] = " " E_SFIRST " ARR[4] = " " E_SNEXT " Functions: ---------- The functions are called like a normal C-routine. They return something in register d0. 1. E_INFO: C-Declaration: long e_info() CALL: C: version=e_info(); GFA: version%=C:e_info%() RETURN-VALUE: version: upper word: Release, lower word: rev. 2. E_SFIRST: C-Declaration: long e_sfirst(pattern) char *pattern; CALL: C: found=e_sfirst(pattern); GFA: found%=C:e_sfirst(L:V:pattern$) RETURN-VALUE: pattern: nukll terminated string containing the search-pattern. found: -1.L (failure) or pointer to matching string. 3. E_SNEXT: C-Declaration: long e_snext() CALL: C: found=e_sfirst(); GFA: found%=C:e_sfirst() RETURN-VALUE: found: -1.L (failure) or pointer to matching string. The search-string (pattern strin) must not exceed 20 chars. But it can be sa complicated as you want. There are two wildcards: '*' and '?'; they are used in exactly the same way as in TOS. An pattern string like ?*MS?D*?*O**S?* is valid! (Would return for example COMSPEC=D:\TOS\XYZ.PRG ^^ ^ ^^ Their further use is like the GEMDOS FSFIRST and FSNEXT functions. =====================================================================