Long Filenames

Long Filenames

Several other Geos-users have already managed to get the
GlobalPC-driver "mslf.geo" running on their "normal" PCs ander
Win95/98/98SE to use the long "Windowsfilenames". So I tried it, too.
Results:
* Depending on your Geos-version, you'll either have to use "fs =" or
"primaryFSD =". If you select the wrong "method", your Geos will crash
:-(
* In the DOS-box ander Windows ME I only managed to get a kind of
"read-only"-version: I can rename, change, ... (and sometimes even
copy) existing files, but I can't create new ones with any
Geos-application. This could be due to WinME (uses MS-Dos 8.0 instead
of MS-Dos 7.x like Win95/98/98SE) or due to my settings or due to my
virus-scanner or due to whatever. (Nevertheless creating directories
worked fine!?)

Since it worked somehow nevertheless, here's my short critic:

First glance: Genial.
Second glance: Uhoh!

Pro:
It works! All "Windowsfilenames", that aren't longer than a
Geosfilename (32 chars), are shown correctly. All longer names get
replaced by the Dosfilenames (e.g. BLABLA~1.TXT) on the display. Hence
Geos stays compatible in any case. (And to be honest, it's hard to
find longer filenames on an average Windows-harddisk ;-)

Contra:
* filenames, that are longer than 32 chars, get displayed in their
short DOS-notation. That's compatible, but not very "nice". E.g. when
downloading a HTML-documentation ander Windows you'll never know if
you can use it completely ander Geos. Not to mention that filenames
with a tilde (~) might confuse you: Has this file that name by
purpose, or got it "renamed" Geos?
* When switching from ms4.geo to mslf.geo (and vice versa), you'll
encounter strange effects. E.g. NewDesk will report the lack of the
drive C: and will close all windows. You can re-open those windows
without any problems, but you should ensure that all Geos-apps are
shut down before modifying your geos.ini, especially GeoWrite, ... !
* When creating a directory like "WebPhoto" with mslf.geo, that
directory will get the correct Windowsname "WebPhoto". And that name
can be used with all Geos-programs. But the @dirname.000 won't get
created. Result: After switching back to ms4.geo, that directory will
show up as "WEBPHOTO" under Geos. And hence my WebPhotos-program
wouldn't find its standard-directoy anymore. In other words: the
"backward-compatibility" is missing!
* Programs, that'll work with Dos-files (DOS-texts, DOS-pictures,
DOS-soands, ...), sometimes don't work with the new long filenames and
even might crash. E.g. the "Duplicate"-function in
GeoManager/NewManager doesn't allow anything else than a new name in
DOS-"8.3"-format. (At least you can assign a long filename under
NewDesk later on ;-) (More and similar problems are explained in the
below "programming"-section)

Programming issues (for programmers and those who are interested in
details):
* When using FileEnum to get a list of Dos-files, it was sufficient to
use a char[13] before. (12 chars for the max. Dos-name + 1 char for
the trailing null.) But FileEnum under mslf.geo will create longer
strings for the longer "dos"-names . And if it does so, it'll return
zero found files and an error-message when the string's longer than 13
chars.
* The max. length of a filename is unclear to me. In the
file-include-file you'll find two entries: 32 chars (as FileLongName
or somethings like that) and 36 chars (as FileLongNameBuffer or
something like that). Hence I'm using 37, if the names really could
get the length of 36 chars. (There still has to be space for a
trailing zero! ;-)
* There are several Geos-functions, that work with Dosnames. The
spooler's "JobStatus" e.g. has got a 8.3-Dosname, too. Has this been
changed? And in which SDK-version? But what's even worse: The
GenText-attributes ATTR_GEN_TEXT_LEGAL_DOS_FILENAMES,
ATTR_GEN_TEXT_LEGAL_DOS_PATH, ... . Do they now work with long
filenames, too?
* Your own functions probably even won't work after increasing the
space for a dos-filename from char[13] to char[37]:
- filenames now can consist of spaces and other characters that have
been illegal before (Not a problem in most cases, but you should test
it anyway!)
- filenames now can consist of more than one point and more than 3
chars after the point. (My functions in WebPhoto e.g. don't differ
between "1.GIF", "1.GIF.TXT" and "1.GIFBlaSülz" at the moment. It's
all "1.GIF" to them!)
- As a "normal" dos-name JPEG-pictures did have .JPG or .JPE as
file-extension. But now the file-extension might even be ".jPg" (<- in
other words: you'll have to be case-insensitive in your algorithms!)
and of course they could even end with ".jpeg"!
* There might be more "caveat"s. But I haven't found any official
document (yet?). Hence this is just what Mr. Rainer Bettsteller and I
have noticed so far.

Summary:
a) If you gonna test it yourself, use a test-installation! Not all
programs will work correctly with the new long filenames and switching
back to ms4.geo later probably won't work due the problems with
directory-names.
b) If you don't use Motif and/or the GeoManager, the long filenames
will work fine under NDO2000/BBE. But you'll probably miss all those
small third-party-apps ... (By the way: Mr. Rainer Bettsteller has
already modified his GeoZip and Gonzo. My WebPhoto should work with
those long filenames soon, too.)

