Caveat in using Visual Studio Express 2015

On my Windows 7 computer ‘Mithral’, I recently installed and started using “Visual Studio Express 2015″, which has Update 3.1, and am happy with it overall.

However, there is a type of malfunction which can take place, and apparently did. This IDE detected that I have 8 cores, and decided as a default that it would try to build as many as 8 targets concurrently, to maximize its speed. It did not detect that my 8 cores are threaded as 4, which is of minor significance. I changed the setting to 6 simultaneous builds, which means to me, that for each of the 6 targets, only one source file should be in the process of being compiled at once.

A type of condition seems to be possible, in which for an unknown reason, the application starts to build an extreme number of targets, which on my system meant maybe 15-20 targets. In the Task Manager, I saw up to 20 ‘cl.exe’ processes running at once. This was what led to an ‘OOM’ (‘Out-Of-memory’) condition, and required me to force the application to close from the Task Manager, as the IDE window had also stopped responding.

After that, I was not sure of the status of my build, so that I Cleaned the build, and also rebooted my machine, because the worst thing to my mind, would have been a not-clean shutdown. It seems that the actual reboot may not have been necessary.

After the reboot, I was able to build my Solution again, with no ill effects.

I am not sure what triggers this error, but do remember that on that occasion, I had Minimized the IDE application window and Restored it again. The whole thing gave me a bigger scare than was necessary, since no long-term corruption resulted.

Dirk

 

d3dcompiler_47.dll

Microsoft has stipulated, that in the future, all DirectX applications will need to use a DLL named D3DCOMPILER_47, if not of some greater version. What this driver does seems quite useful.

In the past, it had always been a limitation in the design of raster-based graphics, that actual shader code needed to be fed to the graphics drivers directly as text. As an alternative, D3DCOMPILER allows for the shader code to be compiled into bytecode, which DirectX drivers can understand. This also has uses in obfuscating copyrighted content. But mainly, it provides performance improvements in fact, because many games today have highly complex “Compute Shaders” etc..

When we install the Windows SDK on a Windows 7 or a Windows 10 computer, not the same libraries and header files will install each time.

(Some Text Deleted Because Erroneous Before.)

Dirk

(Edit 09/18/2016 : )

I have learned, that the library D3DCOMPILER_47.DLL is supposed to reside in both the System32 and the SysWOW64 folders (on a 64-bit Windows system), and is auto-generated there, much as D3DX9_43.DLL was, by the DirectX system on the computer, which is supposed to be running the game in question.

Because the DirectX system on Windows 7 will generate at maximum, D3DCOMPILER_43.DLL , some game developers have been including their own version of the _47 DLL, in the same directory as the EXE File, which is also the first directory the EXE File tends to search for it.

But a problem with that is, that some version of this library will be built specifically for Windows 8.1 for example, and will therefore not run properly on Windows 7. This produces an obscure error message, which I do not recall the exact spelling of.

Yet, the onus is not on the OGRE developers to supply their own version of this library. They do supply a version with their SDKs specifically, but that one is now built to run on Windows 8.1 as well.

Further, version _47 may only be needed for DirectX 11 applications, while _43 may still be good enough for Legacy DirectX 9. Yet, if OGRE was coded to use _47, then it will use that version throughout, even if I was only to try building their DirectX 9 rendering system.

The correct Path on my Windows 7 box ‘Mithral’ for this DLL, is

 


C:\Program Files (x86)\Windows Kits\8.1\Redist\D3D\x86

 

Contrarily to what the spelling of this Path may suggest, the DLL version I find there does load correctly on Windows 7. And, I am based on the conventional 32-bit build of OGRE. The above Path is related to one, which will also reveal the 64-bit DLL.

As for OGRE still requiring the Legacy DirectX SDK to build, this is a question of which version of the header files it has been programmed to expect, as well as of providing both the DXGUID and D3DX Static Libraries, whose file-names end in .LIB, as opposed to any DLL Files, which are the Dynamically Linked Libraries.

It is common, for the compilation of software to rely on such static libraries, whereas to run the software should only require the DLL Files, under Windows.

 

Different Visual Studio versions may be Installed Side-By-Side.

Our world is no longer such, that we need to be privileged, in order to have access to a compiler. While Linux offers us their open-source compilers, even the Windows world allows us to download their Visual Studio Express versions by now, although one down-side of that is, the fact that we do not obtain ‘Microsoft Foundation Classes’ this way. This makes the Visual Studio Express compilers a ‘Freemium’.

Yet, they could still act as a workhorse, for projects that were designed to use or build other libraries. And, there exist projects we cannot build with MinGW.

I have held a paid-for license to “Visual Studio 2005″, which I also beta-tested in 2005 before buying it. But obviously, this is such an old compiler version, that many of the open-source projects we can download, can no longer even be built with VS 2005. Yet, back in 2005 I paid a pretty penny for my copy. It currently remains installed on a Windows 7 computer I name ‘Mithral’.

So I have been stuck in a corner, it seemed. I have many VS 2005 projects which I maintained and compiled meticulously, as well as the old, buggy version of ‘MFC’ that came with it, all of which I stood to lose, if I was going to switch to a new compiler for Windows.

And yet, upgrading to a newer compiler has its obvious benefits.

To my rescue, comes the fact that we can install ‘VS 2005′ and ‘VS 2015′ side-by-side! I now have both installed, and both work. And I have built some projects successfully just this night, using Solution Files generated by a 3rd-party tool named “JUCE“.

The main danger to watch out for, is to keep our ‘VS 2005′ and ‘VS 2015′ projects in completely separate folders, because if we open a VS 2005 solution in VS 2015 by accident, it will get converted, and will then never be compatible with VS 2005 again.

Dirk