Wednesday, June 04, 2008

64 bit in a day!

I finally sat down and decided to port my code to 64 bit. I created a new configuration for x64, added Win64 to the predefines and fired off the build. And then it dawned on me, I have 3rd party libraries linking in a few projects (python, lua, gdlib, zlib, xerces/xalan, mysql, sqlite3, odbc and openssl). So I had to make quick decisions of whether to continue or stay with 32bit for a bit longer.

lua: using the actual source to build a DLL, no problem.
sqlite3: using the actual source to build a DLL, no problem.
zlib: 64 bit library I found and linked, no problem.
mysql: had to install the 64 bit version to get include/lib, no problem.
odbc: already native, just had to make a few variable adjustments in the code.
openssl: took a bit of wrestling with the code (assembly file had a syntax error and makefile was including an incorrect static library), in the end I build the 64 bit libs and all worked out.
gdlib: this was a bit tricky, since I could not find 64 bit libs, I had to build it myself inside my code (as I did with lua and sqlite3) but it then needed libpng and libjpeg, which had to be included. After some more wrestling with the config I managed to build it successfully.

And now for the casualties:

python was on the chopping block for a while, I really like lua as an embedded language and python for scripting in the shell. So I made a decision to not have python support from within the app server.
xalan/xerces has been a bit problematic from the beginning and multi-threaded tests occasionally failed which never happened with MSXML. I could not find 64 bit libs and the build system was depended on Configure, so I decided to not include it and rely on MSXML which is way faster and more stable on Windows. When I port to linux I will probably go with libxml2 and libxsl.

After all that the server itself built without a hitch and I was able to start and test it. I surprised myself that there were no portability issues with 64bits compile.

Made me so confident that I installed VMWare player with Ubuntu on it and created a makefile that built 1 of my source files... with about 300 to go; hey it's a start. I suspect the toughest part is going to be porting the synchronization, socket and file based classes; I have been on projects where I had to port code from windows to unix, so it shouldn't be too tough. The 3rd party stuff i have so far is pretty portable, so it should not present a big problem.


My biggest dilemma is what do I call my app server?!
Do I need an animal/plant/insect/object mascot?

All the good names that represent fast and lightweight have been taken by products that are often neither...
I have been busy for the last few months profiling, linting and optimizing the code. After numerous runs I have convinced myself and (used lint to prove) that there were no memory leaks in the code.

But I was still not convinced, so a friend suggested I run it through his DevPartner BoundsChecker to verify. After a bit of mucking around and restoring old MSDev 2005 vcproj files (apparently BoundsChecker doesn't work with MSDev 2008 at the moment or at least his version didn't). We ran it through a kitchen-sink style test and asked server to exit (I made sure you can do that via admin site). It did so and no memory leaks reported, and they all rejoiced and ate the minstrels. I tend to be very picky with code and was pretty sure that there were no leaks but had to be sure, it's a server afterall and a leak would adversely affect uptime.

Speaking of uptime, the server has been up for over a month (it gets bounced not because there are problems but rather I keep rebuilding it with newer features). I do get a decent number of hits mostly from zombies and bots looking for the latest PHP exploit (I am not kidding, 10-30 attacks on PHP per day, everyday, on my server which obviously doesn't even run PHP). It also helps that many of the HTTP requests are malformed or very long (like that Exchange bufferoverflow one I get every so often) and it tests lots of error handling. And all those port scans. Just more fodder for testing.