W3C home > Mailing lists > Public > www-lib@w3.org > April to June 1996

Re: about HTFWriter_new

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Thu, 04 Apr 1996 15:16:02 -0500
Message-Id: <199604042016.PAA03602@anansi.w3.org>
To: Jiang Tao <jiangt@ceci.mit.edu>
Cc: W3C Lib <www-lib@w3.org>
Jiang Tao writes:

> I found that it is the same reason which cause libapp_4.c
> not to work on Wondows NT just as I mentioned before.
> In libapp_4.c, the stream HTFWriter_new is used, and the
> second argument of HTFWriter is a FILE *fp, which is
> opened in libapp_4.c while HTFWriter_write() (which is
> in WWWCORE.dLL) attempts to write data to this *fp.
> 
> The solution is to use HTSocket_DLLHackFopen() and
> HTSocket_DLLHackFclose() to replace the fopen() and
> fclose() in libapp_4.c, that's all.
> 
> I think the same reason causes ComLine not to work
> on Wondows NT, as the stream HTFWriter_new is also
> used in ComLine (HTLine.c). So, the key to the problem
>  is that whenever we use the stream HTFWriter_new on
> windows NT, we MUST use the HTSocket_DLLHackFopen() and
> HTSocket_DLLFclose() provided by w3 lib instead of
> using fopen() and fclose() directly.

This is correct. I am currently working on a more integrated model to handle
transport issues such as access to local file system, for example. This model
allows you to swap the transport so that you for example can use asynchronous
file access under Windows. Another result is that you will open and close any
file descriptors in the same mmodule (DLL) and hence the problem above will go
away.

-- 

Henrik Frystyk Nielsen, <frystyk@w3.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA
Received on Thursday, 4 April 1996 15:16:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:26 GMT