#3840 tclWin32Dll.c not buildable w/VC6

obsolete: 8.5b3
closed-fixed
5
2007-11-15
2007-11-13
No

Compiler error:
..\win\tclWin32Dll.c(557) : error C2065: 'DWORD_PTR' : undeclared identifier

Line in the source is:
|| ((DWORD_PTR)&tsdPtr < (DWORD_PTR)tsdPtr->stackBound)) {

VC5 does not have the define of DWORD_PTR in its basetsd.h. Stealing the define tree of it from the platformSDK got rather "branchy". I punted with this, but I don't know if it's correct (enough).

Index: tclWin32Dll.c

RCS file: /cvsroot/tcl/tcl/win/tclWin32Dll.c,v
retrieving revision 1.52
diff -c -r1.52 tclWin32Dll.c
*** tclWin32Dll.c 10 Nov 2007 19:01:35 -0000 1.52
--- tclWin32Dll.c 13 Nov 2007 18:41:15 -0000
***************
*** 15,20 ****
--- 15,25 ----

#include "tclWinInt.h"

+ /* VC++ 5.x doesn't define this, so punt. */
+ #ifndef DWORD_PTR
+ # define DWORD_PTR DWORD
+ #endif
+
#ifndef TCL_NO_STACK_CHECK
/*
* The following functions implement stack depth checking

Discussion

  • Donal K. Fellows

    Logged In: YES
    user_id=79902
    Originator: NO

    As a general C hacker, wouldn't DWORD_PTR be a *DWORD? (And shouldn't it be a typedef?)

     
  • David Gravereaux

    Logged In: YES
    user_id=7549
    Originator: YES

    It's one of those weird pointer as an int things as far as I can tell. And with win64 being odd about such things, I don't have a clue :) I'll let the experts hack this. I am not one.

    Yeah, it should be a typedef, but the older compiler doesn't have it in its <windows.h> tree. The platSDK does and so do the newer tools.

     
  • Donal K. Fellows

    Logged In: YES
    user_id=79902
    Originator: NO

    VC5 and win64? Now that's just perverse.

     
  • David Gravereaux

    Logged In: YES
    user_id=7549
    Originator: YES

    STOP it, you're getting distracted. DWORD_PTR is a built-up definition well entwined in macro mush for platform specs.

    The code determines the logic. The tool is used to build the source. Source and tool are separate issues.

    Please focus on DWORD_PTR missing under VC5. Maybe use #if _MSC_VER < 1200 (??) ... #endif if you like, I don't know what the correct solution is.

     
  • Pat Thoyts

    Pat Thoyts - 2007-11-14

    Logged In: YES
    user_id=202636
    Originator: NO

    WTF are you using VC5 for !?!
    DWORD_PTR is a unsigned integer type that is large enough to hold a pointer if someone casts a pointer to a DWORD this is what you should use in case the code gets compiled on Win64. There is also INT_PTR, ULONG_PTR, HANDLE_PTR, and ptrdiff_t for dealing with (ptr1 - ptr2).
    IMO as the compiler cannot handle the platform sdk headers for about the last 10 years, fuck it.

     
  • David Gravereaux

    Logged In: YES
    user_id=7549
    Originator: YES

    Sorry, VC6

     
  • David Gravereaux

    • summary: tclWin32Dll.c not buildable w/VC5 --> tclWin32Dll.c not buildable w/VC6
     
  • Joe Mistachkin

    Joe Mistachkin - 2007-11-14

    Logged In: YES
    user_id=113501
    Originator: NO

    Thanks for clarifying. As somebody with first-hand experience, I would just like to add that we should continue to support VC6 without any additional Platform SDK headers (i.e. VC6 SP6 "out-of-the-box"). The post-VC6 compilers (especially VC8) require jumping through a variety of hoops to compile the core properly and the recent Platform SDKs do not work properly with VC6.

     
  • David Gravereaux

    Logged In: YES
    user_id=7549
    Originator: YES

    Thanks Joe. The only limit on level of the tool used, other than this issue, is in Tk for the Vista theme code. That is properly blocked off by the makefile, so no concern there. And for that, I can plainly understand why the PlatSDK is required <wink/>

    This is a deep core file, not an additive feature.

     
  • Pat Thoyts

    Pat Thoyts - 2007-11-15

    Logged In: YES
    user_id=202636
    Originator: NO

    OK I can see the point -- the downside is that this isn't a macro but a typedef:
    typedef ULONG_PTR DWORD_PTR, *PDWORD_PTR;
    (in basetsd.h) so the #ifdef test won't work properly. Umm.

    VC8 shouldn't require any hoops jumped by now. The makefile.vc stuff should have it sorted.

     
  • Pat Thoyts

    Pat Thoyts - 2007-11-15
    • status: open --> closed-fixed
     
  • Pat Thoyts

    Pat Thoyts - 2007-11-15

    Logged In: YES
    user_id=202636
    Originator: NO

    Switching from DWORD_PTR to UINT_PTR seems a better fix. This type is available on VC6 and in more recent headers and works out to be the same thing. Its an unsigned int rather than an unsigned long but on the 32 bit x86 thats the same and on the 64 bit systems they both equate to unsigned __int64.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks