We have an Delphi application that has a built in com object. When compiled in Delphi XE3 (Windows 8) we can't reference it from Visual Studio C#. However, an older version that was compiled in Delphi 2010 (Windows 7) works as expected.
The com object registers without errors and i can access it by using VBA script in Excel. Has anyone come accross something like this?
The most likely explanation is a bitness mismatch. I'm assuming that the COM server is 32 bit since you have been compiling it in Delphi 2010.
Suppose that your COM server is an in-proc server. Then I guess that your failing host is a 64 bit application. If so then you need to make the bitness match. Most probably by switching your host to be 32 bit by targeting x86.
If the COM server is out-of-proc then the issue is with registration rather than executable bitness matching. It will be registered in the 32 bit registry view, but your 64 bit host is looking in the 64 bit view. This would explain why your 32 bit Excel VBA code can find it. You need to register the server in both 32 and 64 bit registry views. Or switch the host to 32 bit.
Related
Just when I thought I understood Microsoft's confusing naming with regard to WIN32 and WIN64 registry and folders I read this article (Using 32-bit or 64-bit ActiveX Components on x64 Windows) and find myself still a bit confused on how to properly register 32 bit and 64 bit OCX controls on the same WIN64 computer. From the article it says that on a WIN64 system the default regsvr32 is for registering 64 bit OCX controls and to register 32 bit versions of the OCX control I should use C:\windows\syswow64\regsvr32.exe. The thing is I've been registering my WIN32 OCX control using the default regsvr32.exe (in C:\windows\system32) and it seems to have been working fine when I run my 32 bit app which uses the 32 bit OCX. I have the following questions:
Q1 How has registering WIN32 OCX with default regsvr32 been working given what I read in the article.
Q2 I want to register both the WIN32 and WIN64 versions of the OCX control on a single computer. From the article it seems like I should use the two different versions of regsvr32.exe from syswow64 and system32 for WIN32 and WIN64 versions respectively. Is this correct?
Q3 Can the GUID for the OCX be the same for both the WIN32 and WIN64 versions? I'm thinking it can be the same since a different portion of the registry is used to register for each of these architectures. Correct?
Q4 Where do I look in the registry to confirm that both 64 and 32 bit versions of the OCX have been registered to confirm that registering the 2nd one didn't overwrite the first one?
Per suggestion in comment by Andrew here is my comments as an answer.
A1 & A2 Well since no one has replied to this I'll add what I've learned since posting. It seems the article I referenced is misleading in describing how to run 32 and 64 bit regsvr32.exe. From my own testing it seems that the default 64 bit regsvr32.exe can be used to register both 32bit and 64bit OCX controls. It seems regsvr32 (the 64 bit version at least) looks at the target OCX or DLL file and determines if it is 32 or 64 bit and installs it in the appropriate registry. There doesn't seem to be any need to use the 32 bit version of regsvr32 on 64bit windows.
A3 Yes both 64 and 32 bit versions can be registered which use the same GUID.
A4 For 32bit OCX in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID area of the registry and for 64 bit its in
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID
Are there any problems with programs that are compiled with Delphi 2010, using Rave reports (no database connection) running on Windows 10?
In principle, there's no reason why a program compiled with Delphi 2010 will not work perfectly well on Windows 10. Indeed, a program compiled with any 32 bit version of Delphi (Delphi 2 or later) can, in principle, be executed on Windows 10.
The usual caveats apply though. You have to make sure that your code respects features like UAC. So don't attempt to write to HKLM, system directories, etc. as standard user.
As a broad guideline, if your program executes on Windows 8.1, you can expect it to execute on Windows 10 also.
So, in summary, you should be perfectly capable of producing a program that runs on Windows 10 using Delphi 2010. However, it's impossible for anyone to tell you definitively that your program will run because only you know the full details of how your program is implemented. You should test your program on each new operating system as it is released, if not before it is released.
I'm not sure, but the internal Kernel ID from Windows is set from 6.x (Windows Vista - Windows 8.1) to 10.0 (Windows 10) so this can be a problem.
Situation:
I developed a DelphiXE5 ISAPI Webbroker application on a VMWare workstation under WIndows 7 Pro 64Bit. Testing on that platform with the code compiled as 32bit (default for DelphiXE5) was successful. The program consacts Stamps.com via HTTPS and uses the Stamps.com SOAP web application to purchase postage and create a mailing label with a valid postage stamp (indicium).
The mailing label is created as a PDF on a Stamps server and they send me back a URL which I then use to fetch the PDF and save it in my local SQL Server database. This fetch is done using INDY 10.6.0.5040 (per Remy at Indy). As part of that fetch, the INDY ssl component has to load and use the OpenSSL libraries. These load OK in the test environment.
I then moved the program (compiled as 32bit) to the Windows 64bit 2003 R2 server. This server is a virtual server running under VMWare. I am sure that the actual hardware is truly 64 bit. The OpenSSL libraries will not load on that server. I have tried the most current 32 bit libraries and the most current 64 bit libraries. Same result ... not loading. I tried the ones that load successfully in test .. they failed. Using the Indy WhichFailedToLoad() function shows "failed to load libeay32.dll". Funny thing is , I get the same message with the 64bit libraries. The libraries, even though 32 vs 64 bit, have the same name, so i get the same message. Now, my specific questions are ....
could there be a default area that the libraries load from and my placing them in the same directory as my program dll is not changing anything at all ?? Indy is going the default first and if they exist, that's the ones it is using. If so, does anyone know where that might be. I have tried to trace through the INDY code to see what was hapening but it jumps into assembler and I'm not a ms assembler programmer. I know IBM mainframe assembler in my sleep but MS seems uside down and backwards to me :-)
For Delphi experts out there.... SHould the program really be compiled as a 64 bit application and put in production and then use the 64bit libraries? In the test environment I'm running on 64bit hardware, 64bit host, 64bit guest on which the 32bit compile takes place. The 32 bit libraries work there and it seems that it should work in production on W2003 Server as that is identitical .. except for the OS version.
Could it be permissions problem with IIS 8.5 that wont let my dll read or load the OpenSSL libraries ? If so, any hints as to what ?
I have the DLL in the scripts directory along with libraries.
Who ever figures this out can get a job as my backup :-) ... really !
If your program is 32bit, the dll it uses have to be compiled in 32bit.
As for the location of the OpenSSL dlls, in my case, on a Win2012 R2 server, I put them in C:\Windows\SysWow64\inetsrv.
A number of delphi applications that I work with use an activex chartfx control. I realize that the company softwarefx stopped supporting delphi a while ago but we are transitioning to 64 bit builds and this component is our main obstacle. We could convert all our charts to TeeCharts if necessary but this would be a lot of changes.
I have gotten the 32 bit chartfx component to install and compile in xe2 but am unsure of the next step. Support did provide me with 64 bit dlls.
So I guess I have 3 questions:
has anyone sucessfully moved chartfx to a 64 bit delphi environment or
could you direct me to instructions on creating a component that is 32 bit at design time but can be 32 bit or 64 bit for compile?
is there a better way to do this?
edit: uploaded chartfx62 client server delphi code to http://www.filefactory.com/file/ce61229/n/Cfx62ClientServer_TLB.pas
You need to get the 64 bit ActiveX DLLs to go with your 64 bit runtime. Designtime Delphi is still always 32 bit.
If ChartFX doesn't supply 64 bit version you are stuck. Having looked on the website it seems that the vendor does not yet supply a 64 bit ChartFX ActiveX and is soliciting feedback as to how much demand there is for it.
I would recommend transitioning to TeeChart which is native Delphi code and has a very strong tradition on Delphi. You can be confident of future support for other platforms as and when they become available.
I have a plan to install my application which is compiled using RAD2010 in Vista 32 bit dev. environment, in a win 2008 server 64 bit.
I use Firebird 2.0 (32 bit) as database server.
Is there any issue? Or it should run without any problem?
No problem for this.
If you can use Firebird 2.1 (a version for 64bit server can be use).
Just take the fbclient.dll (32 bit version)
I see no reason why it shouldn't work, 32 bit processes and services work well under x64. If you need lots of memory for you application you can set the LARGE_ADDRESS_AWARE flag which gives your application access to 4GB of address space instead of 2 GB. If you want that you need to add a line containing {$SetPEFlags $20} to the .dpr file.
We have encountered 2 problems with Windows 2008 Server, but it does not seem they should impact you too much:
Critical Sections now come with a debug baggage that is cached and not freed when they are released. If you create lots of them, the memory footprint of your application will be much bigger. Can happen when using Interfaces or Threads heavily. see is-the-memory-not-reclaimed-for-delphi-apps-running-on-windows-server-2008-sp1 and critical-sections-leaking-memory-on-vista-win2008.
When using ADO, there is a memory leak (in MS stack) when passing the ConnectionString. If you close the connections and open them a lot passing the ConnectionString you end up eating all the memory after a while.
The only problem is if your application is library that needs to be loaded into a 64bit Process.
Examples:
Shell Extensions
ISAPI applications