xsharp.eu

Hello!
I have an old VO 2740 program which uses OLEAutoObject to control Excel 2003. I created a OLELib.
As time passed by, the Excel version changed up to O365, but all 32 bit, and I never changed the created OLELib.

Now I ran the same exe on a new virtual machine with Win11 and Excel O365 64 bit.
I was just curious about the expected error or crash.
But it worked!? I could open the Excel file, get the content and store it in a SQL Server table like before.
Has anybody an explanation for this?
If I don't know the reason I can't trust it will be working always.

BR Kurt

I have seen solutions where Excel 64bit could access data with 32bit ODBC which normally is not possible. It was not the need for us to investigate, because we install now the 64bit ODBC where needed. It seems that Microsoft has implemented some mechanismns to open to Excel the "old 32bit world".
I believe that in any case you can't completely trust in OLE-Access. It is workplace-depending. The Excel installation can satisfy the needs and it can not. Excel can now be installed as a virtualized application where you don't have OLE access available.

Arne

Hi Kurt,
OLE/COM can cross the 32/64 bit border.
In fact, OLE is the only possibility for 32 bit applications (like VO) to drive Outlook 64 bit as MAPI does not works on 64 bit applications (it was impossible for Microsoft to port MAPI from 32 to 64 bit).
Wolfgang

Hello!
Thanks for your answers. Now it seems quite logical to me, as it is not about DLL in same process, but calling interfaces (OLE Automation) and as long as Excel provides this interfaces for 32 bit (too), they follow the interface definitions which must not change (only new ones additional are allowed) and how it is implemented on Excel side doesn't matter.
My VO program is just running on 4 computers and will discontinued soon, so no problem with different Excel versions and installations.
BR Kurt

Hi Wolfgang,

I struggled with this too in VO, thus limiting the outlook installation for users to the 32bit version.

However, in #x, using the SimpleMapi library (package https://github.com/PandaWood/Simple-MAPI.NET), much to my suprise,
I'm able to send mails using MAPI to outlook 365, 64-bit version client (see attachment)

Don't know how or why it works exactly, but it seems to be able to cross the 32/64 bit boundary for mapi.

You might give it a try if this works for you,

Luc

Hi Luc,
thank you very much for this!
Maybe I'm able to port that to X# and build a COM library from it.
Wolfgang

Hello All,

If a component has a 32bit version of the DLL installed in Windows\SysWOW64 folder it will work (despite 64 is in the name). Also, if the component has a 64bit version of the DLL in the \Windows\System32 (despite 32 in the name), it will work on 64bit system.

Kind of confusing at a first glance, but think of it in reverse.

So, that's why MAPI32.DLL works in both 32bit and 64bit OS modes because it exists in Windows\SysWOW64 and \Windows\System32 folders.

HTH,
Jamal

Excel automation is typically done via out-of-process COM (EXE). This can cross the 32/64 bit boundary because Windows marshals the calls between processes. It would not work with an in-process COM DLL. I regularly call Visual FoxPro 32-bit COM EXE servers from 64-bit .NET.