Mail Archives: djgpp/1996/08/27/17:27:46
On Tue, 27 Aug 1996, Mark Habersack wrote:
> On 26 Aug 1996, Alexander Lehmann wrote:
>
> >Mark Habersack <grendel AT ananke DOT amu DOT edu DOT pl> wrote:
> >
> >.... LFN support for plain DOS. ...
> >
> >: Until Micro$oft won't provide support for LFNs in DOS (will they
> >: ever do?) such a library might be needed.
> >
> >Actually, instead of putting this into a C library, wouldn't it be
> >considerably better to suppy a DOS TSR that implements the
> >necessary INT calls so that all programs (not only djgpp) can use
> >this and also djgpp program do not require to be recompiled.
> I was thinking about that. But the problem is how the other programs
> detect the presence of LFN extensions. If they use INT 2Fh to
> detetect Win95, then there might be a problem 'cause the TSR cannot
> provide all the services Win95 gives the DOS apps. And that means
> problems. DJGPP itself would work OK, because it just check whether
> the LFN INT 21h functions return error or not. However, if another
> program wants to, say, invoke the Change Window Title function which
> is also in Win95's INT 21 - we're in trouble. And there is no point
> in writing all the funcs just to get LFN support. OTOH, such a TSR
> might be useful.
Well, any program that checks for LFN support via the presence of
Win95 can IMHO be considered buggy enough to be ignored. As long
this works with djgpp and reasonably sensible other programs I think
it is ok. Obviously we don't want it to break other programs, but this
will not happen with the win95 detect bug, I think.
> >Also, apparently the same may be necessary for other platforms not
> >supporting LFN in DOS but in their native environment (OS/2, NT4,
> >Linux dosemu), though it will be considerably easier there, I
> >guess.
> Linux already supports VFAT from Win95. Just download the 2.0.0
> kernel and you can mount Win95 VFAT partition. As for WinNT, there's
> a problem of access to disk at the sector level. Such access is
> needed to create LFNs which are stored as a chain of dir entries
> with 0x0F attribute. They have to be stored one after another, and
> the only way to provide this is to access the disk with either INT
> 25/26 or INT 13. AFAIK, INT 13 is being monitored by WinNT and all
> the access to disk using this INT is forbidden. INT 25/26 are DOS
> artifacts which I don't know whether are supported on NT. Probably
> there's a way to access disk at the sector level in NT, but it
> requires the knowledge of VxD calls in this environment which I
> don't have (the knowledge).
No, sorry I meant a TSR to supply the LFN INTs would be useful based
on the filename support already available in the system. E.g. NT
supports VFAT16 as well as NTFS with long names (at least 4.0beta
does). In the case of Linux, supporting kernel supported long
filenames (VFAT,ext2fs, rockridge etc) via the LFN api would also be
useful, I think the normal behaviour of dosemu is to do some
namemangling.
bye, Alexander
--
Alexander Lehmann, | "On the Internet,
alex AT hal DOT rhein-main DOT de (plain, MIME, NeXT) | nobody knows
lehmann AT mathematik DOT th-darmstadt DOT de (plain) | you're a dog."
<URL:http://www.mathematik.th-darmstadt.de/~lehmann/>
- Raw text -