I am going through my project code base, which consits of libraries and
applications. Some libraries are Dll's. Code is written in C++ for Windows
using MS VS 2010.
I taught for Dll we should write DllMain function which is entry point for
the DLL application. But in my project for DLL "DllMain" function is not present.
My question when we require DllMain and when it is not required?
Thanks for your time and help.
DllMain is not mandatory. If you have some initialization code required to run when loading the dll, you should create a DllMain function, and treat the initialization there. Otherwise it's not required.
See here some more information.
Related
I am working on an older InstallShield 2010 installer. It puts down DLLWRAP referenced from programfiles\installshield. There are two Custom actions that call functions DLLWrapCleanup after install finialize and DLLWrapStartup after SetupCompleteSuccess.
Can anyone explain what this is and what it does - or even if it is needed? Thanks.
As Installsheild Help describes here: it is a helper DLL for custom actions from a standard DLL.
If you change your custom actions from "standard" to "msi dll" you can remove the DLL and the dllwrap actions from your ISM.
Stefan Krueger describes the differences here.
A "MSI DLL" is a DLL that exports a function that matches the prototype defined in the MSI documentation. This is the only type of DLL that Windows Istaller can use directly as a custom action.
A "Standard DLL" can have (virtually) any prototype. InstallShield adds a wrapper around it that shaows Windows Installer only the MSI DLL interface and translates all additional parameters into properties. So essentially your cuatom action calls a DLL (provided by InstallShield) which calls another DLL (your Standard DLL).
Personally when I started doing this years ago, I used standard DLLs. When I learned the difference I switched to using MSI DLLs.
I'm trying to patch a .NET DLL file using the Quick Patch project of InstallShield. The DLL needs to be registered for COM Interoperation.
When I patch the file, the dll seems to be replaced correctly in the GAC, but when I try to access it from my application I get an error indicating that the application cannot connect to the DLL.
I think that it is not being registered properly for COM interop, but I'm not sure about it.
Any idea of what should I do to make it work?
Thanks,
You probably have to run regasm(it's in .NET framework directory) with correct params to register for com interop. Also the DLL file is usually built with certain COM visible options selected. Been a long time since I dealt with that nightmare though, so can't remember all the details.
http://msdn.microsoft.com/en-us/library/tzat5yw6(v=vs.80).aspx
I have developed a C++ DLL in windows which has many CUDA accelerated functions.
Currently i haven't created the DllMain function as it is not mandatory.
I know that there are many limitations on the functions that can be called in the DllMain.
I just want to know that is it safe to call a CUDA Runtime function in DllMain just to initialize the default context, so that the subsequent CUDA calls are faster?
I'm using Visual Studio 2008, CUDA 5.0 and Windows 8 for development.
Reading the DLLMain documentation, I would advise against it. From the docs:
Warning There are serious limits on what you can do in a DLL entry point. To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL.
More specifically:
Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose.
Since the CUDA Runtime API requires cudart.dll, this applies to your question.
So I would create an initialization function for your library that does CUDA initialization, and require it to be called explicitly at application startup.
How does the Visual C++ program load dll's before entering the main function in visual studio express 2008? In a project developed by others a dll was loaded by "a.ext:native" but I don't know how is this configured.
There are different ways to instruct the OS to load a DLL. The most common way is to link to a .lib file (through the project's linker settings), where the .lib is a build-time stub associated with the DLL. When the linker finds this .lib file during the linking stage, it knows that the DLL is required, and modifies the EXE internally to tell the operating system that the DLL must exist in order for the program to run.
When the program is later run, the operating system first looks for all required DLL's - even before beginning to execute the code for the program. If any of these DLL's are missing, the operating system throws an error, an error box pops up, and the program will not run.
It's also possible to dynamically load a DLL, but this isn't all that common.
How to include the windows runtime dll files in setup project.
without vc++ 6.0 software in the machine the project must execute.
or give me the hint how to make a the project setup(EXE) in vc++ 6.0 ,i am using create installor,
You can modify the project settings to link statically to the C runtime (I assume this is what you mean when you said windows runtime ?). The static link flags are:
MultiThreaded static linkage (/MT)
MultiThreaded debug static linkage (/MTd)
Sorry, been awhile since I used VC6.0, so I had to check the GUI. You'll find this in project settings, C++ tab, Code Generation combo box, "Use run-time library").
To add to what Cannonade has already said, if you are doing it through Visual Studio, then this can be done through Project Settings->General Page->Use MFC as a static library. This way your created exe will be ready to run on any windows box.