Im a bit new to rust. So im trying to fetch FileDescription from windows crate. Im failing to convert the descriptionBuffer from VerQueryValueA into utf8 string. Cant figure out what im doing wrong.
fn get_proc_data(pid: u32) -> Option<String> {
let mut path = None;
unsafe {
let h_snap = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE | TH32CS_SNAPMODULE32, pid);
if h_snap != INVALID_HANDLE_VALUE {
let mut mod_entry: MODULEENTRY32 = MODULEENTRY32 {
..Default::default()
};
mod_entry.dwSize = size_of_val(&mod_entry) as u32;
if Module32First(h_snap, &mut mod_entry).as_bool() {
let char_vec = mod_entry.szExePath.iter().map(|f| f.0).collect::<Vec<u8>>();
path = match from_utf8(&char_vec) {
Ok(s) => Some(String::from(s.to_string().trim_end_matches(char::from(0)))),
Err(_) => None,
};
}
}
CloseHandle(h_snap);
if path.is_some() {
let mut infoBuffer: [u8; 2048] = [0; 2048];
let pat = path.as_ref().unwrap();
let lpvoid: *mut c_void = infoBuffer.as_mut_ptr() as *mut c_void;
let c_str = CString::new(pat.as_str()).unwrap();
let pstr = PSTR(c_str.as_ptr() as *const u8);
let verInfoLen = GetFileVersionInfoSizeA(pstr, &mut 0);
let ok = GetFileVersionInfoA(pstr, 0, verInfoLen, lpvoid);
let mut descriptionBuffer: [u8; 256] = [0; 256];
let descriptionPtr: *mut *mut c_void =
descriptionBuffer.as_mut_ptr() as *mut *mut c_void;
let mut descriptionLen = 0;
if ok.as_bool()
&& VerQueryValueA(
lpvoid,
"\\StringFileInfo\\040904E4\\FileDescription",
descriptionPtr,
&mut descriptionLen,
)
.as_bool()
{
info!("{:?}", descriptionBuffer);
let res = from_utf8_lossy(&descriptionBuffer);
info!("{:?} {:?}", path, res);
}
}
}
return path;
}
Example outputs
info!("{:?}", descriptionBuffer);
INFO - [180, 162, 146, 165, 206, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
info!("{:?} {:?}", path, res);
INFO - Some("C:\Users\acoop\AppData\Local\Amazon Music\Amazon Music.exe") "�����\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}\u{0}"
Querying for file information properties is a multi-step process:
Determine the version info size by calling GetFileVersionInfoSizeW
Allocate a sufficiently sized buffer; a Vec provides everything needed (contiguous memory, runtime dynamic size, low stack memory overhead)
Read the entire version info into the allocated buffer by calling GetFileVersionInfoW
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(())
}
Using the excellent guide by Nadieh Bremer I'm making a stretched chord diagram.
However, with certain data inputs the rendering goes awry.
I've made a demo to demonstrate my issue here:
https://codepen.io/benmayocode/pen/MPEwdr
Specifically, in the .js file lines 269 to 281 file I have:
var respondents = 40,
emptyPerc = 0.4,
emptyStroke = Math.round(respondents*emptyPerc);
var Names = ['BEN', 'ROSE', '', '1', '2', '6', ''];
var matrix = [
[0, 0, 0, 10, 10, 0, 0] ,
[0, 0, 0, 0, 10, 10, 0] ,
[0, 0, 0, 0, 0, 0, 24] ,
[10, 0, 0, 0, 0, 0, 0] ,
[10, 10, 0, 0, 0, 0, 0] ,
[0, 10, 0, 0, 0, 0, 0] ,
[0, 0, 0, 24, 0, 0, 0] ,
];
This renders incorrectly - but if I change it to...
var respondents = 40,
emptyPerc = 0.4,
emptyStroke = Math.round(respondents*emptyPerc);
var Names = ['BEN', 'LIB', 'ROSE', '', '1', '2', '6', ''];
var matrix = [
[0, 0, 0, 0, 10, 10, 0, 0] ,
[0, 0, 0, 0, 0, 10, 0, 0] ,
[0, 0, 0, 0, 0, 10, 10, 0] ,
[0, 0, 0, 0, 0, 0, 0, 24] ,
[10, 0, 0, 0, 0, 0, 0, 0] ,
[10, 10, 10, 0, 0, 0, 0, 0] ,
[0, 0, 10, 0, 0, 0, 0, 0] ,
[0, 0, 0, 0, 24, 0, 0, 0] ,
];
Then it works great. I obviously see the difference between the two blocks of code, but why are they producing different results, and is it possible to modify my code to accommodate both examples?
If you examine the dodgy arc, you will see you can flip it into the right place by altering the sign on the transform from (50,0) to (-50,0). If you then look at the code that assigns the transform, it is
.attr("transform", function(d, i) {
d.pullOutSize = pullOutSize * ( d.startAngle + 0.01 > Math.PI ? -1 : 1);
return "translate(" + d.pullOutSize + ',' + 0 + ")";
});
with a note in the original text to say that "the 0.01 is for rounding errors". Given that the startAngle is already 3.13--i.e. very close to Pi--it looks like this is an edge case where the value fell just the wrong side of the cutoff. Changing the allowable rounding error value to 0.02 puts the arc in the correct place, or you could do something like
d.pullOutSize = pullOutSize * (
// is the start angle less than Pi?
d.startAngle + 0.01 < Math.PI ? 1 :
// if yes, is the end angle also less than Pi?
d.endAngle < Math.PI ? 1 : -1 );
to prevent edge cases like that in your dataset.