On Tue, Sep 21, 2004 at 11:32:43AM -0700, Kelson Vibber wrote:
A few days ago I noticed that GTK+ and GLib are now available through the Cygwin installer, so I started reworking my directions for building Dillo on Cygwin (currently at http://www.hyperborea.org/software/dillo/cygwin.html ). I hadn't tried it since Dillo 0.7.3, so when I built 0.8.2 with the new built-in libraries, I discovered some problems with DPI.
First, since Cygwin knows it's running under Windows, it appends .exe to any executable files it builds. (When you run a command in Cygwin, it will look for the file as written, then look for it with .exe added -- so the compiler is really gcc.exe but you can still run it by typing "gcc".) This includes the DPI plugins, which end up being bookmarks.dpi.exe, downloads.dpi.exe, etc. This means dpid will not find them when it looks for available plugins unless you rename them.
Second, even after renaming them, I can't get any DPI plugins to actually work. Here is the output from clicking on the bookmarks button:
Nav_open_url: Url=>dpi:/bm/< url_str = dpi:/bm/ Dpi_check_uds: Connection refused /tmp/kvibber-5re3lm/dpid.srs debug_msg - init_sockdir: The socket directory /tmp/kvibber-5re3lm exists and is OK dpid started Capi_dpi_conn_timeout:: try 1 main.c:153: get_command: dpid tag is NULL : main.c:326: main: get_command failed : bookmarks.dpi (v.13): accepting connections... [accept]: Software caused connection abort
This error message from accept() is weird.
File permissions on the sockets look the same as they do on a Linux box (srw-------)
It may just be something about the way Cygwin handles sockets.
Most probably as this scheme works for the *BSDs, GNU/Linux, etc.
Unfortunately I have very little experience with sockets on *any* platform (and very little experience with C, for that matter)
Anyway, I figure Cygwin support probably isn't a priority, but I thought I'd point out the issues in case anyone was interested in tracking them down.
I don't have Cygwin (nor time) here to test it, but surely the Cygwin developers have a clue of what's happening. They probably would appreciate the report too, as they aim to provide the most POSIX like environment I guess. The best way is to test it by stages. The implementation of dpid is not that complex: there's an external daemon process 'dpid' which listens on named sockets and that launches the real dpis when there's activity in the respective named socket. When this happens, the new dpi process "takes over" the socket until it finishes. The details are in doc/Dpid.txt under the sections: "How does it work?" and "dpi service process diagram". Hope this helps. -- Cheers Jorge.-