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

libraries



Hi all!

Some thoughts about header files, libraries and so on.


(1) setmode

The new jpeg source (V4) has a switch for libraries with setmode(). This
function changes the mode of an open file, and there's no other 'good'
method, because ANSI has forgotten the problem of binary I/O on
stdin/stdout. Example:

#ifdef USE_SETMODE
#include <fcntl.h>		/* to declare setmode() */
#endif

...

#ifdef USE_SETMODE		/* need to hack file mode? */
  setmode(fileno(stdin), O_BINARY);
  setmode(fileno(stdout), O_BINARY);
#endif

Please add that to the libs (I already spoke with Peter Sollich, so that
he can add the same function to the standard Pure C libraries).


(2) XBIOS function names

I was going to repeat that all XBIOS calls should start with uppercase
characters... but now I see in falcon.h, that setmode() has been
renamed to Vsetmode()... :-)


(3) stdin binary?

entroy wrote in his mail concerning library PL26:
>Patchlevel 26 is likely to be the last patchlevel with TOS style (CR-LF
>pair) carriage control.  Unless I hear some really good arguments against
>doing so, I'm going to convert everything to UNIX style (LF) carriage
>control.  Many of the programs I use get really confused with TOS style
>files.  Also, J. Bammi's GCC libs use the UNIX style, so converting
>everything will make sychronizing the two libraries easier.

Here we go. Most of my text editors use CR/LF. Probably all GEM programs.
Libraries that can't read or write these files are useless for me. By
now, there's no ANSI method to do binary I/O on stdin or stdout, that's
why I propose to implement setmode() (see 1.). And for all properly
written programs, this is enough.

BTW: I have a lot of GEM programs which get confused by files *without*
carriage returns :-) And for *those* programs, I don't have the source
code (as opposed to most UNIX stuff).


(4) Operating system header files

In the last days, I've tried to port a program from PureC with Pure's
libraries to gcc with MiNT libs.

Unfortunately, some system functions have conflicting prototypes, and
most of the OS structures are defined differently. In addition, practically
*all* BIOS/XBIOS/GEMDOS structures are defined differently. And finally,
even the *names* of the include files are different.

Obviously, there's no way to change that without breaking existing
source code. My proposal: let's make a new standard (together with
Eric Smith, Pure Software and the Lattice guys). What we need:

(1) Standard prototypes for *all* operating system functions (perhaps
    we'll need a standard compiler.h for sizeof(int) and cdecl etc, too).

(2) Standard definitions of operating system structures. In theory, this
    should always be what Atari's documentation says (I *think* that
    this is what Pure does). In particular, I don't understand why
    the MiNT libs use _DTA instead of DTA and so on.

(3) A standard location for these files. Let's define a new subdirectory
    in include\, so that we can #include <tos/mint.h> or <tos/vdi.h>
    This would allow each of us to support 'old' programs.

All the other library stuff should be defined clear enough by ANSI (C)
or POSIX 1003.1. Of course, I am willing to do a part of the job.
Comments?


-- 
________________ cut here _________________________
Julian F. Reschke, Hensenstr. 142, D-W4400 Muenster
  eMail: julian@math.uni-muenster.de, jr@ms.maus.de
________ correct me if I'm wrong __________________