Mail Archives: opendos/2003/03/11/14:15:45
On 2003-03-10, Joe da Silva wrote:
> Thanks for confirming what I suspected ... I was/am looking at the
> LTOOLS source code (to make this compatible with DR-DOS 6.0)
> and noticed that it simply assumes LFN is available if running
> under Windoze, otherwise not.
Hm, this does not sound like a good test to me.
For example, JP Software's 4DOS 6.02+ tries to use the LFN API
when it has detected that MS-DOS 7.0 or higher was loaded *and*
the Windows 4.xx GUI is running.
I think, it uses INT 2Fh/AX=1611h or the identical function
INT 2Fh/AX=4A33h in order to determine if it is running under
MS-DOS 7.0 or higher, not the usual INT 21h/AH=30h or AX=3306h
(which is too easy to be faked by non-Microsoft DOS versions
and OEM issues).
Besides other things, DR-DOS "WinGlue"/"WinBolt" (the version
of DR-DOS, which runs Windows 4.xx) also emulates these functions,
but I still think it is a bad thing to base the detection of the
LFN API on one of these functions, simply because there are now
several DOS TSRs (DR-DOS LONGNAME, LFNDOS, DOSLFN, etc.) which
do not emulate them - when emulating them one has to take a lot
of other implications into account... It's like opening a can of
worms, so to speak.
JP Software simply chosed to introduce a 4DOS.INI directive
(Win95LFN=Yes|No) to give the user a chance to override the
auto-detection.
Still better, IMHO, is to make a dummy call to one of the
INT 21h/AH=71h functions with CF set on entry and see if
CF has been cleared on return (it will still be set on
older DOS versions). This is how the DR-DOS 7.02+ COMMAND.COM
works, but after all the years I would have to look this up
in the sources, which function is actually used to make the
test (maybe INT 21h/AX=71A0h???). Anyway, this would require
some amount of research in order to cross-check the behaviour
under other DOS clones such as PTS-DOS, General Software's
Embedded DOS, Datalight's ROM-DOS, or WinDOS.
> If there was a "standard" way of detecting LFN, I was going to
> change LTOOLS accordingly. However, I think I'll leave this
> aspect of the code alone, rather than risk "breaking" it.
Whatever the test will be, there should IMHO be a way to override
the automatic detection.
Greetings,
Matthias
--
<mailto:Matthias DOT Paul AT post DOT rwth-aachen DOT de>; <mailto:mpaul AT drdos DOT org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
- Raw text -