Help! 64-bit programming question for an MVP

Discussion in 'Windows 64 Bit' started by Marcus P., Feb 28, 2006.

  1. Marcus P.

    Marcus P. Guest

    I distribute a 32 bit in-proc COM server to my clients.

    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.
     
    Marcus P., Feb 28, 2006
    #1
    1. Advertisements

  2. 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.
     
    Charlie Russel - MVP, Feb 28, 2006
    #2
    1. Advertisements

  3. Marcus P.

    Rob Perkins Guest

    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
     
    Rob Perkins, Feb 28, 2006
    #3
  4. You need a blog. ;-)
    --
     
    Andre Da Costa [Extended64], Feb 28, 2006
    #4
  5. Hey, stick around, Rob. We could use some programming background here. :)
    Thanks for stepping in!
     
    Charlie Russel - MVP, Feb 28, 2006
    #5
  6. Marcus P.

    Rob Perkins Guest

    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
     
    Rob Perkins, Feb 28, 2006
    #6
  7. Marcus P.

    Dave English Guest

    In message <>, Rob Perkins
    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.

    Though microsoft.public.windows.developer.winfx.general is a good place
    for 64-bit Windows programming.
     
    Dave English, Feb 28, 2006
    #7
  8. 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. :)
    --
     
    Andre Da Costa [Extended64], Feb 28, 2006
    #8
  9. Marcus P.

    Rob Perkins Guest

    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
     
    Rob Perkins, Feb 28, 2006
    #9
  10. 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???

    Tony. . .
     
    Tony Sperling, Feb 28, 2006
    #10
  11. Marcus P.

    Rob Perkins Guest

    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
     
    Rob Perkins, Feb 28, 2006
    #11
  12. I recently got Visual Studio 2005 Professional, trying learn C# (its so
    intimidating). could recommend some free ebooks Rob?
    --
     
    Andre Da Costa [Extended64], Mar 1, 2006
    #12
  13. Right - thank you very much.

    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. . .
     
    Tony Sperling, Mar 1, 2006
    #13
  14. Marcus P.

    Rob Perkins Guest

    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
     
    Rob Perkins, Mar 1, 2006
    #14
  15. 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.
     
    Chuck Walbourn [MSFT], Mar 2, 2006
    #15
  16. Marcus P.

    Rob Perkins Guest

    There you go, more concise than I could ever have done it.

    Thanks Chuck!

    Rob
     
    Rob Perkins, Mar 2, 2006
    #16
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.