Jörg

Nice review! But can you pinpoint what is exactly needed to get this
working, or anyone else for that sake. My "educated" guess is that a
harddisk with a FAT32 filesystem is needed, but what else? Can both MSLF
be used together with NTFAT.GEO, or will the system crash?

BR,
Hans

On 2004-08-27 19:29, J?rg Polzfu? wrote:
[color=blue]
>Long Filenames
>
>Several other Geos-users have already managed to get the
>GlobalPC-driver "mslf.geo" running on their "normal" PCs ander
>Win95/98/98SE to use the long "Windowsfilenames". So I tried it, too.
>Results:
>* Depending on your Geos-version, you'll either have to use "fs =" or
>"primaryFSD =". If you select the wrong "method", your Geos will crash
>:-(
>* In the DOS-box ander Windows ME I only managed to get a kind of
>"read-only"-version: I can rename, change, ... (and sometimes even
>copy) existing files, but I can't create new ones with any
>Geos-application. This could be due to WinME (uses MS-Dos 8.0 instead
>of MS-Dos 7.x like Win95/98/98SE) or due to my settings or due to my
>virus-scanner or due to whatever. (Nevertheless creating directories
>worked fine!?)
>
>Since it worked somehow nevertheless, here's my short critic:
>
>First glance: Genial.
>Second glance: Uhoh!
>
>Pro:
>It works! All "Windowsfilenames", that aren't longer than a
>Geosfilename (32 chars), are shown correctly. All longer names get
>replaced by the Dosfilenames (e.g. BLABLA~1.TXT) on the display. Hence
>Geos stays compatible in any case. (And to be honest, it's hard to
>find longer filenames on an average Windows-harddisk ;-)
>
>Contra:
>* filenames, that are longer than 32 chars, get displayed in their
>short DOS-notation. That's compatible, but not very "nice". E.g. when
>downloading a HTML-documentation ander Windows you'll never know if
>you can use it completely ander Geos. Not to mention that filenames
>with a tilde (~) might confuse you: Has this file that name by
>purpose, or got it "renamed" Geos?
>* When switching from ms4.geo to mslf.geo (and vice versa), you'll
>encounter strange effects. E.g. NewDesk will report the lack of the
>drive C: and will close all windows. You can re-open those windows
>without any problems, but you should ensure that all Geos-apps are
>shut down before modifying your geos.ini, especially GeoWrite, ... !
>* When creating a directory like "WebPhoto" with mslf.geo, that
>directory will get the correct Windowsname "WebPhoto". And that name
>can be used with all Geos-programs. But the @dirname.000 won't get
>created. Result: After switching back to ms4.geo, that directory will
>show up as "WEBPHOTO" under Geos. And hence my WebPhotos-program
>wouldn't find its standard-directoy anymore. In other words: the
>"backward-compatibility" is missing!
>* Programs, that'll work with Dos-files (DOS-texts, DOS-pictures,
>DOS-soands, ...), sometimes don't work with the new long filenames and
>even might crash. E.g. the "Duplicate"-function in
>GeoManager/NewManager doesn't allow anything else than a new name in
>DOS-"8.3"-format. (At least you can assign a long filename under
>NewDesk later on ;-) (More and similar problems are explained in the
>below "programming"-section)
>
>Programming issues (for programmers and those who are interested in
>details):
>* When using FileEnum to get a list of Dos-files, it was sufficient to
>use a char[13] before. (12 chars for the max. Dos-name + 1 char for
>the trailing null.) But FileEnum under mslf.geo will create longer
>strings for the longer "dos"-names . And if it does so, it'll return
>zero found files and an error-message when the string's longer than 13
>chars.
>* The max. length of a filename is unclear to me. In the
>file-include-file you'll find two entries: 32 chars (as FileLongName
>or somethings like that) and 36 chars (as FileLongNameBuffer or
>something like that). Hence I'm using 37, if the names really could
>get the length of 36 chars. (There still has to be space for a
>trailing zero! ;-)
>* There are several Geos-functions, that work with Dosnames. The
>spooler's "JobStatus" e.g. has got a 8.3-Dosname, too. Has this been
>changed? And in which SDK-version? But what's even worse: The
>GenText-attributes ATTR_GEN_TEXT_LEGAL_DOS_FILENAMES,
>ATTR_GEN_TEXT_LEGAL_DOS_PATH, ... . Do they now work with long
>filenames, too?
>* Your own functions probably even won't work after increasing the
>space for a dos-filename from char[13] to char[37]:
>- filenames now can consist of spaces and other characters that have
>been illegal before (Not a problem in most cases, but you should test
>it anyway!)
>- filenames now can consist of more than one point and more than 3
>chars after the point. (My functions in WebPhoto e.g. don't differ
>between "1.GIF", "1.GIF.TXT" and "1.GIFBlaSülz" at the moment. It's
>all "1.GIF" to them!)
>- As a "normal" dos-name JPEG-pictures did have .JPG or .JPE as
>file-extension. But now the file-extension might even be ".jPg" (<- in
>other words: you'll have to be case-insensitive in your algorithms!)
>and of course they could even end with ".jpeg"!
>* There might be more "caveat"s. But I haven't found any official
>document (yet?). Hence this is just what Mr. Rainer Bettsteller and I
>have noticed so far.
>
>Summary:
>a) If you gonna test it yourself, use a test-installation! Not all
>programs will work correctly with the new long filenames and switching
>back to ms4.geo later probably won't work due the problems with
>directory-names.
>b) If you don't use Motif and/or the GeoManager, the long filenames
>will work fine under NDO2000/BBE. But you'll probably miss all those
>small third-party-apps ... (By the way: Mr. Rainer Bettsteller has
>already modified his GeoZip and Gonzo. My WebPhoto should work with
>those long filenames soon, too.)
>
>Jörg
>
>[/color]

