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

Does TCL 8.4.9 support Win64 on AMD64 or EM64T platforms?

Which compiler is recommended for this?

Due to some issues we've had with the Windows Server 2003 Platform SDK
compiler, I'm using the 64 bit C++ compiler that's part of Visual Studio
.NET 2005 beta 2.  Both of these compilers are incarnations of VC8, with
the VS.NET compiler being a later build than the Platform SDK version,
and using a later version of MFC, etc.

I noticed that there is a patch by Pat Thoyts against 8.4.9 on
SourceForge at
http://sourceforge.net/tracker/?fun...=310894


but it seems to have some issues.  Is further work being done on this?

Thanks,

Jeff McWilliams
Senior Software Developer
Altair Engineering

Jeff McWilliams wrote:
> Does TCL 8.4.9 support Win64 on AMD64 or EM64T platforms?
>
> Which compiler is recommended for this?
>
> Due to some issues we've had with the Windows Server 2003 Platform SDK
> compiler, I'm using the 64 bit C++ compiler that's part of Visual Studio
> .NET 2005 beta 2.  Both of these compilers are incarnations of VC8, with
> the VS.NET compiler being a later build than the Platform SDK version,
> and using a later version of MFC, etc.

Tcl 8.4.9 should support AMD64 out-of-the-box (I think I
had to make a recent one-line patch), but I've never tried
VC8 myself (and will try and stay away from it for as long
as possible).  All you really need is MSVC6 and the 64-bit
Platform SDK installed.

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

On 2005-05-26, Jeff Hobbs <jeffh@removethis.activestate.com> wrote:
> Jeff McWilliams wrote: 
>
> Tcl 8.4.9 should support AMD64 out-of-the-box (I think I
> had to make a recent one-line patch), but I've never tried
> VC8 myself (and will try and stay away from it for as long
> as possible).  All you really need is MSVC6 and the 64-bit
> Platform SDK installed.
>

Thanks.  I wonder if there would be issues mixing PlatformSDK compiled
TCL dll's with VS.NET 2005 compiled dll's and exe's.  Otherwise I may
try compiling using VC8 and the patch on SourceForge.

Platform SDK debugging issues really keep us from using it
for compilation of our main application code.

Jeff McWiliams -

Jeff McWilliams <Jeff.McWilliams@nospam.clanmcwilliams.org> writes:

>On 2005-05-26, Jeff Hobbs <jeffh@removethis.activestate.com> wrote: 
>
>Thanks.  I wonder if there would be issues mixing PlatformSDK compiled
>TCL dll's with VS.NET 2005 compiled dll's and exe's.  Otherwise I may
>try compiling using VC8 and the patch on SourceForge.
>
>Platform SDK debugging issues really keep us from using it
>for compilation of our main application code.
>
>Jeff McWiliams -
>

You might annotate the patch about the issues you have with it. Works
for me - but I don't have a 64 bit system.

--
Pat Thoyts                            http://www.patthoyts.tk/
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

On 2005-05-26, Pat Thoyts <cng@mfcyng.serrfreir.pb.hx> wrote:
> Jeff McWilliams <Jeff.McWilliams@nospam.clanmcwilliams.org> writes:
> 
>
> You might annotate the patch about the issues you have with it. Works
> for me - but I don't have a 64 bit system.
>

Okay - I'll keep notes and see if I can figure out how to submit any
annotations I may have.

Jeff

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?


Thanks,

Jeff

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.

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

On 2005-05-26, Jeff Hobbs <jeffh@activestate.com> wrote:
> Jeff McWilliams wrote: 
>
> 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 m
ay
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