While building the latest DOSBox SVN using Visual Studio 2003 I found something kind of annoying under Windows 10. The first thing is that if I search through the source code base, the application locks up, hard. It turns out that this has been an ongoing issue with Windows 8 (maybe Vista/7?) with Aero rendering of all things. The fix is to disable Desktop Compositing & Desktop Themes, but the application comparability tab is hidden on many applications for Windows 10.
See how the application preview doesn’t render anything at all? This is the hint that it’s broken. I think it may be worth sharing this ‘fix’ as I’m sure that other applications that behave strangely have the same issue.
I found the solution to this over on stackoverflow in this discusstion:[https://stackoverflow.com/questions/2422581/visual-studio-net-2003-on-windows-7-hangs-on-search]. The fix is a registry entry in the “HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers” key.
The required settings to devenv.exe is:
“^ RUNASADMIN DISABLEDWM DISABLETHEMES”
Which, will run Visual Studio as Administrator allowing you to debug, and disable all the Aero assists for the application allowing things like search to work again.
I had gone further and enabled the Windows XP SP3 compatibility settings, however on doing a clean build I was presented with this error:
fatal error C1033: cannot open program database ''
Which I never could find any good source on what caused it, other than by guessing to remove the Windows XP flag, and now I’m able to build.
While debugging and re-building the debug database is held open on Windows 7 (maybe Vista?) and beyond on x64 based OS’s. You’ll get the annoying LNK1201 error.
There is a fix on bytepointer.com (local backup vs7.1_on_win7_pdb_handle_leak_unofficial_fix_win10.zip) that involves patching/replacing natdbgde.dll . All I can say is that it seems to be working for me.
In order to do a full build of DOSBox I had to re-build SDL, SDL-net, zLib, libPNG, and set them to a common C runtime linker setting to get a build where the final link didn’t complain. However when it came to existing project files I did have to find some older Visual C++ 6.0 stuff for many of the components, but using those I was able to ‘upgrade’ them to the 2003 environment and produce a working set.
I’ve got to say, that the AVI capture in the newer branches (I’m using build r4177) is really great!
Any particular reason why you’re trying to build with a 15 year old Visual Studio version on 12 year younger Windows? 😉
I was going to see if the resulting binary “just runs” on XP. I picked up a bunch of XP home packages for $5 each.
And it was kind of a point to use it, I paid a good $30 for Visual Studio 2003 Enterprise Architect.
Heh, when I bought Visual Studio 2003 Enterprise Developer it was for the bundled servers. I used that Windows 2000 Advanced Server for a long time. The compiler itself wasn’t that great, and .NET 1.1 was an instant classic after .NET 2.0 in 2005 and Vista dropping support for 1.1 in 2006.
I don’t know exactly what you mean by “just works” but for me the issue was you need to install the 2003 CRT DLLs on XP for code to “just work”, or you can statically link the CRT. But Visual C++ 6 really does “just work” because MSVCRT.DLL is already installed on Win98/Win2k and above. So if you take Visual C++ 6, then pair it with the 2003 SDK, you have all the API support and none of the distribution headaches. Unfortunately the 2003 SDK is a real PITA to install, since it used the ActiveX IE hosted installer thing.
In 64 bit land, the 2003 SP 1 SDK shipped with a 64 bit compiler that links against 64 bit MSVCRT.DLL too. This compiler is a few months before Visual C++ 2005 shipped. Queue “the best things in life are free…”
And yeah, I also got a few copies of XP Home and Vista Home Basic for $5 at the end of their respective lives. I think I’ve thrown most of those away.
fatal error C1033: cannot open program database ''
Is my browser not able to show this correctly, or it’s a sneaky base64 quiz?
“fatal error C1033: cannot open program database” – I would check the output folder permissions, delete any stray PDB files, and try to build again. If this fails, building in release mode without debug symbols should fix it (or not – compilers are weird)
I don’t know why the new fancy WordPress editor will do stupid stuff like that from time to time, it looked great in the preview, but yeah it decided to base64 that quote.
I tried cleaning the solution, even as far as to remove the Debug/Release folders and all pdb’s and anything ‘new’ outside of the project files and it still errored out.
Oh yeah and rebooting, re-launching over and over… it always failed. It wasn’t until I removed the Windows XP SP3 compatability flag then it’d let me do a full rebuild.
I don’t understand how or why, just know that was the only thing that did anything.
When I was creating my VS guide for DOSBox I went through all the Visual Studios because I was looking into backward compatibility. Turns out VS2008 with legacyextender is all I really needed for the lowest version of VS for NT3.51-2000 (i586+) support. (Need to compare to my mingw guide to implement those changed and 3.50 support)
For the third party libraries for VS2003 and VS2005 I had to to Visual Studio Project Converter since those libraries only supported newer versions of VS but with VS2008 as my new minimum didn’t have any issues since those libraries supported that version.
I cheated and dug out old project files from older versions that supported either 2003 or VC 6, and just pasted those project files into place. I figured that many of these things are ‘established’ enough that there wouldn’t be any significant file drift. Turns out I guess I got lucky as there was none at all, it just worked.
Ah, now I remember how I got around VS2003 not working in Windows 10. I believe I used the multi-target feature to use the newer version of VS with the old 2003 toolset.
That makes total sense!
I was got same problems using MSVC 2003 in Windows 8.1 in the past. It was known bug in VC 2003 when using Windows 7 upwards that causing handle leaks. If you don’t want disable DWM while you debugging your app, then try this unofficial fix:
http://bytepointer.com/articles/vs7.1_2003_on_win7_pdb_handle_leak_bug_unofficial_fix.htm
For maintain older projects, now I’m sticking with VC2005.