Winternl.h Download

[Sabel Kantah]

Itshould be noted that the Windows docs do not in fact recommend linking against winternl.h - it's internal to Windows, and can change at any moment. If you need a function listed there, it's preferable to use run time dynamic linking, as the location of the function/structures you're using can change arbitrarily.

I had a problem with using winternl.h, I was using some of the datatypes out of there and have sucessfully compiled it for x64 without any problems. However I made some changes and now for some reason its failing to compile, through debugging I've found that the reason seems to be down to _WIN32_WINNT not being defined at all which causes winternl.h to not define any types. It was specifically this that was causing the problem with the PEB struct

Now the only thing I've seemingly changed is removing precompiled headers and creating a new class. Neither of which had the define for _WIN32_WINNT. I've created a brand new project copied the class that imported winternl.h over and compiled it fine. Everything is the same, imports, includes and libs etc. I can't get my head around what I did to cause this to not be defined. I've spent ages going over the two projects and cant find a cause for the problem.

I can upload the code to pastebin if need be however as both classes are the same in each project I shouldnt think this should make a difference. I guess I must of messed with something in the projects settings but I can't figure out what that may be

I've recently spent some time experimenting with the CallNtPowerInformation Win32 API call. If you are not familiar with this call, it's a Windows NT specific call that provides access to the power management related features of the OS. Among other things, it allows the current CPU frequency and battery charge to be retrieved. Like many other Win32 API's, CallNtPowerInformation has a very general prototype (notice the two LPVOID's for input and output):

To use CallNtPowerInformation, the InformationLevel argument specifies one of a number of different possible function codes. Some of these update power management settings, some retrieve current settings, and some retrieve system status values. Based on the function code, you provide input and output arguments via standard structures passed in via lpInputBuffer and lpOutputBuffer.

Where things might start to get odd is when you try to use the ProcessorInformation information level. This information level requires an output buffer of type PROCESSOR_POWER_INFORMATION. However, quoting from the MSDN documentation: "Note that this structure definition was accidentally omitted from Winnt.h. This error will be corrected in the future. In the meantime, to compile your application, include the structure definition contained in this topic in your source code." Peachy.

Being the dilligant programmer I know you are, you will, of course, want to check your return value when you call this function. Believe it or not, things are still wierd. To get the definition of the NTSTATUS typedef, you need to include winternl.h. To get the complete set of return codes, you need to include ntstatus.h. However, if you include both ntstatus.h and windows.h you get warnings about duplicate preprocessor definitions. This is because some of these constants are defined in both header files. To solve this little problem, you need to define WIN32_NO_STATUS before including windows.h and undefine it before including ntstatus.h. This tells windows.h not to define return codes and reenables return code definition for ntstatus.h.

The next problem you're likely to face is the fact that your program fails to link. This is because the powrprof.h does not explicitly specify C function linkage. If you include the header file unadorned in a C++ program, it'll assume C++ linkage, and try to call the API with a mangled name. This does not work, so you're forced to explicltly specify C linkage for the include file. The net result of all these complications might well end up looking like so:

The TIB is officially undocumented for Windows 9x. The Windows NT series DDK (as well as the MinGW/ReactOS implementation) includes a struct NT_TIB in winnt.h that documents the subsystem independent part. Even before TIB was effectively documented, many applications have already started using its fields that they are effectively a part of the API. The first field containing the SEH frame, in particular, is directly referenced by the code produced by Microsoft's own compiler.[1] The Win32 subsystem-specific part of the TEB is undocumented, but Wine includes a TEB definition in winternl.h.[2]

The TIB can be used to get a lot of information on the process without calling Win32 API. Examples include emulating GetLastError(), GetVersion(). Through the pointer to the PEB one can obtain access to the import tables (IAT), process startup arguments, image name, etc. It is accessed from the FS segment register on 32-bit Windows and GS on 64-bit Windows.

FS (for 32-bit) or GS (for 64-bit) maps to a TIB which is embedded in a data block known as the TDB (thread data base). The TIB contains the thread-specific exception handling chain and pointer to the TLS (thread local storage.) The thread local storage is not the same as C local storage.

A process should be free to move the stack of its threads as long as it updates the information stored in the TIB accordingly. A few fields are key to this matter: stack base, stack limit, deallocation stack, and guaranteed stack bytes, respectively stored at offsets 0x8, 0x10, 0x1478 and 0x1748 in 64 bits. Different Windows kernel functions read and write these values, specially to distinguish stack overflows from other read/write page faults (a read or write to a page guarded among the stack limits in guaranteed stack bytes will generate a stack-overflow exception instead of an access violation). The deallocation stack is important because Windows API allows to change the amount of guarded pages: the function SetThreadStackGuarantee allows both read the current space and to grow it. In order to read it, it reads the GuaranteedStackBytes field, and to grow it, it uses has to uncommit stack pages. Setting stack limits without setting DeallocationStack will probably cause odd behavior in SetThreadStackGuarantee. For example, it will overwrite the stack limits to wrong values. Different libraries call SetThreadStackGuarantee, for example the .NET CLR uses it for setting up the stack of their threads.

It is not common to access the TIB fields by an offset from FS:[0], but rather first getting a linear self-referencing pointer to it stored at FS:[18h]. That pointer can be used with pointer arithmetic or be cast to a struct pointer.

Using Microsoft Windows SDK or similar, a programmer could use an inline function defined in winnt.h named NtCurrentTeb which returns the address of the current Thread Information Block as NT_TIB *.[4]

3a8082e126