• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 678
  • Last Modified:

using CreateWaitableTimer in Non-MFC Code?

I am trying to include the function CreateWaitableTimer() and its associated functions into a 'C' program, that otherwise doesn't have anything to do with Windows or MFC.

It says to #include <winbase.h>. I did this. I then tried to compile it but got errors about DWORD. I found the definition of DWORD in windef.h, but then got errors in winnt.h about "winnt.h(2057) syntax error: identifier 'PCONTEXT' ". Well, PCONTEXT is defined above that in the same file.hhmmmmmm.

Anyway, it looks like I could spend days adding #include files into my file just to use this function, and getting them in the proper order. Can anyone help me use this function? What do I need to #include? Then comes the question of what libs I need to link with.....

Thanks,

Tom
0
gunn
Asked:
gunn
1 Solution
 
jhanceCommented:
CreateWaitableTimer is a Win32 API function (NT only by the way) and it's defined in winbase.h.  If you include that as well as windows.h, you should have all you need.  Be sure to link with kernel32.lib.  This function is not MFC but certainly requires a 32-bit compiler.  You didn't mention your environment, if you're not using a compiler which supports NT, then you can't use this function.
0
 
Tommy HuiEngineerCommented:
thanks for the quick response. Your answer is correct in that including windows.h did the trick (found that out shortly after the question...hehe).

Anyway, forgot to mention about the environment. I'm running WindowsNT4.0 w/ Service Pack 3, and the MSVisualC++ 5.0 compiler.

Heres my new problem with this function: I'm getting a 'CreateWaitableTimer' undefined: assuming extern returning int'
message. I went through winbase.h and found that there is a preprocessor definition #if( _WIN32_WINNT >= 0x0400 ) around the  prototype of the functions I need.  It seems to be not true as I would think.  Why is this not true in my case???


0
 
gunnAuthor Commented:
man, you guys are fast in your responses. before I could finish typing out the comment above about the problem, thui had answered my question!! It works fine now...thanks guys.
0
 
gunnAuthor Commented:
THE FOLLOWING IS FROM MSDN
Article Id : Q167799
Last Reviewed: March 31, 1998
Section 3 - Header File Conventions

In the header files, information guarded by


    #if _WIN32_WINNT >= 0x0400

is implemented only in Windows NT version 4.0 and later.
It is not implemented in Windows 95.
This precompiler guard allows you to do compile- time checking for platform differences.
The value of _WIN32_WINNT is set in WIN32.MAK, depending on the platform you choose to target.
By default, WIN32.MAK now sets the TARGETOS to WINNT and the APPVER to 4.0.
As a result, by default, _WIN32_WINNT is now defined as 0x0400.

If you are building an application to run on Windows 95 and you want compile-time notification of compatibility issues,
set TARGETOS=BOTH in your makefile.
When TARGETOS is defined as BOTH, _WIN32_WINNT is not defined for the precompiler,
and the only information parsed at compile time will be applicable to both Windows 95 and Windows NT.

If you do not include WIN32.MAK in your makefile,
you need to explicitly define _WIN32_WINNT as 0x0400 to get some of the new Windows NT 4.0- specific material from the header files.

There are several API sets present in Windows 95,
OEM Service Release 2 that are still guarded by (_WIN32_WINNT >= 0x0400),
e.g. the Cryptography API. If you are writing an application specifically for Windows 95,
OEM Service Release 2, and you want the header files to provide compile time access to these APIs,
it is necessary to define _WIN32_WINNT as 0x0400.
Notice that an application that uses these technologies will not run correctly on the retail release of Windows 95.
The vast majority of application programs that are expected to run on Windows 95 should be built without defining _WIN32_WINNT.


0
 
bhovanCommented:
THE FOLLOWING IS FROM MSDN
Article Id : Q167799
Last Reviewed: March 31, 1998
Section 3 - Header File Conventions

In the header files, information guarded by


    #if _WIN32_WINNT >= 0x0400

is implemented only in Windows NT version 4.0 and later.
It is not implemented in Windows 95.
This precompiler guard allows you to do compile- time checking for platform differences.
The value of _WIN32_WINNT is set in WIN32.MAK, depending on the platform you choose to target.
By default, WIN32.MAK now sets the TARGETOS to WINNT and the APPVER to 4.0.
As a result, by default, _WIN32_WINNT is now defined as 0x0400.

If you are building an application to run on Windows 95 and you want compile-time notification of compatibility issues,
set TARGETOS=BOTH in your makefile.
When TARGETOS is defined as BOTH, _WIN32_WINNT is not defined for the precompiler,
and the only information parsed at compile time will be applicable to both Windows 95 and Windows NT.

If you do not include WIN32.MAK in your makefile,
you need to explicitly define _WIN32_WINNT as 0x0400 to get some of the new Windows NT 4.0- specific material from the header files.

There are several API sets present in Windows 95,
OEM Service Release 2 that are still guarded by (_WIN32_WINNT >= 0x0400),
e.g. the Cryptography API. If you are writing an application specifically for Windows 95,
OEM Service Release 2, and you want the header files to provide compile time access to these APIs,
it is necessary to define _WIN32_WINNT as 0x0400.
Notice that an application that uses these technologies will not run correctly on the retail release of Windows 95.
The vast majority of application programs that are expected to run on Windows 95 should be built without defining _WIN32_WINNT.


0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

Tackle projects and never again get stuck behind a technical roadblock.
Join Now