It appears to me that even with the coming of MTOS we will still
be stuck with  FILENAME.EXT for the future. This isn't
all that desirable for some folks (like myself). I will put out a few
ideas how to get longer filenames out of GEMDOS , and maybe you'd like
to comment on it. (Eventually we will force Atari & Microsoft to adapt
this standard (har har))

 o The most obvious: kill GEMDOS beneath the system calls. This implies
   a totally new disc structure (*slobber*)

 o The most simple: add a translation table  to the disk structure, that maps
   long filenames to short filenames (uniquely of course, short filenames
   should be then out of reach for regular GEMDOS accesss (like Fopen..).
   This requires with HDs a lot of RAM for caching and slows down I/O a bit.

 o The most kludgey: in an effort to remain MSDOS compatible, how about this:
   Since a directory entry is somewhat like this  (pseudo-C)

   struct _foo
   {
        char filename[8],
             ext[3],
             filetype,
             otherstuff[ 20];
   }

   one might consider allocating two successive entries in the directory
   table. So that the full filename would be constructed from this

   struct _baz
   {
        char filename[8],
             ext[3],
             filetype,
             otherstuff[ 20];
             unused = 0xE5;
             longfilename[ 31];
   }

   union _bar
   {
        struct _foo;
        struct _baz;
   }

   pseudo access code (just for illustration purposes):
   /* -------------------------------------------------------------------- */
   #define LONGFILENAME 0x80

   extern char *filename;      
   _bar *p;

   if( ! (p->_foo.filetype & LONGFILENAME))
   {
        memcpy( filename, p->_foo.filename, 11);
        return;
   }    
   memcpy( filename, p->_baz.filename, 8);
   memcpy( filename, p->_baz.longfilename, 31);
   memcpy( filename, p->_baz.ext, 3);
   return;
   /* -------------------------------------------------------------------- */

   In order to hide the second entry from older TOS versions and MSDOS
   one might set longfilename to $E5 per default, as to not have it
   listed in the old-style DIR search. Maybe the filetype byte ought to
   be left alone as well. All this oughta yield a max filesize of ca.
   40 chars, which is a LOT better than 11.
   To distinguish between oldstyle and newstyle filenames, one can use
   a free filetype bit.

Conceivably 'kludgey' could even be done w/o the official sanctioning
of Atari.

Nat!
--
Email: wallm...@backus.pu.informatik.th-darmstadt.de
         "Bang that bit that doesn't bang"

I have two other alternatives:

- On a directory table there is 10 bytes unused per file. This can be
used to extend the filename to 18 characters.

- On IBM world there is a program called 4DOS that creates a file
called DESCRIPT.ION that is hidden and that contains descriptions
of the files on that directory. A program would have to be written
to update the descriptions when files are erased, copied or moved.
Another program would read the descriptions and update the directory
window. I wouldn't mind sacrificing the date and time to have more space.
====================================================================
| " Competence, like truth, beauty and   =   Carlos J. C. Varela   |
| a contact lens, is in the eye of the   =   EENG6801.RYERSON.CA   |
| beholder."                             =   Fnet Node: #18, #38   |
====================================================================

[In article <1992Mar24.002549.31...@infoserver.th-darmstadt.de>,
     wallm...@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes ... ]

 > It appears to me that even with the coming of MTOS we will still
 > be stuck with  FILENAME.EXT for the future.

I think that's still an unanswered question. If MultiTOS is truly based
on MiNT, it may be possible to use MiNT's installable file systems.
The real bottleneck is that the AES and application software assume
the 8+3 filename format and the backslash path delimiter.
 ---
 Steve Yelvington              Marine on St. Croix, Minnesota, USA
 st...@thelake.mn.org          umn-cs!thelake!steve

In a previous article, wallm...@backus.pu.informatik.th-darmstadt.de
(Natuerlich!) sagt:
+It appears to me that even with the coming of MTOS we will still
+be stuck with  FILENAME.EXT for the future. This isn't
+all that desirable for some folks (like myself). I will put out a few
+ideas how to get longer filenames out of GEMDOS , and maybe you'd like
+to comment on it. (Eventually we will force Atari & Microsoft to adapt
+this standard (har har))

It might not be quite the same thing, but I rather fancy the idea of
using the first few bytes of the file to contain its name, plus maybe
an icon.  This could be done within the MSDOS rules, although there
would be problems about how the files could have individual names in
the disk's directory.  Maybe the first 11 characters of each extended
filename would have to be unique..

There's probably some horribly obvious flaw in this method.  (:
--
Bush used your $$$ for this

In article <92084.102012EENG6...@RyeVm.Ryerson.Ca>, EENG6...@RyeVm.Ryerson.Ca
(Carlos Varela) says:

Come on, this exists since years and is called UNIXMODE. Better yet, use
the MiNT facilities for loaded file system drivers...
___________________________ cut here _____________________________________
JULIAN F. RESCHKE, HENSENSTR. 142, D-W4400 MUENSTER
EMAIL: JUL...@MATH.UNI-MUENSTER.DE, J...@MS.MAUS.DE
____________________ correct me if I'm wrong _____________________________

MultiTOS truly is based on MiNT (Atari showed it at CEbit, so I'm allowed
to say that much now :-)). Not every feature of MiNT will necessarily
appear in MultiTOS, and vice-versa; but it might not be unreasonable to
suppose that MultiTOS will have some sort of installable file systems.

Exactly. Actually, the backslash isn't so much of a problem (it's easy enough
to convert / <-> \) but all the existing applications that think that
all files have 8+3 uppercase names are going to be a real pain.

I should emphasize here that all of the above are my opinions only.
What Atari does with its operating system is its business, not mine,
and I cannot speak for them.
--
Eric R. Smith                     email:
Dept. of Mathematics            eric.sm...@uwo.ca
University of Western Ontario

In article <1992Mar24.002549.31...@infoserver.th-darmstadt.de>, wallm...@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
|> It appears to me that even with the coming of MTOS we will still
|> be stuck with  FILENAME.EXT for the future. This isn't

MTOS will be capable of using alternative file systems.

Frank

The thing with installable file systems is nice, but I consider this
(up till now) only a 'personal fix'. Assuming that I am a distributing
software, I'd assume that the default filesystem STILL to be GEMDOS.
And if GEMDOS has this 11 character limit, I can't see how you
can conveniently use long filenames 'outside' your computer.

Of course if at one time GEMDOS would be officially replaced by an alternative
filesystem, (being the "most obvious solution" from my orig. article),
I'd be more than happy, but I (somehow (har)) feel that this won't be the case
very soon.

Personally I believe (now), that having a filename translation table, is
probably the best (and easiest) way to go (at least for my programs). This
way one can optionally translate the filenames, to longer ones, and best of
all this is independent of GEMDOS at all. (A lot like Space Quest for this
matter...)

Thanks for the many reponses (also by Email)

Nat!
--
Email: wallm...@backus.pu.informatik.th-darmstadt.de
         "Bang that bit that doesn't bang"