error LNK2001: unresolved external symbol _fltused in wdk

Question

I am trying to define a double data type variable in a C code which is going to be used in the Windows kernel. The code compiles but gives error while linking. I tried using

Answer 1

Don't know if still applicable to current WDK but Walter Oney demotivates the use of floating point stuff in drivers here.

The problem is worse than just finding the right library, unfortunately. The C compiler's floating point support assumes that it will be operating in a an application environment where you can initialize the coprocessor, install some exception handlers, and then blast away. It also assumes that the operating system will take care of saving and restoring each thread's coprocessor context as required by all the thread context switches that occur from then on.

These assumptions aren't usually true in a driver. Furthermore, the runtime library support for coprocessor exceptions can't work because there's a whole bunch of missing infrastructure.

What you basically need to do is write your code in such a way that you initialize the coprocessor each time you want to use it (don't forget KeSaveFloatingPointState and KeRestoreFloatingPointState). Set things up so that the coprocessor will never generate an exception, too. Then you can simply define the symbol __fltused somewhere to satisfy the linker. (All that symbol usually does is drag in the runtime support. You don't want that support becuase, as I said, it won't work in kernel mode.) You'll undoubtedly need some assembly language code for the initialization steps.

If you have a system thread that will be doing all your floating point math, you can initialize the coprocesor once at the start of the thread. The system will save and restore your state as necessary from then on.

Don't forget that you can only do floating point at IRQL < DISPATCH_LEVEL.

There's FINIT, among other things. If you're rusty on coprocessor programming, my advice would be to tell your management that this is a specialized problem that will require a good deal of study to solve. Then fly off to Martinique for a week or so (after hurricane season, that is) to perform the study in an appropriate environment.

Seriously, if you're unfamiliar with FINIT and other math coprocessor instructions, this is probably not something you should be incorporating into your driver.

There is also an interesting read from Microsoft: C++ for Kernel Mode Drivers: Pros and Cons

On x86 systems, the floating point and multimedia units are not available in kernel mode unless specifically requested. Trying to use them improperly may or may not cause a floating-point fault at raised IRQL (which will crash the system), but it could cause silent data corruption in random processes. Improper use can also cause data corruption in other processes; such problems are often difficult to debug.