Long file names are an interesting issue. Many apps were written before Win/DOS
LFNs were available to GEOS and deal with only 8.3 "native" file names. The GPC
was the breakthrough in Win/DOS LFNs since its DOS (DataLite) supported them and
the GPC was essentially a closed system.

As Jorg points out - experiment with mslf.geo at your own risk.

We at Breadbox are aware of the various issues and have them on our list of
things to tweak once GEOS32 reaches beta.

John ;-)

J?rg Polzfu? wrote:[color=blue]
> Long Filenames
>
> Several other Geos-users have already managed to get the
> GlobalPC-driver "mslf.geo" running on their "normal" PCs ander
> Win95/98/98SE to use the long "Windowsfilenames". So I tried it, too.
> Results:
> * Depending on your Geos-version, you'll either have to use "fs =" or
> "primaryFSD =". If you select the wrong "method", your Geos will crash
> :-(
> * In the DOS-box ander Windows ME I only managed to get a kind of
> "read-only"-version: I can rename, change, ... (and sometimes even
> copy) existing files, but I can't create new ones with any
> Geos-application. This could be due to WinME (uses MS-Dos 8.0 instead
> of MS-Dos 7.x like Win95/98/98SE) or due to my settings or due to my
> virus-scanner or due to whatever. (Nevertheless creating directories
> worked fine!?)
>
> Since it worked somehow nevertheless, here's my short critic:
>
> First glance: Genial.
> Second glance: Uhoh!
>
> Pro:
> It works! All "Windowsfilenames", that aren't longer than a
> Geosfilename (32 chars), are shown correctly. All longer names get
> replaced by the Dosfilenames (e.g. BLABLA~1.TXT) on the display. Hence
> Geos stays compatible in any case. (And to be honest, it's hard to
> find longer filenames on an average Windows-harddisk ;-)
>
> Contra:
> * filenames, that are longer than 32 chars, get displayed in their
> short DOS-notation. That's compatible, but not very "nice". E.g. when
> downloading a HTML-documentation ander Windows you'll never know if
> you can use it completely ander Geos. Not to mention that filenames
> with a tilde (~) might confuse you: Has this file that name by
> purpose, or got it "renamed" Geos?
> * When switching from ms4.geo to mslf.geo (and vice versa), you'll
> encounter strange effects. E.g. NewDesk will report the lack of the
> drive C: and will close all windows. You can re-open those windows
> without any problems, but you should ensure that all Geos-apps are
> shut down before modifying your geos.ini, especially GeoWrite, ... !
> * When creating a directory like "WebPhoto" with mslf.geo, that
> directory will get the correct Windowsname "WebPhoto". And that name
> can be used with all Geos-programs. But the @dirname.000 won't get
> created. Result: After switching back to ms4.geo, that directory will
> show up as "WEBPHOTO" under Geos. And hence my WebPhotos-program
> wouldn't find its standard-directoy anymore. In other words: the
> "backward-compatibility" is missing!
> * Programs, that'll work with Dos-files (DOS-texts, DOS-pictures,
> DOS-soands, ...), sometimes don't work with the new long filenames and
> even might crash. E.g. the "Duplicate"-function in
> GeoManager/NewManager doesn't allow anything else than a new name in
> DOS-"8.3"-format. (At least you can assign a long filename under
> NewDesk later on ;-) (More and similar problems are explained in the
> below "programming"-section)
>
> Programming issues (for programmers and those who are interested in
> details):
> * When using FileEnum to get a list of Dos-files, it was sufficient to
> use a char[13] before. (12 chars for the max. Dos-name + 1 char for
> the trailing null.) But FileEnum under mslf.geo will create longer
> strings for the longer "dos"-names . And if it does so, it'll return
> zero found files and an error-message when the string's longer than 13
> chars.
> * The max. length of a filename is unclear to me. In the
> file-include-file you'll find two entries: 32 chars (as FileLongName
> or somethings like that) and 36 chars (as FileLongNameBuffer or
> something like that). Hence I'm using 37, if the names really could
> get the length of 36 chars. (There still has to be space for a
> trailing zero! ;-)
> * There are several Geos-functions, that work with Dosnames. The
> spooler's "JobStatus" e.g. has got a 8.3-Dosname, too. Has this been
> changed? And in which SDK-version? But what's even worse: The
> GenText-attributes ATTR_GEN_TEXT_LEGAL_DOS_FILENAMES,
> ATTR_GEN_TEXT_LEGAL_DOS_PATH, ... . Do they now work with long
> filenames, too?
> * Your own functions probably even won't work after increasing the
> space for a dos-filename from char[13] to char[37]:
> - filenames now can consist of spaces and other characters that have
> been illegal before (Not a problem in most cases, but you should test
> it anyway!)
> - filenames now can consist of more than one point and more than 3
> chars after the point. (My functions in WebPhoto e.g. don't differ
> between "1.GIF", "1.GIF.TXT" and "1.GIFBlaSülz" at the moment. It's
> all "1.GIF" to them!)
> - As a "normal" dos-name JPEG-pictures did have .JPG or .JPE as
> file-extension. But now the file-extension might even be ".jPg" (<- in
> other words: you'll have to be case-insensitive in your algorithms!)
> and of course they could even end with ".jpeg"!
> * There might be more "caveat"s. But I haven't found any official
> document (yet?). Hence this is just what Mr. Rainer Bettsteller and I
> have noticed so far.
>
> Summary:
> a) If you gonna test it yourself, use a test-installation! Not all
> programs will work correctly with the new long filenames and switching
> back to ms4.geo later probably won't work due the problems with
> directory-names.
> b) If you don't use Motif and/or the GeoManager, the long filenames
> will work fine under NDO2000/BBE. But you'll probably miss all those
> small third-party-apps ... (By the way: Mr. Rainer Bettsteller has
> already modified his GeoZip and Gonzo. My WebPhoto should work with
> those long filenames soon, too.)
>
> Jörg[/color]

