| Date: | January 21, 2004 / year-entry #26 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040121-00/?p=40983 |
| Comments: | 24 |
| Summary: | My code samples assume you are using the latest header files from the Platform SDK (free download), the one that includes support for Win64. If you have an older SDK then you won't have various new data types like UINT_PTR and INT_PTR and should just use UINT and INT. I write code that is Win64-compliant... |
My code samples assume you are using the latest header files from the Platform SDK (free download), the one that includes support for Win64. If you have an older SDK then you won't have various new data types like UINT_PTR and INT_PTR and should just use UINT and INT. I write code that is Win64-compliant as a matter of course since all code in Windows must be Win64-compliant. Writing noncompliant code is as foreign to me as it would be for a chess player to consider the ramifications of an illegal move. It doesn't even enter my mind. The question for readers: Should I assume that everybody has the latest header files? Or should I write old-style code (that won't run on Win64)? |
Comments (24)
Comments are closed. |
assume win64. better people get used to compliant code sooner rather than later.
I aggree. Show us the compliant way. That way we can learn. I know of no excuse for a serious developer not to use the latest Platform SDK.
Yes please use compliant code.
I have also just made my own code compliant.
What i do is include definitions for the new types in my headers. They can be turned on by a #define.
I do know of very good reasons for not using the latest platform sdk.
Every time when you install a new platform sdk you have a risk of code not compiling or running anymore.
For me this has been the case many times. sometimes it takes me several days to get everything fixed.
So you can only do this when you have enough time to fix everything up, and for example not when you are about to release a new version of your product.
Show us the right way; now that you can download the Platform SDK for free, there is no excuse for not having it.
You should toss the Platform SDK link in your Links section and maybe put some gentle reminders every so often to get it if people don’t have it.
I’d rather see your samples in Win64, since it will get me (and the other people) more exposed to this ‘new way’ of coding. The code I do is not Win 64 compliant since it is a huge app I am mantaining but I rather very much sample code on the net, like you, sets what I think should be a fine example.
Thanks for the very good blog,
Juan
Win64 compliant code is good. A lot of people haven’t gotten into the habit of writing compliant code yet – more public examples of it can only be a good thing.
Jack: done, link added. We’ll see if it helps any.
Something is still strange here. As mentioned in a previous thread, I use VS6SP5 for programming that will actually be delivered to customers. In that previous thread we did not discuss the Platform SDK, but since you mention it now, yes I also have the February 2003 Platform SDK installed. Nonetheless the relevant header file (which I named in the other thread) declares the function type TimerProc() and the function SetTimer() to take parameters of type UINT not UINT_PTR.
I am all in favor of your examples using current headers and valid code. But I still can’t figure out how you get different current headers than customers get.
I also still wonder, when you put shims in Windows to make broken programs work, will that include shims to make these two kinds of broken programs work:
(1) Programs that conformed to broken VS6SP5 implementations
(2) Programs that had buggly casts inserted in order to get them to compile while the programs’ own code conformed to MSDN’s datatypes and function prototypes.
I just downloaded the Platform SDK and took a peek at winuser.h: Its declarations are
typedef VOID (CALLBACK* TIMERPROC)(HWND, UINT, UINT_PTR, DWORD);
WINUSERAPI
UINT_PTR
WINAPI
SetTimer(
IN HWND hWnd,
IN UINT_PTR nIDEvent,
IN UINT uElapse,
IN TIMERPROC lpTimerFunc);
These match the current MSDN documentation.
So I guess I’m not looking at the same header file you’re looking at. (I tried to figure out which header file you were referring to but I couldn’t find anything in your previous comments that actually named a header file.)
I emphasize again that the type changes from Win32 to Win64 >>have no binary effect on Win32<<. On Win32, UINT_PTR devolves to UINT, so code that uses UINT is identical to code that uses UINT_PTR when compiled for Win32. It is only when compiling for Win64 that things go wrong.
So I don’t understand points (1) and (2), since the changes here have no code effect.
"On Win32, UINT_PTR devolves to UINT"
Ordinarily it does not. If it did then I wouldn’t get compilation errors when using UINT_PTR.
Now I’ve done a bit of poking around. It seems that the February 2003 Platform SDK doesn’t register its directories with Visual Studio 6. It doesn’t say which version of Visual Studio it registers its directories with, but I have the impression that it only registered its directories with Visual Studio .NET 2003 (in my case). This surely explains why VC++6 is using header files that came from VS6SP5 instead of header files from the February 2003 Platform SDK.
I suppose that in VC++6, every time I create a new project, I can go to its project settings, preprocessor category, and tell it to take include files from the Platform SDK’s directory. Now that I know that this didn’t get automated, I can do it manually.
In fact I just did that to an existing project, and it worked. It used a declaration of TimerProc with a UINT_PTR parameter, UINT_PTR devolved to UINT as you said, and no error resulted from this part of it. However, there’s a new error message:
error C2668: ‘InlineIsEqualGUID’ :
????????????????????????
??????(???;???????)
I didn’t code the call to InlineIsEqualGUID, that was put in by the MFC and/or ATL App Wizard. I wonder if I can figure out how to fix this.
Mr. Chen, any chance that you can use Unicode?
VC++&’s error message in the above posting roughly translates to:
error C2668: ‘InlineIsEqualGUID’:
Overloaded function call cannot be
resolved. (New functionality;
reference help.)
I don’t run this server, sorry.
Norman: in VC6 go to Tools | Options… | Directories. Add the platform sdk "include" directory *above* the vc98 stuff. Do the same for "bin" and "bin/winnt" to the executables and "lib" to the libraries.
Google for inlineisequalguid c2668 reveals the following page:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q243298 – BUG: Error Message: C2668: InlineIsEqualGUID: Ambiguous Call to Overloaded Function
Basically, ATL declares an InlineIsEqualGUID function, but now so does GUIDDEF.H in the Platform SDK headers. The use of ‘using namespace ATL;’ in atlbase.h (a very bad practice) causes the compiler to complain about ambiguity.
Updating the Platform SDK broke one thing for me. The debug version of MS Layer For Unicode (Unicode support library for Win9x) will not link with VC++ 6 anymore. For now, I just build the debug version with native Unicode. But I can’t debug it on Win9x anymore.
I’ve heard this was on a to-do list and may be fixed by now.
asdf recommended: ‘in VC6 go to Tools | Options… | Directories. Add the platform sdk "include" directory *above* the vc98 stuff.’
Done, AND also these two:
C:Program FilesMicrosoft SDKincludemfc
C:Program FilesMicrosoft SDKincludegl
Also did the bin and lib stuff as you recommended.
Now I worry what will happen when we deliver source code to customers, if customers have VS6SP5 but don’t have the Platform SDK.
Why is the Platform SDK separate from VS service packs? Why don’t VS service packs include the header, executable, and library files that the Platform SDK has? After all, how many platforms are there that are targeted by VS?
(Yeah I know, embedded Windows platforms used to be targeted by add-ons to the ordinary Visual Studio instead of the separate eMbedded tools stuff, so my question was maybe 90% valid historically, but surely my question is 100% valid now.)
No, don’t add the gl stuff to the includes.
You’re supposed to do:
#include <gl/gl.h>
not
#include <gl.h>
Not sure about the mfc ones though.
To asdf: Thank you again for your advice, and I deleted the gl directory from the includes.
To Mr. Chen: I know this isn’t your responsibility, but I also know you sometimes have contacts with them. How come MSDN still doesn’t have any plans to include the October 2003 Platform SDK in CD shipments to subscribers?
Actually I don’t know anybody involved in MSDN subscriptions, sorry.
Is there any way to get the platform SDK without using their funky ActiveX control (like a direct download or something)? AX Controls give me problems here….
There should be a link to the cab-files on the page (http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm). However I had some trouble to download them using IE6 and the page isn’t Netscape friendly (the links won’t show in Netscape). So I ended up by copy the links from IE into Netscape and the download worked.
The link provided by Andreas Magnussen still provides cab files for the February 2003 Platform SDK instead of the October 2003 version.
The file sizes are still almost unthinkable for anyone who uses a wireless modem for their personal internet usage (32kbps where I live, though faster speeds are available in densely populated areas).
Last PSDK, always