Re: [libmicrohttpd] Real Windows support?

[Luke-Jr]

On Monday, October 14, 2013 7:08:15 AM LRN wrote:
> 2) Rewrite MHD to use Windows sockets and other Windows constructs
> (async callbacks, threads/fibers, completion routines, etc). This will
> most likely fork MHD, since the code you end up with will not be
> compatible with the POSIX abstractions that MHD uses.

Windows sockets basically just infer a change of headers included, an 
additional call at startup, and a different type for sockets (which is 
trivially resolved with a typedef). In my experience, it is otherwise 
completely compatible with standard BSD sockets. While Windows does have some 
advanced socket stuff, I concluded after some research that it doesn't provide 
any tangible benefits over using select.

> > Since my software already does
> > pretty much everything libmicrohttpd should depend on for other
> > protocols, perhaps I can help make this happen if I know what is needed.
> 
> What exactly does your software do?

In this context, it is basically an advanced proxy server (mainly for a non-
HTTP protocol). At a higher level (likely irrelevant to this conversation), it 
is a Bitcoin miner and mining proxy.

> > - Even then, I could never get a working Win64 build.
> 
> There have been some patches offered to plibc that would fix this.
> However, some things plibc does (like storing handles in 'int') don't
> work on x86_64, so it is still unclear what the right thing to do would
> be, and whether it's really feasible to do it, and whether that would
> break source-level compatibility with all plibc-using programs or not.
> Few people really need x86_64, so this issue never got any development.

IMO, the right thing to do is have the software use a typedef. For example, 
cURL uses curl_socket_t, and my own software uses SOCKETTYPE.

> > - It is calling setlocale(LC_ALL, ".OCP"), which screws up my program by
> > causing sprintf (uses in other protocols my software needs to support!)
> > to use commas for the decimal point instead of periods on non-English
> > systems (and who knows what other oddities).
> 
> I am not the one who added this, so i don't know what the reasoning
> behind it was.

This is the biggest problem for me right now, as it breaks RPC usage by users 
who don't even care about the HTTP server (which really is only present for 
legacy hardware, and not used in the modern protocols - so not a very common 
need).


On Monday, October 14, 2013 1:49:06 PM Evgeny Grin wrote:
> > On 14.10.2013 17:13, Evgeny Grin wrote:
> >>  Windows handles actually limited to 32-bit values, so no problem with
> >> it.
> 
> 14.10.2013, 17:26, "LRN" <address@hidden>:
> > That's news for me. Got any references for this one?
> 
> http://msdn.microsoft.com/en-us/library/aa384203.aspx
> http://msdn.microsoft.com/en-us/library/ms810720
> http://stackoverflow.com/questions/18266626/what-is-windows-handle-range-on
> -a-64-bits-application
> http://stackoverflow.com/questions/2699768/can-windows-handle-inheritance-> 
> cross-the-32-bit-64-bit-boundary

These seem to define current behaviour for backward compatibility, and 
probably can't be relied on long-term. :/

Admittedly, it may be useful as a stop-gap measure, but a real fix would 
probably need to store handles properly at some point.

Luke