I would expect the mfc to refer to the Microsoft Foundation Classes, but this still leaves the following questions:
What does the s stand for?
What does the 90 mean?
These MFC link libraries are lightly documented by Microsoft's TN033 Tech Note: http://msdn.microsoft.com/en-us/library/hw85e4bb.aspx
A quick summary about the mfcsxxx.lib files is: The MFCSxx[U][D].LIB libraries are used in conjunction with the MFC shared DLLs. These libraries contain code that must be statically linked to the application or DLL.
The "U" designates that the library is built for Unicode.
The "D" designates that the library is built for Debug.
If the number in the library is 90, then it's compiled with and for Visual Studio 2008 (VC++ 9.0)
If the number in the library is 100, then it's compiled with and for Visual Studio 2010 (VC++ 10.0)
Note that while the mfcsxxx.lib files have code that is statically linked to the output binary, they are used in conjunction with the DLL versions of MFC - when statically linking MFC, the [nu]afxcw[d].lib libraries are used (where "n" or "u" determines whether or not the library is Unicode, and "d" is used in Debug builds).
Other related MSDN pages:
Library Naming Conventions (for MFC static linking)
Naming Conventions for MFC DLLs
C Run-Time Libraries
90 is 9.0 and means it corresponds to Visual Studio 2008
I'm going to take a stab at the 's' and say it says the library supports MultiByte Character Sets (as opposed to Unicode or ANSI), but I could not find a link that directly confirmed that.
Edit:
Michael Burr is correct, the 's' indicates it is a library that is statically linked and used in conjunction with the shared DLL versions of MFC. I almost prefer the documentation for Visual Studio 2003: http://msdn.microsoft.com/en-us/library/eezxhb2t(v=vs.71).aspx where it has the DLL in the table and explains what it is for.
Related
I just tried to compile an old MFC app under VS2013. It complained that non-Unicode MFC applications were deprecated, and refused to compile. Which is somewhat contrary to this announcement that talks about deprecating support for MBCS. Until now there were three choices for the Character Set option:
Unicode
MBCS
Not set
Personally, I'm entirely comfortable with dropping support for MBCS - I neither want nor need MBCS. But nor do I want nor need Unicode - ANSI/ASCII is just fine by me. So insisting that every MFC application henceforth must speak Unicode, and (in effect) provide the foundations of a platform support all possible languages, no matter who its intended audience is, seems... extreme. Am I missing something? Should I still be able to compile an MFC application with no character set specified under VS2013?
You can. Currently all my programs use the Unicode library. Except one older one, that includes very old code from previous versions and this program is needed for update support for this od version...
Currently there is an Addon that still supports MBCs.
Vote for it
As I understand the discussion (see comment of Mark Davis dated December 2014) such an Addon will be available up and including VS2015 (whatever Version is meant).
To be more precise what happens when you select "None" for the character set:
You program is linked against the MBCS Version of the MFC
Also the Windows SDK will Default to the MBCS Version of the API. So i.e. GetWindowTextA is calls instead of GetWindowTextW
So in fact. Setting _UNICODE and _MBCS to nothing just Defaults to _MBCS...
Internally the SDQ always checks a if UNICODE (not _UNICODE) is set. If not the MBCS Version is chosen.
I have been recently learning multi-threaded algorithms from Introduction to Algorithms (by Cormen, Rivest), third edition. And the preface of the book inspired me to use Cilk Plus extension for the same developed by MIT. However, I have not been able to get any article online to integrate it with my CodeBlocks IDE for utilization. Is there any set of commands to declare linker settings for the same?
Contents of the Folder C:\Programs(x86)\Intel\CilkTools
bin : contains ia32, intel64 folders (containing dlls) + other dlls and exe
doc : an html page and a jpg document
include : has CilkTools which has four .h files : cilkscreen.h, cilkveiw.h, fake_mutex.h, and lock_guard.h
opensrc : has a zip file (ZedGraph, open source graphing package)
visual studio and example files
You're confusing the compiler with the Cilk tools. First you'll need to install Intel C++ Composer and integrate that into your IDE. The Wikipedia article I found on Code Blocks claims that should work, but I don't know the details.
Then you'll want to install the Intel Cilk Plus SDK which provides you the Cilkscreen race detector and the Cilkview scalability analyzer. The Cilk tools come with an addin to integrate into Visual Studio, but you'll have to use the command line with other IDEs. The major benefit of the addin is being able to click on a callstack entry and go to that line in the Visual Studio editor. But the text version of the report is easy enough to read.
Don't ask why the names are so confusing. We (the development team) were not allowed to choose the names.
- Barry Tannenbaum
Intel Cilk Plus Development
I just recently bought some hardware that came with a header file and object file library (The hardware is NI USB-6008 DAQ Card). I want to link the library to my current project in visual C++. I have included the header file, but how do I link the library that came with the hardware to the project?
Thanks!
I am going to assume you are using Visual Studio and the library has come compiled already. Right click your program under solution explorer, select properties and under the Configuration Properties, select Linker then Input. You should see a field called Additional Dependencies in which you can add the .a or .lib file. The settings look like the below. You can also link in the source files (only Visual Studio can do this as far as I am aware) by typing #pragma comment (lib, "yourlibraryfilehere.lib") This method only works if the .a or .lib file is in Visual Studio's /lib/ directory.
Is it possible to use GNU gettext with MS Visual C++? Does someone know where to find a sample project that compiles under Visual C++?
Update:
Thanks to Sorin Sbarnea for his comments which help me to put all the pieces together:
I'm used to the Delphi version of gettext where you simply compile the unit gnugettext.pas with your project, that is why I was simply trying to compile gettext.h with my MSVC project. It might work for other C++ compilers but not with MSVC.
The FAQ of GNU gettext explains how to do it with MSVC by using precompiled DLLs. But there are no links to the DLLs and these DLLs aren't in the main download. They must be downloaded separatly from the ftp site. You will need 2 files for the dlls:
gettext-runtime for win32
libiconv for win32
And if you need tools to extract the strings from the exe, you also need:
gettext-tools for win32
I haven't tried it yet with MSVC, but now I think it will works.
Clearly I know lots of project that are using gettext in MSVC. Also if you are considering using GNU gettext runtime in a commercial, closed-source, project be aware that the runtime library is LGPL. This means mainly that you need to open source any modification you may do to the gettext runtime library (not your code).
Also, gettext utilities are using GPL license - but this is not so important because you don't need/want to distribute them.
For Win32 you should get the gettext runtime from Gnome FTP because the build is newer than the one from GNU.
Regarding open-source software take a look at PoEdit.
GNU gettext-0.18.3.2 Visual C++(MSVC) runtime download, it works well for me.
I am getting an error while porting my application from VC6 to Visual Studio 2005.
Does anyone have any idea what this means?
mfcs80.lib(dllmodul.obj) : error
LNK2005: _DllMain#12 already defined
in MSVCRT.lib(dllmain.obj)
From http://support.microsoft.com/default.aspx?scid=kb;en-us;q148652
A LNK2005 error occurs when the CRT
library and MFC libraries are linked
in the wrong order in Visual C++
Because
The CRT libraries use weak external
linkage for the new, delete, and
DllMain functions. The MFC libraries
also contain new, delete, and DllMain
functions. These functions require the
MFC libraries to be linked before the
CRT library is linked.
So
There are two ways to resolve this
problem. The first solution involves
forcing the linker to link the
libraries in the correct order. The
second solution allows you to find the
module that is causing the problem and
to correct it.
Either
Force Linker to Link
Libraries in Correct Order
On the Project menu, click Settings.
In the Settings For view of the Project Settings dialog box, click to
select the project configuration that
is getting the link errors.
On the Link tab, click to select Input in the Category combo box.
In the Ignore libraries box, insert the library names (for example,
Nafxcwd.lib;Libcmtd.lib).
Note The linker command-line equivalent in /NOD:.
In the Object/library modules box, insert the library names. You
must make sure that these are listed
in order and as the first two
libraries in the line (for example,
Nafxcwd.lib Libcmtd.lib).
To set this option in Visual C++ .NET,
read the "Setting Visual C++ Project
Properties" online help topic.
Or
Locate and Correct the
Problem Module To view the current
library link order, follow these
steps:
On the Project menu, click Settings.
In the Settings For view of the Project Settings dialog box, click to
select the project configuration that
is getting the link errors.
On the Link tab, type /verbose:lib in the Project Options
box.
Rebuild your project. The libraries will be listed in the output
window during the linking process.
I'm sure there are a number of reason this could happen - the worst one I ever found was when trying to integrate a number of static libraries (ours) that were originally DLLS (in fact, we build the projects as both DLL & static libraries).
Our C++/CLI DLL was using the static versions of these libraries (To avoid DLL dependency issues that were causing ASP.NET loading issues when the C++/CLI Dll was being used) and was initially seeing the same linker error.
The problem turned out to be the use of AFX_MANAGE_STATE(AfxGetStaticModuleState()) macro that was needed when the code was built as a DLL but not actually needed for the static library call.
To solve this i ended up adding the following code to the stdafx.h of each project.
#ifdef OMUTILITIES_LINK_STATIC
#undef AfxGetStaticModuleState
#define AfxGetStaticModuleState AfxGetModuleState
#endif
This, of course, may not be your specific problem. But the way i eventually figured it was by turning on the /VERBOSE option for the linker and seeing who, what, where & when it was pulling in the runtime libraries. (Project Properties/Configuration Properties/Linker/Show Progress in vs2005)
You could set the linker input to ignore the troubling library in the project properties, but this may or may not work.