Let's think I'm writing a windows service and a win32 application in visual c++. These both do the same function except the service does it again and again. Both the applications need modules which are separate DLLs.
I have few questions,
Is it a good practice to include overlapping (used in both app and service) code in DLLs?
What are the defects may occur when creating separate DLLs for applications (Those DLLs may include exported Classes and exported global functions)?
What is the difference when implementing a class inside an application and implementing it in a separate DLL and use it in the application?
P.S. Assuming both the service and the application are mutually exclusive in the timeline (Runs one at a time).
Related
I'm in the process of learning VC++ but I wonder why do end-users also need MSVC++?
As far as I can see in MSDN most if not all of the libraries that my programs use (the actual DLL files) already come with the system itself (user32.dll, kernel32.dll, etc).
But how come Paint and Notepad do not need MSVC++, but my software, which is way more simple than Notepad requires this runtime? What does the runtime do? How does it work? Is there a way to make my software work without MSVC++?
The runtime provides all the standard functions and classes, like std::string and std::vector, as well as the support code that runs constructors and destructors of global objects, finds exception handlers, etc. Windows comes with a version of all this, and for a while Visual C++ used it, but it was discovered that there were incompatibilities with the Standard, so newer versions of the compiler come with fixes (Windows can't bundle the new fixes in place of the old DLLs, because it would break existing programs).
Yes you can avoid the need for the runtime redistributable installer. You can use the /MT build option, which bundles all the required library functions right into your executable. After that, you'll only need DLLs that come with Windows.
The setting is in Project Configuration under C/C++ -> Code Generation -> Runtime Library
But note that this will make your executable file somewhat larger, and any bug fixes (especially security fixes distributed via Windows Update) won't affect your program, since you have a particular implementation baked in.
Adding to Ben's answer:
The runtime bundles a lot of features for each respective version of Visual Studio. The main advantage of using the DLL version of the runtime is that you get (security) updates "for free" whenever the system updates the DLLs in question.
Another advantage that some people will point out is that it saves resources to use the DLL version if many processes use the runtime via the DLL. This is because Windows has a mechanism to share DLLs in memory across processes (or the major part of them).
You will notice that bundling the runtime into your binary - also called static linking - will make your binary bigger, because each of your binaries now carries its own version of the runtime (that cannot be replaced without linking the program anew).
Also beware of mixing (your own) DLLs that statically link to either different versions of the runtime (i.e. Debug vs. Release) or that dynamically and statically link to the runtime depending on the DLL. The problem here is allocators. The functions to allocate (malloc, calloc, new) and free memory are incompatible across these. The best method in such a case is to use an independent mechanism such as IMalloc - or carry the deallocator inside your object instances always, ensuring that the call to free/delete doesn't cross module boundaries, even if the instance is handled in another module.
Most applications created with Microsoft developer tools need some kind of runtime to be installed first.
However most viruses never need any kind of runtime to work. Also they also seem to use undocumented core/kernel APIs without have lib files etc.
So what runtime/application do most virus /virus writers use ?
If the runtime is statically linked in (as opposed to dynamically), then an EXE will be self-contained and you won't need a runtime DLL. However, really, you don't even need a runtime library at all if your code can do everything without calling standard library functions.
As for Windows APIs, in many cases you don't strictly need an import library either -- particularly if you load addresses dynamically via GetProcAddress. Some development tools will even let you link directly against the DLLs (and will generate method stubs or whatever for you). MS tries to ensure that names for documented API calls stay the same between versions. Undocumented functions, not so much...but then, compatibility typically isn't the foremost of concerns anyway when you're deliberately writing malicious software.
I would like to know the exact differences between API and DLL.
Thank you.
Pretty much the only connection between the two terms is that if you do native Windows programming, APIs you use or write will usually manifest as DLL files. But neither is this the only concrete form an API can take, nor does every DLL represent an API.
API means "Application Programming Interface" - it's an abstract term for a collection of code entities (functions, classes, etc. - depends on the programming language) that's intended to be used by programmers at large to access the functionality of an application or library.
A DLL is a file format on Windows that contains executable code as a way to modularize applications.
An application programming interface (API) is an interface implemented by a software program that enables it to interact with other software. It facilitates interaction between different software programs similar to the way the user interface facilitates interaction between humans and computers. - Wikipedia
A Dynamic Link Library (DLL) is a one way of providing an API. (Interface to the programmer) You may have various other methods, like Web services.
A DLL is a library of code, and API is an interface to a library of code.
DLL = Dynamic-link library
API = Application programming interface
A DLL is just a file on Windows systems that has some code in that can be used by other executable files. An API is a way of using one piece of software, or a software library, to be used with another. For example there is a Windows Registry API that allows you to use the registry, but the code that runs when you use the API is stored in a DLL.
Updates:
DLL (Dynamic Link Library) is a code component (some what like the Beans in Java). DLLs contains the methods or functions or routines or whatever you call those code fragments.
And an API is an interface between an application and that DLL. Most of the time DLLs are used to provide services to other applications, these DLLs are called Server DLLs and if a DLL is requesting some service by using the API call or its dynamic invocation then it is said to be the Client DLL. So simple think, APIs are nothing but the methods or functions which are accessible from outside of that DLL.
Hope you got the idea now.
API are the header files (.h) which contain function and class declarations (input and output parameters), the implementation of these declaration i.e definitions of class or functions will be in particular dlls.
But to connect (dynamic linking) both these .h and .dll files, you require .lib files, these files will resolve the address of function definition during run-time and that particular dll files are loaded. Hence, libraries contain (APIs(.h), lib and dll files).
APIs make application development independent of underlying library implementations.
Example:
if you write a program in C to print "Hello World". And if you run the
same program in windows and Linux.
Both these executable will use different system libraries to display it on screen, as C language provides set of APIs like "STDIO.h","STDLIB.h", You need not worry about the underlying library implementations.
So you can think, API as header files, which connect function/class declarations with function/class definitions. Hence, the name "Application program interface".
You will have to be specific. DLL can stand for:
Data Link Layer,
Dynamic Link Library (Shared library on Windows Platform). It can also be a resource library too.
An API (Application Programming Interface) is an interface that's implemented by software programs to interact with other sotware. E.g. JDBC api is needed if a database connection is required in java.
From Wikipedia:
An API is implemented by applications,
libraries, and operating systems to
determine their vocabularies and
calling conventions, and is used to
access their services.
The purpose of a DLL (Dynamic libraries almost always offer some form of sharing, allowing the same library to be used by multiple programs at the same time).
In essence, the WINAPI (Windows API) are all implemented in DLL files, such as mmsystem.dll for MMSYSTEM Sound API.
References:
API
DLL
An API is an interface for communication of different components of an application, where dll is a library file which contains code so that your program can use using your API
Every DLL has some (is an?) interface (API) because otherwise it would be useless, but not every API is a DLL as in example You can have Web Api where You are using remote endpoints using in example HTTP protocol - not even a file like in DLL case
A simplified answer.
API is always (by definition) an application programming interface. It's a collection of methods that can be used as an interface to an app, a web service, etc.
DLL is a shared library file of the same format as executable. It contains code and data to be shared between other EXEs so you don't have to recompile them every time a DLL is updated. DLLs, for example, allow you upgrade Windows versions and keep the applications running on the latest version. It may contain code that's reusable by one or more executables, like an API. One the other hand, it may contain only data, like icons (.icl) and fonts (.fon).
When we create a DLL using Visual studio (VC8 or 9), we get an option as
create Regular DLL
using MFC as shared DLL
or
using MFC as static library
How are they different? Which one is advisable to use?
A static library means the code you use from the library is included in your executable. Because of this, you don't need to ship the library or require the end user to have it on their machine. However this bloats the size of your executable and ties you to that library version, so if you need to update just the library, you have to ship a new executable.
A shared library calls the library at the time it needs it (runtime) to execute the code, but it requires the user to have it (usually a specific or minimum version) installed on their machine. You can also distribute the required version of the library with your application if you need to.
As for which is better, I don't know. I'm not a Windows C++ or MFC programmer so I couldn't say. On my Linux servers, the applications I write are generally server-side and thus use shared libraries.
It depends on how your application is to be used, distributed, updated, how often the MFC library changes, if it's generally available on user's PCs etc.
[I think I got my answer now]
If you use MFC DLL as dynamic linking, your code will need the Microsoft Foundation Library DLL's (specifically the version your code requires) installed along with your application or dll in the user end. So this means your installation package would contain
Your application/DLL and supporting files
All MFC Dlls
This makes the installation package size go bigger and also make take time for user to download your installation setup.
If you link to MFC as static library, you code will work even without MFC DLLs present at the user end . The reason being pretty simple that all the MFC libraries you refererred in your code, will be linked into your application or dll. This means those MFC libraries used in your app/dll becomes the part of the your binary; however, your app/dll will be little bigger.
Another consideration is servicing your application.
If you ship the MSFT redis, dynamically linking against its libraries, and then MSFT later "fixes" some vital flaw in a DLL, they patch the DLL on your customer's machines through Window's Update. If you statically link, you will need to update all your customers directly.
Of course, if you are concerned that a patched DLL might break your application (because you rely on unspecified behavior), you may want to handle the servicing (and testing) directly with your customer.
I am converting an InstallShield project to a WiX based Installer. I have a number of VB6 projects whose binaries need to be registered.
The InstallShield project actually marks these as self-registering files. From what I have read this seems to be a "Bad Thing" in the Windows Installer world.
My question is, what should I be doing then? A VB6 project could have its internal GUIDs change after each recompile - and yes I'm already using Binary Compatibility.
I've used Heat to generate all the Registry and Class entries, but some of these entries change from build to build. I've read that Heat wasn't designed to be used every build, but instead to be used as a starting point.
What are others doing to deal with VB6 and WiX registration?
We have two types of components we develop in VB6. Latent common components that we reference across projects and volatile application components that we build daily. The common components are packed as merge modules (using WiX) while the application components map to components of the application setup. This is a snippet of our main .wxs file
<Component Id="MyFile15.ocx" Guid="YOURGUID-BCB7-451C-B07D-D205AEAE1EB9" >
<File Id="MyFile15.ocx" Name="MyFile15.ocx" LongName="MyFile15.ocx" KeyPath="yes" src="$(var.SrcAppBinnPath)\MyFile15.ocx" DiskId="1" />
<?include Registry_MyFile15.wxi ?>
</Component>
We are still using WiX 2.0 so we are using a tweaked version of tallow to produce the registry .wxi files for all the ActiveX DLLs/OCXs/EXEs we are building daily. Instead of com/typelib entries we are shipping all of the COM registration as direct registry table entries. We are targeting legacy Windows Installer 2.0 because we dont need any of the newer features.
We are using custom actions (VC6 DLLs) for some special cases -- MSDE setup, database patching, DCOM download/setup. We are using a Platform SDK bootstrapper that downloads instmsiX.exe and prepares Windows Installer on virgin systems (mostly 9x and NTs). We are using 7-zip self-extractor to unpack bootstrapper and msi on client machine. In some cases we are using UPX --lzma on executables but these do not scale very well on Terminal Servers where the non-packed versions are reused across sessions.
Lately we've been migrating our clients to portable builds using reg-free COM. We are using our in-house UMMM tool to produce registration-free COM manifests. SxS COM has limitations (no DCOM, no ActiveX EXEs) but allows us to change builds while the application is live -- no reinstall downtime.
One thing we've been toying with is eliminating global COM registration altogether by using registration-free COM. (The main advantage we are after is the ability to deploy different versions of the same application side by side in complete isolation.)
However, with registration-free COM you still have to write or generate the manifest files that need to be deployed by the setup. The answers to the linked question show that there are some tools to help with that.
In the mean time, we also still use a mix of self-registration and automatic wxs generation with heat.exe for our old VB6 and Delphi libraries. While you are right that heat was not initially designed to be used like that, it has been moving in that direction for a while now.
In any case, stable regeneration of identifiers (which is what was missing in the initial design of heat.exe) is only important if you want to support minor upgrades or share components between applications. We just completely uninstall the previous version of the product during an upgrade (aka a major upgrade), so we don't need to worry about such things.
edit: Since writing this answer in 2010, I've learned a thing or two about windows installer. I no longer believe that a major upgrade frees you from the need for stable GUIDs. Component GUIDs should stay stable as much as possible between in-place upgrades. Major upgrades don't always have the same end result as uninstalling+reinstalling.
I went a different route and defined all my objects using interfaces I created in IDL and compiled to type libraries(.tlb). A slightly long winded approach but it means all the GUIDs remain fixed regardless.
I am able to impliment versions of the interfaces and handle multiple versions of the dll in the same file.
Drawbacks are, this doesn't help with OCX controls and you can't use events accros the tlb boundary. This is not an issue for me as I generally use callbacks from DLL's to their callers as they can be more efficient.
This product is deployed on DVD to clients around the world, currently using an InstallShield installer but I am investigating moving to WiX as well.