«

Our application uses two third party libraries that as far as I can tell
don't have x64 bit versions (TIBCO Rendezvous, IBM Websphere MQ). Both of
these libraries are static link libraries. I assume when I link my x64
program, all libraries have to be x64 bit also, is this correct? If so, is
there anyway to insert some sort of thunking layer in-between so that I can
move forward and create a x64 bit version of our program without having to be
dependent on the third party vendors having to supply an x64 bit version of
their libraries?

Note that I also posted this on: microsoft.public.vc.language
--
Thanks,
Nick

am
remove "nospam" change community. to msn.com

This is, primarily, an end user and IT Pro focused newsgroup (hence the
..general in the designation). As such, we're somewhat short of developers
here. You might have better luck asking this question over on one of the
MSDN forums.

That being said, you can't directly call a 32-bit DLL from a 64-bit EXE "in
process". If you can make the call out of process, you can make it work, as
I understand it, but we're pushing up against what I know.

--
Charlie.
http://msmvps.com/blogs/xperts64

"nickdu" <> wrote in message
news:1108BBFA-0CE6-4814-BB51-...
> Our application uses two third party libraries that as far as I can tell
> don't have x64 bit versions (TIBCO Rendezvous, IBM Websphere MQ). Both of
> these libraries are static link libraries. I assume when I link my x64
> program, all libraries have to be x64 bit also, is this correct? If so,
> is
> there anyway to insert some sort of thunking layer in-between so that I
> can
> move forward and create a x64 bit version of our program without having to
> be
> dependent on the third party vendors having to supply an x64 bit version
> of
> their libraries?
>
> Note that I also posted this on: microsoft.public.vc.language
> --
> Thanks,
> Nick
>
> am
> remove "nospam" change community. to msn.com

The good news, though, is that one can still compile 32bit code on a 64bit
system and provided that code doesn't dig deep into the system with any
direct hardware access that would otherwise require a Driver, the app will
run the same, or marginaly better. So anything that uses these libraries
could run unaffected as 32bit, while any new 64bit development would need
new support.

Tony. . .


"Charlie Russel - MVP" <> wrote in message
news:A51F7666-45CF-4FAC-8B42-...
> This is, primarily, an end user and IT Pro focused newsgroup (hence the
> .general in the designation). As such, we're somewhat short of developers
> here. You might have better luck asking this question over on one of the
> MSDN forums.
>
> That being said, you can't directly call a 32-bit DLL from a 64-bit EXE
"in
> process". If you can make the call out of process, you can make it work,
as
> I understand it, but we're pushing up against what I know.
>
> --
> Charlie.
> http://msmvps.com/blogs/xperts64
>
> "nickdu" <> wrote in message
> news:1108BBFA-0CE6-4814-BB51-...
> > Our application uses two third party libraries that as far as I can tell
> > don't have x64 bit versions (TIBCO Rendezvous, IBM Websphere MQ). Both
of
> > these libraries are static link libraries. I assume when I link my x64
> > program, all libraries have to be x64 bit also, is this correct? If so,
> > is
> > there anyway to insert some sort of thunking layer in-between so that I
> > can
> > move forward and create a x64 bit version of our program without having
to
> > be
> > dependent on the third party vendors having to supply an x64 bit version
> > of
> > their libraries?
> >
> > Note that I also posted this on: microsoft.public.vc.language
> > --
> > Thanks,
> > Nick
> >
> > am
> > remove "nospam" change community. to msn.com
>

Correct.

--
Charlie.
http://msmvps.com/xperts64


"Tony Sperling" <> wrote in message
news:...
> The good news, though, is that one can still compile 32bit code on a 64bit
> system and provided that code doesn't dig deep into the system with any
> direct hardware access that would otherwise require a Driver, the app will
> run the same, or marginaly better. So anything that uses these libraries
> could run unaffected as 32bit, while any new 64bit development would need
> new support.
>
> Tony. . .
>
>
> "Charlie Russel - MVP" <> wrote in message
> news:A51F7666-45CF-4FAC-8B42-...
>> This is, primarily, an end user and IT Pro focused newsgroup (hence the
>> .general in the designation). As such, we're somewhat short of developers
>> here. You might have better luck asking this question over on one of the
>> MSDN forums.
>>
>> That being said, you can't directly call a 32-bit DLL from a 64-bit EXE
> "in
>> process". If you can make the call out of process, you can make it work,
> as
>> I understand it, but we're pushing up against what I know.
>>
>> --
>> Charlie.
>> http://msmvps.com/blogs/xperts64
>>
>> "nickdu" <> wrote in message
>> news:1108BBFA-0CE6-4814-BB51-...
>> > Our application uses two third party libraries that as far as I can
>> > tell
>> > don't have x64 bit versions (TIBCO Rendezvous, IBM Websphere MQ). Both
> of
>> > these libraries are static link libraries. I assume when I link my x64
>> > program, all libraries have to be x64 bit also, is this correct? If
>> > so,
>> > is
>> > there anyway to insert some sort of thunking layer in-between so that I
>> > can
>> > move forward and create a x64 bit version of our program without having
> to
>> > be
>> > dependent on the third party vendors having to supply an x64 bit
>> > version
>> > of
>> > their libraries?
>> >
>> > Note that I also posted this on: microsoft.public.vc.language
>> > --
>> > Thanks,
>> > Nick
>> >
>> > am
>> > remove "nospam" change community. to msn.com
>>
>
>