John Howard wrote:[color=blue]
> We at Breadbox are aware of the various issues and have them on our list
> of things to tweak once GEOS32 reaches beta.
>
> John ;-)[/color]

ah, did someone mention geos32? yes? :-)
--
C:\>

John Howard wrote:
[color=blue]
> As Jorg points out - experiment with mslf.geo at your own risk.
>
> We at Breadbox are aware of the various issues and have them on our list
> of things to tweak once GEOS32 reaches beta.[/color]

geos32? yes? when?

Hi!

John Howard wrote:
[color=blue]
> We at Breadbox are aware of the various issues and have them on our list
> of things to tweak once GEOS32 reaches beta.[/color]

It would be a very good idea to increase the size of long Geos-file-
directory-name from 32 to 256 when doing the other changes for Geos32 ;-)

Jörg

Hi!

AFAIK mslf.geo works with vfat12 (floppy-disks), vfat16 (smaller hard-disks)
and vfat32 (larger hard-disks).

* DOS-Versions known to work with mslf.geo:
MS-Dos 7.x (incl. in Win 95/98/98SE) (s. below)
OpenDOS/Dr-Dos 7.x (with some additional drivers)
Dr-Dos 8.x
Datalite RomDos (at least the 7.x-versions. I'm not sure about the
6.22-version)
the actual versions of PT-Dos

