Re: fwrite() failure in libwww
I did not have a chance to read to whole original mail that describes
the problem, but it seems to me that you might have used different C
runtime libraries in the libwww and you application. MSVC provides a
number of C runtime libraries. In the case that libwww is a DLL, the
correct C runtime library you should link is the Multithreaded DLL
(MSVCRT.LIB). This will let your application to read/write a file
descriptor that is opened in the libwww.dll. In MSVC studio, you can
choose MSVCRT.LIB by go to Build-Settings-C/C++/Category=Code
Generation. Make sure both libwww and your app are liked to MSVCRT.LIB.
Jimmy Han Tel: (415)574-3500 x 269
Principal Software Engineer Fax: (415)574-4657
Global Internet Software Group email: firstname.lastname@example.org
Eric Prud'hommeaux wrote:
> > Hi, Did you ever solve this problem ?
> > I am suffering from exactly the same problem.
> > I realize that you posted this two months ago, but there was
> > no followup to the issue in the libwww archive.
> > > My current environment is Windows NT 4.0 Workstation,
> > > usng the MS VC++ 4.2 compiler. I have the latest
> > > 5.0 library release: 5.0a. It built without (almost)
> > > a hitch.
> > >
> > > After 3/4ths of a day of monkeying around, I have
> > > come to the conclusion that the contents of
> > > the original file pointer opened up by HTLoadToFile() gets
> > > whacked somewhere along the way. Any other function that tries to
> > > access that file pointer (such as fwrite() in HTFWriter_write()
> > > or fflush() in HTFWriter_flush()) causes the program
> > > to crash...although I cannot find where this is happening.
> The problem is probably that the library that calls fopen is not the same
> library that is doing the module. I have no idea why this is a
> restriction, but have proven that it is with a simple case like:
> make a DLL project
> add lib.c:
> #include <stdio.h>
> _export FILE * myFopen(char * path, char * mode)
> return (fopen(path, mode);
> _export int myFwrite(void * ptr, size_t size, size_t nmemb FILE *
> return (fopen(ptr, size, nmemb, stream);
> make a new conslole app project that includes the first one
> add app.c:
> #include <stdio.h>
> extern FILE * myFopen(char * path, char * mode)
> extern int myFwrite(void * ptr, size_t size, size_t nmemb FILE *
> int main(void)
> FILE * file = myFopen("asdf", "w");
> int ret;
> ret = fwrite("asdf\n", 5, 1, file); /* fails */
> ret = myFwrite("asdf\n", 5, 1, file); /* succeeds */
> return ret;
> We did some reorganization to help this situation some time ago. Ideally,
> the FILE will be opened, written, and closed through the same DLL, kind of
> a pain though, sometimes. I don't believe I checked the test apps out on
> windows, so I'm not surprised that there are problems. Write back with any
> inspirations you have for solutions.
> thank you,