Creating aliases in DOS...
Joel M. Hoffman
>A few times I think it would be nice to be able to create "Alias" files
>under DOS. What I mean is a file that's basically a pointer to another
>file. This could be extended to subdirs as well.
In terms of aliased commands (like the csh `alias' feature), all you
need are .bat files. If you want to create an alias for a built-in
command, you have to edit command.com's internal command table.
I took this latter step to make `del' an alias for `copy %1 \tmp' so
that I can >really< undelete anything I want. I changed the DEL in
the command table to RM!, so I can still access the real DEL command
for cleaning up \tmp when I have to.
-Joel
(jo...@wam.umd.edu)
Raj Manandhar
In terms of aliased commands (like the csh `alias' feature), all you
need are .bat files. If you want to create an alias for a built-in
command, you have to edit command.com's internal command table.
Well, there's always CED (an old, free TSR, which works up to DOS 3.3
at least). It gives you command recall, aliases (for built-in commands
too), and a few other nice things like that. A lot easier than editing
command.com :). It can be found on archives somewhere.
Raj
--
Raj Manandhar +1 617 495-8348 or -2038 r...@cfa272.harvard.edu
Harvard-Smithsonian Center for Astrophysics ...!harvard!cfa272!raj
60 Garden Street, Cambridge, MA 02138 raj%cfa...@cfa.bitnet
Raymond Chen
If you actually read the body of his article, you'll find that what he
really wants is soft links.
The program (which does pretty much what Mr. Wallace suggests it could do)
is called f-link, available, I believe, from garbo.
Aaron Wallace
under DOS. What I mean is a file that's basically a pointer to another
file. This could be extended to subdirs as well.
First, if this has already been hacked, I'd be interested in such a beast.
The "simple" solution seems to be:
Aliases are normal DOS files with special contents which would never appear
in a real file (i.e. .ALIASXX etc). A TSR would trap calls to the
various calls that open files, and if the file is an alias, the "real"
file's path is read (from the alias file) and this file is opened/executed
instead. This switch might confuse apps.
For a directory alias, the
"fake" directory could have an improbable file as its first entry, such
as XXALIAS.FAK, which contains the real path.
Does such a program seem possible? The only "pain" would be in the recursive
parsing of pathnames, but that wouldn't be too bad. Would this break too
many applications?
Anyone wanna write it? (I would, but there's only so much time...)
Aaron Wallace
Tony Porczyk
>A few times I think it would be nice to be able to create "Alias" files
>under DOS.
4DOS has had aliasing under DOS for a long time. You might wanna take a
look at it before reinventing the wheel.
T.
Daniel L'Hommedieu KD4CYH
semicolon form for multiple commands on a single line. I would
recommend the purchase of Anarkey. It is ftpable from
wuarchive.wustl.edu and exists as /mirrors/msdos/keyboard/anarkey4.zip,
or some close derivative. A registered copy is $40 (or so) and it gives
DOS such capabilities as: aliases, multiple commands/command line, and
file-name completion.
Daniel L'Hommedieu / ea...@catt.ncsu.edu / KD4CYH on 146.88- in RTP
--
As the sweat poured down my forehead, I quickly glanced at the clock to
see how much longer I had to complete my exam. The two hours left would
seem like days. As each precious second passed, I decided I should make
up new math rules. Two hours is enough to be creative, isn't it?
Joel M. Hoffman
>In article <1991Oct2.0...@wam.umd.edu> jo...@wam.umd.edu (Joel M. Hoffman) writes:
>
> In terms of aliased commands (like the csh `alias' feature), all you
> need are .bat files. If you want to create an alias for a built-in
> command, you have to edit command.com's internal command table.
>
>too), and a few other nice things like that. A lot easier than editing
Actually, it's not as much of a hassle as one might think. When I got
DOS 5.0 (and had to re-edit command.com), it took me less than 5 min.,
using BPE (Binary Patch Editor). I just searched for the strings and
modified them....
-Joel
Bob Davis
>>A few times I think it would be nice to be able to create "Alias" files
>>under DOS. What I mean is a file that's basically a pointer to another
>>file. This could be extended to subdirs as well.
>
>In terms of aliased commands (like the csh `alias' feature), all you
>need are .bat files. If you want to create an alias for a built-in
>command, you have to edit command.com's internal command table.
>
The original poster, Mr. Wallace, seemed to me to mean 'symbolic link'
in asking to have one file simply be a pointer to another file. However,
he used the term 'alias' to refer to this pointer file, and 'alias'
most often has the meaning assumed by the respondents -- that of being
able to call any command by another name. 4DOS and the excellent, older
Freeware program, CED, provide the very useful 'alias' facility.
For some reason which I do not know, it evidently is difficult
to provide the 'symbolic link' capability in the DOS filesystem.
Several times I have read words to that effect.
I have often wanted such a capability of having the symbolic link
file simply point to another file. If someone reading this can give
the nickel (as opposed to the dollar) explanation of the difficulty,
in providing DOS symbolic links, I would like to read it.
Seems I have read of a DOS program called F-LINK which embodies
a first step at providing symbolic links. Anyone know of its availability
and effectiveness?
_____________________________________________________________________________
Bob Davis, UofALA alum \\ INTERNET: so...@trantor.harris-atd.com | _ _ |
Harris Corporation, ESS \\ UUCP: ...!uunet!x102a!trantor!sonny |_| |_| | |
Advanced Technology Dept.\\ AETHER: K4VNO |==============|_/\/\/\|_|
PO Box 37, MS 3A/1912 \\ VOICE: (407) 727-5886 | I SPEAK ONLY | |_| |_| |
Melbourne, FL 32902 USA \\ FAX: (407) 729-3363 | FOR MYSELF. |_________|
Chris Waters
>Actually, it's not as much of a hassle as one might think. When I got
>DOS 5.0 (and had to re-edit command.com), it took me less than 5 min.,
>using BPE (Binary Patch Editor). I just searched for the strings and
>modified them....
It may not be much hassle to edit COMMAND.COM, but it can be dangerous,
especially for the unskilled (though I suppose that eliminates most of
the people here <smile>). But a solution like using 4DOS or CED provides
a much more complete, robust, and generally useful mechanism for using
aliases. Especially 4DOS, which is a tool that no msdos programmer should
be without IMO.
4DOS is a program that ALMOST makes software development under msdos
bearable. After my editor, I consider it the most useful thing on
my disk.
--
Chris Waters | Calvin: I wonder why man was put on earth.
aka | What's our purpose? Why are we here?
xt...@netcom.COM | Hobbes: Tiger food.
Morgan Schweers
Okay, another programmer and myself have been beating our heads against
this very problem for a Long While (TM).
Here's the set of things that have to be overcome, to provide proper links:
File Size (as reported by FindFirst and FindNext must be correct), Open calls
(both FCB and Handle) must be properly parsed and returned to the calling
program, but accessing the linked file. CHKDSK must not scream and yell and
cry bloody murder. Cross-drive links should be supported (I.E. my X.COM file
on C:\UTILS should be able to link to D:\UTILS\XYZZY.COM). Application
programs of all flavors should see these files as normal files. Attributes
should be preserved, and changes to attributes should be made to both files.
(That one is questionable... Any comments?) Last, but certainly not least,
some provision should be made for circumstances in which the software that
handles the links is *NOT* in memory. (I.E. Person boots from an original
DOS diskette... What happens when they try to copy a linked file? What
*SHOULD* happen?)
With all of this in mind, it shouldn't be too hard to start running
through the scenarios and realize that complete compatibility is almost
impossible. Heck, even one of my favorite ideas is almost impossible...
A linkable directory. At the end of the directory (through FindFirst and
FindNext) it chains to another directory, which could chain to another, and
so on, and so on... This would allow me to place *ONE* \UTILS directory in
my path, and have it chain to all the other ones... (I have a \UTILS directory
on *EVERY DRIVE* except my floppies... and a few of those, too.)
One of the main problems *IS* not making CHKDSK scream... If it weren't
for that, I could simply crosslink files! (Heck, a zero-byte .EXE file
crosslinked to a zmodem program should work fine!) However, if the user can't
use CHKDSK or NDD without fear of trashing hir files then the user is suddenly
without a few *VERY* valuable tools...
Anyhow, I'm open to suggestions. I'll admit that I have the low level
experience to do this... The only real problem for me is that Microsoft
hasn't created a real file system for their machines yet. If they had, then
I wouldn't have to worry about this garbage. *sigh* (In fact, I would be in
an entirely different field, being that viruses would no longer exist!)
I'm willing to work with someone in playing out this idea, but my brain
got stuck after about a week of verbally rapping this out with another
programmer...
-- Morgan Schweers
--
m...@netcom.com | Morgan Schweers | Happiness is the planet Earth in your
m...@gnu.ai.mit.edu| I hate disclaimers| rear view mirror. -- Jeff Glass
Freela @ Furry | but I often say +--------------------------------------
K_Balore @ Furry | things that others| I'm a practicing furry! Some day
-----------------+ don't like, so... | I hope all this practice will pay off
IT'S NOT COMPANY OPINION. So there. | and I'll grow fur! -- me
phy...@csc.canterbury.ac.nz
the way that the Unix-world "csh" shell (plus good old CED & 4DOS) understand
the word, but that isn't what the original poster wants. To implement links
(hard or soft, in Unix parlance), or logical name definitions (in DECspeak),
there are a few possibilities for MSDOS...
(1) Hard links. Simply have the "starting cluster" of the link point to the
same starting cluster the original file points to. There are big limitations
here:
(a) CHKDSK reports links as being "cross-linked" and might try to "fix" them;
the solution is to assign some otherwise-unused bit in the attribute byte
of the link to say it is a link (e.g. the MSB, but that might clash with
some networking software, or some otherwise illegal combination like
VolumeID+ReadOnly).
(b) What if the original file's size or attributes change? The link's won't
change automatically. Even if you patch the operating system to do so,
the system won't be able to know where all the links are, without a very
inefficient search of all directories on the disk.
(c) If you link to a directory, the ".." entry will be wrong. Not a huge
problem, perhaps (try, in Unix, changing to a linked directory, then do
a cd ..).
(d) You can only link to files on the same hard disk partition. Again, a
limitation you can live with.
(e) You might try to update the same file by two different programs; SHARE
would have to be made cleverer. Of course, making any file that is linked
(and all of the links) read-only solves this problem (and (b)).
2. JOIN/SUBST/ASSIGN. Notice DOS already has the ability to call a drive by an
alternative drive name, or by a directory name, or a directory by a drive name.
But not a directory by a different directory name, nor any file in general by
another name. It might not be all that difficult to extend the existing code to
do this, although I suspect it is (since it hasn't been done before!), and JOIN
at least has some side-effects for some software - these tools are generally
used only to aid old stupid software that isn't versatile enough, although I
personally like the idea of giving drive names to important directories, to
remove local differences between machines. The main problem with this method is
that it is up to Microsoft or Digital Research to implement it; from what I've
seen of these facilities, they vary from version to version, so if you could
write a program to do it, it might not work on more than one version of DOS.
3. Soft Links, where the file name of the resolution of the link is the "data"
in the link's file. This can only work if significant changes are made to the
operating system, but such changes are similar to what network software, and
perhaps the JOIN, SUBST, and ASSIGN mentioned above do. There are some
differences, though, which mean it might be difficult to use existing hooks
that allow selected drives to be processed by installed software, but the
"clumsy" method of intercepting all int 21h calls would still work. But it
takes a lot of work to make links look and feel right to the software (such as
looking up the true size and attributes).
The last option is my personal favourite. The advantages are:
* on a system without special link software, the links look like moderately
normal files; they can be deleted and edited as text files (well, that might
not be possible if you use odd attributes, as mentioned in 1(a)). Of course,
they then only appear to be little text files, not the file they point to.
* You can point to files on other disks.
* You can delete the resolution of the link (or create it later), without
severe system hiccups.
* Links can have creation dates and attributes of their own. Personally, I
like the idea of links' attributes being logically "OR"ed with those of
the resolution file, and something sensible would have to be done to pass
the 6 password bytes used by DRDOS over to the link.
* If you delete the link, you don't change the resolution file's directory
entry.
* You could have links to links to links.
* Once the file is open, it is as efficient is using the original file.
* You can have links names as long as you like. (compare with Data General's
RDOS links, where the resolution name had to fit in the rest of the dir
entry. Not a big limitation there, perhaps, because of the way directories
were handled). The other side of the coin is that you waste a whole
cluster (perhaps several thousand bytes) on the name, no matter how long it
is. That might not be bad on modern compressed drives (like STACKER and the
SSTORE facility in DRDOS 6).
* No problem for CHKDSK.
* Good for virus protection; the originals can be in a write-protected
partition, and the links in whatever work partition is convenient. Most
viruses refuse to attack files shorted than a certain length (most of the
links would be safe), and even if they were "infected", it would just be
the name, which the linking software would quickly identify as being
invalid.
If anyone else wants to join forces with me to implement such a thing, let me
know...
Bye,
Mark Aitchison, Physics, University of Canterbury, New Zealand.
John R. Levine
DOS 5.x, I made much the same case for symbolic links, i.e. implementation
is straightforward and they're quite useful. MS agreed they were useful
but the backwards compatibility implications were so bad they didn't want
to do it. Bummer.
--
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 492 3869
jo...@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl "You can take the
girl out of New Jersey, but you can't take New Jersey out of the girl."
Morgan Schweers
Okay, a bit of crow-eating is in order for myself here... I posted that
it was difficult, nigh onto impossible to create a soft-link system for MS/DOS.
After I was besieged by a bignum of people who desired it, I began thinking
about the nature of reality. Surely, if so many people want something that
badly, and so many of them feel that there *MUST* be someway to do it under
MS/DOS, perhaps reality will adjust itself...
Sho 'nuff. Here's the solution. I may or may not have time to implement
this myself, but I would kinda appreciate being mentioned if any does decide
to implement it. (As the Stone Soup Group says. Don't want money. Got
money. Want ADMIRATION!) *grin*
Actually, the idea is *NOT* complete as there is a *WEE* bit of a
problem, that I would *LOVE* for someone to suggest a quick (or not so quick)
fix for. The full idea is at the end of the document. I'd *MUCHO* appreciate
it if any serious DOS Guru's would take a look, and see if they have a
way around the end-predicament. It's really something which *SHOULD* be
get-around-able, but I'm not 100% sure.
First my comments on phys169's comments... (Who was one of the people
who sent me e-mail saying that there *MUST* be an answer.) His idea is a
really neat one, but involves opening the files to find the link-to
location. This feels kludgy to me, but in the end it may be the only
solution... *sigh*
Oh, by the way. It's 3am, I've been up *WAY WAY* too long, and I'm
slightly high on whatever fatigue poisons get into my body after more than
24 hours of awakitude... I think I'm technically competent at this hour,
though...
Some time ago phy...@csc.canterbury.ac.nz happily mumbled:
>It is possible to pre-process command lines in DOS to implement "aliases" in
>the way that the Unix-world "csh" shell (plus good old CED & 4DOS) understand
>the word, but that isn't what the original poster wants. To implement links
>(hard or soft, in Unix parlance), or logical name definitions (in DECspeak),
>there are a few possibilities for MSDOS...
Feh. The incredible facility of the :== operator under DCL has yet to
be implemented under DOS. (I'd *LOVE* the concept of "DI*R :== DIR")
Aliases as yet are straight text replacement schemes, and don't have any real
parsers in place yet.
As for logical name definitions, I'm hoping that this will pave the way
for something similar...
>(1) Hard links. Simply have the "starting cluster" of the link point to the
>same starting cluster the original file points to. There are big limitations
>here:
> (a) CHKDSK reports links as being "cross-linked" and might try to "fix" them
This is a bigtime problem. Perhaps the biggest, in fact.
> (b) What if the original file's size or attributes change? The link's won't
Ahh, happily I have a solution for this. (At least I think I do.)
> (c) If you link to a directory, the ".." entry will be wrong. Not a huge
> problem, perhaps (try, in Unix, changing to a linked directory, then do
> a cd ..).
Actually, it makes for some interesting images of the disk hierarchy!
> (d) You can only link to files on the same hard disk partition. Again, a
> limitation you can live with.
Ahah! This I can get around!
> (e) You might try to update the same file by two different programs; SHARE
> would have to be made cleverer. Of course, making any file that is linked
> (and all of the links) read-only solves this problem (and (b)).
*vigorous shake of head* You want opens to all be redirected to the one
file, so Share, etc., still understand things like they normally would.
>2. JOIN/SUBST/ASSIGN. Notice DOS already has the ability to call a drive by an
>alternative drive name, or by a directory name, or a directory by a drive.
Ick. I've disassembled Join and Subst, in the effort to do this some time
back. The idea didn't strike me then, but now... *heh heh heh*
>is that it is up to Microsoft or Digital Research to implement it; from what
>I've seen of these facilities, they vary from version to version, so if you
>could write a program to do it, it might not work on more than one version of
> DOS.
True, true, but I think it's time to give up on version 2.1 users. The
version is around six years old, and three major upgrades ago. My idea will
only work on DOS 3.1 and up. However, I believe it is compatible with the
OS/2 Compatibility box and DR-DOS. (Though I haven't checked DR-DOS yet.)
>3. Soft Links, where the file name of the resolution of the link is the "data"
>in the link's file. This can only work if significant changes are made to the
>operating system, but such changes are similar to what network software, and
>perhaps the JOIN, SUBST, and ASSIGN mentioned above do. There are some
>differences, though, which mean it might be difficult to use existing hooks
>that allow selected drives to be processed by installed software, but the
>"clumsy" method of intercepting all int 21h calls would still work. But it
>takes a lot of work to make links look and feel right to the software (such as
>looking up the true size and attributes).
I have this urge to say, "Ick, ick, ick! No, no, no!" I've felt
from the beginning that the only solution is to have a database of
filenames which are compared against a (this is where my mistake was)
file access and translated. My mistake was for the longest time that I
believed that I should trap it at the 'file open' and such level. However,
there is a deeper wave than this... rising in the land. There is a deeper
wave than this, listen to me, mon! *grin*
After all, just trying to access this file would require a number of
opens, reads, verifications, etc., etc. The best option would be to do
something (ANYTHING) which let you get the needed info without opening
the file.
>The last option is my personal favourite. The advantages are:
> * on a system without special link software, the links look like moderately
> normal files; they can be deleted and edited as text files (well, that might
> not be possible if you use odd attributes, as mentioned in 1(a)). Of course,
> they then only appear to be little text files, not the file they point to.
Hmmm... The problem is, as you describe below, that they always will take
up space. (Minimum of a cluster, and a cluster minimum on an HD is 2K...) If
you can avoid that, it'd probably be a good idea. (After all, the links could
get hairy, taking up that much space.)
> * You can point to files on other disks.
Doable with my idea as well. (Relax folks, it's at the end of the message.)
If no solution can be found to the minor problems I put forth in my message
below, perhaps a counterbalance solution would work.
> * You can delete the resolution of the link (or create it later), without
> severe system hiccups.
With a bit of 'verification' code in the memory resident portion
of the link handler, it could easily wipe out a 'link' file which was
pointing to a certain no-deleted file as soon as it is accessed. (Or
upon startup, if it would work better... Implementation details,
implementation details... *grin*)
In any case, perhaps a cross between a in-memory (or on-disk) database
of links, and links built into the files would work... One simply says which
files *ARE* the links, and the actual link files would contain the links.
I'd *REALLY* like to find an answer to the technical problems I pose below,
however. That would be the least pessimal solution. (The most optimal
solution would be to go over to Unix. *sigh*)
> * Links can have creation dates and attributes of their own. Personally, I
> like the idea of links' attributes being logically "OR"ed with those of
> the resolution file, and something sensible would have to be done to pass
> the 6 password bytes used by DRDOS over to the link.
I'm hoping to get my hands on the DR-DOS Technical Reference Manual,
so I can solve interesting little problems like this one. *Grin*
> * If you delete the link, you don't change the resolution file's directory
> entry.
This should never be necessary. It would probably be a Neat Feature to
keep track of inodes pointing to the file, and... Whoops! Slipped into
Unix for a moment. Sorry 'bout that!
> * You could have links to links to links.
Ooooh... Okay, that's a toughie. I'd say that the link-creation
software has to prevent this by silently passing the link on to the
original. That's easy enough with my algorithm, as well as with
yours. Thus if you linked to a link, the link software would
determine the *REAL* file, and link to it. If you had links-to-links-to,
etc., you'd have a *REALLY* slow file open on one end... *grin*
> * Once the file is open, it is as efficient is using the original file.
Yupyup. Without a doubt this is a *VERY* important point! Any loss of
efficiency would be a Bad Thing. Thus, we have to catch the system at the
earliest point possible, to do the substitution.
> * You can have links names as long as you like. (compare with Data General's
> RDOS links, where the resolution name had to fit in the rest of the dir
> entry. Not a big limitation there, perhaps, because of the way directories
> were handled). The other side of the coin is that you waste a whole
> cluster (perhaps several thousand bytes) on the name, no matter how long it
> is. That might not be bad on modern compressed drives (like STACKER and the
> SSTORE facility in DRDOS 6).
Ahhh, this can be dealt with by making the filesizes zero bytes, and having
the information stored in a central file or kept in memory.
> * No problem for CHKDSK.
This too is, as mentioned before, an extremely important result!
> * Good for virus protection; the originals can be in a write-protected
> partition, and the links in whatever work partition is convenient. Most
> viruses refuse to attack files shorted than a certain length (most of the
> links would be safe), and even if they were "infected", it would just be
> the name, which the linking software would quickly identify as being
> invalid.
Now there's an interesting concept... I'll have to look into whether
viruses infect prior to or after name resolution... I would guess that
it's before name-resolution, which would have some interesting side-effects.
>If anyone else wants to join forces with me to implement such a thing, let me
>know...
You know I'm interested! *grin*
Okay, here's my tentative solution. (A bit of this has been code-tested,
and produced some *FUN* results!)
The basic concept is the undocumented function call, Int 2F, function 11h,
subfunction 23h. This function is the network redirector name resolution
function. (It can be found on page 619 of your Undocumented DOS book. What,
you don't *HAVE* it? Tsk tsk! It's published by Addison Wesley, authored
by Schulman, Michels, Kyle, Paterson, Maxey, and Brown. ISBN 0-201-57064-5.
This project is almost impossible without it.)
(To test this idea out, you can make a *VERY* small assembly
language routine which traps Int 2Fh, function 1123h. Then it should
do a string compare with a hardcoded filename, and if it matches, it
should change it to a different hard coded file name. Run this, and
try to access the first hardcoded file. It's interesting! Many of
the errors one can make while writing a piece of code like this are
interesting too! Trust me... *grin*)
The idea behind my concept of links is this... Your memory
resident program traps this function. Since this function is passed
an UNRESOLVED name, you have to pass it onwards, and deal with things
when the value is returned. On the return pass, you may have a
resolved name pointed to by the ES:DI registers. This resolved name
can then be compared against a list of fully resolved pathnames, in
the search for a match. If there is no match, the program returns the
values, and lets the OS go on its merry way.
If, however, there is a match then the resolved pathname gets replaced
by the link-destination pathname.
Now, the only solid problem with this is that DOS is not reentrant.
This problem comes into play when one considers that we *MUST* have a
fully resolved pathname to work with. If we don't have a fully resolved
pathname, then our compare could falsely assume that a program is a link,
when in fact it's only named similarly. Moreover, we could miss links that
are on 'non-standard' areas. (I.E. Subst, Join, etc.)
Now, this would be relatively short work for a reentrant operating system.
However, under DOS, our modification gets serious here. At this point it would
be best to call the 'TRUENAME' function call. (That's Int 21h, function 60h,
sportsfans!) However, since we're almost certainly already in a DOS function
call, the main question we need to ask is how to get around it?
One of the options presented here is to call the Int 2Fh, function
12h, subfunction 21h. (Canonicalize file name) This however, is a
'nono' according to the undoc'ed DOS book. It suggests that this is an
'INTERNAL DOS ONLY' function call. *sigh* Is nothing easy in this world?
*grin*
Now, to be frank, I haven't had time to *TRY* calling INT 21h,
subfunction 60h, to see if it's actually one of those 'safe' routines.
If it is, that would be excellent. If not, I'm asking for suggestions
on how to call the Int 2Fh, function 1221h from within a TSR... (If
either of these problems can be solved by anyone, then the rest of the
problem falls into place.)
The one things that I *DO* know is that Int 21h, function 60h calls
Int 2F, function 1123h. This means that you'll have to have your own
reentrant-testing code, which passes the request onwards in case you are
already in control.
A similar problem will need to be solved for any reasonably subtle
method of soft linkages.
Now, for certain areas of the system, there's an even easier way of
doing the entire schtick. There are some areas of the system that do an
actual 'TRUENAME' before accessing the files. This means that they call
the INT 21h, function 60h before opening the file. For these calls (I
believe the DOS COPY command is one of them) you could trap the said call
(INT 21h, function 60h), let the call execute, match the resultant name
against a table, and patch as necessary. This situation has no such
problems as I described above, in dealing with reentrancy, since it's a
far-outer-interface.
The INT 2Fh, function 1123h is a deep majik interface, and is going
to need some work in figuring out how to make it play nice.
Any help is appreciated!
>Bye,
>Mark Aitchison, Physics, University of Canterbury, New Zealand.
-- Morgan Schweers
P.S. Yeah, yeah, I'm excited. It's the closest I've come to solving
this damned problem in a long LONG time. Now I'm down to bare
metal, and I need someone who knows more than me. Hey Ralf,
you got a minute? *grin*
Ralf....@b.gp.cs.cmu.edu
} Okay, a bit of crow-eating is in order for myself here... I posted that
}it was difficult, nigh onto impossible to create a soft-link system for MS/DOS.
}After I was besieged by a bignum of people who desired it, I began thinking
}about the nature of reality. Surely, if so many people want something that
}badly, and so many of them feel that there *MUST* be someway to do it under
}MS/DOS, perhaps reality will adjust itself...
It's already been done and has been posted to the net a coupla times
(though I forget the name); the program stores links as files whose data
contains a magic header and the destination of the link (BTW, Unix
stores a soft link as a file whose contents is the destination of the
link).
}Some time ago phy...@csc.canterbury.ac.nz happily mumbled:
}>It is possible to pre-process command lines in DOS to implement "aliases" in
}>the way that the Unix-world "csh" shell (plus good old CED & 4DOS) understand
}
} Feh. The incredible facility of the :== operator under DCL has yet to
}be implemented under DOS. (I'd *LOVE* the concept of "DI*R :== DIR")
Try
alias di*r *dir
under 4DOS or NDOS. Once again, it's just the braindead COMMAND.COM
that can't do it.... (the second asterisk is to prevent alias expansion
of the result)
}> (e) You might try to update the same file by two different programs; SHARE
}> would have to be made cleverer. Of course, making any file that is linked
}> (and all of the links) read-only solves this problem (and (b)).
}
} *vigorous shake of head* You want opens to all be redirected to the one
}file, so Share, etc., still understand things like they normally would.
The program I mentioned above has just that effect: since it's a wrapper
for INT 21h, the file actually opened in response to a file open call is
the final destination of the link.
}> * You could have links to links to links.
}
} Ooooh... Okay, that's a toughie. I'd say that the link-creation
}software has to prevent this by silently passing the link on to the
}original. That's easy enough with my algorithm, as well as with
}yours. Thus if you linked to a link, the link software would
}determine the *REAL* file, and link to it. If you had links-to-links-to,
}etc., you'd have a *REALLY* slow file open on one end... *grin*
That slowness is one of the reasons most implementations of Unix put the
limit on soft link traversals during name resolution at only 8. (Some
limit is needed due to the possibility of loops, since a soft link can
point higher in the directory tree than it is itself)
} Now there's an interesting concept... I'll have to look into whether
}viruses infect prior to or after name resolution... I would guess that
}it's before name-resolution, which would have some interesting side-effects.
Since the links are supposedly software-transparent, the virus would
infect the destination of the link.
} The basic concept is the undocumented function call, Int 2F, function 11h,
}subfunction 23h. This function is the network redirector name resolution
}function. (It can be found on page 619 of your Undocumented DOS book.
}
} The idea behind my concept of links is this... Your memory
}resident program traps this function. Since this function is passed
}an UNRESOLVED name, you have to pass it onwards, and deal with things
}when the value is returned. On the return pass, you may have a
}resolved name pointed to by the ES:DI registers. This resolved name
}can then be compared against a list of fully resolved pathnames, in
}the search for a match. If there is no match, the program returns the
}values, and lets the OS go on its merry way.
}
} If, however, there is a match then the resolved pathname gets replaced
}by the link-destination pathname.
}
} Now, the only solid problem with this is that DOS is not reentrant.
}This problem comes into play when one considers that we *MUST* have a
}fully resolved pathname to work with. If we don't have a fully resolved
}pathname, then our compare could falsely assume that a program is a link,
}when in fact it's only named similarly. Moreover, we could miss links that
}are on 'non-standard' areas. (I.E. Subst, Join, etc.)
You'll also miss file accesses made via FCBs, which will be a problem
since COMMAND.COM uses them for renaming and deleting files. If you use
a database of name associations to implement links, it will no longer be
correct after a rename or delete from the DOS prompt.
} Now, this would be relatively short work for a reentrant operating system.
}However, under DOS, our modification gets serious here. At this point it would
}be best to call the 'TRUENAME' function call. (That's Int 21h, function 60h,
}sportsfans!) However, since we're almost certainly already in a DOS function
}call, the main question we need to ask is how to get around it?
}
} One of the options presented here is to call the Int 2Fh, function
}12h, subfunction 21h. (Canonicalize file name) This however, is a
}'nono' according to the undoc'ed DOS book. It suggests that this is an
}'INTERNAL DOS ONLY' function call. *sigh* Is nothing easy in this world?
Since the network redirector should only be called by DOS (it expects
various DOS data fields to be set), you will already be inside a DOS
function call. I'm not sure whether that will work properly, though,
since 2F/1221 may wind up clobbering the storage (but not the stack)
used by the original DOS call which invoked INT 2F/1123 (any DOS call
that takes a path). You'd have to try it. Calling INT 21/60 will
definitely NOT work, because it will overwrite the internal stack used
by the file access call.
} The one things that I *DO* know is that Int 21h, function 60h calls
}Int 2F, function 1123h. This means that you'll have to have your own
}reentrant-testing code, which passes the request onwards in case you are
}already in control.
That's because the latter is the mechanism by which network redirectors can
override the default DOS name resolution. INT 21/60 calls INT 2F/1123 to
resolve the name; if and only if that call fails does DOS resolve the name
itself. All other DOS calls which take pathnames call the function that
implements the INT 21/60 call.
} Now, for certain areas of the system, there's an even easier way of
}doing the entire schtick. There are some areas of the system that do an
}actual 'TRUENAME' before accessing the files. This means that they call
The only one I know of is COMMAND.COM. It calls TRUENAME to make sure
that you aren't trying to copy a file onto itself. However, it does not
use the returned names for opening the source and destination files, as
the returned values may not be valid given the current JOINs, SUBSTs,
etc. For the same reason, no other software uses TRUENAME's result to
access files unless they are going through an indirect server call (INT
21/5D00) anyway.
}P.S. Yeah, yeah, I'm excited. It's the closest I've come to solving
} this damned problem in a long LONG time. Now I'm down to bare
} metal, and I need someone who knows more than me. Hey Ralf,
} you got a minute? *grin*
That's about all I have.... :-)
--
{backbone}!cs.cmu.edu!ralf ARPA: RA...@CS.CMU.EDU FIDO: Ralf Brown 1:129/26.1
BITnet: RALF%CS.CMU.EDU@CARNEGIE AT&Tnet: (412)268-3053 (school) FAX: ask
DISCLAIMER? Did | "Secrecy is the beginning of tyranny."
I claim something?| -- from the Notebook of Lazarus Long
Stan Brown
>In article <1991Oct09.09...@netcom.COM>, m...@netcom.COM (Morgan Schweers) wrote:
>} Feh. The incredible facility of the :== operator under DCL has yet to
>}be implemented under DOS. (I'd *LOVE* the concept of "DI*R :== DIR")
>
>Try
> alias di*r *dir
>under 4DOS or NDOS. Once again, it's just the braindead COMMAND.COM
>that can't do it.... (the second asterisk is to prevent alias expansion
>of the result)
In DOS 5 you can do this easily:
doskey di=dir $*
It's true that if you want D or DI to be a synonym for DIR, you have to
call doskey twice.
--
Stan Brown, Oak Road Systems +1 216 371 0043
Cleveland, Ohio, USA email: br...@ncoast.org
"I told you, but you wouldn't listen. So now you have to pay--as all
must pay who do not listen to the word of Brown. Hah!"
Morgan Schweers
>} Okay, a bit of crow-eating is in order for myself here... I posted that
>}it was difficult, nigh onto impossible to create a soft-link system for MS/DOS.
>}After I was besieged by a bignum of people who desired it, I began thinking
>}about the nature of reality. Surely, if so many people want something that
>}badly, and so many of them feel that there *MUST* be someway to do it under
>}MS/DOS, perhaps reality will adjust itself...
>
>It's already been done and has been posted to the net a coupla times
>(though I forget the name); the program stores links as files whose data
>contains a magic header and the destination of the link (BTW, Unix
>stores a soft link as a file whose contents is the destination of the
>link).
Unfortunately, the program so posted (or at least the f-link program
from some site or another) doesn't work. At all. Period. No idea why,
it just doesn't work. Back to the drawing board, I'm afraid...
>Try
> alias di*r *dir
>under 4DOS or NDOS. Once again, it's just the braindead COMMAND.COM
>that can't do it.... (the second asterisk is to prevent alias expansion
>of the result)
Hmmmm... Sounds pretty good. 4DOS causes confusion on my system,
though (or at least it used to.) I'll have to try a newer version.
>
>}> (e) You might try to update the same file by two different programs; SHARE
>}> would have to be made cleverer. Of course, making any file that is linked
>}> (and all of the links) read-only solves this problem (and (b)).
>}
>} *vigorous shake of head* You want opens to all be redirected to the one
>}file, so Share, etc., still understand things like they normally would.
>
>The program I mentioned above has just that effect: since it's a wrapper
>for INT 21h, the file actually opened in response to a file open call is
>the final destination of the link.
Eh? I'm confused here. You sound like the program actually worked...
What DOS version? (The little tiny program F-LINK sure didn't do *ANYTHING!*)
>Since the links are supposedly software-transparent, the virus would
>infect the destination of the link.
Supposedly... The question is does the virus infect the 'file' before
name resolution or after. Then the question is, does it search for the
'REAL' INT 21h...
>You'll also miss file accesses made via FCBs, which will be a problem
>since COMMAND.COM uses them for renaming and deleting files. If you use
>a database of name associations to implement links, it will no longer be
>correct after a rename or delete from the DOS prompt.
Ick. Therefore, we either have to resolve the name before determining if
it's a link, or we have to have the file 'know' that it's a link some other
way. (date-time-stamps set specially, or something.)
>Since the network redirector should only be called by DOS (it expects
>various DOS data fields to be set), you will already be inside a DOS
>function call. I'm not sure whether that will work properly, though,
>since 2F/1221 may wind up clobbering the storage (but not the stack)
>used by the original DOS call which invoked INT 2F/1123 (any DOS call
>that takes a path). You'd have to try it. Calling INT 21/60 will
>definitely NOT work, because it will overwrite the internal stack used
>by the file access call.
I've verified the Int 21/60 problem. (Real easy! *grin* I love
pretty crashes!) I haven't had a second yet to verify the 2F/1221
possible problem.
>} The one things that I *DO* know is that Int 21h, function 60h calls
>}Int 2F, function 1123h. This means that you'll have to have your own
>}reentrant-testing code, which passes the request onwards in case you are
>}already in control.
>
>That's because the latter is the mechanism by which network redirectors can
>override the default DOS name resolution. INT 21/60 calls INT 2F/1123 to
>resolve the name; if and only if that call fails does DOS resolve the name
>itself. All other DOS calls which take pathnames call the function that
>implements the INT 21/60 call.
*sigh* Okay, does this mean that (as I've guessed so far) if you
redirect 2F/1123, then you *MUST* call both the 'remainder' of 2F/1123,
*AND* (if that call fails to resolve the name) 2F/1221?
>} Now, for certain areas of the system, there's an even easier way of
>}doing the entire schtick. There are some areas of the system that do an
>}actual 'TRUENAME' before accessing the files. This means that they call
>
>The only one I know of is COMMAND.COM. It calls TRUENAME to make sure
>that you aren't trying to copy a file onto itself. However, it does not
>use the returned names for opening the source and destination files, as
>the returned values may not be valid given the current JOINs, SUBSTs,
>etc. For the same reason, no other software uses TRUENAME's result to
>access files unless they are going through an indirect server call (INT
>21/5D00) anyway.
Ick. Okay, I hadn't gotten that far. It was 'COPY' which clued me
off that Int 21/60 was being called at some point. *sigh* The infamous
'File cannot be copied onto itself' message.
>}P.S. Yeah, yeah, I'm excited. It's the closest I've come to solving
>} this damned problem in a long LONG time. Now I'm down to bare
>} metal, and I need someone who knows more than me. Hey Ralf,
>} you got a minute? *grin*
>
>That's about all I have.... :-)
*grin* S'okay! Helped a bunch... Tell me, is Int 2Fh reentrant?
(I already know that 21h isn't, but I can always hope that they learned
better later...)
>--
>{backbone}!cs.cmu.edu!ralf ARPA: RA...@CS.CMU.EDU FIDO: Ralf Brown 1:129/26.1
>BITnet: RALF%CS.CMU.EDU@CARNEGIE AT&Tnet: (412)268-3053 (school) FAX: ask
>DISCLAIMER? Did | "Secrecy is the beginning of tyranny."
>I claim something?| -- from the Notebook of Lazarus Long
-- Morgan Schweers
Ping-Shun Huang
> Last, but certainly not least, some provision should be made for
> circumstances in which the software that handles the links is *NOT* in
> memory. (I.E. Person boots from an original DOS diskette... What
> happens when they try to copy a linked file? What *SHOULD* happen?)
In my opinion, link information should be stored in a separate data file
in each directory which has any links in it or to it. This solves the
problem of running low-level disk utilities, which won't notice anything
unusual going on. As far as what should happen when the special
software isn't loaded, my opinion is that the links should just
completely disappear (the data files stay, of course). This allows the
user to return his/her system to normal in case there are any problems
and he/she wants to see if the link software is responsible.
I might enjoy beating some details of this, but not on the net.
--
Above text where applicable is (c) Copyleft 1991, all rights deserved by:
UNIX:/etc/ping instantiated (Ping Huang) [INTERNET: psh...@athena.mit.edu]
Frank Budzelaar
Before starting a new bunch of postinga, could we please be more
precise in our terms:
alias: A textual replacement for a command, i.e. when I type ls,
this could be an alias for dir. The command line interpreter
replaces ls by dir before interpreting the command line.
4dos and ndos (and various other utilities) support aliases.
link: A link looks like a file, but is actually a reference to another
file. Unix supports links: If A is a link to B, I can open either A or B
and still access the same file. Note that this completely
different from an alias as described above. aliases only work
at the command line, links also work when you open a file in
let's say a word processor. The idea of links is nice, but
I haven't seen a good utility supporting links on DOS.
Greetings,
frank budzelaar
/----/----\
/ / /
----/----/----/------
/ / \
/ /-----/
Disclaimer:
Of course my opinions are my own.
------------------------------------------------------------------------
Frank Budzelaar "My other computer is a 486"
Eindhoven University of Technology seen on an XT
email: bu...@eb.ele.tue.nl
-----------------------------------------------------------------------
Frank Budzelaar
Actually, its very easy to support links under dos: just create
a second or third directory entry to the same entry in the fat table
at there you are.
However, when you kill such a file, your file system will get corrupt,
and chkdsk it not so happy either...
No kidding, DOS is not written to support links, and without a major
changes, it never will. It would mean that the directory structure must
be altered for that.
However, I see no fundamental problem in writing a TSR utility, which
monitors the opening of files. It could maintain a translation table
which is used to translate the name of a file to another, and thus
provide symbolic links. Tricky points are:
* if you do a dir, you will want to see these files as well.
* chkdsk may get completely confused. I'm not sure: I don't know at which
level chkdsk gets its information.
* "ill behaving" utilities may cause serious problems, as the file
system looks different at a high level than at a low level (imaging:
if you compute the space used by your files, and end up with a number
greater than the size of your harddisk...)
Probably, these problems can be solved. If I'm wrong, enlighten me !
Ralf....@b.gp.cs.cmu.edu
} Tell me, is Int 2Fh reentrant?
}(I already know that 21h isn't, but I can always hope that they learned
}better later...)
Depends on which function you call. Since we're talking about DOS, I'll
limit myself to 2F/11xx and 2F/12xx. The former depends on the network
redirector, the latter on which subfunction. The majority of the 2F/12xx
calls are reentrant, but those which perform equivalents of non-reentrant
DOS calls aren't. They get around DOS's non-reentrancy by using a different
stack frame, but there's only one alternate stack frame....
Auric__
> On Wednesday, October 16, 1991 at 5:27:47 AM UTC-7,
^^^^^^^^^^^^^^^^^^^^^^^^^^^
> good read.
It's over 31 years old. Comments not necessary.
--
I will destroy your world like I destroyed my own.
Arnold Ziffel
>> On Wednesday, October 16, 1991 at 5:27:47â?ŻAM UTC-7,
>
>> good read.
>
> It's over 31 years old. Comments not necessary.
--
Stress is that condition created when the mind overrides the body's
basic desire to choke the living shit out of some asshole who
desperately needs it.
Kerr-Mudd, John
arn...@hooterville.invalid (Arnold Ziffel) wrote:
> Auric__ <not.m...@email.address> wrote:
>
> >> On Wednesday, October 16, 1991 at 5:27:47â?ŻAM UTC-7,
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >> good read.
> >
> > It's over 31 years old. Comments not necessary.
>
> Google users don't care...
>
it's all a bit late now). But so is DOS Programming (retro-types
(myself included) excluded).
--
Bah, and indeed Humbug.