[ofw] RE: patches for depreciated ExAllocatePool() calls

[Jan Bottorff]

>WSDK for Windows Server 2008 RC0 - WinDDK 6001.17051
>Not ready for prime-time yet....cl encounters internal compiler error on
>x86 build of ibal   :-(

We spent a bunch of time trying to get the IB stack to build with the WDK (6000 or earlier 6001), without total success.

The compiler internal error you talk about is know. Microsoft has an bug recorded in August 2007 as "Windows OS Bugs : 2014888". We were told it's a long path for a compiler fix to eventually make it into the WDK. 

The root cause is incorrect compiler processing of __ptr64 operations when the pointer is inside a structure. A work around is to specify the /Os compiler optimization option for projects/files that have this failure.

A sticky problem we came across is the behavior of how __ptr64 pointers are converted has changed between the DDK and WDK. In one case, there is I believe a global variable pointer initialized with (-1). The compiler expands this into a 64-bit wide value of 0xFFFF FFFF FFFF FFFF (on 32-bit builds). This __ptr64 value is assigned to the default destroy function pointer in the IBAL function array, which is not defined with __ptr64. The end result is eventually, when the destroy callback function pointer is used in some operations, its __ptr64 value is 0xFFFF FFFF and a 64-bit compare is used against the global with a value 0xFFFF FFFF FFFF FFFF, which is false. This results in a failure. I believe the DDK compile sign extended the 0xFFFF FFFF into 0xFFFF FFFF FFFF FFFF (which was wrong) when the pointer without __ptr64 is assigned to the pointer with __ptr64. 

There is no compiler error/warning when this __ptr64 mismatch happens, your code just crashes or run incorrectly. We didn't have a good way to verify every place in the IB stack this MIGHT have this problem. On though is perhaps we should just remove all the __ptr64 attributes and use some other strategy. My understanding is the purpose of __ptr64 is to make some structure have the same shape between 64-bit and 32-bit user mode. This is needed when you run 32-bit apps on 64-bit OS's. This also means test code for correct __ptr64 should include 32-bit user mode code running on a 64-bit OS.

Jan