Re: Various MiNT questions

[bousch@topo.matups.fr (Thierry Bousch)]

Hello Evan,

> I hate doing that!   I know it may seem trivial, but lots of programs
> just want to take the command line argument and pass it to GEMDOS.
> Other programs call unx2dos or whatever.  Its hard to know which method
> should be used for which.

If a program doesn't accept the '/' separator, recompile it with gcc and
the MiNT libraries. If you don't have the source, trash it. You never
know, the binary could have been compiled with Pure-C or <shudder> Gfa-Bugsic.
Apart from STZIP, are there many TTP-programs whose source is not free?

> my system and it works as long as I'm on drive U:  And if standardized
> I could start using this in source code too, as in :
> 
>   Fopen ("/d/something",0);

Why not use fopen() instead?

> instead of Fopen ("\\d\\something",0);  It would make porting apps easier
> and would make MiNTLIB a bit faster since it wouldn't have to parse names
> all the time.

Someone has to do the job, if it's not the library it will be the kernel.

> Is it too late to make this change?  It doesn't slow anything down and
> doesn't break anything so far.  Id like to see it in 1.11 since 1.11 seems
> like it will be the standard.

Eric will certainly comment on this point, but in the very early versions
of MiNT, both separators were accepted by the kernel. According to MiNT's
Changelog, this was really painful to handle and has been removed very
soon.

To understand why this is painful, think of KNOPARSE filesystems
(especially tosfs) which expect a complete filename with their native
directory-separators (in this case, it's '\'). If the relpath2cookie()
routine receives a filename with mixed separators, it would have to make
a copy of this string before doing the translation (you don't want to
modify user-supplied strings), exactly as the MiNT libraries do.

Or, -all- filesystems would have to support both separators, but it would
only move the problem one level deeper.

Thierry.