[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] MiNTlib - new functions



On Fri, Dec 25, 1998 at 07:28:31PM +0200, Petr Stehlik wrote:
> 1) keyboard input - something like kbhit() and getch()

I think these functions are missing on purpose.  Correct me if
I'm wrong but I think they were introduced by Borland for
Turbo C (and that's why they are very popular in M$-DOG
environments).  In which header file do you want to declare
them?  There is no standard one I think.

Currently they would pollute the library namespace so I would
opt against an implementation.

But the GNU binutils 2.9.1 for MiNT are almost ready (except for strip
and - sigh - gdb everything works, at least under Linux).  The
new linker will support weak symbols and this will give a chance
for a clean solution.  The library could then define the
symbols "kbhit" and "getch" as weak (so they can be safely
overriden by user-supplied functions) and the declarations
for them could be put inside "#ifdef __TC_COMPATIBLE__" or
the like.

> Do you have any suggestion how to implement a kbhit() function so it
> would work both under MiNT (probably using TTY) and under TOS (Cconis?)
> Or is it a good idea to use Cconis() under MiNT as well?

I think a select on "/dev/tty" will do the job.  Maybe you have
to put the terminal into raw mode before.

As far as I see it, this should work on all OSes, not only MiNT.

> 2) better support for LFN
> 
> In PARCP I use fopen(filename, "wb") for creating a file but I never
> bothered converting the filename to 8+3 if the dest filesystem was FAT.
> I always thought GEMDOS would convert it for me. However I have just got
> a bug report that said copying a filename containing SPACE char is a
> real killer for TOS FAT.
> 
> For example by creating a "ab de" filename GEMDOS really writes the "ab
> de" filename (including the space) to directory entry. But then, when
> reading the directory it shows just "ab". Thus the file is no longer
> readable, rename or delete is not possible.
> 
> I thought it would be nice if MiNTlib converted the filename for me.
> Any opinions or algorithms?

IMHO this is the file system driver's job, not the library's.  If
you really need the conversion you should read the mtools manpage
on your linux box.  The filenames produced by the algorithm 
described there look ugly but people are used to it (also from
W95) and you won't have to bother about duplicate FAT entries.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de