direct longfilename on freedos

BTW, the real reason I'm resurrecting this old thread is because that FPC 3.0 announcement thread probably isn't the best place to talk about DOS LFNs.

> Well, that is the problem in a multi OS project like FPC.> Not everyone wants to limit themselves to 8.3 on all systems,> because the best one can do is 8.3.

Okay, but you have to admit that "RTL-CONSOLE" is probably a bad example. What's wrong with "RTL-CONS" or even "RTL-CONS.OLE" or just stuffing it all in "RTL"? Or even "CONSOLE.RTL"?

Anyways, there's one thing you're forgetting. If you unzip LFNs in pure DOS without LFNs (thus no need for '~' aliases at all), it will truncate them. So "GNUmakefile" becomes "GNUMAKEF" instead, but DJGPP's Make will still happily accept it. In fact, I haven't tested lately, but for the most part, even old (non-LFN aware) programs should behave similarly (barring some rare buffer overflow). Actually, most people never use more than 32 chars for filenames.

Or you could just assume all the bundled RTL units (etc.) are read-only and just stuff them in a database (or even .ZIP archive, remember that old "contribs" FPC unit that read .ZIP as a file system? zfs210.zip).

On that note, I half (barely) expect you (marcov) to suggest that someone write a wrapper (Delphi) "class" for all file accesses, thus reading and converting all filenames from DESCRIPT.ION (or similar). But that's basically what StarLFN (TSR) already does for us (LONGNAME.DAT), and it mostly seems to work fine. (Although apparently that's very slow for reading a .ZIP with thousands of files.)

> However in general the idea is to keep msdos (16-bit) and> go32v2(32-bit) running on pure dos for minor development if> the changes are not too intrusive, but in time bootstrapping> etc only cross-.

No, the idea (overall) seems to be, "Need a new file system? Switch to Linux." Nobody cares about DOS enough to backport anything, so we don't even have ext2. The whole system is flawed or obsolete (to them), so there's no use for any improvements. Throw it away, and start from scratch.

> Anyway, starting with 3.0, most units/ packages are under control> of a build tool written in FPC that makes things like this easier.> It might be worth posting a bugreport for the rtl-console thingy.> Deriving some short package name for 8.3 target systems might be> doable, and then the tool will do the rest.

Just cheap brainstorming here ....

I had one (horrible) idea where somebody (kernel?) could just hash the LFN itself into CRC32, which fits in eight bytes (0xABCD0123), so any time someone tries to read/write from "My Long Name.txt", the kernel automatically hashes it and can read the actual file "ABCD0123.CRC" instead. Of course, then you have to have a special unzip tool and/or convert all your old filenames semi-automatically.

VFAT is still patented until roughly 2017. I have no idea if that makes much of a difference to the few remaining kernel devs.

There is LFNAPI.C in the kernel sources, but it's not enabled by default (and doesn't even seem to compile for me). It's probably incomplete. A quick check on SF.net SVN shows most of the commits from 2001-2 by Bart O., but he's been too busy in recent years to do much. Although honestly, int 21h 71xxh isn't that extensive, so it couldn't be that hard to add (famous last words).

I think ROM-DOS 7 claims to have LFN support built-in, but I've never tried it. (Obviously Win95 worked but only in "GUI" mode. I haven't used 32-bit Windows since Vista; it still worked there, but overall NTVDM had regressed too much for my tastes, and 64-bit editions don't support it at all.) Not sure about DR-DOS and its (abandoned) driver. So, for now, we only seem to have a few (semi-buggy) third-party TSRs like DOSLFN.

Speaking of ODI's LDIR (etc.), apparently it hardcodes an OEM check for FAT32 only for MS-DOS 7, requiring a simple binary patch for FreeDOS, and then it works fine.

direct longfilename on freedos

There are some stand-alone LFN utilities and one is called LDIR that lists LFN files without LFN driver loaded.
This is Odi's Dir for long file names 1.47
Copyright (C) 1999 Ortwin Glueck
This is free software under GPL. See the readme file for details.