Long filenames problem 
Author Message
 Long filenames problem

Ok, this might be sightly off-topic here, since it's more of a Win 9x question
rather than a TP question, but I'm updating my DOS.PAS replacement unit to
provide long filename support in a Win9x Dos box, but I don't know if LFN
support is provided (or not) on a system-wide basis, or if I need to determine
LFN support on a per-drive basis. What about networked drives - do they behave
differently as far as long filenames are concerned? Do all Win9x accessable
drives have to be case insensitive?

TIA,

--
Jay

Jason Burgon - Author of Graphic Vision
New version 2 now available from:
http://www.*-*-*.com/



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem
Jason Burgon schrieb:

Quote:
> Ok, this might be sightly off-topic here, since it's more of a Win 9x question
> rather than a TP question, but I'm updating my DOS.PAS replacement unit to
> provide long filename support in a Win9x Dos box, but I don't know if LFN
> support is provided (or not) on a system-wide basis, or if I need to determine
> LFN support on a per-drive basis. What about networked drives - do they behave
> differently as far as long filenames are concerned? Do all Win9x accessable
> drives have to be case insensitive?

I suggest you to download my LFN-unit from
http://home.t-online.de/home/andreas.killer/ and read some
parts before you start your work.

--- FILE_ID.DIZ ---
Support of long filenames under Win95 (and above) for TP6, TP/BP7 and
compatible compilers. After integrate this unit all
default-Pascal-routines has the ability to work with long filenames.
It's NOT necessary to rewrite an existing program! All routines detect
automatically if they are supported and are disabled by itself if not.
Changing long filenames in short also avaible under pur DOS. Over 3900
lines full (in german) documented pascal-source. Can be used for Real-,
Dpmi- and Windows-programs. Hooks also into unit Dos and/or unit WinDos.
--- FILE_ID.DIZ ---

The documentation and the interface-part is avaible in english.

By, Andreas.



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem

Quote:
> I suggest you to download my LFN-unit from
> http://home.t-online.de/home/andreas.killer/ and read some
> parts before you start your work.

Thanks Andreas, I've been and had a look at it. I'm not sure it answers any of
my questions though!

Quote:
>>I don't know if LFN support is provided (or not) on a system-wide basis, or
if I need to
>>determine LFN support on a per-drive basis.
>>What about networked drives - do they behave differently as far as long

filenames are >>concerned?

Quote:
>>Do all Win9x accessable drives have to be case insensitive?

I noticed in your code that if any given LFN function returns "unsupported",
you switch off that particular LFN function. Surely Windoze either suports all
the LFN functions, or none at all! How could an application possibly cope with
some LFN calls that worked and some that didn't?