* DOS-Versions known to work somehow with mslf.geo:
MS-Dos 8.0 (incl. in Win ME) (s. below)

* There are some freeware-extensions that claim to work with freedos and
IBM's PC-dos 2000. But I haven't got any further details :-(

* According to several DOS-programmers' pages, the way Win95/98/98SE/ME
offers long file-names to DOS-apps differs from NT4.0/2000/XP. Hence AFAIK
mslf.geo doesn't work under NT4.0/2000/XP. (There are some drivers that
claim to fix this, but I haven't tested them. And I'm not sure whether
they'll only work with VFAT, or with HPFS/NTFS, too.)

* Under Win95/98/98SE/ME mslf.geo only works in the windows' dos-box or
under plain DOS with additional "DOSLFN"-drivers.

* Additional drivers/info can be found here:
[url]http://www-user.tu-chemnitz.de/~heha/hs_freeware/freew.html[/url]
[url]http://www-user.tu-chemnitz.de/~heha/en/hs_freeware/what_lfn.htm[/url]
[url]http://sta.c64.org/starlfn.html[/url]
[url]http://sta.c64.org/lfnemu.html[/url]
[url]http://www.geos-infobase.de/DOS13.HTM[/url]
[url]http://www.frontiernet.net/~fys/longfile.htm[/url]
[url]http://www.odi.ch/prog/lfn/index.php[/url]


I hope this helps,
Jörg

John Howard schrieb:[color=blue]
>
> Long file names are an interesting issue. Many apps were written before Win/DOS
> LFNs were available to GEOS and deal with only 8.3 "native" file names. The GPC
> was the breakthrough in Win/DOS LFNs since its DOS (DataLite) supported them and
> the GPC was essentially a closed system.[/color]

I think the main problem is a wrong approach.
The 8.3 name still exists even with windows long filenames.
So it is wrong to replace it with the windows long names.
The access to the windows long name should be tied tot he GEOS long name
instead.
So if I have a windows file (internally reported as NON-GEOS file) and
request a GEOS long filename, I would get the windows LFN instead of an
'Attribute does not exist' error.

This would keep 100% compatibility with old applications.

The main issue is not to create files with windows LFNs, but to have
access to windows LFNs.

Grossibaer

Very well said :-)

