<2024年4月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

文章分类

导航

订阅

A compile error when upgrade ATL projects from VS2002 to 2003

Issue:

In the ATL projects generted by VS2002, there is a Proxy/Stub project which is used for RPC(Remote Procedure Call). When you open such project in VS2003, you will get a fatal error asserted by compiler like below.

 

#if !(TARGET_IS_NT50_OR_LATER)

#error You need a Windows 2000 or later to run this stub because it uses these features:

#error   /robust command line switch.

#error However, your C/C++ compilation flags indicate you intend to run this app on earlier systems.

#error This app will die there with the RPC_X_WRONG_STUB_VERSION error.

#endif

 

Solution:

Bringout the project settings dialog for the PS project and go to the preprocessor definitions by following Configuration Settings> C/C++> Preprocessor Definition.

 

Before you change, it look like this.

WIN32;_WIN32_WINNT=0x0400;REGISTER_PROXY_DLL;NDEBUG

 

What you need to do is changing the _WIN32_WINNT to 0x0500 or higher. The reason is the  ‘TARGET_IS_NT50_OR_LATER’ preprocessor is defined like as below:

 

#if (0x500 <= _WIN32_WINNT)

#define TARGET_IS_NT50_OR_LATER                   1

#else

#define TARGET_IS_NT50_OR_LATER                   0

#endif

 

Notes:

I provided a quick fix to solve the compile error when you update your ATL projects from VS2002 to VS2003 (refer my blog). Below is an in-depth explanation found in MSDN.

 

Some of the features of Microsoft RPC and the MIDL 3.0 and later compilers are platform-specific and intended for implementation in distributed applications that run only on Windows NT® 4.0 or Windows?2000. Some features are supported in Windows NT 3.51 and Windows® 95, as well as in later versions, but are not supported on older platforms.

As a precaution, the MIDL 3.0 and later compilers generate guards that facilitate compatibility checking during the C-compilation phase. MIDL generates two types of guards: a platform-dependent guard (32-bit versus 64-bit) and a release-dependent guard (feature set dependency). For example, MIDL generates the following guard to prevent C-compiling of a 32-bit stub for other platforms:

#if !defined(__RPC_WIN32__)
#error? Invalid build platform for this stub.
#endif

The release-dependent guard is triggered by a set of features found in the processed IDL file(s) and by the /target switch. For example, if the interface uses features supported only on Windows NT 4.0, Windows?2000, or later, MIDL generates a guard with the TARGET_IS_NT40_OR_LATER macro. If supported features require Windows NT 3.51 or Windows 95/98, MIDL generates a TARGET_IS_NT351_OR_WIN95_OR_LATER macro:

#if !(TARGET_IS_NT40_OR_LATER)
#error You need a Windows NT 4.0 or later to run this stub because it uses these eatures:
#error?? -Oif or -Oicf.
#error However, your C/C++ compilation flags indicate you intend to run this app on earlier systems.
#error This app will die there with the RPC_X_WRONG_STUB_VERSION error.
#endif

Other guard macros that can be used are TARGET_IS_NT50_OR_LATER and TARGET_IS_NT351_OR_WIN95_OR_LATER macro. These macros, defined in Rpcndr.h, depend on the environment variables winver and _win32_winnt and are evaluated by the C/C++ compiler.

If, at C-compile time, you get an error message indicating that you need a specific platform to run a stub, first check to make sure you have not used a feature that is not available on this platform. The features triggering a particular guard are listed in the body of the guard. In the previous example, the -Oicf compiler switch triggered the guard. Notable features of this kind include the /robust switch and the [async] attribute available on Windows?2000 and later, the pipe type constructor, the /Oif compiler option, and the [user_marshal] and [wire_marshal] attributes available on Windows NT 4.0 and later. Stubs using these features will not run on earlier systems.

Also, the technology needed to use OLE and OLE Automation data types (for example, BSTR or STGMEDIUM) in remote operations is present only on Windows?NT 4.0. Therefore, you cannot develop a custom interface that uses these data types in a remote procedure call to run on earlier platforms.

Note??Feature sets evolve and grow differently on Windows NT/Windows?2000 than they do for Windows 95/98/Me. Review the description of the /target switch for exact mapping between the two product lines.

If you know that your target platform is correct for the features you are using and still receive an error, you may need to set the environment variables appropriately.

Add this line to your makefile:

CFLAGS = $(CFLAGS) -DWINVER=0x400 

To build for Windows NT 3.51, Windows 95, or later releases

Add this line to your makefile:

CFLAGS = $(CFLAGS) -D_WIN32_WINNT=0x400

Note that this target control is not in effect when you are building for MS-DOS®, 16-bit Windows, or Macintosh platforms.

To build for Windows NT 4.0, Windows?2000, or later releases

Add this line to your makefile:

CFLAGS = $(CFLAGS) -D_WIN32_WINNT=0x500

posted on 2006年5月12日 22:16 由 Raymond

Powered by Community Server Powered by CnForums.Net