Mail Archives: opendos/2003/03/12/01:51:10
Thanks, Matthias.
Please see below ...
Joe.
> -----Original Message-----
> From: Matthias Paul [SMTP:Matthias DOT Paul AT post DOT rwth-aachen DOT de]
> Sent: Tuesday, March 11, 2003 11:32 PM
> To: opendos AT delorie DOT com
> Subject: Re: DR-DOS LFN detection?
>
> 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).
>
[Joe da Silva]
Yes, this is similar to what LTOOLS does presently.
(This is what I meant by "if running under Windoze".)
> 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.
>
[Joe da Silva]
Yes, it was because of these TSR's that I thought that
there should be a better way to detect LFN support
(although unfortunately the DOSLFN TSR doesn't work
properly with DR-DOS 6.0 anyway).
> 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.
>
[Joe da Silva]
Hmmm ... Unfortunately, I have no access to these other
DOS clones. If there is doubt about using this INT 21/71
dummy call CF detection with these, perhaps I should
forget the idea? OTOH, LTOOLS doesn't presently work
properly on DR-DOS 6.0, so it may not work with some
of these DOS clones anyway. I just don't want to introduce
any new incompatibilities, especially since I am not the
maintainer of this program.
> > 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 -