I am using a COM interface to connect to an external device that is connected to the computer running the software via TCP/IP. I am posting this, because on one system this connection fails, mysteriously.
From the manufacturer, I have received an instrument.dll and an instrument.tlb. Unfortunately, details and code are subject to a confidentiality agreement, so I can only provide pseudocode.
I have two minimal examples, one on Free Pascal (the important one, because this is where I am developing):
uses
Instrument_TLB; // Imported via the Lazarus "Import Type Library" function from the .tlb or the .dll
[...]
procedure TForm1.FormCreate(Sender: TObject);
begin
AInstrument := CoInstrument.Create;
if AInstrument.Connected then ...
end;
and one on Visual Basic, provided by the manufacturer:
Private Sub Form_Load()
Set theInstrument = New Instrument
If theInstrument.Connected Then ...
End Sub
This VB6 project has the instrument.dll as a reference.
The behaviour on different computers is as follows (supplemented with information from Sysinternals Process Explorer):
System A (Windows XP, 32bit, used for compilation): Both the FP and the VB executable work as expected, a connection can be established. In Process Explorer, both executables have one thread with instrument.dll and the TCP/IP connection can be seen to be up.
System B (Windows 7, 64bit): Both the FP and the VB executable work as expected, a connection can be established. Process Explorer was not used.
System C (Windows 7, 64bit): The VB executable works as expected, a connection can be established. In Process Explorer the VB executable has one thread with instrument.dll and the TCP/IP connection can be seen to be up. The FP executable can NOT connect, there are two threads with instrument.dll and no TCP/IP connection seen in Process Explorer.
I know that based on the little information I am able to give, no one can come up with a "solution" - however, advice on how to investigate this problem further, what tools to use for debugging would be highly appreciated!
Thanks for your time.
It turned out that the registry on system C contained several entries on how to connect to the instrument, and in one, there was a slightly wrong IP address. I do not know why this key was used by my 32bit FP software and another one by the 32bit VB6 test application, but changing the IP address was one factor.
The other factor was to run the software in compatibility mode for Windows 7 on Windows 7 SP1. I don't know why that is necessary (because it works without compatibility mode on Windows SP1 on system B), but I would like to get rid of it asap ...
Related
I have an ancient program that I use for reading and writing data from AutoCAD. This program is written in Delphi 5. I have tried to update it to a newer release but several of the libraries I use no longer exist and it is a huge program with lots of libraries used.
The program uses the ACAX##ENU.TLB type library that is provided with AutoCAD. Where ## changes for each AutoCAD release. Every time Autodesk sends out a new AutoCAD version I import the new type library and life goes on.
Now I am faced with Windows 10. For some reason the automation links between my program and AutoCAD are not working in Windows 10. Did something change about the way the type libraries work between Windows 7 and Windows 10? Something that Delphi 5 is no longer compatible with? Maybe it's a 16bit vs 32bit vs 64bit issue. That is all over my head but I understand that Windows 10 dropped support for some 16bit operations. But my program itself runs perfectly. Even the BDE can be made to work which is amazing to me.
Is there anything I can do for an experiment? I am really lost about what to even experiment on.
Thanks.
Well, it's been a long time since I asked this question but here is an answer:
I was able to get my Delphi 5 compiled program working with AutoCAD 2017 in a Windows 10 environment. I am pretty sure that the solution was to run the program WITHOUT administrative permissions and WITHOUT any compatibility modes switched on. Apparently Windows places restrictions on COM communications as soon as you turn on either of those features. There may have also been issues with Windows 10 still having UAC active even when you set UAC all the way off. There is a registry setting to actually set UAC to off but my corporate IT prevents turning that off even with admin rights.
So in the end it was not a problem with Delphi, my program or with AutoCAD. It was a Windows 10 problem.
There was a bit of a clue that might be helpful to others: with the admin permission and/or windows XP compatibility turned on the program took several extra seconds to boot. With the settings turned off it booted quickly.
Or maybe its something entirely different from any of this. But the program is working now.
Thanks.
I wanted to use the Desktop version of IB XE7 in my development environment but can't get the connection to work.
The original app had used a full server version of IB and I now wanted to run the app on a lower cost single PC type application and selected the IB Desktop version.
The Rad Studio 10.1 Berlin is running on a W7 64bit Virtual machine.
FireDac is the database connection component.
IB XE7 Desktop is the database server on the development PC.
Target for the application is a VM with W7 32bit, with another IB XE7 Desktop on that VM.
I can build the 32 bit app and it will connect to the IB XE7 Desktop on the target PC (running W7 32bit in a VM) after changing the FireDac connection component protocol field to 'local' instead of TCP/IP, something I read in Stack Overflow.
What I can't get to work is the database connection in the development environment.
I first installed the 64 bit version of IB, then removed it and tried the 32 bit version with the same result.
After reading up on some connection problems online, I tried putting 'gds_db' and 'localhost/gds_db' in the server name field, but it still didn't work, although it did change the error.
Error - with nothing in the server name
[FireDAC][Phys][IB]unavailable database.
Error after putting 'gds_db' in the server name
[FireDAC][Phys][IB]Unable to complete network request to host "gds_db".
Failed to locate host machine.
The specified name was not found in the hosts file or Domain Name Services..
First tried 64 bit IB installed, then removed all gsd files found and then the Registry entries, and installed the 32bit version. Problem still persisted.
Note: Database Workbench 5 connects OK to the database on the same VM.
Any ideas welcome.
Thanks.
James F.
I remember it being quite a performance to get Delphi XE8 + Seattle working with IB XE7,
in particular I kept getting the "unavailable database" error when trying to connect from
inside the IDE. Note: the following are things I found necessary to get Delphi working with a local instance of the full IB XE7 package. Requirements for the Developer and Desktop editions very probably differ, hopefully in ways explained in their documentation.
Some of the things to check are:
Check in the Windows Services app that the server is running.
My server shows up as
Interbase XE7 Server gds_db
As you can see, the Services app should tell you the name of the server.
If you want to connect to it via TPC/IP check that you have an entry
in your \windows\system32\drivers\etc\service file like this
gds_db 3050/tcp # InterBase Server
Hash-sign developer_ibxe7 3054/tcp # InterBase Server
The line containing developer_ibxe7 should start with a #, but SO won't display that for some reason. Anyway, that line is commented out because it refers to a developer edition I installed at some point.
Check that your OS environment contains an entry like this one
INTERBASE=d:\ibxe7
If it isn't, add it and reboot the machine.
In my case, d:\ibxe7 is the top-level folder in which I have IB XE7 installed.
With those things set up/checked start a new Delphi project in the IDE, add an IBConnection to it, and set its DatabaseName to a local IB database. For me, specifying
LocalHost:D:\Delphi\Interbase\Databases\MA.GDB
works fine. Then, see if you can set the Connected property to True. If you can't,
leave a comment and I'll see what else I can remember.
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.
Scenario:
Delphi ISAPI dll written using Delphi XE, 32 Bit.
ISAPI dll is running through IIS 7.5 on a Win 7 64 enterprise desktop
machine.
DLL runs fine.
Debug the ISAPI DLL in the Delphi XE IDE by using Run->Attach to
Process:
Launch the ISAPI DLL and attach to the wpw3.exe *32 process in the
debugger - can trace and debug code as it runs in the ISAPI context.
Problem:
My hard drive died last week and I got a new Win 7 installation - the
standard corporate wide Win 7 64 Enterprise image (not the same as my
previous Win 7 64 installation).
Now, when I go into Run->Attach to Process, I no longer see the
wpw3.exe *32 process by name, although it is visible in task manager
by name. Invoking the 'show system processes' option on the 'Attach to
Process' Dialog box does not help.
What I DO see now (which I never saw before in my old deployment) is
a long list of 'generic' System process with PID's but no
descriptions other than 'System'.
One of these processes is my wpw3.exe *32 process, and I have identified
its PID using MS's Process Explorer. But if I try to attach to
that process I get an error message - 'Cannot create process -
access denied' - so I can't debug. (Same error message 'Error
Opening process, Access denied' also shows in Process Explorer for
certain properties, although the descriptive name of the process '
wpw3.exe *32' is visible there, associated with the PID.)
How can I get the Run->Attach to process dialog box to display the
proper wpw3.exe *32 process name and attach to it, so I can debug?
Is this a Delphi problem? An IIS problem? An ISAPI problem? Is this one problem - ie lack of descriptive process name and inability to attach to process are caused by same problem; or is this two problems: one problem being lack of descriptive name, another the inability to attach to the process?
(Do not want to use - cannot really use - webApp debugger for this -
these are ISAPI dll's that are deployed to production exactly as they
are written and debugged in IIS - I need to see them running in IIS
context.)
Been debugging ISAPI dll's for several years this way, with different versions of Delphi and in various OS and server environments without any problems - never encountered this problem before. I am stumped.
My account has admin rights, but it hit me that I should try running DelphiXE as an admin – launch it with the ‘run as administrator’ option.
I got prompted ‘do you want to allow…’ – clicked yes and Delphi ran. Set up my process and hooked in and traced through my code - process names now visible and I can attach to my IIS process and debug in the Delphi Debugger.
I did not have to go through this step in my previous deployment, for whatever reason - but problem solved.
If you want to debug a 32 bit ISAPI dll on a 64 bit OS you can use the following process.
This assumes that you have followed other steps to allow 32 bit ISAPI dlls to work.
Stop IIS
net stop w3svc
Start the 32 bit worker process in debug mode
%SYSTEMROOT%\SysWOW64\inetsrv\w3wp -debug
Attach to the w3wp in the debugger. As you noted you need to be running Delphi with elevated privileges for this to work.
The background to this query was this question.
I have installed this driver for Firebird and placed it within the path (system32) used by the IDE. The XE Data Explorer recognises the driver, and it is possible to create a connection using the Data Explorer. Trying to view tables or any other database element through this connection results in the error described in this question. As far as I can see #Alejandro Jourdan has not obtained a solution to this problem, and I can find no solution on any of the support sites for Firebird or for Delphi XE.
The second problem comes when I create a TSQLConnection using this connection. The connection works to the extent that it generates the login prompt to the database, but when it tries to open the connection I get the error message: 'file is not a valid database' This error message is (sort of) reproducible from within the Data Explorer which gives the following error:
I/O error during "CreateFile(open)" operation for file [database path] Error while trying to open file. Access is denied..
The database is valid and can be opened from the Firebird command line utility, and from a Data Base browser.
Environment:
Machine: Lenovo Thinkpad W510
OS: Windows 7 Ultimate 64bit
Delphi: Embarcadero® RAD Studio XE Professional Version 15.0.3953.35171
Database: W1-V2.5.0.26074 Firebird 2.5 (64 bit)
Also Installed:
Embarcado Borland® Developer Studio 2006 Enterprise Version 10.0.2288.42451 Update 2 (XP Version)
Borland Delphi Version 7 (XP Version)
EDIT:
See my own answer below. This edit has removed extensive detail that proves to be unnecessary in the light of that answer, while retaining the core of the question, and the links contained within it.
The first thing that sticks out to me is that you're using the 64-bit version of Firebird, and that you mentioned it comes with both a 32- and 64-bit driver. Are the DLLs named the same? If so, I suspect that the IDE/OS are trying to load the 64-bit version of the DLL in a 32-bit application, which isn't possible (32-bit apps can't load 64-bit drivers, and vice versa).
Try one of two things:
First, if the DLLs have the same name, rename the 64-bit version temporarily, and restart the IDE. Then try again.
Try installing the 32-bit version of Firebird, even though you're running a 64-bit OS.
The basic question I had (in part I) was:
I want to install a Firebird database
driver, and to have it available
within the Delphi XE IDE. I want the
database driver to be usable on the
same basis as other, supplied database
drivers (eg Interbase, SQL - from
within the Data Explorer in the IDE).
I have obtained an appropriate driver.
After considerable investigation I have found that it is not possible to achieve the integration into the Delphi IDE that I was trying to achieve. This is because the Data Explorer is a .NET application and the available DBExpress drivers (here and here) are just not compatible with .NET. I understand that I can use the drivers by setting up the parameters appropriately, in both the IDE and by programming in the application I am developing.
I have drafted this answer to assist others to avoid this particular blind alley. I am also editing the part II question in order to remove a lot of the detail, that proves to be unnecessary in the light of this answer.