I use Delphi Seattle and my application has one 32Bit Exe and another 64Bit Exe.
For certain operations like MS Graph API I need these DLL's (libeay32.dll and ssleay32.dll).
Both Dll's have the same names, how can I ensure my Exes use the matching Bit's DLL.
All my work is in a single folder
I was hoping the 64 bit dll's would not have the name as ...32.dll
You can't have the 32bit and 64bit DLLs in the same folder, since their filenames will clash, as you noted. So, put them in different folders instead, and then at runtime you can have each EXE call Indy's IdOpenSSLSetLibPath() function in the IdSSLOpenSSLHeaders unit to tell Indy which folder to load the DLLs from.
Related
I made an application that uses the openssl dlls (libeay32.dll and ssleay32.dll).
It is indy using them, I don't call the dlls directly.
The simplest workaround i found to avoid an installer (i just delpoy an exe and i am ok with this approach) is to:
put the dlls as resources of the exe
on program start I extract them in the exe folder
the exe uses them
This is perfect but I would like to improve the approach by extracting the dlls in a temp folder and not on the exe folder (that in many cases is the desktop).
The problem is that I don't know how to force the application to use the dlls in the temp folder, because now the behaviour is:
if dlls are not in current directory try to search in the directories defined in the system path.
Who knows a solution to force indy to use the dlls in my temp path? (like "temporarly registering the dlls")
If you are using an up-to-date version of Indy 10, the IdSSLOpenSSLHeaders unit has a public IdOpenSSLSetLibPath() function to tell Indy which custom folder to look in for the OpenSSL DLLs:
procedure IdOpenSSLSetLibPath(const APath: String);
Load the DLLs yourself with LoadLibrary as soon as you have written them to the temp folder.
This will make Indy's LoadLibrary use your DLLs when they need them:
If lpFileName does not include a path and there is more than one
loaded module with the same base name and extension, the function
returns a handle to the module that was loaded first.
You can use SetDllDirectory to manipulate the DLL search order.
Considering the following:
We have a 32 bit Datasnap server installed on a 64 BIT Windows Server
In embarcadero\rad studio\11.00\redist are 2 folders : 32 bit and 64 bit, with in each a midas.dll.
Which file should we put where?
In windows\system32 or windows\syswow64?
On a 64 bit system:
The 64 bit system directory is named System32.
The 32 bit system directory is named SysWOW64.
If you must copy a DLL into the system directory, make sure that you copy 32 bit DLLs to the 32 bit system directory, and 64 bit DLLs to the 64 bit system directory. That's essential if you want your application to be able to locate the DLL.
Since your code is 32 bit, you need to use the 32 bit DLL.
However, you should probably place the DLL in the same folder as your executable since the Windows system directory is private and reserved for use by the system. Applications should not modify the system directory.
Never put anything in the Windows system directories (unless you have a very, very, very good reason to write there).
It's a very bad practice (dating back to Windows 3.x times and poor developers skills, because those dirs are always in the search path) just leading to troubles (i.e. if another application chnages your DLL with its own with little or no checks). Put the DLL in the application folder. It will ensure your application uses the correct version of the DLL. Or if you have to write it elsewhere for a very, very, very good reason use one of the techniques to add a directory to the search path or redirect DLL loading.
Windows system directories must be regarded as operating system private ones. This kind of practices which Windows doesn't forbids enough are those that often makes Windows a slow and unstable system.
If you're application is 32 bit, you need the 32 bit DLL regarless of the operating system.
Using the latest Indy10 sources from subversion, installing in to Delphi XE4,
I get this error when I try to install "dclIndyProtocols180.bpl":
Error:
Can't load package C:\dev\..\comp\Indy10\Lib\Output\BPI\Win32\Debug\dclIndyProtocols180.bpl.
%1 is not a valid Win32 application.
The BPI\Win32\Debug folder in question contains these files:
dclIndyCore180.bpl
dclIndyProtocols180.bpl
IndyCore180.bpi
IndyCore180.bpl
IndyProtocols180.bpi
IndyProtocols180.bpl
IndySystem180.bpi
IndySystem180.bpl
How do I fix or work around this? I am not exactly new to Indy, or Delphi, but each time there's a new delphi release, there are interesting surprises for those of us who prefer to build from source code and track subversion rather than using that random point in time which ships with the Delphi XE4 installer.
As a general side question: Is there any place where the status of the Indy project's subversion code, compared with whatever Embarcadero ships in their products is noted, or recorded?
By default a new package in Delphi might automatically be 64 bit, or you may have built a dependency as a 64 bit BPL, but not have switched to 32 bit for that BPL and rebuilt it.
Also you might have folders in your Library path that allow 32 bit and 64 bit BPls to try to load each other, causing this issue.
I already asked how to upgrade to the latest Indy TCP TP components version ( GET INDY COMPONENTS ) and Installed Indy 10 with DELPHI XE 2 now. For all the Indy projects I defined an outfolder in the project options section of DELPHI XE2, here I found later all the the .bpl files and all the -DCU#s files I need now in order to compile my application using the new INDY components to add this output folder as a library search path in these projects.
I found at my XE2 installation a path/folder with *.dcu files for x32, x64, release and debug mode (C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\lib\win64\release).
Do I need now all the INDY *.dcu I have created also in these different flavours compiled, how to set the path for all project to use the new *.dcu from my folder ?
Should I copy all my dcu's to these many sub folders ??
You should not replace the pre-installed Indy files with the updated compiled files (in case you need the originals in the future, such as for DataSnap projects). Install the newer Indy into its own separate folder, then update the projects search paths to refer to that installation's output folder(s) instread of the pre-installed folder(s).
You should not overwrite the .dcu files that are part of the Delphi installation. What's more, I would not recommend that you do anything with the .dcu files that you used to build these .bpl files.
What you should do is to include the Indy source files, the .pas files, in your project. Personally I prefer to avoid using a search path to achieve that and instead simply add all the necessary .pas files to the project. But you may prefer to use the search path option.
But the main point is that since this project is supplied in source form it is best to compile the source yourself, as part of your project. That makes it much easier for you, whilst debugging, to step through the Indy code. There's no need to have separate DCU files for release and debug. It makes the build process simpler, only one thing to build. It makes it easier if your source code targets multiple Delphi compiler versions.
I need to know if a exe file contains at least one icon. A fast way, if that's possible.
I tried with PrivateExtractIcons and it works, but only for 32 bit exe files.
It's not working for 64 bit exe files.
I need this to work with any exe file in any Windows >= XP (x86 and x64).
I'm using Delphi 2009.
Call LoadLibraryEx passing LOAD_LIBRARY_AS_DATAFILE or LOAD_LIBRARY_AS_IMAGE_RESOURCE.
Call EnumResourceTypes to check if the module has any icon resources.
Note that this is not exhaustive since some applications (e.g. modern Office) store their image assets in custom form and not icon resources.