Hi, although I'm not a main developer, I think I can answer a bit.
I have Dillo built now as a native Windows VC++ 6 project and am debugging it.
cool !
Dillo uses pthreads and fork. Wouldn't it be better to use one multi-process API? Shouldn't it be all pthreads? Of course, there is no fork under
In the current CVS version I only found one reference to fork and it was to start a plugin. Currently, this is no longer used and is dead code. However, some way of starting the dpid automatically will most likely return - for the current CVS version this dpid has to be started manually. But either way, the plugins and the dpid are totally seperate programs. dpid is designed to only be started once. This functionality should be reproducable in Windows, I'd say :-) The other fork's are within the plugin framework when the dpid actually starts the requested plugin. You probably can delay that framework. Dillo will still work - with limited functionality.
Although Berkeley sockets are available in Windows, the AF_LOCAL protocol doesn't seem to be. I've faked that out to get Dillo to compile but more work may be needed there. Why are you using AF_LOCAL? What does that code do and why?
It's again related to plugins :-) ... dillo talks to its plugins via unix domain sockets. And that's what this code relates to. If you only need a help browser, you can ignore the plugin framework I would say. That way you will get no bookmarks, though. And the preferences are also planned to be done via a plugin. Or at least delay the plugin stuff until it matured. That's the cool part about the plugin design :-) I hope that helps, Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198