I didn't have time to address everything in my last post so I'll take a second bite of the cherry. :-)

Dean Kent (dkent@realworldtech.com) on 5/14/07 wrote:
---------------------------
>>In our case I don't actually have any urgent plans to make the software itself
>>64 bits. 4GB is actually enough for our software, at least for a while. (By
>>the time you get to over 2GB of data in our case the performance is the limiting
>>factor, not the available memory.) The problem is that we can't get close to 2GB
>>on a normal 32 bit Windows PC. The maximum possible project size available to the
>>user is constrained by the software's ability to access memory, whereas running
>>the same 32 bit software on a 64 bit OS the user is constrained by their own patience.
>
>While it may not result in development costs, it is likely that it results in support
>costs. Customers will complain about performance, and even if the answer is to
>upgrade - it still costs support time and effort.

Everything has a cost, yes. But not everything costs the same.

I can't speak for the general case but I know exactly how much time and effort and maintenance costs we have incurred in trying to deal with memory issues in 32 bit Windows. I also know every time we have had to choose a "more complex, slower, but more memory efficient" algorithm vs a "simpler, faster, but more physical or virtual memory intensive" algorithm in order to implement something. The customer never sees that as a direct cost, but it's in there -- new releases are delayed and new features are omitted because we spend more time implementing and debugging something than we otherwise would have, customer data is sometimes lost because a bug crept in there due to the complexity of the code, and so on.

Interestingly, the only support costs we have incurred so far from customers who are using 64 bit systems that were as a result of them using 64 bit systems occurred right at the beginning, when the driver for one of the hardware components wasn't yet mature, but by the time customers started using it the supplier had posted an update on their website so we simply asked them to download a new driver.

Currently customers with 64 bit systems are being unfairly punished because we still incur the costs of making the software work well on a 32 bit system, and not only does that make the code more buggy and slower to develop but it also means they are not getting the performance out of it that their systems are capable of. Maintaining 32 bit support definitely has costs, and I am very confident that the costs to the end users are far greater than the costs they might have incurred had they switched to a 64 bit system, even if that meant having a dedicated PC just to run our software and their regular PC for everything else.

>Nonetheless, the original point was (and is) that the average user does not need
>it, and therefore has little incentive to move to it. As you indicated, even those who *do* need it may resist.

Yes, but if you think the average user is only going to move to it when they need it, then I think the fact that my new notebook came with 64 bit Vista without even being advertised as doing so suggests that a lot of people will quite quickly have a 64 bit OS without even knowing it, let alone needing it.

Very few people actually need the computing power that they currently have, but that doesn't stop them from getting it, and I don't see why 64 bits will be any different.