Re: VS 2005/C++/x64

Hi Jeffrey...

Now that you bring it up, I've always wondered about the difference between
_WIN32 and WIN32. Some projects you see both declared in the project
settings, sometimes one or the other. When you wade through the include
files, sometimes you see references to one and sometimes the other. Are the
_-versions just automatically set by the compiler and don't need to be set in
the project properties?

Is there a doc sheet saying which parameters are automatically defined when?

I think people mostly just took the defaults when setting up our build
projects, and we've got WIN32 explicitly in the project properties.

With respect to the CRT issue, I point you to <time.h>. I stumbled across
this while looking for definitions for size_t. At the top of that include,
it has a block saying "if _WIN32 isn't defined, blow up". Mid-way down the
file it has a check saying "if size_t isn't defined, define it either as 32
or 64 depending on architecture". Then lower down after that it has another
block saying "if size_t isn't defined, define it for a 32-bit architecture".
Seemed redundant at the very least.


""Jeffrey Tan[MSFT]"" wrote:

Hi Mark,

Sorry for letting you wait. I am discussing this issue with some VC++
developers internally.

This is a documentation problem. _WIN32 is always defined but _WIN64 is
defined when compiling for any 64-bit version of Windows.

When you compile for x86 "$env:ProgramFiles(x86)\Microsoft Visual Studio
9.0\VC\bin" Is used.
When you compile for x64 "$env:ProgramFiles(x86)\Microsoft Visual Studio
9.0\VC\bin\amd64" is used.

You may use the code snippet below to check if the _WIN64 macro is defined.
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
#ifdef _WIN64
#pragma message("_WIN64 is defined!\n");
#pragma message("_WIN64 is not defined!\n");
return 0;

Regarding the MSDN document issue , I would recommend you to use the links
in the SDK topic to submit to the Microsoft. The email goes into an
automated feedback system in Microsoft and ends up attached to a doc bug
internally which is assigned to the writer who owns the topic. Again, this
can take a little time to process but eventually it gets there.

Regarding using the ATL, MFC, CRT in x64, we do not believe there are any
new macros, _WIN64 should be enough.

Hope it helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support


Relevant Pages

  • Re: Statement on backwards compatibility?
    ... > this fundamental statement of WIN32 compatibility guarantee. ... No compile errors or warnings and I was able to run it all ... >> The terms upwards and backwards compatibility are a little ambiguous, ... >> refer to the expectation that products compiled on a higher O/S ...
  • Re: [Python-Dev] compiling python2.5 on linux under wine
    ... webkit itself comes in at 10mb alone. ... libxslt1 and libxml2 have compile errors in mutually incompatible ... versions on win32, plus, unfortunately, the versions that _do_ compile ... i tried hunting down python-gobject and python-gtk for win32, ...
  • Re: Statement on backwards compatibility?
    ... >>> this fundamental statement of WIN32 compatibility guarantee. ... No compile errors or warnings and I was able to run it all ... >>> go as far as saying LEGAL commitment) to their WIN32 developer base. ...
  • Re: Win32, Linux, .NET >> Where is this mess going to?
    ... What did you use to port the code from Win32 to .NET? ... What is the difference in exe file size when you compile to Win32 ... which project type you want, that you get 2 different component palettes, ...
  • Re: About VS C++
    ... Instead they have to have a different .NET support plan. ... People said the same thing about Win32 programming, ... Delphi 2 came out. ... that compiles fine in VS2005 needs heavier tweaking in order to compile in ...