Re: TCL on Win64 for AMD64 with VS.NET 2005 beta 2?

On 2005-05-26, Jeff Hobbs <jeffh@activestate.com> wrote:
> Jeff McWilliams wrote:
>> Okay, I'm compiling with the VS.NET 2005 Beta 2 compiler after patching
>> the 8.4.9 release code with Pat Thoyt's VC++ 8 patch from SourceForge.
>>
>> Pat Thoyt passes -DUSE_32BIT_TIME_T to the compiler to try and get it to
>> not use a 64-bit value for time_t, stating in his VC8 patch
>> that TCL can't handle it.
>>
>> When I'm building with the VS.NET 2005 64-bit compiler, compilation
>> immediately fails.
>>
>> If you look at Vc\Include\crtdefs.h in the Visual Studio 8 install dir,
>> it has the following:
>>
>> #ifdef _USE_32BIT_TIME_T
>> #ifdef _WIN64
>> #error You cannot use 32-bit time-t (_USE_32BIT_TIME_T) with _WIN64
>> #undef _USE_32BIT_TIME_T
>> #endif
>> ...
>> it would appear that with this C runtime it's no longer possible to use
>> a 32-bit time_t. Any ideas?
>
> I would question why he thought Tcl can't handle a 64-bit time_t.
> It certainly can - and has with platforms like Solaris 64 for
> years. There may be a Windows-specific 64-bit time issue (as
> some of the clock stuff is Windows-only). However, I did make a
> patch recently to correct a 64-bit issue on Windows (compiling
> for Win-ia64) that may have been related.
>
> I would go on the assumption that 64-bit time_t works, and fix
> Tcl if necessary, not trick out some headers.
>

Okay, I've taken out the -D_USE_32BIT_TIME_T, and have modified my
generic/tcl.h to read:

#if !defined(TCL_WIDE_INT_TYPE)&&!defined(TCL_WIDE_INT_IS_LONG)
# if defined(__GNUC__)
# define TCL_WIDE_INT_TYPE long long
# if defined(__WIN32__) && !defined(__CYGWIN__)
# define TCL_LL_MODIFIER "I64"
# define TCL_LL_MODIFIER_SIZE 3
# else
# define TCL_LL_MODIFIER "L"
# define TCL_LL_MODIFIER_SIZE 1
# endif
typedef struct stat Tcl_StatBuf;
# elif defined(__WIN32__)
# define TCL_WIDE_INT_TYPE __int64
# ifdef __BORLANDC__
typedef struct stati64 Tcl_StatBuf;
# define TCL_LL_MODIFIER "L"
# define TCL_LL_MODIFIER_SIZE 1
# else /* __BORLANDC__ */
# if _MSC_VER < 1400
typedef struct _stati64 Tcl_StatBuf;
# else
# if defined(_WIN64)
typedef struct _stat64 Tcl_StatBuf; <- mine for WIN64
# else
typedef struct _stat32i64 Tcl_StatBuf; <- Pat's change
# endif
# endif /* _MSC_VER < 1400 */
# define TCL_LL_MODIFIER "I64"
# define TCL_LL_MODIFIER_SIZE 3
# endif /* __BORLANDC__ */
# else /* __WIN32__ */

We're not using the VS.NET 2005 compiler for 32-bit so I can't say whether
it's correct to leave Pat's changes for _stat32i64 in or out. His changes may
be okay when compiling for X86, they may not. I'd have to stare at
sys/stat.h more before coming to a conclusion about which of Microsoft's
variants for stat64 is the right one to use in 32-bit mode.

One other thing I noticed.

In win/tclWinDde.c, DdeServerProc params 7 and 8 are defined as DWORD.
In the latest Ddeml.h (found in VS.NET 2005\PlatformSDK\Include)

the callback function for DdeInitialize() defines params 7 and 8 as being
ULONG_PTR - meaning they're 32-bit on WIN32 and 64-bit on WIN64.

I don't think we personally use the DDE feature, but the compiler
generated a warning for this - and I'm sure it would be an error
to accept a 32-bit int when a 64-bit int is passed.

How are you folks dealing with
Microsoft's LONG_PTR, ULONG_PTR, DWORD_PTR datatypes within TCL?
Do you use them to be compliant with the "polymorphic"
multi-bitted-ness of Microsoft's API or are you avoiding them?

Jeff
Received on Thu Sep 29 14:19:23 2005