For the record, i actually found out that in VS2013 you can choose to build your project for XP

Yes, that's what I had in mind in my first posts in this thread and then clarified a bit in post #41 above. But the question is what this really means. Alright that the compiler does not itself creates anything that requires newer versions than XP, but the resulting exe or dll still depends on msvcr120.dll. So, when Wonko realized that he had seen different versions of msvcr120.dll around, I came to think that there might be separate official versions of msvcr120.dll and msvcr110.dll with only XP compatible dependencies that together with a project built with an XP compatible toolset will create something that runs on XP. But I'm not sure about the last part of this.

But like I mentioned in another post earlier, if you install an earlier version of Visual Studio on the same machine, you can also choose the Visual C++ compiler toolset that comes with that older version within the project settings in Visual Studio 2013 as well. The libyal projects are originally Visual Studio 2008 projects, so it should never be a problem to build them in Visual Studio 2013 with Visual Studio 2008 Platform Toolset. As an example of Platform Toolset settings and because I happen to be the kind of person who wants to be able to build anything possible out of anything available, my Visual Studio Platform Toolset dropdown list looks like this:

Now, I have seen that the Visual C++ compiler that comes with Visual Studio 2008 has a version number very close to the version number of the C++ compiler compiler that comes with Windows Driver Kit 7. Since WDK 7 has libraries for targeting Windows versions and their corresponding system dlls rather than a particular Visual C++ version and corresponding msvc[r/p][m][nnn].dll, I thought that it might be possible to select Visual Studio 2008 Platform Toolset in Visual Studio 2013 and then manually change VC++ library directories (other sections of the same dialog) to point to WDK 7 library directories instead of the usual VC++ library directories. That way I hoped that it would be possible to avoid VC++ runtime dependencies without the need to create WDK 7 projects with their completely different kind of build scripts. The libyal libraries consist of many different projects, so that would have meant huge amount of work so that was definitely something I wished to avoid. So the idea, since the VS 2008 and WDK 7 compiler versions are almost the same the compiler should not expect anything in the target libraries that it wouldn't find in the WDK 7 libraries. This idea with simply switching libraries without creating new projects for everything seemed to work fine and the results are the dll and exe files I published in the other thread.

You can go a step further and use the /MT compiler flag to kill dependency (see below, no more msvcrxxx.dll linkage).
Doing so, zlib is then (obviously) a bit bigger than the zlib.dll linking msvcrxxx.dll.

Yes, of course. But to do that is usually unnecessary because all you get is a copy of the VC++ runtime library functions needed in each dll or exe you build. This also means that they cannot share library data between each others. For instance, I want to set a error notify stream and show error messages from libvmdk.dll in my proxy dll. Therefore I open a stream with fopen in my proxy dll (or use default streams like stderr) and pass them to functions in libvmdk.dll. But I cannot do that if my proxy dll and libvmdk.dll are linked to different versions of msvcr*.dll, or if they are linked to static runtime libraries using /MT instead of /MD. This is because the file stream I open in my proxy dll will not be recognized by the VC++ runtime functions that are used by libvmdk.dll.

Another problem with statically including VC++ runtime in this way is that you actually get even less control over other dependencies. It is very easy to get an exe or dll with built-in VC++ functions that in turn are statically linked to kernel32.dll functions that might not be available in earlier versions of Windows.

About msvcrt.dll, note that MS recommends not to use it as this is originally meant for windows system only and MS can change it at any time.

This is something that unfortunately has been misunderstood for many years. The thing with msvcrt.dll is that it is nowadays (since Windows 2000) a system dll, much like user32.dll, gdi32.dll, advapi32.dll and so on, not really a VC++ runtime dll. Therefore, the supported functions in it depend on the operating system, not the version of VC++ you build your VC++ project for. That's essentially what Microsoft are talking about here and that's the reason why no version of VC++ since 6.0 have directly supported linking against msvcrt.dll. No newer versions of VC++ could add any new features they introduce to msvcrt.dll anymore in the way the could before Windows 2000.

But since msvcrt.dll is a system dll, it is fully supported to use it in projects that target a specific Windows version instead of a particular VC++ version/toolset. For instance, Windows Driver Kit has full support for using msvcrt.dll all the way up to WDK 7. All you need to do is adding a line USE_MSVCRT=1 in the sources file of the WDK projects. The way this is done makes sure that the dll or exe built will only use the functions in msvcrt.dll officially available on the Windows version you build for. This is done by adding a few support files into the dll and exe, such as msvcrt_win2000.obj, that contains a few function definitions that were not available directly in msvcrt.dll in Windows 2000. This method has never been supported in Visual Studio though, so that's mainly the reason why Microsoft recommend not to use msvcrt.dll directly in a Visual Studio built project.

Now, what I did in this example was comparing VC++ compiler versions between Visual Studio and WDK to see which version of Visual Studio compiler was likely to be able to directly use the libraries that come with WDK 7. That's turned out to work well and I think that's a pretty nice solution to most of the VC++ bloat that otherwise need to follow dll and exe files in one way or another.

I understand now how to build libvmdk against different versions of MSVCRxxx but cannot find yet how to setup my VS2013 to use the plain msvcrt.dll.

The sources file you mention does not apply to vs2013 I believe.

Currently downloading WDK 7.1 and will give it a new try : I guess it is about forcing VS2013 to use a msvcrt.lib pointing to msvcrt.dll (contained in the WDk) versus a msvcrt.lib pointing to msvcrxxx.dll contained in "Visual Studio xx\VC\lib".

I understand now how to build libvmdk against different versions of MSVCRxxx but cannot find yet how to setup my VS2013 to use the plain msvcrt.dll.
The sources file you mention does not apply to vs2013 I believe.

That's right. The "sources" files define project settings in WDK 7 and earlier WDK projects. It would have been possible to create WDK 7 projects by writing sources files for each project in libyal libraries too and simply specified to link to msvcrt.dll by adding USE_MSVCRT=1 in those sources files. But that would have meant quite a lot of work and I wanted to see if that was really necessary first. It turned out it wasn't.

Currently downloading WDK 7.1 and will give it a new try : I guess it is about forcing VS2013 to use a msvcrt.lib pointing to msvcrt.dll (contained in the WDk) versus a msvcrt.lib pointing to msvcrxxx.dll contained in "Visual Studio xx\VC\lib".

Exactly. That's the trick here.

But you need to use a compiler in Visual Studio that is compatible enough with the compiler in WDK 7 so that it does not expect anything in the libraries that it won't find in the WDK 7 libraries. The compiler in question is roughly the same as the one that comes with Visual Studio 2008. So, download and install Visual Studio 2008 as well (Visual C++ 2008 Express Edition should be enough). When you have done that, you don't actually need to open Visual Studio 2008. You can select Visual Studio 2008 Platform Toolset in the project settings for your Visual Studio 2013 projects.

Then, change VC++ directories settings for the projects (you can select several projects to do the changes simultaneously) to point to the WDK paths instead of VC++ paths. Then, add msvcrt_win2000.obj as "additional library" for the dll projects (not the lib projects), that setting is somewhere in the project settings dialog as well.

Just one thing I would like to recommend, please use 32 bit version of depends.exe when you look at dependencies for 32 bit files. Particularly if you upload screenshots like this one. Otherwise those rather annoying and unnecessary red warning icons for architecture mismatch turn up all over the dependency trees.