Getting concrete info on Win9x LFN support is proving incredibly difficult.:-(

--
Jay

Jason Burgon - Author of Graphic Vision
New version 2 now available from:
http://www.jayman.demon.co.uk



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem
Hi!

There is also a LFN-unit available on
http://members.xoom.com/goldman47/index.htm , Miscellaneous. Perhaps it
helps you!

CU
Jens

--
[ MY WEBPAGES (IN GERMAN AND ENGLISH) ]

[ HOMEPAGE: http://home.t-online.de/home/jens.gesing/index.htm ]
[ PROGRAMMING-DO-IT-YOURSELF: http://members.xoom.com/goldman47/index.htm ]



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem
Jason Burgon schrieb:

Quote:
> > I suggest you to download my LFN-unit from
> > http://home.t-online.de/home/andreas.killer/ and read some
> > parts before you start your work.
> Thanks Andreas, I've been and had a look at it. I'm not sure it answers any of
> my questions though!

Not all, but most I think. :)

Quote:
> I noticed in your code that if any given LFN function returns "unsupported",
> you switch off that particular LFN function. Surely Windoze either suports all
> the LFN functions, or none at all! How could an application possibly cope with
> some LFN calls that worked and some that didn't?

Well, I wrote the first version of this unit under Win95A and I found at
this time that not all existing windowsversion supports all functions. I
also found out that windowsversions exist that truly has the same
versionnumbers but they are different working.

The base idea of my unit was and is to make long filenames possible for
older program without rewriting it and so IMHO it is better to return a
valid but unexpected result in this special case.

Quote:
> Getting concrete info on Win9x LFN support is proving incredibly difficult.:-(

That's right. I got the most information about LFN's from ralf browns
interrupt list, try it, it's very helpful.

By, Andreas.



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem

Quote:
> Hi!

> There is also a LFN-unit available on
> http://members.xoom.com/goldman47/index.htm , Miscellaneous. Perhaps it

Thanks. I'll take a look.

--
Jay

Jason Burgon - Author of Graphic Vision
New version 2 now available from:
http://www.jayman.demon.co.uk



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem

Quote:
> Jason Burgon schrieb:
> > I noticed in your code that if any given LFN function returns
"unsupported",
> > you switch off that particular LFN function. Surely Windoze either suports
all
> > the LFN functions, or none at all!
> The base idea of my unit was and is to make long filenames possible for
> older program without rewriting it and so IMHO it is better to return a
> valid but unexpected result in this special case.

Yes, it's an admirable goal, though I'm not sure it will really be practical
in many cases. It seems to me that trying to support LFN's opens up a can of
worms because (from the very limited info I've managed to get hold of - see
below) it then allows your application "native" access to different file
systems such as HPFS and NTFS and ....who knows what else in the future.

This means for example, that you can't treat a filename as generic. It's
validity and case-sensitivity might depend on which drive it's being used on
because there might be multiple file systems in operation. Of course there is
no LFN "Parse Filename" function. Nice one Microsoft. Even DOS 1.0 has a
"Parse Filename" function - sort of.

Quote:
> > Getting concrete info on Win9x LFN support is proving incredibly
difficult.:-(
> That's right. I got the most information about LFN's from ralf browns
> interrupt list, try it, it's very helpful.

Yes, Ralf Brown's is my main source of info. However, while it is very good as
a "quick reference" for the interrupt calls, it's shit useless as a source of
"strategic" information.

The best I've come up with so far is a document from Microsoft's Knowledge
Base:

http://msdn.microsoft.com/library/techart/msdn_longfile.htm

I really need more than this and Ralf Brown's though. :-(

--
Jay

Jason Burgon - Author of Graphic Vision
New version 2 now available from:
http://www.jayman.demon.co.uk



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem


Quote:


> > Jason Burgon schrieb:

<snip>

Quote:
> The best I've come up with so far is a document from Microsoft's
> Knowledge Base:

> http://msdn.microsoft.com/library/techart/msdn_longfile.htm

> I really need more than this and Ralf Brown's though. :-(

If you're any good with C, look for LFNDIR.ZIP. The program appeared in
the 5 May 1998 issue of PC Magazine (US Edition) It can be used in RAW
(as in non-W95/98) DOS to do "DIR" on directories with LFNs.

If you cannot find it, drop me a line and I'll email it.

Robert
--
Robert AH Prins

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem


Quote:


> > The best I've come up with so far is a document from Microsoft's
> > Knowledge Base:

> > http://msdn.microsoft.com/library/techart/msdn_longfile.htm

> > I really need more than this and Ralf Brown's though. :-(

> If you're any good with C, look for LFNDIR.ZIP.

Thanks  Robert, but I aready know how LFN's are stored and coud easily
implement a "Dir" function myself. That's not really the issue because I want
my unit to work at the O/S<->Application level. In fact what's more of an
issue are non-[V]Fat partitions, such as NTFS, network drives, and what the
Windows/DOS 7.x int21 API expects/allows you to do with them.

Btw, does anyone know of any (non MS) DOS that supports LFN's? Caldera/DR were
working on it for Open/DRDos, but seemed to have dropped it.

--
Jay

Jason Burgon - Author of Graphic Vision
New version 2 now available from:
http://www.jayman.demon.co.uk



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem
Jason Burgon schrieb:

Quote:
> Btw, does anyone know of any (non MS) DOS that supports LFN's? Caldera/DR were
> working on it for Open/DRDos, but seemed to have dropped it.

No. I worked on a my own project "TSR that support long filenames 4 DOS"
in the past and I dropped it also, because it's very heavy work to
implement such feature and 99.5% of all users doesn't need such a
program.

If you want to restart such a project I can give you some source which
can read a DOS-drive with INT13h. It is perfected to the point that it
can read FAT12 up to FAT32 and show a directory from any starting
cluster within any partition on this drives.

By, Andreas.



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem

Quote:
> Jason Burgon schrieb:

> > Btw, does anyone know of any (non MS) DOS that supports LFN's? Caldera/DR
> >were working on it for Open/DRDos, but seemed to have dropped it.
> No. I worked on a my own project "TSR that support long filenames 4 DOS"
> in the past and I dropped it also, because it's very heavy work to
> implement such feature and 99.5% of all users doesn't need such a
> program.

Yes. The raw LFN implementation, written as a TSR or as part of the kernel is
probably only the tip of the iceberg too. I mean, the system wouldn't be much
use without a defragger than couldn't handle the LFN directory entries, a
batch file processor that couldn't handle LFN's, a Copy command that couldn't
handle LFN's, etc, etc.

Quote:
> If you want to restart such a project I can give you some source which
> can read a DOS-drive with INT13h. It is perfected to the point that it
> can read FAT12 up to FAT32 and show a directory from any starting
> cluster within any partition on this drives.

It' a very kind offer Andreas, but I think I'm too old to take on the world
again! ;-)
Maybe has a niche application in Win9x "oh-my-God!" type recovery utilities
and similar though, where Windows won't, or shouldn't be active (like
Partition Magic for example). Add a good quality GUI front end (I wonder where
that would come from?) to the tool, and hey presto, we have something worth,
ooh at least 0.1 Euro! :-) No, I'm just being an old cinic. There could be
avenues to explore there. I've got a pretty good File Manager application for
example that, with your TSR would allow people to rearrange their files on
VFAT partitions without having to boot up Windows.
Maybe we should ask if there is a need for such a thing. I should think it
would have to be free software.

CalderaDOS was open source for a while - though they seem to have had a change
of heart on that one too. I even have some of the source code somewhere I
think. Any serious "VDOS" would need a rewrite from the kernel up, but I can't
see Caldera reinstating the LFN project (well, maybe), or making DR-DOS open
source again for others to do it. :-(

Btw, I've made good progress with my unit. I'll release it as freeware when I
think it's ready for a beta test. I've just got get rid of a couple of bugs
and decide on, and implement a filename parsing policy. It seems that filename
parsing really needs to be tied to the disk volume the file is intended for,
using the Win9x "Get Volume Information" data. This is a little tricky to do
while keeping the unit backwards compatible with DOS.PAS, for some of the
functions though. Obviously the best solution would simply be to let the O/S
decide on the validity of a file or directory name, but this might not always
practical in the real world. Some more careful thinking is required on this.

In keeping with the rest of the unit (aka DOS and DPMI), I've decided to give
it the same API under both DOS and Win9x Dos box. Any functionality that can't
be supported or emulated under pure DOS won't be provided. The only difference
will be the validity of filenames and paths - hopefully dictated by their
associated volume. That way the application user, rather than the application
programmer can decide if he wants to use LFN's or not.

I don't know if I'll get it to support the Win3.x target yet as the rest of my
unit is aimed squarely at the DOS and DPMI environments.

--
Jay

Jason Burgon - Author of Graphic Vision
New version 2 now available from:
http://www.jayman.demon.co.uk



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem

Quote:
>It' a very kind offer Andreas, but I think I'm too old to take on the world
>again! ;-)
>Maybe has a niche application in Win9x "oh-my-God!" type recovery utilities
>and similar though, where Windows won't, or shouldn't be active (like
>Partition Magic for example). Add a good quality GUI front end (I wonder where
>that would come from?) to the tool, and hey presto, we have something worth,
>ooh at least 0.1 Euro! :-) No, I'm just being an old cinic.

I know you meant this ironically, but:
Nobody will ever pay, simply because you can do all that from a 20 MB
minimal linux installation, installed from a $2 dollar CD from
www.cheapbytes.com.

You could write your backup program in FreePascal, run it under Linux and X
:-)



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem


