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.
Related
I am not sure if StringCbPrintf and the include file strsafe.h where it is defined belong the the WinAPI. On one hand, Microsoft documents the function on its WinAPI sites and strsafe.h is under the Windows SDK directory structure which indicates (to me, at least) that it is indeed part of the WinAPI. On the other hand, strsafe.h includes stdio.h etc. which belong to the CRT. I was always under the impression that the WinAPI is completely independent from the CRT (but not vice versa). Possibly, my assumption about the relationship between WinAPI and CRT is wrong. Thus my question: is StringCbPrintf part of the WinAPI?
The StrSafe API is a bit strange because it does not have its own .DLL nor its own exported functions. I assume it was developed this way because it needed to support older versions of Windows that had already been released. It was created during the WinXP service pack security push:
During February and March 2002, all application development in
Microsoft stopped and developers took part in the Security Push
initiative. The goal was to check all code for possible security
vulnerabilities and fix those problems. One of the outcomes of the
Security Push was a library of safe string functions called
"strsafe.lib" with an associated header called "strsafe.h." This
library is available through the Platform SDK that can be downloaded
from the MSDN web site and is automatically installed as part of
Visual C++.NET 2003.
As far as I can tell, a copy of strsafe.h was also included with Writing Secure Code (Second Edition) by Michael Howard and David LeBlanc but I'm not sure if they are the original authors (David LeBlanc is the author of SafeInt):
You can find a copy of Strsafe.h in the companion content in the
folder Secureco2\Strsafe.
msvcrt.dll is basically a system file these days, only Windows 95 shipped without it. You are not supposed to use it as your C run-time but SDK code from Microsoft can probably use it without issues.
msvcrt.dll is now a "known DLL," meaning that it is a system
component owned and built by Windows. It is intended for future
use only by system-level components.
If you want to use msvcrt.dll as your C run-time as well then you must use the WDK for <= Windows 7 but when using the inline version of StrSafe.h, as long as you link to a .lib that contains the required vsnprintf type functions it should not really matter which CRT it comes from. There is also a StrSafe.lib file but Microsoft recommends that you use the inline version.
You are correct that the Windows API is supposed to be independent of the CRT but StrSafe also supports stdin functions like StringCbGetsA and they did not choose to separate those into a separate header for whatever reason. That combined with the need for a existing vsnprintf type function to do the actual work means that StrSafe is somewhat attached to the CRT even though it is meant to be used by all WinAPI developers.
There is probably no true answer to whether it is part of the WinAPI or not since it is a bit subjective. Since it is included with the SDK in the include folder one would assume that Microsoft believes it is a SDK/API component and not a CRT component.
If it's not implemented in Windows and exported from one of its DLLs (as e.g. CreateFile() or CloseHandle() from kernel32.dll), I'd say it's not part of the WinAPI, even if it ends up calling things that are implemented in Windows.
I am coding for WinAPI in MinGW
One thing I still have not fully understood is the VC redistributable,
I got a whole pack of question to it
Some say that such programs will need the msvcrt.dll
is the same library needed for bot c++ and c compilation?
is this available on all targets of clients?
must I redistribute it? can I redistribute it?
can I easily get rid of this external dependency?
is there other compiler that will allow me not to carry such unpleasant external dependency? (as I vaguely remember hearing that something is wrong with it - it is probably not core system lib, I heard, or it is not free to use and redistribute the library)
I see something wrong is here as I would like to produce no dependency small exes only calling the system WinAPI and if I use
some like C standard library functions functions I would prefer it economically and statically compiled in, not any third-party dependencies
MSVCRT.DLL contains mostly the C runtime, and MinGW can only use the C part. C++ binary code cannot be used across compilers generally.
It depends on your "target". It is available from Windows 2000.
No. No. It is Microsoft-proprietary code, and every Windows version has a slightly different version.
No. I am not aware of a mature alternative C run-time DLL.
You do not need to worry about the dependency, as it is available everywhere. (Do notice that it is not really a great run-time, esp. regarding multi-byte characters.)
Microsoft compilers can link with "static" libraries so that the resulting executable depends only on system DLLs like kernel32.dll, user32.dll, etc. MinGW cannot do this (yet).
EDIT: A concise description of the MSVCRT.DLL problem is here.
According to the MS White-paper here:
http://www.microsoft.com/en-gb/download/details.aspx?id=13350
you can redistribute certain parts of the Visual Studio components.
Some software, such as the Microsoft .NET Framework, can be
distributed. Components of software products included in MSDN
subscriptions that can be distributed (either within an application or
as separate files) without royalty are identified in the REDIST.TXT
file associated with the product. Components that can be distributed
to non-Microsoft platforms are identified in the OTHER-DIST.TXT file
associated with the product. Code identified as distributable that has
the extension .lib cannot be directly distributed; it must be linked
into the application. However, the resulting output can be
distributed.
You may also:
Modify and distribute source code and objects for code marked as “sample” or “Code Snippet”.
Distribute the unmodified output of Microsoft Merge Modules for use with an application's .msi file.
Distribute the MDAC_TYP.EXE file containing core data access components (such as the Microsoft SQL Server OLE DB provider and ODBC
driver).
Distribute the object version of C++ libraries (Microsoft Foundation Classes, Active Template Libraries, and C runtimes).
MS also produces a redistributable package specifically for the purpose of developers: http://www.microsoft.com/en-gb/download/details.aspx?id=40784
So, to answer your questions:
Yes. Although it is "purely C", it contains fundamental functions that are used by the C++ part of C as well, such as file I/O, time and date functions, math functions, and so on.
Within reason. See link above.
No, yes. As described above: You may choose to just say to customers "you need to download an install this package", but the license should allow you to distribute it free of charge with your product.
Depends on what you call "easily" and exactly what parts of the library your code uses. Some functions may be easy to replace, others not so - but it's not easy in the sense of "yes, just go do http://www.example.com/msvcrt.dll-plugin-replacement" - it would require coming up with some replacement code. The reason MinGW DOESN'T come with its own C library is that it's not entirely trivial to write a replacement for ALL of the windows functionality that you may need here...
See above - if it was easy, someone would have done it. There MAY be some compilers out there that come with their own library, but it's probably not a free-of-charge and free to distribute one (I'm not aware of any product that doesn't rely on the MSVCRT.DLL - but it's not impossible that one exists)
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 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.