Jeremy White wrote:
> AFAIK, the only reason we have to use the CRTDLL fopen is
> so that the file handle is known to Wine. That way, if the program
> uses any non CRTDLL Windows API on the file handle, it will work.
The other major thing that we need WINE's fopen for is handling Windows
style pathnames: glibc is unlikely to be able to open D:\foo\bar.baz
> However, in my experience, code that uses fopen() tends to only
> use fwrite() and fread(). Thus, I believe that code like that would
> mostly work. Further, if we're working with Winelib with code
> that doesn't behave as I expect, IMHO it would be better to normalize
> all of that code than to wrapper and/or reinvent glibc.
We mostly just have to wrap it, not reinvent it, I think. The
exception is for some of the things like reading and writing Windows
style CR/LF text files.
Hmm - it appears as though the MSVC 6.0 EULA may allow redistribution
of the MSVCRT DLL under liberal enough conditions that closed source
(but not open source) Winelib apps could use it. I don't know if this
is something that we'd *want* winelib apps to do, but it's an intriguing
possibility if the linkage issues could be worked out.
-Gav
--
Gavriel State
CEO
TransGaming Technologies Inc.
[EMAIL PROTECTED]
