Date: Tue, 11 Mar 2003 13:31:30 +0100 From: Matthias Paul Subject: Re: DR-DOS LFN detection? To: opendos AT delorie DOT com Message-id: <006301c2e802$4530cd40$c03dfea9@atlantis> Organization: Aachen University of Technology (RWTH), Germany MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <01FD6EC775C6D4119CDF0090273F74A4FD6A39 AT emwatent02 DOT meters DOT com DOT au> Reply-To: opendos AT delorie DOT com 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 -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org "Programs are poems for computers."