I've got an C++ application originally written with Visual Studio 6.0
The application is standard and raw Win32 API, no MFC(*Edit 2), no .NET, statically linked, multi-threaded executable.
I have migrated through all versions of Visual Studio up to 2010 (today) and never had any problems until now:
It compiles and runs perfectly with VS2010 BUT the generated executable size is four (4) times larger!
I've tried all the options I know (optimizations, remove debug info, etc..) with no results. Granted, I am new to VS2010, but not to Visual Studio.
Has anyone encountered this problem? Again: I am NOT using any frameworks, it is a raw, statically linked, Win32 application, no DLLs, no ODBC, no network, no .NET
Hoping to see my executables small once again, I thank you for any input.
Edit 1:
Original Size=626KB (VS6.0, VS2008)
Bloated size=2.013KB (VS2010)
Edit 2:
After some research and dumps, I discovered a hidden reference to MFC.
Originally I said it did NOT use MFC, but it does.
The increase in size may be caused by changes to the MFC. Here is an explanation, and here is a workaround by the same author that brings the executable's size back down into regions where it was with 2008. The workaround involves editing copies of MFC source files, though, a process not everybody may be happy with, and which needs to be repeated after every update, e.g. after installing a Visual Studio service pack.
Update:
It looks like the OP does not use MFC, so these might be two different issues. I have experienced the size increase myself but unfortunately cannot say whether caused by MFC or not since my project statically links to the MFC.
If you are using static linking, I suggest using the linker switches if you are compiling at the command line using the syntax:
cl /Ox [your C++ source file(s)] [libraries required if any] [resource files required if any] /link /FILEALIGN:512 /OPT:REF /OPT:ICF /INCREMENTAL:NO
If you are building within the Visual Studio IDE, you check the linker settings by selecting the project properties from the menu. In the configuration, select the Release and then click the linker settings found on the left pane, this will show you a list of configurations corresponding to the linker settings currently set by default.
In the Command Line under the linker, specify the option /FILEALIGN:512 in the Additional options entry then click the Apply button. In the General option under the linker, disable the incremental linking by selecting No(/INCREMENTAL:NO ). In the debugging option of the linker, select No for Generate Debug Info. For the linker optimization, you select the Eliminate Unreferenced Data(/OPT:REF) in the References and Remove Redundant COMDATs(/OPT:ICF) in the Enable COMDAT folding.
For the compiler optimization, make sure the Release configuration is selected, click the C/C++ tree view on the left pane and under that, click the Optimization, Select Full Optimization(/Ox). In the General setting under C/C++, Select Disabled for the Debug Information Format.
Don't forget to click the Apply button for every changes you make.
I hope everything I've mentioned here would be helpful to you and all of these applies to Visual C++ 2005 and 2008 but hopefully, it would also apply to Visual C++ 2010, if not, kindly check the documentation included with your Visual C++ 2010 installation.
Any chance you've left the default platform target at "Any CPU"? If so, change it to x86 for 32-bit only code. I'm guessing that will make up most of the difference. The remainder is likely in changes in compiler optimizations (more aggressive loop unrolling and whatnot where size has been traded for speed since RAM is cheap). I believe all the granular optimizations are still available from the command line, but many have been obscured in the UI options panels.
See Are there any tools for tracking down bloat in C++? - some techniques how to analyze what contributes to the executable size are described there. Once you perform analysis on both VC 6 and VS 2010 output, hopefully you will find something useful.
There is one particular gotcha which has hit me when porting from VC 6 to some Visual Studio edition: meaning of some optimization options has changed and the values I was using in the VC 6 project were no longer supported, and as a result the exe produced by VS was not optimized at all, causing both executable bloat and slow performance. Check your optimization settings in Properties/C/C++/Optimization and make sure optimization is on /Ox, /O2 or /O1.
This is because in VS2010 Microsoft added functionality allowing HTML components in a dialog windows so a bunch of stuff is pulled in and linked in even if you aren't using it and the optimizations and options and removing unreferenced code do not help. There is not a "good" way of removing the code, but there are some hacked up ways. We compile our size-critical stuff on VS2008 still because of this. Side note, our non-GUI code actually compiles smaller for what that's worth. Hoping MS comes up with an option for this in a fix/patch so I can do everything on VS2010 but I'm not holding my breath...
Related
I have installed the Visual Studio 2015 and created Win32 project with some code. I compiled it successfully, but I can't launch exe file, because I don't have some ucrtbased.dll...So how can I solve it?
Edit:
The English equivalent message is:
"The program can't start because ucrtbased.dll is missing from your computer. Try reinstalling the program to fix this problem. "
This problem is from VS 2015 silently failing to copy ucrtbased.dll (debug) and ucrtbase.dll (release) into the appropriate system folders during the installation of Visual Studio. (Or you did not select "Common Tools for Visual C++ 2015" during installation.) This is why reinstalling may help. However, reinstalling is an extreme measure... this can be fixed without a complete reinstall.
First, if you don't really care about the underlying problem and just want to get this one project working quickly, then here is a fast solution: just copy ucrtbased.dll from C:\Program Files (x86)\Windows Kits\10\bin\x86\ucrt\ucrtbased.dll (for 32bit debug) into your application's \debug directory alongside the executable. Then it WILL be found and the error will go away. But, this will only work for this one project.
A more permanent solution is to get ucrtbased.dll and ucrtbase.dll into the correct system folders. Now we could start copying these files into \Windows\System32 and \SysWOW64, and it might fix the problem. However, this isn't the best solution. There was a reason this failed in the first place, and forcing the use of specific .dll's this way could cause major problems.
The best solution is to open up the control panel --> Programs and Features --> Microsoft Visual Studio 2015 --> Modify. Then uncheck "Visual C++ --> Common Tools for Visual C++ 2015". Click Next, then and click Update, and after a few minutes, Common Tools should be uninstalled. Then repeat, but this time install the Common Tools. Make sure anti-virus is disabled, no other tasks are open, etc. and it should work. This is the best way to ensure that these files are copied exactly where they should be.
Error Codes: Note that if the installer returns a cryptic error number such as -2147023293, you can convert this to hex using any of the free online decimal-to-hex converters. For this error it is 0xFFFFFFFF80070643 which, dropping the FF's and googling for "0x80070643", means `0x80070643 - Installation cache or ISO is corrupted'.
Why is ucrtbased.dll even needed?: Any DLL named "crt" is a "C-Run-Time" module or library. Microsoft explains them best. There are many variants of CRT today. They contain essential helper-code used by all Microsoft compiled executables, to "shim" or help your executable operate on the ever-growing number of OS versions and hardware. If the MSVC compiler is used, the relevant CRT DLL is linked automatically at compile-time. (If the DLL cannot be found at compile-time, then a linking error is generated.)
One way to not require the DLL, is to "statically-link" it to your project. This means that you essentially take the contents of ucrtbased.dll, and include it in your executable. Your file size will grow by approximately the size of ucrtbased.dll.
Incidentally, if you've ever run a MSVC program (usually from another individual, one of your old compiled programs from a previous OS version, or yours from a different machine) and it does not start, giving an error message of needing "Microsoft Visual C++ 20xx Redistributable" or "run-time" - then it means it can't find the needed *crt*.dll file. Installing that particular redistributable package (if known) will install the DLL, and allow the program to run... or at least get past that error and alert you of another missing DLL.
If you find yourself in this "DLL Hell" predicament, google "dependency walker" for an advanced tool to show which DLLs are still missing. This usually doesn't happen with professional software, simply because their (large, bundled) installers check for any missing dependent libraries (including CRT) and installs them first.
The problem was solved by reinstalling Visual Studio 2015.
rdtsc solution did not work for me.
Firstly, I use Visual Studio 2015 Express, for which installer "modify" query does not propose any "Common Tools for Visual C++ 2015" option you could uncheck.
Secondly, even after 2 uninstall/reinstall (many hours waiting for them to complete...), the problem still remains.
I finally fixed the issue by reinstalling the whole Windows SDK from a standalone installer (independently from Visual C++ 2015 install):
https://developer.microsoft.com/fr-fr/windows/downloads/windows-8-1-sdk
or
https://developer.microsoft.com/fr-fr/windows/downloads/windows-10-sdk
This fixed the issue for me.
An easy way to fix this issue is to do the following (click on images to zoom):
Make sure to close Visual Studio, then go to your Windows Start -> Control Panel -> Programs and Features. Now do this:
A Visual Studio window will open up. Here go on doing this:
Select the checkbox for Common Tools for Visual C++ 2015 and install the update.
The update may takes some time (~5-10 minutes). After Visual Studio was successfully updated, reopen your project and hit Ctrl + F5. Your project should now compile and run without any problems.
I would like to suggest additional solution to fix this issue. So, I recommend to reinstall/install the latest Windows SDK. In my case it has helped me to fix the issue when using Qt with MSVC compiler to debug a program.
I am not sure it will help but you can try this.This worked for me
Start -> Visual Studio Installer -> Repair
after this enable the Microsoft Symbols Server under
TOOLS->Options->Debugging->Symbols
This will automatically set all the issues.
You can refer this link as well
https://social.msdn.microsoft.com/Forums/vstudio/en-US/6aa917e5-a51c-4399-9712-4b9c5d65fabf/ucrtbasedpdb-not-loaded-using-visual-studio?forum=visualstudiogeneral
I would like to use VC2010 to handle a BCB 2006 project I have. I do not want to convert the code to VC since much UI will need to be ported. I just want to be able to view build & debug from VS IDE.
Viewing: I assume once I create VS projects for the native BCB code viewing will be possible, although the UI editor will not.
Building: I found the "C++ Native Multi-Targeting" option of VS, although I'm not sure on what to set the different options there to (Daffodil is mentioned as helpful although I'm not sure what the added value is over existing functionality).
Debugging: not sure how to do this at all from within VS. There are some stand alone console tools that convert debug info files e.g. tds2pdb (wheres the documentation link?).
If anyone has experience with such a task I would thank you for any advice.
No. The C++ Builder IDE is a stand-alone, separate Win32 executable that has nothing to do with VC or Visual Studio, and can't be embedded in it in any way. You'll have to use C++ Builder itself to view, build, and debug it's apps; there's no way to do so as part of Visual Studio.
Even simply using the C++ Builder code will most likely not be possible if there is any UI involved at all. C++ Builder's GUI components are based on the Visual Component Library (VCL) that it shares with Delphi, and therefore it uses a Delphi Object Pascal compiler to build those parts of the application. There are also data types and set operations that VC will not understand or support, and some special #pragmas and #hppemit statements the VC compiler wouldn't be able to use.
Is there a way in MS Visual Studio 2010 (I use Intel Visual Fortran Composer XE 2011) to search for subroutines and modules? For example if I am in a subroutine (written by somebody else) that calls another subroutine subname, I usually use "find in files" to find this latter subroutine, but is there a more direct way, e.g by right clicking on the function (or module) name? i could not find any.
Thanks
As of Composer XE 2011 update 6 (compiler version 12.1), the style of source browsing that you are after is available within the Intel Fortran Visual Studio integration. You need to make sure that you have enabled it - under Tools > Options in the Text Editor > Fortran > Advanced category set Collect Call/Callers graph information and Collect Object Browser information to true and Disable Database to false.
A restart of Visual Studio may be required. Modules and procedures in the current solution can then be browsed using the drop down lists at the top of the source code editing windows and various options on the right click menu in the editor window.
For solutions with large code bases, acquisition and maintenance of the of information that the source browser relies on can be rather resource hungry. Support for procedures accessed via a generic interface is poor.
Source Editor Enhancements by Fortran CodeNav.
Fortran CodeNav is an useful extension for fortran coding with MS VS. It supports "Jump to declaration of member","List usages of element","Auto-complete" and search. I recommand Fortran CodeNav because it supports shortcut keys. Fortran CodeNav for VS2010 can be downloaded at its old site.
Source Editor Enhancements by IVF
#IanH's answer has mentioned about it. Maybe you could find the guide to Source Editor Enhancements in developer guide and reference book of your IVF version. As of XE2018 update 1(IVF Compiler 18.0), the guide is here. But it doesn't support shortcut keys.
I am using Visual Studio 2008. I don't need to debug some DLLs in my project, so can I disable symbol loading when debugging a Visual C++ program? Does it help to make startup time faster when debugging?
The symbols are all local, so I don't have those slow loading problem, just want to make debugging faster and faster.
For example I am using Qt libraries, when I hit "Starting Debugging", the Output window shows that the symbols for Qt libraries are loaded. If VS can stop loading those symbols, the debugging startup time should be faster. Of course, I still want VS to load symbol for my executable.
Just found out that Visual Studio 2010 actually do what I want.
To load only the symbol for your executable file, without loading other symbols (eg: DLLs):
Go to Tools->Options->Debugging->Symbols
Click "Only specified modules"
Clear "Always load symbols located next to modules"
Click "Specify modules"
Click the new icon
Enter your executable filename (eg: my-awesome-app.exe)
Also found out that Visual Studio 2010 seems to perform better than Visual Studio 2008 when debugging. At least the IDE layout switches back faster when the debugging is stopped.
I am not sure what you mean by 'startup'. I assume you are talking about the launching of the actual application. The time to launch the target application is expensive regardless of mode you launch it. It may be less in Release but that will be negligible.
Turning off all symbol paths as mentioned in the other solution is a viable option. However, I am not sure why you are debugging if you do not want symbols for your launched application. Without the applications symbols you will not be able to see where you are in the source code when you are debugging.
If you are looking for a faster debugging experience you can use WinDbg. It comes with the Windows SDK but can also be downloaded seperately. If is a faster UI than Visual Studio, but it is much more cumbersome to use if you are more comfortable with a GUI. WinDbg uses commands to perform almost all tasks, but you can do some great debugging and it is faster in many cases compared to Visual Studio. In the event you want to debug C++\CLI or any managed application (e.g. C#), I would stick with Visual Studio. There is an extension in WinDbg called SOS, but it requires some advanced debugging experience to use correctly.
I just moved from Visual Studio 2008 to Visual Studio 2010 (final) and noticed one major flaw:
When I try to use AutoComplete in a C++ source file for managed C++, a small note in the footer appears:
IntelliSense for C++/CLI is not available
Uh, has IntelliSense for C++/CLI been dropped from Visual Studio 2010? Is there any way to get this back? It is rather useful...
You are correct. Unfortunately it has been dropped. You can check this opened issue on Microsoft's Connect website.
I'll just quote them for the sake of the answer:
Unfortunately in this release we had to cut the intellisense support for C++/CLI due to time constraints. If you want to get some intellisense like quick info and memberlist on the native classes you can get it by choosing no /clr support in the project properties.
About getting back intellisense, your best chances for now are using third-party tools like VA Assist for example. I've tried it with Visual Studio 2008 and its IntelliSense is a whole lot better than the default one.
It is available again in Visual Studio 2012.
If you want to get IntelliSense back, install Visual Assist X from Whole Tomato Software. Here you can get a 30-days trial to check the intellisense.
According to the Visual C++ Team Blog, C++/CLI Intellisense will be in the next version of Visual Studio, but not in a service pack for VS2010. That blog post also gives some detail as to what went wrong and led to this sad state.
I don't know if you can use this settings but it work for me. I only check the Common Language RunTime Support for the cpp files that use it. I do not check it for the whole project and I've got intellisense for all the files that don't use the CLI.
Yes! you can enable the IntelliSence, but in a tricky way. Follow these instructions:
Go to your project properties. (Right click on your project name in
Project Explorer, and select Properties. or simply Alt + Enter)
From Configuration Properties, select General
In the right-hand section, find "Common Language Runtime Support"
and change it to "No Common Language Runtime Support".
Click the OK Button.
Now the IntelliSence is working. But a problem is an error when you compile your code! (The error is: error LNK1123: failure during conversion to COFF: file invalid or corrupt)
You can simply go back to Project Properties an change Common Language Runtime Support to "Common Language Runtime Support, Old Syntax (/clr:oldSyntax)".
Good luck.
This solution is only if you don't want Common Language Runtime
It worked for me in VS2010
Go to Project Propreties > Configuration Properties > General > Common Language Runtime Support and set it to No Common Language Runtime Support.
This will work fine just after hitting Apply button.
As mentioned you could install some paid software such as "Visual Assist X from Whole Tomato Software".
or
You could use open source tools that contain intellisense*, one such tool is Qt Creator 3.3.1 (opensource). You have two options, either setup your entire project with Qt to compile using VS2010 compiler, or use Qt to link to your source files and compile with VS2010. You write your code in Qt, save, flip windows to vs2010 and compile and debug.
When changes are saved in Qt, vs2010 will automatically reload the source file in the project and you can compile.