DOS ain't dead

Hi all,

exist a trick for receive a list with a long filename of files using connamd dir instead dir/lfn in freedos.

E.g

C:>

C:>dir

C:>
.
Pippopallapertica.txt
unfile a caso.jpg


like command dir in DOS of win98..

It's also possible enbedded LFN in kernel for avoid loading of external drivers?

Thanks

Roberto

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.

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

---
DOS gives me freedom to unlimited HW access.

> 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/

> exist a trick for receive a list with a long filename of files using
> connamd dir instead dir/lfn in freedos.
> ...
> like command dir in DOS of win98..

You mean a way to use "dir" as a shortcut for "dir /lfn"? "SET DIRCMD=/lfn"

You mean why isn't it default, auto-detecting? Who knows, maybe bugs. FreeCOM 0.84 also supports DESCRIPT.ION (but, IIRC, not if LFN is enabled, so you have to override it via "/OU" or whatever).

> It's also possible enbedded LFN in kernel for avoid loading of external
> drivers?

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.

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.

Hi all,

today PerditionC (developper of freedos kernel) have reply about my request of direct support of LFN from freedos Kernel.

Seem the support can be added in 2017 ..
i hope!

snip---------------------

Re: [PerditionC/fdkernel] Add LFN support to kernel 2042 (#5)

This should be available in 2017.

?
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

snip--------------------