Calling C DLL's compiled with SAFESEH set to no from Inno Script - inno-setup

I have an existing DLL that is working fine when being called from Inno Script however I need to add a function that calls another third party library (of which I do not have the source code).
Whenever I do that I get a 'could not call proc' error.
In order to compile (in Visual Studio) my DLL with the added function, I have to set SAFESEH to no because of the third party library. Is this likely to be what stops Inno Script from working? Are there any options available to resolve this?
Thanks in advance

Turning off SafeSEH is unlikely to prevent anyone from calling your function.
It is more likely that the 3rd-party library added a dependency to some DLL (MSVC run-time etc.). Use Dependency Walker to check if your imported DLLs change after you add the 3rd-party library.

Related

Acumatica Publishing with DLL resulting in System.BadImageFormatException

I am trying to add some external DLLs to the Acumatica Customisation project but upon publishing it results in "System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid."
Error Image:
I already have added multiple DLLs to the Customisation. And was using the method specified here: Acumatica unable to publish the Customization Package to skip over the errors, but in this case it does not seem to be working.
The first step should be identifying which DLL is the culprit. I suggest you create an empty project and put the files in there one by one with the ignore rules. Maybe you missed to add ignore rule for one of the files.
This error happens because Acumatica attempts to parse the DLL as a .Net framework assembly. If you add non .Net assembly such as native x86/x64 compiled libraries you need to add the ignore rule so Acumatica doesn't attempt to parse it.
If the error is coming from a DLL you compiled, make sure it was compiled in Any CPU platform. This prevents any incompatibility related to 32 bit/64 bit mismatch.

Can't make dll import from to my exe process because of dependencis missing in exe but exist on dll

I have 2 project
dll that include some other 3rd party dll and use them (don't have the sources - just using it)
some testing exe process that I using to check my dll that I developing
Now, I wrote simple class in the dll and I try to use this class instance on my exe tester - and I get an error about that the exe does not find the 3rd party include files that my dll include
How to solve it? How to import all the dependencies missing dll file to my tester exe?
There's no automated solution that I know of to retrieve include paths.
If you include an external header inside one of your DLL's headers, then it also becomes a dependency for your users. You need to abstract away that external code and not expose it in your interface in any way if you want to remove the dependency.

How to localize a win32 (Non-MFC) DLL

I have few win32 DLL's (Non-MFC) along with individual .rc files for different languages, presently we replace the rc file and build the full DLL again for each locale.
I am trying to find out a better way of doing it and found that MFC DLL's have something called satellite dll's wherein we can have a single DLL for the code and other resource DLL's for individual rc files.
But this resource/satellite DLL's solution doesn't seems to be working for Non-MFC dll's.
Could somebody tell me what would be the best way to localize such non-MFC dll's so that we do not need to regenerate the full Dll for each individual locales.
Thanks in advance
Rahul
There's no reason why you can't do the same with non-MFC dlls - I have done so many times.
You just need to create a set of resource-only DLLs, one for each supported language, and (from your main DLL) either load dynamically at runtime, or give them all the same names and just deploy the correct version during installation.
This MSDN page describes how to create a resource-only DLL. Although it mentions that it's helpful for MFC, there is no necessity to use MFC at all - you can apply the same logic that MFC uses to decide which satellite to load.
Partial screenshot

Should third-party static libraries be included as an item in VC++ 2010 project?

I use third party static library (provided as a .LIB file without source code) in my project. For linking purposes it is enough to add it via "Properties/Linker/Input->Additional Dependencies"
This library is not used in any other project in the solution.
I wonder if I should add it as an item to project file itself. The advantages that I see: it will be immediately obvious that this project uses it and one wouldn't have to add it to version control system manually (anything that is a part of the project/solution is added automatically if you use something like AnkSVN).
The project in VCS must be buildable. It is impossible without the lib. So you should add it.

Determining existence of DLL before using it

Using Visual C++ 2008 Express Edition. I'm linking my application with an import library (.lib) for a DLL that might or might not be present on the target system. Before you ask: I cannot distribute the DLL with my application.
If the DLL is not present, as soon as I call a function from the DLL (but not sooner!), I get a message like
This application has failed to start because SomeLibrary.dll was not found. Re-installing the application may fix this problem.
What I want to happen instead, is that the application detects that the DLL is not there, and simply disables functionality that depends on it. I could make a call to LoadLibrary and see whether it succeeded, but I'm not sure whether this is sufficient. Maybe the import library does more work behind the scenes?
Is a simple LoadLibrary call sufficient? If not, what else do I need to do? Can this even be done?
Update: Of course I can use LoadLibrary, and then GetProcAddress for each of the functions I want to use. But that's a hassle, and I was hoping to avoid that and simply use the provided import library instead.
This is what the DelayLoad linker option is for, but I don't know whether the Express edition supports it.
No, LoadLibrary() is exactly what you want. The only consequence to using it is the hassle of setting up the function pointers into the DLL when you successfully load the DLL, but the process for that is well-covered elsewhere on the net.
If you go check here (MSDN) you will see that when LoadLibrary fails loading, the function returns a NULL value, and you can even check the specific error (that should be a file not found) using GetLastError function.

Resources