Mail Archives: opendos/1997/05/08/14:40:49
On Wed, 7 May 1997, Benjamin D Chambers wrote:
> Ooh, ooh, Me just had think!
> (Watch out, folks, this could get ugly :)
>
> Say you have the following set up:
>
> (The following are either ENV vars or retrieved through an int call or
> _something_)
>
> OS_DIR
> SHARED_LIBS_DIR
> GAMES_DIR
> DRIVER_DIR
Or, *like we already discussed*, we could put the directories into a file
(paths.dir). This would look something like:
[app]
c:\dosapps
d:\dosapps
[utility]
c:\util
#this is a comment
[temp]
c:\temp
e:\ #E: is my RAM disk
[download]
c:\receive
Where different users would put in their own directories. Then, we create
a library to read paths.dir. Finally, a program that uses this library to
find the directories it wants. A comm program could would up "download"
to find where to put downloaded files. The proposed OpenDOS package
manager, would use these entries to determine where to install files.
This list has been around for a while now. There's alot that's been
discussed. Instead of re-inventing the wheel every two months, I'd
encourage you to read the mailing list archives
(www.delorie.com/opendos/archives) and build from what's already been
discussed.
[snip]
>
> It could, say,
> Error: TMP_DIR not set.
> 1 - Abort
> 2 - Enter path manually
> 3 - Enter path and set to TMP_DIR
> 4 - Use another FSSTND path
>
> The last one would give you a list of the paths you have set, so you just
> hit the number of the one you want!
>
> If grabbing the paths is an OS call, this could be part of the call - the
> program itself wouldn't have to do anything :)
Which would have the side-effect of plastering that over whatever pretty
interface the programmer made. You could let the *program* choose from
those options (and have it get the needed user input itself).
- Raw text -