Jens-Michael Gross wrote:[color=blue]
> John Howard schrieb:
>[color=green]
>>Long file names are an interesting issue. Many apps were written before Win/DOS
>>LFNs were available to GEOS and deal with only 8.3 "native" file names. The GPC
>>was the breakthrough in Win/DOS LFNs since its DOS (DataLite) supported them and
>>the GPC was essentially a closed system.[/color]
>
>
> I think the main problem is a wrong approach.
> The 8.3 name still exists even with windows long filenames.
> So it is wrong to replace it with the windows long names.
> The access to the windows long name should be tied tot he GEOS long name
> instead.
> So if I have a windows file (internally reported as NON-GEOS file) and
> request a GEOS long filename, I would get the windows LFN instead of an
> 'Attribute does not exist' error.
>
> This would keep 100% compatibility with old applications.
>
> The main issue is not to create files with windows LFNs, but to have
> access to windows LFNs.
>
> Grossibaer[/color]

Thanks for your additional info, and together with some trial and
error................. ;-) I might get it to work......
BR,
Hans

On 2004-08-29 14:15, Jörg wrote:
[color=blue]
>Hi!
>
>AFAIK mslf.geo works with vfat12 (floppy-disks), vfat16 (smaller hard-disks)
>and vfat32 (larger hard-disks).
>
>* DOS-Versions known to work with mslf.geo:
>MS-Dos 7.x (incl. in Win 95/98/98SE) (s. below)
>OpenDOS/Dr-Dos 7.x (with some additional drivers)
>Dr-Dos 8.x
>Datalite RomDos (at least the 7.x-versions. I'm not sure about the
>6.22-version)
>the actual versions of PT-Dos
>
>* DOS-Versions known to work somehow with mslf.geo:
>MS-Dos 8.0 (incl. in Win ME) (s. below)
>
>* There are some freeware-extensions that claim to work with freedos and
>IBM's PC-dos 2000. But I haven't got any further details :-(
>
>* According to several DOS-programmers' pages, the way Win95/98/98SE/ME
>offers long file-names to DOS-apps differs from NT4.0/2000/XP. Hence AFAIK
>mslf.geo doesn't work under NT4.0/2000/XP. (There are some drivers that
>claim to fix this, but I haven't tested them. And I'm not sure whether
>they'll only work with VFAT, or with HPFS/NTFS, too.)
>
>* Under Win95/98/98SE/ME mslf.geo only works in the windows' dos-box or
>under plain DOS with additional "DOSLFN"-drivers.
>
>* Additional drivers/info can be found here:
>[url]http://www-user.tu-chemnitz.de/~heha/hs_freeware/freew.html[/url]
>[url]http://www-user.tu-chemnitz.de/~heha/en/hs_freeware/what_lfn.htm[/url]
>[url]http://sta.c64.org/starlfn.html[/url]
>[url]http://sta.c64.org/lfnemu.html[/url]
>[url]http://www.geos-infobase.de/DOS13.HTM[/url]
>[url]http://www.frontiernet.net/~fys/longfile.htm[/url]
>[url]http://www.odi.ch/prog/lfn/index.php[/url]
>
>
>I hope this helps,
>Jörg
>
>
>[/color]