Method 1 is the traditional DOS way of installing software. Maybe some advanced usage of JOIN & SUBST is what you are looking for?
Another alternative (though slightly messy) would be to combine Methods 1 & 4. By that, I mean, leave the *.bats in C:\DOS. The *.bats will temporarily create a new Environment & PATH extended as the application expects and then remove the adjustment. This will slow down many types of computing, as HPA mentioned, SW builds come to mind -L. On Tue, Nov 29, 2016 at 2:54 PM, Mateusz Viste <mate...@nospam.viste.fr> wrote: > On Tue, 29 Nov 2016 13:02:59 -0800, H. Peter Anvin wrote: >> But why the batch file in the first place? It truly makes no sense: it >> pollutes the namespace equally, and can just cause problems (e.g. in the >> case of more than 9 arguments.) Not to mention slowing down a make. > > Here's the thing: I, as a user, store lots of useful software on my PC. > Many of these programs are so useful that I like to have them available > immediately from anywhere: ZIP, UNZIP, UNRAR, UPX, NASM, TCC, OPTIPNG, > QV, MPXPLAY, UHEX, GOPHERUS, LAME... the list goes on and on. > > To achieve this, I know of four ways. Each comes with some limitations. > > Method 1: Store every program in its own directory, and add each > directory to the %PATH%. Problem: obviously the environment will get very > bloated, very fast. Besides, some programs come with add-on tools that I > do not want to be available from within my path. > > Method 2: Trim out the programs from everything besides a single exe, and > put them all in a single directory declared in my %PATH%. But this poses > two problems that I cannot live with: first, not every program can be > trimmed out to a single executable file (data files, config files, etc), > and second - almost all programs come with their respective README files > and other valuable documentation that I really want to keep within the > vicinity of the executable (ie. in the same directory). > > Method 3: Store each tool in its own directory, and place a COPY of its > executable inside a directory in the %PATH%. Well, this is just messy - > upgrading the program needs to think about replacing the executable each > time in both places, and it's simply a waste of disk space. > > Method 4: Keep each program in its own directory with all its original > files, and only store *.bat "links" in a single directory somewhere in > the PATH. This mitigates the troubles of methods 1 and 2, at the cost, > unfortunately, of *.bat's own limitations (max 9 args and '=' processing > weirdness). > > The method 4 is what I started doing back in the nineties, and as of > today I still didn't find a better (or let's say, less worse) way. That's > a lifetime project it would seem. > > The method 4 is also something that I implemented last year inside FDNPKG > (the FreeDOS package manager), but since I discovered recently how oddly > the '=' character is processed in %1-like arguments (there's a separate > thread about that on freedos-devel), I will have to figure out some > improved method... first thought pointed to computing some COM loader > relying on INT21,4Bh but that's far less trivial than the current batch > method, and hobby time is scarce. > > Mateusz > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-kernel ------------------------------------------------------------------------------ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
