Question may sounds strange but I want to make this question clear.
Some people talk about 64 bit Active-X components
64 bit COM(ActiveX) server
while others claim there is no 64x COM implementation
http://www.pcreview.co.uk/forums/64-bit-activex-vs-windows-forms-t3764967.html
Who is right? Can I implement 64-bit Active-X (dll COM server) ?
64-bit COM is alive and well on the 64-bit version of Windows. It wouldn't have Windows Explorer if COM was dead. And the many, many other Windows component that depend on COM. There's nothing in x64 code that could prevent COM from working.
You can write 64bit ActiveX controls for IE, but be aware they will only run in 64bit IE.
Also be aware 32bit IE is the default for users when they click the IE icon, even on 64bit Windows.
Related
Here is what I have:
Problem: Trying to connect two different 64-bit applications:
Microsoft Access 64-bit
QuickBooks Entrprise 21.0 (I'm not sure if it is actually 32-bit or 64-bit)
Using:
Visual Studio 2022 64-bit edition
VB.NET
64-bit version of QBFC15 library for QuickBooks
My thought is that when you use a 64-bit API, it would connect to a 64-bit application. I am most likely incorrect.
When I connect to MS Access in the debug 64-bit mode, it connects fine. The Intuit developer Network says you need to publish applications in the 32-bit mode. I have always used the 32-bit mode for publishing QuickBooks applications because they were 32-bit programs and, well, frankly, 64-bit applications hadn't come out yet (no old person jokes here). Anyway, I was really excited to see that the 64-bit version of a QBFC library came out (QBFC15) and they offer both 32-bit and 64-bit. So I downloaded the 64-bit version (which they recommend on their site https:\\developer.intuit.com>
So I'm thinking, hey, it's a 64-bit SDK! Yeah! So now I have this project that tells me I need to connect a 64-bit Access application to QuickBooks. When I debug, my new application connects just fine to MS Access in the 64-bit mode! Yeah! But the 64-bit Intuit SDK needs to be published in the 32-bit mode!!!! I'm confused. I know that they have put the cart before the horse and I know that they must still be running QuickBooks Enterprise in the 32-bit mode but come on. Putting out the SDK before the commercial product comes out to use it one? (I'm done whining now...got to get it out somehow!).
So how am I to connect my application to both "64-bit" programs when one errors in the 32-bit mode and the other errors in the 64-bit mode?
The programming isn't the issue, but this scenario seems really problematic. Do I tell the customer they need to downgrade their Microsoft Office to the 32-bit mode version? That would be an easy answer I guess, but it sure makes me look bad. Any other suggestions out there that could help me in this would be much appreciated.
If you running desktop edition of QuickBooks, then if you are running a x32 bit version of QuickBooks?
Then that means automation and working with the desktop edition means your software ALL MUST remain x32.
Only in 2022, have they rather recent upgraded and offer a x64 bit verison.
So, you have to check which desktop version of QuickBooks you are running. (most up to rather recent have been x32 bits - for a VERY long time).
So, what determines what QBFC library, what version of Access, and quite much vb.net?
You must continue to force your vb.net projects to run as x86, and NOT use "any" CPU and not use x64.
So, what will determine what all of your code is to run as?
It will be the desktop edition of QB that determines this.
It is of ZERO use to adopt office x64, access x64, or run your vb.net software, and the QBFC sdk and library as x64 bits if QuickBooks remains as x32.
(you using the wrong bit size and architecture here).
so, you have to be 100%, and in fact 200% sure
now, if QBFC is hitting the server database for QuickBooks, then that can be x64 bits but if you using the QB sdk and QBFC? Then that all must remain x32 bits until such time you upgrade the desktop edition of QuickBooks.
So, you have to REALLY but REALLY find out if in fact if you are running x32 QuickBooks for desktop, or x64 for desktop.
The version of QuickBooks and what version you you THEN much choose of QBFC library, vb.net, Access/office then again will have to match the bit size of QuickBooks desktop.
So from everything else from down to Access to vb.net to QBFC then all again much match the version of QuickBooks for desktop you have installed.
Now, if vb.net, Access you use is NOT to interface via the QBFC .dll and SDK? Then you don't care. But, inter process communication based on so called "windows COM objects"? And say upgrading from office x32, and the associated software systems you have? You can't just out of the blue decide to jump to office x64 without say your company and IT department not knowing the difference between x32 bit software, and that of x64 bit software.
Hint: 8 bit Apple II computer has a different architecture then a 16 bit IBM PC. And going from 16 bits to x32 bits? Again, a huge and large jump.
And from x32 bit software to x64 bit software? again a huge jump.
So, while windows can happy run x32 bit software, and it been a x64 bit OS by default for 10+ years?
Well, software packages running as x32 bits, and them interfacing to x64 bit software is a whole different matter. Such software has to remain the same bit size - and you can't have different bit size process on windows such as x32 bit COM objects (ole, COM, ActiveX = same technology stack).
So keep this basic knowledge and hallmark and pillar in our industry - different bit size software systems can't talk to each other via inter-op, or so called COM object automation.
Our servers are upgrading to Windows 10 64-bit (which is also using Office 64-bit products) and I noticed that in this environment, the old Outlook Redemption code I run in my MS Access VBA applications no longer work due to Access being unable to load the usual dll files (Redemption.dll, StrStorage.dll, dynapdf.dll). Is there a way to get this to work in 64-bit Office?
You will need x64 bit version of the app + dll's used. So if you using say tree-view, there not a x64 bit version. Same goes for any "add in", and that includes Redemption. You course of action is to find a x64 bit alternative, or hope that a x64 bit version of Redemption is released. Same goes for activeX calendar control, or any other add-in, or activeX control(s) you use. You have to ensure that x64 bit versions of such controls or add-ins are available before you can really adopt office x64 bit version.
Make sure the bitness of Access (where your code is running) matches the bitness of Outlook / MAPI system.
Since Redemption (unlike OOM) is an in-proc COM library, it bitness must match the bitness of your code (COM system takes care of that). But since Redemption loads the MAPI system in-proc, the bitness of the MAPI system must match the bitness of the host.
See http://www.dimastr.com/redemption/faq.htm#ErrorCreatingRedemptionObject for more details.
A client is writing a 64-bit Windows app in some language (yet TBD) that can use COM. I have a 32-bit ActiveX EXE that includes functionality they'd like to include. All data to be marshalled between these would be simple 32-bit integers.
I have no experience in this area, but it seems like this should be possible. I've searched other answers here and many talk of using 32-bit DLLs in 64-bit apps but I didn't find anything on the point of out-of-process 32-bit COM servers in the same scenario.
We just migrated an MS-Office-based application from 32-bit Office to 64-bit Office. The application uses a 32-bit out-of-process ActiveX EXE which was written in VB6 ages ago. Everything worked smoothly, no modification to the ActiveX EXE was required.
So, in my personal experience, the answer to your question
Can a 64-bit Windows app use a [32-bit] out-of-process (AX EXE) component?
is yes.
Is it possible to load a 64-bit dll into a 32-bit process ?
Generally speaking, I know it can not happen.
Yet, maybe there are some exceptions ?
No, and neither a 64-bit process can load a 32-bit DLL.
If you're on a 64 bit OS, you can load the DLL in a 64-bit process and have it communicate with your 32-bit process through IPC.
If you're on a 32 bit OS, you're out of luck.
In .NET, it is possible to load a 64-bit DLL into a 32-bit process for reflection only. For details please check "Analyze 64-bit DLL from within T4 template in Visual Studio (32-bit) using Reflection".
I know that this is a special case, but I thought I'd add it anyway because it might help others looking for a similar solution as me.
Yes, you can load 64 code in 32 bit module. example:
vmprotect
metatrader4
above software mixed x86 and x64 in one process.
I found metatrade4 for win7 has a function it exeucte a instruction like :
jmp 0x33:0x175328
segment selector 33 is a 64bit segment. after execution this instruction, cpu will switch to 64bit mode from 32bit mode.
if you use windbg to trace some windows api on windows x64 OS, you will find similar code.
for example:
NtQueryInformationProcess
But new computer bought today at least have 4G ram. We cannot prevent using 64-bit OS to avoid problem. We must face 64-bit positively! Server 2008 R2 only have 64-bit.
Issues around EXE AnyCPU / x86, 32-bit COM / C++ dll must be handled.
Ideally compile both 32 and 64 bit COM / C++ dll.
Is there a way to compile a VB6 component into 64 bits?
My feeling is that the answer is "no", but I would like to confirm this.
Please, if you can, paste a link to an authorative source that would confirm.
No. I hope this counts as authoritative.
64-Bit Windows
Visual Basic 6.0
runtime files are 32-bit. These files
ship in 64-bit Windows Operating
Systems referenced in the table below.
32-bit VB6 applications and components
are supported in the WOW emulation
environment only. 32-bit components
must also be hosted in 32-bit
application processes.
The Visual Basic 6.0 IDE has never
been offered in a native 64-bit
version, nor has the 32-bit IDE been
supported on 64-bit Windows. VB6
development on 64-bit Windows is not
and will not be supported.
No it cannot (well Microsoft has not released a compiler to compile it for a 64-bit environment), but this does not mean that it won't run on a 64-bit system. To run it in conjunction with IIS, you'll need to install the 32-bit version of IIS.