Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Windows 64bit > COleDateTime not defined

Reply
Thread Tools

COleDateTime not defined

 
 
Michael Harvey
Guest
Posts: n/a
 
      08-15-2006
Hi, it seems COleDateTime is not defined in Platform SDK for Windows Server
2003 R2 when compiling C++ unmanaged code for the AMD64 platform. Is this
class available in 64-bits?

I use ParseDateTime and I don't think there is any equivalent in unmanaged
code. I hesitate to use managed code in case the .NET Framework will not be
installed on the target system, although I don't know how likely that would
be for someone with the 64-bit Windows OS.


 
Reply With Quote
 
 
 
 
Michael Harvey
Guest
Posts: n/a
 
      08-29-2006
I don't know if anyone thought about this problem, but I want to post my
solution. It seems if you are using the COleDateTime class in your unmanaged
WIN32 programs, you cannot port that over to a WIN64 program, as it does not
exist there. My solution is to keep the parts of the application that use
COleDateTime as WIN32 programs and use the COPYDATA Windows message to allow
handshaking with the WIN64 programs. I don't know if there is any easier
way. I would be interested in hearing about any suggestions.

"Michael Harvey" <> wrote in message
news:...
> Hi, it seems COleDateTime is not defined in Platform SDK for Windows
> Server 2003 R2 when compiling C++ unmanaged code for the AMD64 platform.
> Is this class available in 64-bits?
>
> I use ParseDateTime and I don't think there is any equivalent in unmanaged
> code. I hesitate to use managed code in case the .NET Framework will not
> be installed on the target system, although I don't know how likely that
> would be for someone with the 64-bit Windows OS.
>



 
Reply With Quote
 
 
 
 
Tony Sperling
Guest
Posts: n/a
 
      08-29-2006
Unless, impractical in your situation, if using '.NET' helps, I would
consider testing for the existance and provide for an alternative after
that. I don't know how x64 handles 'Environment Variables', that's usually a
pretty straightforward way to deal with [Inter Process Communication] I
think they used to call it.

Probably nothing wrong with 'COPYDATA', but it doesn't sound right, there
has to be time related functions to deal with this? Otherwise, how would you
be dealing with the different time formats that are used all around? Without
them, if this is to be network aware, you might have to do real-time
conversion otherwise.

Also, I think MS went and abandoned the term OLE, and put it all under the
COM paradigm, you might try and dig through there and see if other solutions
show up?

Take this with a grain of salt - loose thoughts from an old DOS guy.

Tony. . .


"Michael Harvey" <> wrote in message
news:...
> I don't know if anyone thought about this problem, but I want to post my
> solution. It seems if you are using the COleDateTime class in your

unmanaged
> WIN32 programs, you cannot port that over to a WIN64 program, as it does

not
> exist there. My solution is to keep the parts of the application that use
> COleDateTime as WIN32 programs and use the COPYDATA Windows message to

allow
> handshaking with the WIN64 programs. I don't know if there is any easier
> way. I would be interested in hearing about any suggestions.
>
> "Michael Harvey" <> wrote in message
> news:...
> > Hi, it seems COleDateTime is not defined in Platform SDK for Windows
> > Server 2003 R2 when compiling C++ unmanaged code for the AMD64 platform.
> > Is this class available in 64-bits?
> >
> > I use ParseDateTime and I don't think there is any equivalent in

unmanaged
> > code. I hesitate to use managed code in case the .NET Framework will not
> > be installed on the target system, although I don't know how likely that
> > would be for someone with the 64-bit Windows OS.
> >

>
>



 
Reply With Quote
 
Michael Harvey
Guest
Posts: n/a
 
      09-02-2006
I've looked all around for something to replace COleDateTime in 64-bit.
There's nothing for unmanaged code, but there is something superior in .NET
Framework that handles regional differences much better. However, I don't
want to assume that it's installed. Eventually I guess .NET Framework will
not be optional and then I will use it.

Regarding COPYDATA I already have handshaking between 16-bit and 32-bit
programs in 32-bit OS so it is easy to make it work between 32-bit and
64-bit programs.

"Tony Sperling" <> wrote in message
news:%...
> Unless, impractical in your situation, if using '.NET' helps, I would
> consider testing for the existance and provide for an alternative after
> that. I don't know how x64 handles 'Environment Variables', that's usually
> a
> pretty straightforward way to deal with [Inter Process Communication] I
> think they used to call it.
>
> Probably nothing wrong with 'COPYDATA', but it doesn't sound right, there
> has to be time related functions to deal with this? Otherwise, how would
> you
> be dealing with the different time formats that are used all around?
> Without
> them, if this is to be network aware, you might have to do real-time
> conversion otherwise.
>
> Also, I think MS went and abandoned the term OLE, and put it all under the
> COM paradigm, you might try and dig through there and see if other
> solutions
> show up?
>
> Take this with a grain of salt - loose thoughts from an old DOS guy.
>
> Tony. . .
>
>
> "Michael Harvey" <> wrote in message
> news:...
>> I don't know if anyone thought about this problem, but I want to post my
>> solution. It seems if you are using the COleDateTime class in your

> unmanaged
>> WIN32 programs, you cannot port that over to a WIN64 program, as it does

> not
>> exist there. My solution is to keep the parts of the application that use
>> COleDateTime as WIN32 programs and use the COPYDATA Windows message to

> allow
>> handshaking with the WIN64 programs. I don't know if there is any easier
>> way. I would be interested in hearing about any suggestions.
>>
>> "Michael Harvey" <> wrote in message
>> news:...
>> > Hi, it seems COleDateTime is not defined in Platform SDK for Windows
>> > Server 2003 R2 when compiling C++ unmanaged code for the AMD64
>> > platform.
>> > Is this class available in 64-bits?
>> >
>> > I use ParseDateTime and I don't think there is any equivalent in

> unmanaged
>> > code. I hesitate to use managed code in case the .NET Framework will
>> > not
>> > be installed on the target system, although I don't know how likely
>> > that
>> > would be for someone with the 64-bit Windows OS.
>> >

>>
>>

>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: __STDC_IEC_559__ (defined or !defined ?) Keith Thompson C Programming 0 08-17-2010 04:36 PM
User-defined exception: "global name 'TestRunError' is not defined" jmike@alum.mit.edu Python 1 07-10-2008 12:37 PM
defined? for recursive function call v/s defined? for function call stack Alok Ruby 3 04-13-2006 11:53 AM
Using parenthesis with defined (#if defined(...)) Angel Tsankov C++ 1 04-05-2006 10:00 PM
#if (defined(__STDC__) && !defined(NO_PROTOTYPE)) || defined(__cplusplus) Oodini C Programming 1 09-27-2005 07:58 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57