Message-ID: <01FD6EC775C6D4119CDF0090273F74A4FD6A43@emwatent02.meters.com.au> From: "da Silva, Joe" To: "'opendos AT delorie DOT com'" Cc: "'Prof. Dr.-Ing. Werner Zimmermann'" Subject: RE: DR-DOS LFN detection? Date: Wed, 12 Mar 2003 17:49:45 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Reply-To: opendos AT delorie DOT com 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 > > -- > ; > http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org > > "Programs are poems for computers."