Quote:
> >Maybe has a niche application in Win9x "oh-my-God!" type recovery utilities
> >and similar though, where Windows won't, or shouldn't be active (like
> >Partition Magic for example). Add a good quality GUI front end (I wonder
where
> >that would come from?) to the tool, and hey presto, we have something
worth,
> >ooh at least 0.1 Euro! :-) No, I'm just being an old cinic.

> I know you meant this ironically, but:
> Nobody will ever pay, simply because you can do all that from a 20 MB
> minimal linux installation, installed from a $2 dollar CD from
> www.cheapbytes.com.

> You could write your backup program in FreePascal, run it under Linux and X
> :-)

Yes, but if you've trashed yer one and only hard disk... Besides, a lot of
Win9x people couldn't or wouldn't install Linux - especially not just for a
fix. I take it that Linux can read VFat[32] partitions then?

But, your general point is the same as mine, which is that this kind of
software has a very low street value, despite the fact that I should think
it's very time consuming to get really right.



Wed, 18 Jun 1902 08:00:00 GMT  
 Long filenames problem

Quote:
>> You could write your backup program in FreePascal, run it under Linux and X
>> :-)

>Yes, but if you've trashed yer one and only hard disk...

Then you run it from startup disc, bootable cdrom, whatever, or temporarily
hang in a $2 dollar 40 MB disc.

Quote:
> Besides, a lot of
>Win9x people couldn't or wouldn't install Linux - especially not just for a
>fix.

The same people also wouldn't like to use DOS. But they'll have to if their
windows doesn't boot. Also it could be done on top of linux (the disc boots
into the backup system)

Quote:
>I take it that Linux can read VFat[32] partitions then?

Better than windows, since it only sees long filenames, and doesn't bother
with short ones.
(no joke, try to install windows from a long file name directory, or install
e.g. a Microsoft product as powertoys in a nested long file name directory)

Quote:
>But, your general point is the same as mine, which is that this kind of
>software has a very low street value, despite the fact that I should think
>it's very time consuming to get really right.

You say it is no use. I say it is partly done :-)
This way you only have to write the backup software. The disk drivers are
extremely advanced as a part of a separate OS :-)
Also you have a fully functional OS to build your app on. Not a vague
dos-tsr-driver combination.

BTW: I took Linux as example because I know it best. I wouldn't be surprised
if the same was possible from OS/2, with a nice Pascal (to stay ontopic)
backup app, written in SpeedPascal or FPC/2



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. Long FileName - Short Filename conversion

2. Another problem with long filenames (LFN)

3. Long filenames in DOS mode

4. extend borland pascal to long filenames and use of win95/98/me/xp filedialogs

5. lfn110.zip TP6+ Support of long filenames

6. BDE Bug with long filenames ?

7. Long Filenames

8. BP7 / Long Filenames LFN

9. Erase Function for Win95 Long Filenames

10. unit dos and long filenames with windows95

11. long filenames under BP7.0 ?

12. Long FileNames

 

 
Powered by phpBB® Forum Software