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: jhan@gi.net

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 *
> stream)
> {
>     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 *
> stream);
> 
> 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,
> -eric

Received on Friday, 20 December 1996 13:59:13 UTC