Help! 64-bit programming question for an MVP
Marcus P.
Will a client developing 64 bit applications using my 32 bit COM server have
problems?
Ideally - the COM server "just works" and the host application still runs as
a native 64 bit app....
Any ideas?
TIA.
Charlie Russel - MVP
have no idea what the answer is, and none of the regulars that hang out here
are programmers. It _is_ a .general newsgroup, after all.
--
Charlie.
http://msmvps.com/xperts64
Rob Perkins
> You'll do better asking this question over on a programming newsgroup. I
> have no idea what the answer is, and none of the regulars that hang out here
> are programmers. It _is_ a .general newsgroup, after all.
>
It depends entirely on the scenario.
If you have a Win64 client calling a Win32 out-of-process server (a COM
EXE), or vice versa, then as far as I know your calls and data will be
marshalled over COM, and you shouldn't ever have a problem.
Win32 calling Win64 in-process COM DLL, I have no idea. It may not work,
but knowing Microsoft they found a way to shim it for 80% of cases. If
you're using COM already and you're willing, just give each COM server
its own process space and marshal things with proxy/stubs.
Win64 calling Win32 inproc DLL, the same sorts of things apply, but it
will probably work better than the other way, and you'll pretty much
need to give up on the idea of using more than the first 2 GB of RAM.
You might need to recompile the Win64 program so that it only uses the
first 2GB of its memory space. (there is a compiler flag for this, I'm
told) That way the WOW64 subsystem can load it and use it in WOW64.
Otherwise you pagefault/crash the machine without explanation...
The reason (one of them) for this is that Win64's system will
*sign-extend* pointers rather than zero-extending them. If you use a
32-bit memory page with a segment pointer containing a 1 in the 32nd
bit, the system will put all 1's in the upper 32 bits of the 64-bit
pointer when it converts the pointe to 64 bits.
Other such problems exist. The issue is still muddy for me; I plan to
get around it by putting all my high-comp loops into hand-compiled
Fortran (which is what they already are right now, I'm hoping for a
clean recompile when we target x64), shelling those and communicating
using the FileWatcher events for IPC, and writing the rest of my
software in a managed .NET language, with delegates watching the events.
And maybe forcing WOW64 emulation on everything for the time being.
It's more expensive that way in terms of OS resources, but my stuff
consumes all of a processor for hours at a time, so it's not a design
consideration. Much.
In any case, there are some whitepapers and things about the issue
somewhere in the MSDN documentation pile. I wish I could remember where...
Rob
![Andre Da Costa [Extended64]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVPtjmu0HZ5u4prXGFxbh8kY9Mm5ZLqv0W95PVTIqaPN5ctOg=s40-c)
Andre Da Costa [Extended64]
--
--
Andre
Windows Connect | http://www.windowsconnected.com
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta
FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm
"Rob Perkins" <rper...@usa.net> wrote in message
news:46iavhF...@individual.net...
Charlie Russel - MVP
Thanks for stepping in!
--
Charlie.
http://msmvps.com/xperts64
Rob Perkins
> You need a blog. ;-)
LOL. Yes, I do! And I have one, at http://www.parasiticmeme.com...
But the muse only descends on me in response to other Usenet postings,
unfortunately. This and the other recent long post are about it. The
rest of my stuff lately has been complaints about inexplicables related
to MS software.
Tell you what. I'll take the text of my last two long posts, and blog
'em. But old habits die hard, and I've long preferred the simplicity of
Usenet over the thousand formats possible with web forums.
Rob
Andre Da Costa [Extended64]
questions on 64-bit pop here from time to time and some of us like me don't
have a clue. :)
--
--
Andre
Windows Connect | http://www.windowsconnected.com
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta
FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm
"Rob Perkins" <rper...@usa.net> wrote in message
Dave English
<rper...@usa.net> writes
...
>In any case, there are some whitepapers and things about the issue
>somewhere in the MSDN documentation pile. I wish I could remember
>where...
Not sure about white papers as such, but
<http://msdn.microsoft.com/library/en-us/win64/win64/running_32_bit_appli
cations.asp>
is a good place to start.
In message <#NNj6$DPGHA...@TK2MSFTNGP12.phx.gbl>, Charlie Russel - MVP
<cha...@mvKILLALLSPAMMERSps.org> writes
>Hey, stick around, Rob.
> We could use some programming background here. :)
Though microsoft.public.windows.developer.winfx.general is a good place
for 64-bit Windows programming.
>Thanks for stepping in!
--
Dave English Senior Software & Systems Engineer
Internet Platform Development, Thus plc
Rob Perkins
> No problem, but like Charlie says, stick around, lots of programming
> questions on 64-bit pop here from time to time and some of us like me don't
> have a clue. :)
Heh. I happen to be a programmer who doesn't actually *want* the clue,
truth be told. Give me a managed language any day of the year.
Rob, not happy with Kernighan and Ritchie's lexical choices
Tony Sperling
Where would the world be without diversity?
I don't even call myself, 'Programmer', but I have a passion for coding -
'Intuitive Goofy Programming', you might call it - and I believe I recognize
the sound of at least part of your comment, although I am very pleased with
'C'.
Would you enlighten me, please, as to a couple of manageable 'managed'
languages???
Tony. . .
"Rob Perkins" <rper...@usa.net> wrote in message
news:46jjk5F...@individual.net...
Rob Perkins
> Hail, that!
>
> Where would the world be without diversity?
>
> I don't even call myself, 'Programmer', but I have a passion for coding -
> 'Intuitive Goofy Programming', you might call it - and I believe I recognize
> the sound of at least part of your comment, although I am very pleased with
> 'C'.
>
> Would you enlighten me, please, as to a couple of manageable 'managed'
> languages???
In my parlance a "managed" language is one that eschews pointers
altogether and manages memory for you. A partial list includes: Visual
Basic .NET, C#, J#, and Java.
If you live in that world, you almost *never* have to worry about the
OP's original question. Memory managed for you means memory you never
have to think about allocating or deallocating. An entire class of bugs
is therefore never encounterable, let alone encountered.
If you like C (I don't particularly, even though I speak it, but there
you are), then Java or C# are good choices to enter a managed environment.
Rob
Andre Da Costa [Extended64]
intimidating). could recommend some free ebooks Rob?
--
--
Andre
Windows Connect | http://www.windowsconnected.com
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta
FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm
Tony Sperling
Of course, I do agree. Pointers are a nuicance, and error prone. But I also
think the concept is surprisingly intelligent, and having to deal with them
keeps you on the 'straight and narrow'. And then there are so many things
that you can make them do that are extremely fast. I hate them - but I used
to feel mighty good about them when it turned out right.
'C#', indeed? That one passed over my head. O.K. I'll have a look at it.
Just because pointers are good for some jobs shouldn't mean I'd have to
subject myself to a kind of Spanish Inquisition.
Thanks, Rob!
Tony. . .
"Rob Perkins" <rper...@usa.net> wrote in message
news:46k2kpF...@individual.net...
Rob Perkins
> intimidating). could recommend some free ebooks Rob?
Hardly. If you're struggling with C#, try Visual Basic instead. Having
said that, though, if you're part of MSDN there are scads of virtual
labs you can try out, that can get you started with either.
Rob
Chuck Walbourn [MSFT]
vice-versa. out-of-process servers will work across 'bitness'. In-proc
servers will not. You can use the COM+ system to setup an automatic
out-of-process proxy for an in-proc server.
If your server is written in-proc for performance, you should create both a
32-bit and a 64-bit version of it.
--
Chuck Walbourn
SDE, Game Technology Group
This posting is provided "AS IS" with no warranties, and confers no rights.
Rob Perkins
> A 32-bit process cannot load a 64-bit DLL into the same process or
> vice-versa. out-of-process servers will work across 'bitness'. In-proc
> servers will not. You can use the COM+ system to setup an automatic
> out-of-process proxy for an in-proc server.
>
> If your server is written in-proc for performance, you should create both a
> 32-bit and a 64-bit version of it.
There you go, more concise than I could ever have done it.
Thanks Chuck!
Rob