[Caml-list] What's wrong with win32?

[Caml-list] What's wrong with win32?

[Christophe TROESTLER]

Hi everybody,

The following simple program works well undex Unix/Linux :
----------------------------------------------------------------------
open Printf

let header machine port file =
  let addr = (Unix.gethostbyname machine).Unix.h_addr_list.(0) in
  let (ic, oc) = Unix.open_connection (Unix.ADDR_INET(addr, port)) in
  fprintf oc "GET /%s HTTP/1.0\r\n\r\n" file;
  flush oc;
  let rec read_more() =
    let s = input_line ic in
    let s = String.sub s 0 (String.length s - 1) in
    if s = "" then () else (
      printf "%s> %s\n" machine s;
      read_more()
    ) in
  read_more();
  Unix.shutdown_connection ic

let () = header "www.umh.ac.be" 80 "index.html"
----------------------------------------------------------------------

However, when I try to run it under windows 98, (and despite the fact
that it compiles fine to byte-code) I really get into trouble.  First,
the line "flush oc" raises the exception (!!!)

  Fatal error: exception Sys_error("Bad file descriptor")

Also "input_line" seems to wait forever to receive data.  I am not
familiar with win32, so maybe I missed something obvious.

Any help will be greatly appreciated.
ChriS

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What's wrong with win32?

[Christophe TROESTLER]

Ok, I reply to myself -- also to ask a subsequent question...

On Tue, 30 Mar 2004, Christophe TROESTLER <debian00@tiscali.be> wrote:
> 
>   let (ic, oc) = Unix.open_connection (Unix.ADDR_INET(addr, port)) in
>
> However, when I try to run it under windows 98 [...]
>   Fatal error: exception Sys_error("Bad file descriptor")

Ok, the trouble comes from the fact that Unix.open_connection uses
in_channel_of_descr of which the manual says

  in_channel_of_descr  does not work on sockets under Windows 95, 98, ME;
                       works fine under NT and 2000

Well, I tried the program under Win 2000 Professional and got the same
error...  Anyway, it would be nice that (1) open_connection be
mentionend in the manual as not working under win 9* or, even much
better, to make that (2) Unix.open_connection actually works under
win32!  IMHO it is quite unfortunate that in_channel_of_descr does not
work under windows for sockets since it basically forces the
programmer to reimplement input/output functions for these.

Is the current situation made for efficiency reasons (it is costly for
in/out channels to carry their type with them) or is there a deeper
problem with Win$ platforms?

Cheers,
ChriS

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What's wrong with win32?

[Correnson Loïc]

More over, it works very well on W2K with the previous release (ocaml-3.06).
It seems that there is a regression (bug submitted yet).
    LC.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What's wrong with win32?

[Xavier Leroy]

> >   let (ic, oc) = Unix.open_connection (Unix.ADDR_INET(addr, port)) in
> >
> > However, when I try to run it under windows 98 [...]
> >   Fatal error: exception Sys_error("Bad file descriptor")
> 
> Ok, the trouble comes from the fact that Unix.open_connection uses
> in_channel_of_descr of which the manual says
> 
>   in_channel_of_descr  does not work on sockets under Windows 95, 98, ME;
>                        works fine under NT and 2000
> 
> Well, I tried the program under Win 2000 Professional and got the same
> error...

As Loïc Correnson said, Unix.open_connection is broken under Windows
(all versions) in OCaml 3.07, while it works under NT/2000/XP in
earlier versions of 3.06.  This is a stupid coding error while fixing
another bug :-(  The patch against 3.07 sources is simply:

Index: csl/otherlibs/win32unix/unixsupport.c
diff -c csl/otherlibs/win32unix/unixsupport.c:1.18 csl/otherlibs/win32unix/unixsupport.c:1.19
*** csl/otherlibs/win32unix/unixsupport.c:1.18  Mon Jan  6 15:52:57 2003
--- csl/otherlibs/win32unix/unixsupport.c       Thu Apr  1 15:12:36 2004
***************
*** 61,66 ****
--- 61,67 ----
    value res = alloc_custom(&win_handle_ops, sizeof(struct filedescr), 0, 1);
    Socket_val(res) = s;
    Descr_kind_val(res) = KIND_SOCKET;
+   CRT_fd_val(res) = NO_CRT_FD;
    return res;
  }

> Anyway, it would be nice that (1) open_connection be
> mentionend in the manual as not working under win 9* 

Will do.

> or, even much better, to make that (2) Unix.open_connection actually
> works under win32!  IMHO it is quite unfortunate that
> in_channel_of_descr does not work under windows for sockets since it
> basically forces the programmer to reimplement input/output
> functions for these.

It does work (modulo the 3.07 bug) for the NT/2000/XP lineage of Windows.
Making it work under Windows 9x as well would require significant work
(see below), and I don't think it is worth it given that 9x is at
end-of-line.

> Is the current situation made for efficiency reasons (it is costly for
> in/out channels to carry their type with them) or is there a deeper
> problem with Win$ platforms?

It's not a question of efficiency, but rather of not reimplementing a
chunk of the C standard library.  More precisely:

- The buffered I/O channels of OCaml are implemented on top of the
Unix "file descriptor" abstraction and the Unix system calls open(),
read(), write(), lseek(), close().

- Under Windows, the C library provides an emulation of these Unix
idioms that encapsulate Win32 file handles as a Unix-style file
descriptor.  This emulation handles CRLF <-> LF conversion for files
opened in text modes, so it's not 100% trivial.

- In Windows NT/2000/XP, just like under Unix, socket handles (type
SOCKET) are compatible with file handles (type HANDLE), and basic
system calls that operate on the latter (ReadFile, etc) also work on
sockets.  Hence, wrapping a socket as a Unix-style file descriptor
(through the C lib API), then as a buffered I/O channel just works fine.

- In Windows 9x, socket handles are *not* compatible with file handles,
and ReadFile on a socket handle fails.  Therefore, the wrapping of
socket handles described above doesn't work.

- The Win32 implementation of the Unix library already maintains the
information "socket or file" on its file descriptors (type
Unix.filedescr), and arranges so that e.g. Unix.read calls ReadFile()
or recv() as appropriate.  However, to exploit this information at the
level of buffered I/O channels obtained with in_channel_of_descr
would require to throw away the C library emulation of read() et al,
and implement our own.  That's not completely trivial due to text mode
handling, and is in my opinion too much work for the purpose of
supporting Windows 9x, which is an horrible piece of software that
should die as quickly as possible.

Hope this answers your question.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What's wrong with win32?

[Christophe TROESTLER]

On Thu, 1 Apr 2004, Xavier Leroy <xavier.leroy@inria.fr> wrote:
> 
> Hope this answers your question.

It does.  Thanks for taking the time to explain in details.

> [...] too much work for the purpose of supporting Windows 9x, which
> is an horrible piece of software that should die as quickly as possible.

Well, I personally do not care much about win 9x but here some
students and faculty members still run win 9x (somehow understandably
as in their minds the alternative is XP which is quite memory hungry).
Thus I have to take care of that when I write software that they might
(will) run.

Cheers,
ChriS

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners