{"id":25783,"date":"2007-07-31T10:00:00","date_gmt":"2007-07-31T10:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2007\/07\/31\/what-is-the-lpdwhandle-parameter-in-getfileversioninfosize-used-for\/"},"modified":"2007-07-31T10:00:00","modified_gmt":"2007-07-31T10:00:00","slug":"what-is-the-lpdwhandle-parameter-in-getfileversioninfosize-used-for","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20070731-00\/?p=25783","title":{"rendered":"What is the lpdwHandle parameter in GetFileVersionInfoSize used for?"},"content":{"rendered":"<p>The <code>GetFileVersionInfoSize<\/code> function returns two pieces of information. The return value is the amount of memory needed to record the version information of a file, and the <code>DWORD<\/code> pointed to by the <code>lpdwHandle<\/code> parameter is set to zero. What&#8217;s the deal with this strange <code>lpdwHandle<\/code> parameter?\n That parameter used to do something.\n The documentation for <code>GetFileVersionInfo<\/code> used to read<\/p>\n<blockquote class=\"m\"><p> <i>dwHandle<\/i>: The value returned by a preceding call to <code>GetFileVersionInfoSize<\/code> in the <code>lpdwHandle<\/code> parameter. <\/p><\/blockquote>\n<p> The purpose of that parameter is to allow <code>GetFileVersionInfoSize<\/code> to pass information to <code>GetFileVersionInfo<\/code> about what it found.\n In 16-bit Windows and Windows&nbsp;95, 98, and Me, the <code>GetFileVersionInfoSize<\/code> function opened the target file and went searching for the version information. Once it was located, the size of the version was the return value and the file offset of the version information was stored in <code>lpdwHandle<\/code>. The <code>GetFileVersionInfo<\/code> function was very simple: It merely read <code>dwLen<\/code> bytes from the file starting at file offset <code>dwHandle<\/code>.\n In the Windows&nbsp;NT series, this mechanism was abandoned. The handle is not used any more. Why not? I don&#8217;t know, but I have some guesses.\n First, Windows&nbsp;NT supports files larger than 2GB, so a 32-bit value isn&#8217;t big enough to hold a file offset value.\n Second, multitasking introduces a race condition in the <code>GetFileVersionInfoSize<\/code>\/<code>GetFileVersionInfo<\/code> pattern. Whereas in 16-bit Windows, nobody could modify the file between the two calls due to co-operative multi-tasking, in 32-bit Windows, it&#8217;s possible that somebody could sneak in and modify the file between the two calls, resulting in the call to <code>GetFileVersionInfo<\/code> returning garbage. (Yes, Windows&nbsp;95 has this race condition.)\n Third, the amount of memory required to load the version resource is not the same as the actual size of the version resource. It&#8217;s not enough just to seek to the specified location and read <code>dwLen<\/code> bytes from it. For example, a program might load the version resources from a 32-bit module, and we&#8217;ve seen earlier that 32-bit version resources are Unicode. But that program might then call <code>VerQueryValueA<\/code> to retrieve the version string in the ANSI code page. The <code>GetFileVersionInfo<\/code> function needs to return a buffer that can hold not only the actual version resource but also enough memory to hold copies of all the strings in the version resource converted to the ANSI character set so that the <code>VerQueryValueA<\/code> function could return them.\n Whatever the reason, the Windows&nbsp;NT series of operating systems don&#8217;t use the handle value. When you call <code>GetFileVersionInfoSize<\/code>, the function looks for the version resource and returns the size of the memory block needed to record it. (Which, as we saw above, includes translation space for the ANSI strings.) When you call <code>GetFileVersionInfo<\/code>, the function starts over from scratch and looks for the version resource and copies it into the buffer.\n The <code>dwHandle<\/code> parameter is now just a vestigial organ.\n <b>Prediction<\/b><\/p>\n<p> People will take this as the opportunity to complain about the <code>GetFileVersionInfo<\/code> family of functions. (Because all I have to do is mention a function name, and that makes it open season on all problems related to that function, as if every function I mention is one that I have total responsibility and authority over.) <\/p>\n","protected":false},"excerpt":{"rendered":"<p>The GetFileVersionInfoSize function returns two pieces of information. The return value is the amount of memory needed to record the version information of a file, and the DWORD pointed to by the lpdwHandle parameter is set to zero. What&#8217;s the deal with this strange lpdwHandle parameter? That parameter used to do something. The documentation for [&hellip;]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[2],"class_list":["post-25783","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-history"],"acf":[],"blog_post_summary":"<p>The GetFileVersionInfoSize function returns two pieces of information. The return value is the amount of memory needed to record the version information of a file, and the DWORD pointed to by the lpdwHandle parameter is set to zero. What&#8217;s the deal with this strange lpdwHandle parameter? That parameter used to do something. The documentation for [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/25783","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=25783"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/25783\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=25783"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=25783"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=25783"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}