Applications have to be compiled as either a 64bit or a 32bit executable which determines the size of a memory address among other things. Because the interface to windows passes pointers back and forth a lot this means that there is a hidden layer on 64bit machines that handles emulating a 32bit environment for older apps. On the other hand there are lots of subtle issues with going from 32bit to 64bit for an application that makes such conversions non-trivial if the code wasn't properly written in the first place. It can, and probably would be, a lot of work. I think you'd be surprised by the number of applications that are still 32bit on 64bit machines for that reason alone!
It might be worth the work to compile a 64bit version of ioFTPD for some performance advantages for those who are running 64bit OSs but obviously it wouldn't work on 32bit machines. But it goes beyond that because ioFTPD has dependencies. TCL is the biggest I can think of, but SQLite and OpenSSL are also needed. Today that isn't as big a deal as it would have been like 5 years ago, but I'm not sure 64bit TCL is really all that tested. Things like mySQL, nxTools, etc would all need 64bit support. I'm also not sure if the shared memory interface would get broken. In theory it should be because it uses pointers, but it might be possible to work around that.
Given all that I just don't see going to 64bit as a big priority. 2 releases of everything? Bleck. I've held off on supporting features found only in newer processes for the same reason. I like the fact that ioFTPD runs on really old 386, pentium, and athlon processors. However it might be worth seeing how much of a performance improvement we could get it we target new processors with a separate compile. The good news there is it would still be 32bit so we could re-compile the dependencies easily, but we wouldn't even have to do that if we didn't want to...
|