By now you have heard a lot about the fact that under WOW a 32 bit process can get 4GB of VAS. I agree this is great, but I would like you to be aware of something that might hit you really hard. As it turns out enabling 4GB VAS can be problematic due to either 32 bit app you are using or dlls 32 bit application might end up loading.
In the past, past times, developers thought that 32 bit pointer can never exceed 2GB boundary and the max pointer is 0x7fffffff. This assumption was based on Windows architecture of splitting VAS into two major regions user and kernel each 2GB in size. Due to the assumption some developers have ended up using high bits of a pointer to store extra information. Knowing that those bits are not used anyway they, for example, play some tricks and implement blocking free data structures without support for cmpxchng8b... and then Windows added 3GB support http://msdn.microsoft.com/library/default.asp?url=/library/en-us/DevTest_g/hh/DevTest_g/BootIni_de16d3ec-c437-4628-805f-8945ea598a92.xml.asp. All the applications and dlls that made an assumption of half and half split between user and kernel broke down http://blogs.msdn.com/oldnewthing/archive/2004/08/12/213468.aspx.
It has taken a while to shake most of the problems off. The only problem is that nobody has ever expected that suddenly 32 bit application will be given not only 3GB but all 4GB so that many developers has continued relying on the fact that last 1GB can never be given to the app. Well, they have been wrong. Now 32 bit large address aware applications can get all 4GB of VAS to work with. And the problems have started crippling in as more and more of older 32 applications are moved on 64 bit machines to be run in WOW mode.
In the last several month we have seen several cases when user written dlls loaded into server process space bring it down due to incorrect handling of pointers in WOW. In this case server can't do much, for example, incorrectly written dll might corrupt process heap and will force server restart.
So here is my suggestions. If you are a system administrator you need to make sure that before moving critical large address aware application into WOW
A. You get sign off from your developers and developers of external dlls your application loads on correct pointer usage under WOW
B. You test and stress test the application on WOW as thoroughly as possible before making the move
If you a developer, you need to make sure that before running critical large address aware application into WOW, you remove all incorrect pointer manipulation including high bit usage, and possible pointer overflowing such as (a+b)/2
The bottom line of this post is if you can run an application natively in 64bit mode you probably should do that instead of trying continue running it as 32 bit in WOW.
So the question to you then: should you buy native x64 bit version of SQL 2005 instead of running SQL Server in WOW :-)? (Keep in mind SQL 2000 itself doesn't exhibit large address aware problem though dlls that developer/DBA can force SQL Server to load through extended procs or COM might hit the issue)
Have a nice week!