wxWindows: it's official!

Dimitrie O. Paun dpaun at rogers.com
Tue Jan 7 12:39:35 CST 2003


Sorry about my previous attempt, I've pressed Send by mistake.
And I've learned you can't stop KMail from sending... :)

On January 7, 2003 02:09 pm, Francois Gouget wrote:
> include/io.h
> include/msvcrt/io.h
>
> That seems like an include order nightmare. Furthermore your header only
> contains:
> int access(const char *__path, int __amode);

It's a big problematic, but not much. winegcc get this right anyway,
and I can't see how it can be a problem: if you use msvcrt, you first
have to include those headers. If not, they are not in the search path,
so they don't exist. What scenario to you forsee where this can be a
problem.

> If you use that function you will have to link with the msvcrt.
> Ortherwise your Winelib application is going to call the glibc access
> function which will choke on the Windows paths 'c:\Temp\xxx.tmp'. So it
> seems like you might as well use the msvcrt headers...

That's the user's choice. We need to support io.h, mingw has it, cygwin
has it. If we provide it only in msvcrt, we force everybody to use msvcrt, 
which is not right IMO.

Thing is, the cygwin io.h contains only these definitions:

extern long get_osfhandle(int);
extern int setmode (int __fd, int __mode);
int access(const char *__path, int __amode);

You can check it out at:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/io.h?rev=1.3&content-type=text/x-cvsweb-markup&cvsroot=src

Since program not using msvcrt expect only these funtions,
that's what we need to provide. I don't know what get_osfhandle(),
and setmode() are (they are not standard Unix functions), I've
added included only access().

-- 
Dimi.




More information about the wine-devel mailing list