In Delphi XE2, I use Indy TIdHTTP to make a http connection. In Windows 7 it works perfectly. But now I have started the program on a Windows 8.1 computer and when trying to connect (which in Windows 7 works perfectly) I get an error message from Windows telling me that MSVCR110.dll is missing on the computer (message title: "Drag: MyProgram.exe - System error").
Is it safe to take the MSVCR110.dll from my Windows 7 computer and install it on the Windows 8.1 computer in my application's directory? Do I have to somehow register the DLL when I install it in Windows 8.1 in my application's directory?
EDIT 201407152319: Ahhhh, found the culprit: This error occurs only in Windows 8.1 when using the new (version 1.0.1.7) (heart-bleed-tested) libeay32.dll and ssleay32.dll! When using the older DLLs in Windows 8.1 the error does not occur!
Indy has no dependencies on the VC++ runtime library. However, some distributions of the OpenSSL DLLs do. The OpenSSL DLLs that are available on Indy's Fulgan mirror have been compiled without the dependency.
Related
Windows 10, Delphi 10.4.1, IBLite 2020
Hello all,
Getting "ibtogo64.dll not found in the path" when trying to run on any computer that does not have Interbase installed.
I have been using Advantage local server and would like to move to iblite for testing and small desktop projects.
I created a small test project using the sample data.
I copied the compiled project and supporting files, including license file and data to a USB drive.
Stopped the Interbase service and ran the project fine.
Moved the USB drive to a different computer and got the error as soon as project ran.
To make sure the running project was using the local DLL, I moved the USB back to the development computer and removed the DLL. Got the error, pasted back everything fine.
What am I missing.
Things I checked:
Made sure DLL's are in same directory as exe
Deployment files all checked except reg_ibtogo.txt using reg_iblite.txt
reg_iblite.txt is in the license folder
Interbase directory in same directory as exe
Project is release version
I ran the program from USB on laptop that has Interbase installed and service stopped and worked fine.
On Delphi-PRAXiS question came up about license. I have an included license file and according to this that's all I need.
RAD Studio includes InterBase 2020 ToGo and IBLite editions for embedded application development.
Developers can deploy their multi-device applications on Windows (32-bit and 64-bit), macOS (32-bit and 64-bit), iOS (32-bit and 64-bit) or Android (32-bit and 64-bit) devices with an IBLite license, for free. Also, developers using RAD Studio 10.3 Rio Enterprise or Architect editions can deploy their iOS and Android applications with the InterBase ToGo (IBToGo) for Mobile license included. They can additionally purchase an IBToGo license for desktop platforms (Windows, macOS, and Linux).
Developers using Professional edition can purchase an IBToGo license for all platforms separately.
any help would be appreciated,
Gary
Try deploying the InterBase 64 bit client to the .EXE directory, then copy ibclient64.dll to ibtogo64.dll. If that works, we can contemplate why.
I just had this problem on 32 bit. The problem was I did not have the 32 bit Visual C++ runtime installed. So, you likely did not have the 64 bit one.
We are trying to set up 10.4 Sydney automated builds based on the Delphi command-line compiler. Our build servers are Windows Server 2016, but RAD Studio 10.4 is supported only for Windows 10 and attempts to install on Windows Server 2016 have failed. Embarcadero technical support says to purchase RAD Server, but is RAD Server really intended to support automated builds?
Would manual setup be a solution? Is it feasible to manually set up the Delphi 10.4 command-line compiler on Windows Server 2016 (i.e. copy over needed files and import needed Registry settings)? Or will 10.4 install on Server despite this not being officially supported (with our woes being due to heretofore unidentified IS policies or security settings which are interfering with the setup)?
Edit: The error is "No valid license information found for Embarcadero Delphi 10.4. You must provide a valid serial number in order to use Embarcadero Delphi 10.4 Do you want to run the registration wizard again?"
The solution (suggested by our Embarcadero sales rep, not their tech support, who refused to help because 10.4 is not officially supported on Windows Server 2016) was to uninstall 10.4 (what little had installed) and then reinstall. Reinstalling, the installer found the manually-imported license (the same one that it had complained held no valid license information) and allowed the install to proceed. There were no further issues with the install and now both the Delphi 10.4 IDE and command prompt are working properly.
Is windows 10 backwards compatible for exe files built by delphi 10 in windows7?
My attempts to provoke crashes in windows 10 have all failed, but i cant find any documentation to back up my theory, can anyone help?
Windows 10 up to now will run any cleanly written 32 bit Windows executable. It does not matter whether the executable was compiled on Windows 7 or Windows 10.
(For what it's worth: Even Programs written with Delphi 6 and compiled on Windows 95 will work under Windows 10, as long as they behave. That is mostly: Don't write to c:\program files or HKLM in the registry. They will not be able to detect the correct Windows version or use some newer Windows features though.)
Compiling Windows based programs using Delphi on different Windows versions will not affect build results. Same source code will always be built into same end application regardless of which version of Windows you used to run Delphi environment on.
You can even run your Delphi on 32 bit Windows and compile 64 bit application with it if you wish so. Granted you won't be able to debug such application since you can't run 64 bit program on 32 bit OS.
In fact I have heard some people are running Delphi on Linux inside Wine environment while developing Windows applications and it still works.
I Have a dll Project. I want to debug this Project with paserver on remote side. How can i pass my dll outpath dir on remote side and how can i pass my dll’s debug launcher application ?
For example my dll should be run on C:\MyApp\MyApp.DLL (On remote side)
And my debug launcher program should be run on C:\MyApp\MyDebugger.EXE (On remote side)
My Host application is Win32 VCL Application
Best Regards
PAServer is not stable at this stage. It simply cannot be used. There are MANY reports about this:
PAServer can't load dyld: Library
Delphi XE5 PAServer Unauthorized user
How can i debug my DLL project with Delphi's PAServer
Delphi XE4 iOS can't connect to PAServer
https://stackoverflow.com/questions/28115855/paserver-crashes-on-win64
Delphi Mac OS X
https://quality.embarcadero.com/browse/RSP-34061 (2021)
Solution: wait until they release something stable. (You will have to pay again, of course)
follow solution as discussed here : https://www.delphipraxis.net/204383-dll-unter-linux-deploy-prozess-2.html (German only)
I have a Windows 8.1 on a VirtualBox with Delphi XE5.
On my Mac OSX 10.9.1, I installed the package PAServer version 4.2.0.05 and executed with no password.
I've used previously in the PAServer XE4 version, so I know how it works, but tests with XE5 error occurs.
When I create an example app for iOS and deploy, I put the IP of my Mac and do a test connection, so I get the following message:
Remote Error: Unauthorized user, all server request are ignored.
Ping from Windows to Mac is OK.
I have no firewall enabled on Mac and Windows.
I gave permission to all folders generated by PAServer on Mac.
On Windows, I have a user with the same username of Mac.
Using "sudo" to run the PAServer had no effect.
I have no more idea...
PAServer is not stable at this stage. There are MANY reports about this:
PAServer can't load dyld: Library
Delphi XE5 PAServer Unauthorized user
How can i debug my DLL project with Delphi's PAServer
Delphi XE4 iOS can't connect to PAServer
https://stackoverflow.com/questions/28115855/paserver-crashes-on-win64
Delphi Mac OS X
Solution: wait until they release something stable. (You will have to pay again, of course)