Get FileInfo with windows api

Querying for file information properties is a multi-step process:

1. Determine the version info size by calling GetFileVersionInfoSizeW
2. Allocate a sufficiently sized buffer; a Vec provides everything needed (contiguous memory, runtime dynamic size, low stack memory overhead)
3. Read the entire version info into the allocated buffer by calling GetFileVersionInfoW
4. Query for the information of interest using VerQueryValueW; on success the function returns a pointer/size pair into the buffer allocated above

It is the final step that ultimately goes wrong in the code provided. The API expects the address of a pointer variable where it stores the result. The code however passes the address of the first element of descriptionBuffer, and that's where the API writes to (presumably, the code was compiled for a 64-bit target, meaning that the first 8 bytes are the pointer value).

In essence the code did succeed in producing a pointer/size pair, but failed to interpret them according to the API contract. An improved version that queries for a binary's file description might look like this:

fn get_file_description(path: impl AsRef<Path>) -> Result<String, Box<dyn Error>> {
    // Determine version info size
    let size = unsafe { GetFileVersionInfoSizeW(path.as_ref().as_os_str(), null_mut()) };
    if size == 0 {
        return Err(core::Error::from_win32().into());
    }

    // Allocate buffer
    let mut buffer = vec![0u8; size as usize];
    // Read version info
    unsafe {
        GetFileVersionInfoW(
            path.as_ref().as_os_str(),
            0,
            size,
            buffer.as_mut_ptr() as *mut std::ffi::c_void,
        )
    }
    .ok()?;

    // Declare pointer/size pair for output
    let mut ptr = null_mut();
    let mut len = 0;
    // Query for file description
    let success = unsafe {
        VerQueryValueW(
            buffer.as_ptr() as *const std::ffi::c_void,
            "\\StringFileInfo\\040904B0\\FileDescription",
            &mut ptr,
            &mut len,
        )
    }
    // The API call doesn't set the last error code so we cannot use `.ok()?` here
    .as_bool();
    if !success {
        return Err("Failed to query file description".into());
    }

    // `len` here is in elements (as opposed to bytes)
    let descr = unsafe { slice::from_raw_parts(ptr as *const u16, len as usize) };
    // Optionally use `from_utf16_lossy` if you don't need to handle invalid UTF-16
    let descr = String::from_utf16(descr)?;

    Ok(descr)
}

This is better, but certainly not perfect by any stretch of the term. Most of the improvements revolve around character encoding subtleties, the gnarliest of pain points when it comes to Rust on Windows. There is no dedicated string type in Rust that can store strings in Windows' native character encoding, UTF-16.

Noteworthy changes:

• The function accepts an argument convertible to a Path reference. The underlying storage is of type OsStr, sporting a relaxed version of UTF-8 capable of representing any sequence of UTF-16 code units, well-formed or otherwise. This is crucial since Windows makes no character encoding guarantees with respect to filesystem objects. With the exception of a few reserved values, virtually any sequence of 16-bit values is allowed. Your program needs to be prepared for this.
• All narrow-character set versions of the API calls have been replaced with the wide-character versions (see Conventions for Function Prototypes for background information). This is the only safe option when dealing with data you do not control (such as version info resources of arbitrary binaries). Of particular note here is that the windows crate provides an implicit conversion from &OsStr into PCWSTR, so passing a Path into wide-character APIs isn't entirely inconvenient (but they do incur a conversion and allocation).
• Likewise, the windows crate provides conversions from &str to PCWSTR, gated under the "alloc" feature. This allows using a string literal in the call to VerQueryValueW and get everything converted as needed (again, with a conversion and allocation cost).

To turn this into a fully working example, that produces a command line application accepting the path name of the binary image as its first argument, simple add the following Cargo.toml

[package]
name = "fileinfo"
version = "0.0.0"
edition = "2021"

[dependencies.windows]
version = "0.33.0"
features = [
    "alloc",
    "Win32_Foundation",
    "Win32_Storage_FileSystem",
]

and add the following to the src/main.rs file:

use std::{env, error::Error, path::Path, ptr::null_mut, slice};
use windows::{
    core,
    Win32::Storage::FileSystem::{GetFileVersionInfoSizeW, GetFileVersionInfoW, VerQueryValueW},
};

fn main() -> Result<(), Box<dyn Error>> {
    let input = env::args_os()
        .nth(1)
        .ok_or("Expected 1 command line argument")?;
    let path = Path::new(&input);
    let descr = get_file_description(&path)?;

    println!("File description: \"{}\"", &descr);

    Ok(())
}