[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Freetype] Re: Summary of ANSI preprocessor trouble..
From: |
Antoine Leca |
Subject: |
Re: [Freetype] Re: Summary of ANSI preprocessor trouble.. |
Date: |
Thu, 14 Dec 2000 11:53:26 +0100 |
Peter Montgomery wrote:
>
> I noticed that many of the solutions for the include files take the
> form of paths such as...
>
> #include <freetype/freetype.h>
>
> How is this being handled on Win32 platforms where the path separator if
> "\" and not "/" ?
No problem here.
This is a restriction of the _interface_, not of the OS. Since the
introduction of paths in MS-DOS 2.0 back in 1982, the OS is perfectly
happy with both forms; Windows and other peripheric components sometimes
choked on that, but these BUGS were quickly discovered and corrected.
Similarly, Win32 (and the others) allows a lot of "strange" characters
in filenames, but you can notice that in the few ones that remains
forbidden, there is '/'. This is not by chance.
And in the particular case of the C environment, compiler writers take
extra care to ensure compatibility on this item, because of the large
Unix existing base for softwares. Look, on Macintosh where the path
separator really is a ':', any C compiler silently groks '/' in
pathnames (often including in fopen), and convert them to ':' when
talking with the OS.
Bottom line: don't worry. 8.3 is a much bigger problem.
Antoine