Hello, Thanks for the mail, a good explanation of the story behind why it works as it does (using that COM as a kind of DOS-style LNK/PIF file.
Actually, there could be such a *Method 5*: a small TSR that hooks on DOS 21h/AH=4Bh that is able to execute a "LNK" file (or else go back to DOS), and place a LNK file (not COM) in such folder. It would be a good take to make FreeDOS aware of LNK files (but requires some hours of work on it). Aitor El mar, 29 nov 2016 a las 23:57, Mateusz Viste (<[email protected]>) escribió: > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-kernel >
_______________________________________________ Freedos-kernel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
