- From: Henrik Frystyk Nielsen <frystyk@w3.org>
- Date: Thu, 04 Apr 1996 15:16:02 -0500
- 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 UTC