Hi,
When using floating point in a driver it looks like the machine code generated by the WDK’s wxp environment generates symbols that can only be resolved using the WDK’s wlh libraries.
For example I modified the WDK’s mirror sample found in WINDDK\6000\src\video\displays\mirror\disp . In the screen.c file’s bInitPDEV routine I added some simple floating point conversions :
{
// test
float fConstant = (float)ppdev->ulBitCount;
// float -> 1.10 format
LONG lResult = (LONG)(fConstant * 1024.0f);
red = lResult;
}
Then I specified that I needed to link with libcntpr.lib (which is supposed to be exporting the floating point support routines for me) by modifying the sources file:
USE_LIBCNTPR = 1
GDI_DRIVER_LIBS= X:\WINDDK\6000\lib\wxp\i386\libcntpr.lib
When I compile this sample code in the WDK’s wxp environment I get an unresolved external :
\winddk\6000\src\video\displays\mirror\disp\screen.obj : error LNK2019: unresolved external symbol __ftol2_sse referenced in function _bInitPDEV@16
Now the interesting part is that if I modify the sources file again to link with the wlh version of libcntpr.lib it compiles fine… :
GDI_DRIVER_LIBS= X:\WINDDK\6000\lib\wlh\i386\libcntpr.lib
Calling dumpbin or link /exports on the two different libs confirms that one exports ftol2_sse while the other doesn’t.
Any ideas on what’s making the microsoft compiler think that it should be using the sse version over the non-sse one?
I could re-implement ftol2_sse for microsoft but it doesn’t make much sense that it doesn’t work. I’m thinking that either there’s a define I could set that would force the compiler to use the non-sse ftol2, or maybe microsoft has changed the default build parameters to include sse I’ll check this out too.
Thanks for any help!