Howdy, The point about libraries only available on Windows is a compelling reason for some support, given it mostly works today.
Honestly, AolServer isn't so bad at supporting Windows. I wrote most of the cross-platform code and was able to smash down quite a bit of the differences. The approach was to assume the programmer was versed in both Unix and Windows programming and just look for the minimally-invasive intersection between the two, using #idef's throughout as needed. This differs from Tcl where they do a great job isolating the platform code in the win/ source directory. You see the result, for example, with the SOCKET "type". It's a Windows thing, sprinkled throughout AolServer core, because SOCKET's aren't the same as file descriptors on Windows. So, as a Unix programmer, you have to stop and think "what's this SOCKET thing?" which is either a curiosity or a minor speed bump. Other weird Window'ism lurking are in process forking, log file moving, the "Server Control Manager", and those NS_IMPORT/NS_EXPORT declarations. The AolServer thread library is an exception. It stands alone and does a good job of providing a pthread-like interface for Windows and some value add (e.g., mutex lock contention counters, object names, a few other things). I think the answer to "what's the cross-platform burden..." is: 1. When you are writing core code on Unix, you have to still be thinking about Windows -- those SOCKET things, NS_EXPORT's and such, is there a drive letter in the path? Is there a \r before the \n in the line? -- those sorts of things. This can slow you down a little. 2. When you finally go to build on Windows, you have trouble setting up a build environment and resolving dependencies (e.g., OpenSSL, Tcl, etc.). This can be a real drag. This was particularly stressful for me because it always felt like a low-value time sink, often frustrating. So, I think the opportunity for re-factoring is not in the code, it's in the build environment. If someone can figure that out, it could be ok. I tried with the goofy nsconfig.tcl script and failed. -Jim On Sep 27, 2012, at 7:25 AM, Andrew Piskorski <a...@piskorski.com> wrote: > On Wed, Sep 26, 2012 at 09:07:07AM -0600, jgdavid...@mac.com wrote: > >> Should we dump the Windows port in favor of a clean Unix code base, >> configure, build, and install? > > Cross-platform portability is very Nice to Have, and I've actually > used it. Fortunately I've never had to deal with or even look at the > Unix vs. Windows compatibility layer, so I can't speak on its > maintenance burden. It just worked. That was really nice when > (unexpectedly) porting my code from Solaris to Windows. > > The AOLserver Windows build process back then indeed seemed pretty > bad; far too much unscriptable Microsoft project file crap. But I > thought someone cleaned that up later. > > On Wed, Sep 26, 2012 at 09:24:41AM -0600, jgdavid...@mac.com wrote: > >> For folks using Windows, I always follow up with the question: With >> VMware, Parallels, etc. today, even if you're bound to Windows >> hardware, can you just virtualize away the difference? > > Absolutely not. In my case, it's because I use AOLserver as a custom > app server, which needs to build against proprietary libraries that > are ONLY available on Windows. If what you need is a native Windows > library, running Linux in a virtualized container is of no help > whatsoever, you might as well be running on a remote Linux box. > (Cygwin I'm not sure about. Can Cygwin applications build with native > Windows libraries?) > > In my case, actually what happened is the proprietary vendor library > discontinued Solaris support, leaving only Windows, so I ported to > Windows. I'm still running it on Windows today. Now, if I was > writing that same app today I might do things somewhat differently. > But it was Really Nice that the custom AOLserver app I'd originally > written on Solaris mostly Just Worked when I ported it to Windows. > > My own AOLserver on Windows use case is likely very atypical, but I > think it's still a useful minor example of how cross-platform > portability can be unexpectedly helpful, even when you originally > didn't think you'd need or want it. > > Is cross-platform support in AOLserver worth the maintenance burden? > Not having worked on that code, I can't say. But I can say that the > cross-platform code does have real value, and was probably a lot of > work to get right way back when, so I'd caution against throwing it > out without a very clear case that doing so is worth more than the > loss, and that there isn't some better way to achieve the same gains. > > My (completely unfounded in any hard evidence) gut-level suspicion is > that 80% of the simplicity gains to be had from completely discarding > Windows support are likely achievable by instead re-factoring (somehow > or other) whatever parts are actually giving maintainers the most > trouble. > > -- > Andrew Piskorski <a...@piskorski.com> > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > aolserver-talk mailing list > aolserver-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/aolserver-talk ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
