DOS ain't dead

> 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.
>
> Usage: ldir [drive:][path][filename] [/a][/b][/s][/p][/c][/i][/tn][/?]
>
> Display (selected) files of a directory.
> Note: Dates are printed as day.month.year
> Switches:
> /a Displays also hidden files.
> /b Use short output format
> /s Work on subdirectories
> /p pause on page breaks
> /c Disable cache
> /i Force ISO-9660 file system
> /tn Use CD data track n

> Also works in MS-DOS 6.22

And with MS-DOS 6.20.
I have been using it for years, and as a "helper" for quite a few of my own utilities.
e.g. http://www.ausreg.com/f4/f4.htm

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

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.