I'm trying to create an executable for a Windows CE 5.0 device.
The SDK has been selected right (STANDARDSDK_500 (SH4)) and connection to the device works. However, the binary created by Visual Studio refuses to be "deployed" on the device, claiming that the Windows version is not high enough.
Having a look at the EXE file (with the amazing Dependency Walker utility that supports WinCE binaries) shows "OS Ver" 6.0 and "Subversion" 6.0. I want them to be 5.0!
WHERE does one set this, or WHERE can something be overriding the SDK selection I've made? This is rather frustrating. I'd like to like Visual Studio 2010, but it simply makes too much pain, too often. Things should just work.
Grep on the files revealed that the .vcproj file had lines with
AdditionalOptions=" /subsystem:windowsce,6.00"
Removing such corrected the problem.
What's sad is that the setting was completely missing on the IDE side, so there's no way to fix it there. It wasn't even shown on the "command line" summaries of what the IDE presumably sends to the actual compiler.
This is why IDE's often suck.
Related
I miss those tools sometimes, for example, when I have to know a window class so I can subclass it to override WM_CONTEXTMENU to hide the context menu.
I can download them one by one but was wondering if there is some place that includes a bundle with all of them in it?
Spy++ is still included with modern versions of Visual Studio, even up through VS 2015.
I don't know about Dependency Walker. It probably doesn't come with Visual Studio anymore, considering it has been deprecated for a while. Older versions of VS still ship with it, or it can be downloaded separately if you absolutely need it. Process Monitor is a better choice nowadays.
But as far as I know, these tools are still provided with the Windows SDK. The current version (for Windows 10) is here. If that doesn't have everything you're looking for, the Windows 7 version here certainly does. Once installed, look in Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin.
What else was there? WinDiff was there. I don't think that's included anymore. The last version of VS to come with it was VS 2010, and it wasn't in the Windows 7 SDK, either. I don't think this is a big loss. I used it one time because I didn't have another diff tool utility installed. My next move was installing another diff utility… MSVC 6/VS 98 also came with a bunch of OLE and ActiveX testing tools, which I don't think anyone uses anymore. I don't think these come with modern versions of the SDK, either, nor do I know where you can download them. Honestly, these are so before my time that I don't even know what you do with most of these tools. And then there's the really old stuff, the 16-bit utilities that were still being dragged along in a MSVC 6/VS 98 install. If these even still work on modern operating systems, I don't know why you'd want to use them.
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
So i've been searching this for quite a while now, to no avail! Has anyone figured out how to change the $(WindowsSdkDir) macro in visual studio 2010, to make it point to whatever version of the windows sdk they would like?
Hopefully this can be a reference to all those who will search for this after me. :)
To tailor an individual Visual Studio 2010 project to use a specific version of the Windows SDK go to Project | Properties, select the General tab (under Configuration properties) and then set the "Platform Toolset" drop down to point at the SDK you want to use. The WindowsSdkDir macro will change appropriately.
Remember to make this change for all Configurations and all Platforms.
I ran into a similar problem when trying to setup a fresh system using VS2010 and the Windows 7 / .NET 4 SDK (v7.1). The solution turns out to be similar to the one for Visual Studio 2008, but in a different registry location. You want to apply the same edits, but the location is
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows
for 32b Windows and
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows
for 64b Windows.
Also, depending on your installation (for both 32b and 64b versions of Windows), you may also need to change the corresponding key in the HKEY_CURRENT_USER tree.
You want to edit the following keys to point to the SDK version you want to use:
CurrentInstallFolder
CurrentVersion
ProductVersion
After making the changes, I restarted Visual Studio and it used the appropriate SDK version. I don't know if this is a bug in the SDK installer (one was logged for the WindowsSDK v6.1, but none for v7.1) or if it is by design, but everything seems to compile correctly after my changes.
Tested for 32b and 64b Windows 7.
[HKEY_CURRENT_USER\Software\Microsoft\Microsoft SDKs\Windows]
"CurrentInstallFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\"
Note that, in contrast to the other registry locations, here actually no sub-key for 7.1 might exist. Don't be confused Visual Studio 2008 is searching here anyways.
Surely the answer will be "you can't" or "use XP mode", but I'd like to know if it it possible.
The issue I have is that whenever I debug some application and hit a breakpoint, when I stop the debugger the debuggee remains stuck. It can't be killed, I can't attach another debugger (it says it is already being debugged). It won't go away until I close Visual C++.
This is hapenning on a Windows 7 64 bits install. VC has SP 6 installed.
My previous fix was horrible.
Finally, I developped a new fix, working perfectly with the english version of Visual Studio 6. (SP6 I think)
You need to check the version of the file DM.dll located into "Common/MSDev98/Bin"
The correct version is 6.0.9782.0.
link: http://www.dr-hoiby.com/TLLOC.dll (28KB)
how to install: replace "Common/MSDev98/Bin/TLLOC.dll" by the version downloaded.
Best regards.
Comment reposted:
You can try using Visual Studio 2008 with VC6 compiler. I recently blogged about this.
I developped a little fix for that.
You just have to copy the file "ShiftF5Fix.dll" into "Common/MSDev98/AddIns/" et load it from Visual.
It's an hugly fix.
If you modify your source file during debugging you have you answer "NO" to the poup displayed after you press "SHIFT+F5" to stop the process.
link : http://www.dr-hoiby.com/ShiftF5Fix.dll
Best regards
Another option would be to install daffodil.
This is an open source project to compile all versions of visual studio in VS2010.
Once this is configured you can use visual studio 2010 debugger to debug VC6 projects.
On the heels of Dr Holby, I implemented a leaner variant, with source code:
http://www.algonet.se/~tamlin/TLLOC_fixer.zip
The code currently only understands sp4 (?) and SP6, but I think it'll cover most cases.
You only need to compile the source (1.cpp, 1.rc), rename your existing TLLOC.DLL (which btw stands for Transport Layer Local - as opposed to remote debugging) to TLLOC.old.dll, and drop in the one you compiled (~4KB). Should work like a charm for all 32-bit debugging needs, from Windows 95 to Windows 7 (and later).
On long Visual C++ builds, it would be really helpful to hear some sort of (optional) sounds for such build/compile results as:
individual compile error
file compile success/failure
build success/failure
batch build success/failure
Does anyone know how to enable sounds for these kinds of build occurrences in Visual C++ (especially Visual C++ 2008 on Vista)?
CJM is almost right.
In VC++ 9 (Visual Studio 2008) Go to Control Panel's Sounds applet (Control Panel/Hardware and Sounds/Sounds in Vista).
Under the Sounds tab scroll to "Build Succeeded" under "Microsoft Visual Studio" and set a sound for this event.
If you have (or had) multiple VS on this PC (I have 6.0, 2003, 2005, and 2008) there may be multiple entries with names like "Microsoft Developer" or blanks - which I assume work in the older versions. I often end-up setting the wrong ones. It seems you'll have to close VS 2008 and reopen for this to take effect.
Someone mentioned this was broken/removed in VS 2005 - I noticed this as well.
Go to Start | Settings | Control Panel | Sounds, click the Sounds tab, and customize the entries under Microsoft Developer.
Another solution is to install the Visual Studio Power Toys. This includes a feature called 'Toast' that shows a notification in your system tray when a build has finished. You might see if this has options that would be useful for sound notification.
In VS2005, the sound subsystem wasn't working correctly, not sure it was fixed in 2008. Using macros, you COULD play sounds, like different ones for builds that succeeded, and builds that failed, however the person that I knew that did them was constantly crashing due to the macros failing.