Sorry for the late response - travelling without Internet access last week and for the rest of this week.
My changes so far have mostly been to improve the project files in the build process and to pull forward the code that got ripped out. Most of the porting issues are pretty standard - using SOCKET instead of int, line ending stuff, etc. The version that I am distributing an installer for at this instant is based on AOLserver b1-era code. It is roughly equivalent to the AOLserver 4-UH distribution from acs-misc (which came first), except for the installer and several bug fixes. I'm currently internally testing a version of AOLserver from the tip of the tree. I linked it against the RedHat pthreads library, which brings the Windows code much more in line with the non-Windows code. I've haven't tested this version very heavily and I don't have an installer for it yet, but it *seems* to work as well or slightly better than the one I have up right now.
I use CVS, WinMerge, and some perl scripts to keep my development tree up-to-date with the AOLserver changes. It isn't very hard to bring changes AOL makes over to my version. The only problem would be if they started to make extensive use of APIs that aren't available on Windows, and that shouldn't happen before a stable v4 is out anyway.
When I last looked, Cygwin was missing many of the pthreads functions that AOLserver was using. I think this might no longer be true. If all the API functions used are in Cygwin, it is usually just a matter of tweaking some Makefiles to get something to run under it. There would be a performance hit because of the emulation libraries of course, but it would ease the transition for people used to developing on Unix.
I've been driven by a few things. One is that I'm much more comfortable programming on Windows since I worked as a Windows developer for a few years. (For MIT's WinAthena project.) Another reason is that I needed close integration with Windows programs - for example, using OLE automation to automatically log MSN messenger chats on the website or authenticating our Windows users against the ActiveDirectory. It is easier to run these on a single box. And using Windows in a mostly-Windows shop means that it will be much easier for someone to carry on my work after my contract expires next year. Finally, until I got a second box up and running, I had to host my site on my main development machine, which has to be Windows for non-OpenACS related reasons.
