hi Willy,
Yes, I do have strange hobbies :-)
The short answer as to why is that in the games industry Windows servers
are not unknown. Plus during development it's helpful to have the ability
to run all servers locally on a developer's computer, which is usually
Windows for PC games.
Also, something of an academic curiosity for me personally. Like you said,
strange hobbies :)
The clang-cl warnings seem pretty obviously correct to me, and not just
platform differences, but I'll play around with the frontend compiler and
see if that changes anything.
The long problems were not too bad, since the compiler is pretty hardcore
about truncations. Honestly there were a lot more size_t to int conversions
than any long to pointers.
I'll upload what I have to my github sometime this week and send you a
link.
Thanks!
-amol
On Tue, Oct 29, 2019 at 9:56 AM Willy Tarreau wrote:
> Hi Amol,
>
> On Sat, Oct 19, 2019 at 09:41:34AM -0700, Amol Deshpande wrote:
> > hi,
> >
> > I've taken up a hobby task to make a native version of haproxy for
> Windows,
> > using some of the platform-specific features for network I/O.
>
> You're having strange hobbies in my opinion :-)
>
> > I've been using clang-cl to compile and it mostly works well. There are a
> > lot of warnings generated in the code that fall into two categories:
> >
> > 1. General warnings that are probably the difference between clang being
> > stricter than gcc.
>
> Do you have many of them? Some users (at least the ones on FreeBSD ans OSX
> I guess) commonly use clang if my understanding is correct, and a quick
> check at our CI on builds using clang doesn't indicate any warning, so
> they might be partially related to the platform.
>
> > 2. Size difference between unsigned long on LLP64 (Windows) vs Unix
> (mostly
> > LP64, i guess).
>
> Oh yes this is by far the real issue with this platform: there is no
> standard type which is the size of a native register on all archs.
> You have to switch to size_t and consorts to work around this mess :-/
>
> > The Windows stuff is a long way from a pull request yet, but if there is
> > interest I can send a pull request on github for just the common code I
> > have touched. It would be nice to have it upstreamed so I can concentrate
> > on just the gnarly bits.
> >
> > Please let me know (please CC me as I'm not yet subscribed to this list)
>
> So I'm not sure there is any particular interest given that it's not
> frequent to see that platform used on infrastructure components, and
> even a number of developers who have the choice tend to move away from
> it. However if the changes are minimal and non-intrusive, I'm not against
> getting them merged, if at least this eases your task next time you have
> to work on it. But I really have strong doubts regarding the type "long"
> which is broken there :-/
>
> Also do not bother sending a PR, they're automatically closed. We prefer
> reviewable patches here on the ML. If there is a place where your code
> is viewable (even if dirty, don't worry, we all know how it is during
> porting) please just send a link, I'm curious to see how you managed
> to work around all those longs we're using.
>
> Just a question, do you have a compelling use case or did you do it
> only for fun ?
>
> Thank,
> Willy
>