Calling 32-bit COM+ objects from 64-bit CF 9 ?

[paule1234]

We have an internally developed 32-bit DLL that works fine under CF 9 32-bit with a standard x=CreateObject("COM","myobject.myobject") call.  I am now preparing to transition to a 64-bit platform with Windows Server 2008 R2 and CF 9.01 64-bit.   When we try to create the object on that platform, we get a "Can not use  native code: Initialisation failed." error.

So, after much reading it seems there's this magical "COM+" that can bridge the gap between 64-bit and 32-bit apps.  I created a new COM+ application within the windows component services manager, added the DLL and TLB to the components within the application, and can see the process sucessfully fire up when I call createobject from an .aspx page.  However, when I try to call this from a CF9 64-bit cfm page I still get the  "Can not use  native code: Initialisation failed." error.  Not sure how to proceed debugging this, if even possible.

Anybody else gone down this road before?   Any chance Adobe will fix 64/32 bit COM interop anytime soon?

[Adam Cameron.]

I have to concede I might be revealing my ignorance here, but if it's internally developed, can you not just recompile it for 64-bit?

--

Adam

[paule1234]

The DLL was created in Visual FoxPro 9, which is at end of life and not capable of compiling to 64-bit.  Also, in turn, the VFP DLL calls another third-party ActiveX control for which there is no 64-bit version.

[Owainnorth]

Whilst I understand I'm not helping answer the question in the slightest (I would if I knew the answer) I do feel obliged to point out that like it or not, someone needs to re-write that DLL at some point soon.

Before you know it, you've got a 32-bit (eurgh) COM (eurgh) DLL being bodged into COM+ (eurgh) and then called from a 64-bit Java engine on 64-bit Windows. In all honesty, I cannot see Adobe being even vaguely interested in getting that working. Microsoft have completely dropped 32-bit platforms from their Server range, and given they only recently stopped supporting Windows 2000 that gives you an idea what an ancient technology it is.

If you add up the time taken by you, now, and the time taken when you upgrade to CF10 etc you may well find it's worth just ditching the DLL and rewriting it in something more useful and futureproof.

All too often I see companies get blinkered into "I need to achieve this one task" that you end up forever bodging things together, and it inevitably causes headaches. More often than not, the best option is just to rewrite the thing. Technologies move on, very rarely will it take as long to engineer a DLL now as it would have done even five years ago.

O.

[Adam Cameron.]

Owainnorth wrote:

[Stuff]

Well said.

--

Adam