Jump to content











Photo
- - - - -

VMDK Proxy for ImDisk

vmdk proxy imdisk

  • Please log in to reply
60 replies to this topic

#51 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 30 April 2015 - 09:58 PM

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:
 
vs2013_platform_toolsets.png

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.



#52 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 May 2015 - 10:40 AM

Well, at the end of the day the Olof's version depends on the plain msvcrt.dll, not on (say) msvcr90.dll, see attached image.

:duff:
Wonko

Attached Thumbnails

  • libvmdkcff.jpg


#53 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 01 May 2015 - 11:23 AM

Well, at the end of the day the Olof's version depends on the plain msvcrt.dll, not on (say) msvcr90.dll, see attached image.

:duff:
Wonko

 

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.

 

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 but in reality it seems to be a good practice.

 

BSo5VqJ.png



#54 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 01 May 2015 - 11:48 AM

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.



#55 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 May 2015 - 12:17 PM

 ...
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. 

...

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.

...

 

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.

 

Yep :thumbup:

In my hairy reasoner approach this flatly means that in practice it is exactly like having NO dependency whatsoever :yahoo:, since the "plain" msvcrt.dll is on *any* system.

 

:duff:

Wonko



#56 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 01 May 2015 - 01:12 PM

I learned a lot today, thanks @Olof.

 

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".



#57 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 01 May 2015 - 03:06 PM

I learned a lot today, thanks @Olof.
 
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.



#58 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 02 May 2015 - 05:37 PM

Ok, thanks to the guidance from Olof I was able to rebuild my libvmdk project so that it depends on msvcrt.dll and no longer on msvcrtxxx.dll.

 

I share below the tips provided by Olof.

Sorry for the french screenshots...

 

-first install VC2008 express

 

-install WDK 7.1

 

-modify your VC2008 IDE settings search paths (include and libraries) by adding WDK 7.1 paths first in the list

 

XuK0hGN.png

 

seLkgHG.png

 

-add msvcrt "legacy translator" library (msvcrt_win2000.obj) to Linker -> Input -> Additional Dependencies for both DLL projects (zlib and libvmdk)

 

ExRxofS.png

 

-add specific preprocessor definitions to zlib project : 

vsnprintf=_vsnprintf;snwprintf=_snwprintf;open=_open;read=_read;close=_close;write=_write

 

neDR5uv.png?1

 

And voila :)

 

You should end up with the below, i.e a dependency to a msvcrt.dll

 

lcahBQh.png



#59 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 02 May 2015 - 05:41 PM

Thanks!

 

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.



#60 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 03 May 2015 - 02:08 PM

A new version build with latest libvmdk.

 

Built so that it depends on msvcrt.dll and no longer on msvcrtxxx.dll.

 

Proxy.dll size down to 45k.

 

Zip contains latest devio.exe and a batch example to launch devio and imdisk in one go.

Attached Files



#61 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 May 2015 - 03:41 PM

Proxy.dll size down to 45k.

You see :unsure: :
 
 

I decided to cleanup some dependencies, recompile the proxy.dll and include the msvcr120.dll (renamed msvcr110.dll in fact).
 
Now 90k !
Probably the best I can do.

Never say never! ;)

:thumbup:

 

:duff:

Wonko







Also tagged with one or more of these keywords: vmdk, proxy, imdisk

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users