I'm testing swig, and I found that SWIG's vcxproj file runs the mt.exe to generate the manifest file.
swig -c++ -csharp example.i
CL.exe ... -> compile the c++ source
link.exe ... -> generate dll
mt.exe ...
Csc.exe ...
What is this for? I skipped the mt.exe, but it seems to work fine.
It was a Very Big Deal in versions of VS prior to 2010. mt.exe embeds the auto-generated manifest in the executable image, important to get the DLL dependencies that are stored in the Windows side-by-side cache listed. Not much of a big deal anymore, it only embeds an "I'm compatible with Vista" manifest now. The side-by-side cache was rather a big headache and abandoned for VS2010.
You ought to check the .manifest file in the build directory and make sure nothing important is in it. Like the common dialogs version 6 entry that enables visual styles.
This has nothing to do with SWIG, but with how Visual C++ generates it's binary output.
The mt.exe tool does not generate a manifest file, it embeds the info from the manifest file that is already there (I think the linker would have created it) into the output DLL. Without this, the output DLL may only work while the manifest file resides along the DLL in the same directory.
(Note: I never really bothered to dig deeper regarding manifests, what info is exactly in there and if all the info in there is needed all the time, but since it's just all done automatically when you create an exe or dll in VC++ one shouldn't immediately need to bother unless something's not working :-)
Related
I have finished with my "Study Timer" project which I had developed in c++ using SDL and an eclipse IDE but I am new to Eclipse and I would like to know about a way to get Eclipse to produce a new package out of my project which i can directly supply to the end user (similar to how a .swf file is created after publishing a Flash project) that does not contain the various files and folders required only for compilation!.
Specifically:
I have many files and folders in my project that are necessary for development but not for execution!
For example, my project contains: src/ , headers/ , images/ , fonts/ ,Debug/ (contains the actual exe file) , other dll files required to compile and run...
But for execution, I only need the Debug/ , images/ , and Fonts/ !
Is there a way by which Eclipse can automatically generate a clean finished project that can be supplied to the end user?
Is is possible to produce a new executable file that is not dependant on the images and fonts folder but rather have them embedded to produce a larger .exe file (similar to a .swf that contains all the dependant media)?
For a C++ project in order to deploy it to end-users, you just need the executable(s) applications plus any system-specific dependencies (you can inspect them with Dependency Walker and find the installer for the redistributables or package them along with your app). Notice that C++ executables are NOT portable across platforms, so if you compile an exe file for Windows, it will NOT run on Linux or Mac.
Then you might need an installer to deploy everything and install it (if install is needed at all) into another user's system:
A free and easy to use one: http://www.jrsoftware.org/isinfo.php
A professional and opensource not-so-easy-to-use one: http://nsis.sourceforge.net/Main_Page
A commercial professional one: http://www.installshield.com/
Not sure: if you're asking for "what should I give the users from my Eclipse C++ project?" then you should give them a Release version of your application. Release means "optimized and without debugging aid", it will almost surely be faster and smaller than your Debug-folder executable. Then package it as I described above.
In Eclipse you can switch to "Release" (assuming a standard C/C++ Eclipse IDE) from
Build Configurations->Set Active->Release
As already stated, a Release version doesn't contain debugging code (useless for an end-user and even potentially dangerous if you have code that you would like users not to know anything about), it is optimized (debugging code is easier to read even in assembly mode and easier to analyze for bug trackings) and thus the executable is often way smaller in size.
After question update: for your executable to use embedded resources (i.e. reference things inside its own binary executable rather than relying on outsie files) you need a resource file to include and link into your executable. This depends on the compiler as well (Eclipse is an IDE, something that helps you writing code but it's not the program that really creates your exe file.. something that lies under the hood of Eclipse and to which Eclipse "communicate" what to generate).
Long story of what I'm trying to achieve
I'm working on a program that dynamically loads DLLs as plugins. I'm compiling the program using Microsoft Visual C++ 2008. Still, let's assume that any Visual C++ version with which Qt works should be supported. The program directory layout is following:
| plugins/
| plugin1.dll
| plugin2.dll
| QtCore4.dll
| QtGui4.dll
| program.exe
program.exe discovers all plugins DLL files, performs LoadLibrary() on them and calls a certain signature function to find out if it's actually a plugin or not. This works pretty well on computers which have vcredist for MSVC90 installed. Naturally, to make the program work on all computers I have to redistribute it with the msvc*.dll files and with the appropriate manifest file. Qt DLLs also require the redist to run.
Now, I've set up cmake to automatically copy over appropriate redist DLLs and manifest depending on the selected Visual Studio version. For the sake of simplicity let's keep assuming that I'm working with MSVC90. When the redist gets copied to the program directory the layout looks like this:
| plugins/
| plugin1.dll
| plugin2.dll
| QtCore4.dll
| QtGui4.dll
| msvcm90.dll
| msvcp90.dll
| msvcr90.dll
| Microsoft.VC90.CRT.manifest (I'm also aware that this file is bugged in VS2008)
| program.exe
Regarding the bug in manifest file: http://www.cmake.org/pipermail/cmake/2008-September/023822.html
The problem
The program with this layout now works on computers which do not have the redist installed, but the plugins are not getting loaded. In order to get the plugins to load I have to do one of the following:
Copy over the manifest file to plugins/ directory. Remove all references to msvc*.dll files from the manifest file. This works but it's not nice because I'd have to support different versions of edited manifest files depending on the version of used MSVC. Also, I have no idea if this won't break with Visual Studio other than 2008.
Copy entire redist to plugins/ directory. This doesn't require any modification to the manifest file, but now program.exe stupidly tries to load the msvc*.dll files thinking they are plugins. Naturally, this fails gracefully so no big harm is done. The other drawback is that the size of the program package grows by over 1 MB. Both these issues are something that I can live with, though.
Compile plugins with /MT switch. Brief testing has shown that this actually works but I'm not sure if it won't break anything in the future if both Qt and program.exe are /MD.
The question(s)
What's the best solution? What's the correct solution? If there is more than one correct solution then which is the best practice? Am I the first person to ever try to do this?
Update 1 (18 Nov. 2012)
While the question remains unanswered I decided to go for the route that causes the least headache. Until now I've been using solution number 1 and I decided to stick with it. If CMake detects that user is using a different MSVC version than 2008 it will display a warning message saying that automatic packaging is not fully supported.
If your target OS has _WIN32_WINNT >= 0x0502 than you can use function
SetDllDirectory()
before you do loading the plugins.
Put path to main program folder.
The call overrides system load order:
The directory from which the application loaded.
The directory specified by the path in SetDllDirectory() call.
So, you may call the function after application starts up. It is safe in all cases. Good luck!
You can provide full file paths to "LoadLibrary", so you can load your plugins with their paths. I've used this exact layout to load multiple versions of the same library from subdirectories of the current dll in Visual Studio 2005.
You first need to get the current path of the current dll using:
static LPSTR strDLLPath1 = new TCHAR[_MAX_PATH+1];
::GetModuleFileName((HINSTANCE)&__ImageBase, strDLLPath1, _MAX_PATH);
Although if your program.exe is already discovering these plugin files, I would assume you already have access to their full paths.
You can create hardlinks to VC dlls with CreateHardLink() function at installation process. With method (1) that you have described, there may be some problems with different copies of VCRT dlls. Hardlinks or SetDllDirectory() seems the best solution.
Don't mix in a single process static and dynamic link to MSVCRT - it ALWAYS gives you problems!
In summary: Today I discovered that when a DLL is built without precompiled headers, a strange error shows when you try to use it.
Building the DLL goes fine when precompiled headers are disabled. However as soon as the DLL is attached (either compile-time or run-time) it results in the error "Invalid parameter". The actual error codes are different for both cases. When attaching compile-time a dialog pops up with error code 0xc000000d, when calling LoadLibrary() it returns a NULL pointer and GetLastError() returns 0x57.
EDITs:
I discovered that the problem goes away when incremental linking is disabled.
Somehow I missed the following error showed by Visual Studio when running a client that attaches to the DLL compile-time:
'TestClient.exe': Loaded 'D:\Projects\PchDllTest2\Debug\TestClient.exe', Symbols loaded.
'TestClient.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or open the PDB file
'TestClient.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find or open the PDB file
'TestClient.exe': Loaded 'D:\Projects\PchDllTest2\Debug\TestDll.dll', Symbols loaded.
SXS: RtlCreateActivationContext() failed 0xc000000d
LDR: LdrpWalkImportDescriptor() failed to probe D:\Projects\PchDllTest2\Debug\TestDll.dll for its manifest, ntstatus 0xc000000d
Debugger:: An unhandled non-continuable exception was thrown during process load
The program '[5292] TestClient.exe: Native' has exited with code -1073741811 (0xc000000d).
As requested, the function declaration:
#ifdef __cplusplus
extern "C" {
#endif
MYTEST_API int MyTestFoo(int a);
#ifdef __cplusplus
}
#endif
There's one thing that is remarkable about this: When you create a new DLL using a wizard (New project -> Visual C++ -> Win32 -> Win32 Project), the wizard forces you to use precompiled headers when selecting DLL as application type. See answer from ta.speot.is.
I drastically changed the question, as it looked first like I thought that it was somehow documented that PCH is required for DLL projects. This is not the case, it's probably a weird kind of bug (let's hope it's not) or probably I'm doing something very stupid...
Why are precompiled headers required when building a DLL?
They're not.
In summary: Today I discovered that it's not possible to make a (functioning) DLL without building it with precompiled headers. Does anyone know what the reason is for this?
The reason for discovering this is that you misread something.
You can make binaries without precompiled headers just fine.
There's one thing that is remarkable about this: When you create a new DLL using a wizard (New project -> Visual C++ -> Win32 -> Win32 Project), the wizard forces you to use precompiled headers when selecting DLL as application type.
Perhaps in Visual C++ 6, but my experience with Visual Studio suggests otherwise. If you make an empty project with the wizard you do not get a precompiled header.
All that aside, I had a look on Google for "for its manifest, ntstatus 0xc000000d" and ultimately I wound up here. The last answer suggests that your CRT versions are mismatched, which would be very hard to do if you're letting Visual Studio create the projects for you and sticking with the defaults.
It might pay to check that you are linking to the same version of the CRT in your "host" application and library (e.g. both are multi-threaded debug).
The only other thing I can think of is that you're moving TestDll.dll into the Debug folder without its accompanying TestDll.dll.manifest file (if it has one).
I found out that the DLL has an embedded manifest resource containing only a little-endian UTF-16 byte order mark. The windows DLL loader crashes with the described error when it tries to load such a DLL.
I'm convinced that this just is a weird bug: If I build the DLL using Visual Studio or MSBuild, it results in an DLL with the bogus manifest resource. If I execute the commands reported by MSBuild manually on the command line, the DLL contains a valid manifest resource with a UTF-8 BOM.
As described building a DLL with PCH disabled results in a manifest resource containing only an UTF-16 LE BOM.
If a DLL is built with PCH enabled, the manifest resource contains a UTF-8 BOM followed by valid XML.
If a DLL is built with PCH disabled AND incremental linking disabled, the manifest resource contains only XML and no BOM at all.
Another option is to remove the faulty manifest resource using a resource editor after the build has been completed, than the error also disappears.
This is very reproducable, using wizard or if you create an empty project and do everything yourself.
With "precompiled" headers, you are effectively using code that was compiled earlier. If you introduced a bug later, "precompiling" will not compile the bug but use the older bugfree code.
I am starting to learn DX11 and running into trouble with the effects framework. I know it was released as source and I have to build it, but the output from the build is not what I expected.
According to the research I've done on this question, the output from the build should be
D3DX11EffectsD.lib for debug
D3DX11Effects.lib for release
However, when I look into the 'Effects11\Debug' directory after building the project, I only see a file Effects11.lib (well, an Effects11 Object Library file which I assume is a .lib, I'm new to c++), and the exact same file in 'Effects11\Release'. Whats going on here? I've never used VS 2010 for c++ before now but I think I am building the solution correctly.
Is this a matter of renaming the files or have I done something wrong without realizing it? There really isn't much documentation on building and linking libraries in vs 2010 that I could find. Anybody have any suggestions?
Thanks
If you compiled exactly what you got off the web, then I think it would be just a naming convention problem.
You should try compiling it into your end application and see if it yells about debugging symbols missing.
You can also go into the build settings (it has been a while since I have used visual studio for anything other than C# so I don't know exactly where that menu option would be (I assume right clicking on the project should yield some useful results)...I generally do my C++ stuff on linux) and check to see what the built targets are for debug and release. If it turns out that the names are the same for both, but the build targets (i.e. the folder and a few other options, like including debugging symbols) are different then you should be good and it is just a naming problem.
Also, if the files are the exact same size it is likely that they are the same since the debug file should be at least a bit larger than the release one.
If it turns out that they are the same file, try re-downloading or re-extracting the source and just compiling the project again without any changes and see if that gets any results.
I am a professional working for a software firm.In my past company basically i was working on C & C++ on unix.Now i suddenly shifted to C++ on Windows and i feel like i am in a completely different world.Basically i am working on a very big application which was totally written in C++.To keep it simple ,i dont have the source code .I have the exe of the application and several other dependent files.it is a GUI application(several windows,reports,graphs and huge mathematical calculations are done by this application).Now i finally have the source code of the application which includes some headers,some vcproj files,some dsw files and several other which i dont even understand why the hell are they present.
Now as i C++ programmer my responsibility is to make all the BUGS that the clients identify replicate and fix them.
If its a bug on unix i can simply use the binary and source code and run gdb/dbx and find out the issue in some or other way like adding adding some printf statements.
But given the files i mentioned above.how could istart debugging an application in VC++ in VISUAL STUDIO.
Is it very difficult for a C++ programmer to shift from Unix to Windows.
Is ther any good resource which i could refer for this kind of change where i could grasp things quickly?
given the exe and the source code of the application how can i start debugging a program by running the application in VS C++-(BTW i am using VS 2005)
The main difference is that on Unix, you'll have Makefiles, which you won't find on Windows. Visual Studio organizes your code in projects and solutions, and those project files contain all the information VS needs to compile&link your projects.
If you have a *.sln file, just double click it to open it in VS. Then build the source (usually by pressing F6) and run in debug mode (usually F5).
More details:
A project is a collection of source files that result in 'something', usually a LIB, a DLL or an EXE.
A solution is a collection of projects. Useful when e.g. one project creates a LIB that is used by another project. When you set dependencies between projects, VS will build the projects in the right order.
Extensions used:
*.vcproj : Project file for C/C++ sources
*.vcproj..user : contains which windows are open in the GUI.
Can safely be deleted.
*.sln : Solution file
*.ncb : Intellisense database for a solution. Can safely be deleted.
*.suo : contains which windows are open in the GUI. Can safely be deleted.
*.dsw : Visual Studio 6.0 related file - not used in VS2005. (Replaced by *.sln IIRC)
./Debug/* : folder with all
intermediate files for a Debug build
(can be changed)
./Release/* : folder with all
intermediate files for a Release
build (can be changed)
That's all I can think of at the moment.
If you only have a .DSW file and not a .SLN file, then it means that the project was probably last worked on with VC6 and not one of the later Visual Studio versions.
That's a shame, because there have been lots of changes to the C++ compiler since VC6, and you're probably going to find the project doesn't compile with VS2005 without needing some minor changes to source code.
Do you have a .SLN file - if so, what's the version number at the top of the file (it's a text file)? If you don't have a .SLN file, can you get hold of VC6?
I would always try to get stuff going on an unfamiliar platform with the best matching tools, before I tried to bring it forward to later versions.
I understand your pain; I took the same path a few months ago.
You probably figured it out, but Visual Studio is not the exact alternative of gcc/g++. It embeds a text editor, a debugger, and so on.
Usually, you have two compilation "modes", debug and release. (you can add your own)
When in debug mode, all optimization are disabled and you can execute your program in the debugger, use step by step, add breakpoints, ...
Just start it using the F5 key.
More notes on the additional files:
In the Visual Studio world, .vcproj files represents "projects": a bunch of file that belongs to the same project (source files, headers, resources, ...).
A .dsw (old name for current .sln files I believe) is a "solution" file: a group of one or several projects which can have internal dependencies. Example: you can have in the same solution, a library and a software that depends on it. So that when you compile the whole solution, things are built in the correct order.
First thing you should try is to attach to the process while it's running (Ctr-Alt-P and select the process) if you have the .pdb (debug information) files you should be able to debug the process without re-building it.
If that fails try to un-check the "Require source files to exactly match the original version" option in Tools -> Options -> Debugging.
If that too fails you'll have to build the application again (by opening the .sln file and performing a build) so that the binary matches your source files.
Good luck.
Compile the code with debug info and press f5 (Start Debugging). I don't see where is the problem. On linux is sort of the same.
VS2005 can convert the dsw file for you to a sln file, but you need all of the original VC6 files in order for the conversion to be successful. For debugging please check out following msdn link, I hope this will help you.
http://msdn.microsoft.com/en-us/library/sc65sadd.aspx
Please select hyperlink "Debugging Native Code" for C++ specific.