Add JSON validator sample

[kennykerr]

This sample follows on from #2814 (article) and is meant to show how you can implement a traditional Win32-style API in Rust.

This Rust implementation maps to the following hypothetical Win32-style API:

HRESULT __stdcall CreateJsonValidator(char const* schema, size_t schema_len, uintptr_t* handle);
HRESULT __stdcall ValidateJson(uintptr_t handle, char const* value, size_t value_len, char** sanitized_value, size_t* sanitized_value_len);
void __stdcall CloseJsonValidator(uintptr_t handle);

Here's the accompanying article for Getting Started with Rust.

[kennykerr]

I'd appreciate any feedback - need to present a good case for using Rust for systems programming on - and in - Windows.

@ChrisDenton @riverar @tim-weis

[riverar]

Just throwing out there, you could wire up to WinRT types in Windows.Data.Json for extra pizazz.

[kennykerr]

Also, is this a Rust 1.56 bug? https://github.com/microsoft/windows-rs/actions/runs/7632102514/job/20791559920?pr=2815

Why would a dependency in a sample break these unrelated builds?

And I get the same kind of failure on the master branch when I switch to 1.56 as well:

D:\git\windows-rs>cargo check -p windows-sys
warning: D:\git\windows-rs\Cargo.toml: unused manifest key: workspace.lints
warning: D:\git\windows-rs\crates\libs\metadata\Cargo.toml: unused manifest key: lints
warning: D:\git\windows-rs\crates\libs\sys\Cargo.toml: unused manifest key: lints
warning: D:\git\windows-rs\crates\libs\targets\Cargo.toml: unused manifest key: lints
warning: D:\git\windows-rs\crates\libs\implement\Cargo.toml: unused manifest key: lints
warning: D:\git\windows-rs\crates\libs\version\Cargo.toml: unused manifest key: lints
warning: D:\git\windows-rs\crates\libs\bindgen\Cargo.toml: unused manifest key: lints
warning: D:\git\windows-rs\crates\libs\windows\Cargo.toml: unused manifest key: lints
warning: D:\git\windows-rs\crates\libs\interface\Cargo.toml: unused manifest key: lints
warning: D:\git\windows-rs\crates\libs\core\Cargo.toml: unused manifest key: lints
    Updating crates.io index
error: failed to select a version for the requirement `rayon = "=1.8.1"`
candidate versions found which didn't match: 1.8.0, 1.7.0, 1.6.1, ...
location searched: crates.io index
required by package `windows-bindgen v0.52.0 (D:\git\windows-rs\crates\libs\bindgen)`

These older versions of Cargo are quite painful.

[ChrisDenton]

That error doesn't really make sense to me. The crate version definitely exists and aren't yanked. Maybe going back to old cargo corrupts the cache? Does deleting the .cargo/registry help? I think it would be worth opening an issue on the Cargo repo.

[ChrisDenton]

Oh, this might be rust-lang/cargo#10623

tl;dr old cargo didn't understand dep syntax and this results in an unhelpful error message. Any chance of bumping the MSRV to 1.60?

[ChrisDenton]

Looks good! I think I'd be tempted to use a type alias for the handle type. Or even a transparent new type wrapper if you don't mind explaining how this prevents accidentally mixing handle types on the Rust side of the FFI.

Speaking of handles, I'd be remiss if I didn't mention that technically speaking it should be a pointer like *mut core::ffi::c_void or something as it is actually a real pointer to real allocated memory.

[kennykerr]

Looks like bumping MSRV to 1.60 fixed the build. Thanks Chris.

[jonwis]

This is much easier to read than what we have currently. Thanks @kennykerr !

[jonwis]

Just throwing out there, you could wire up to WinRT types in Windows.Data.Json for extra pizazz.

Please don't. :) Use literally anything other than Windows.Data.* if you can.

Not everything needed to be in the platform SDK 😞

[riverar]

Looks good to me; going to skip the explicit approval to avoid chasing green ✅ here while you finish up some tweaks.

[kennykerr]

Thanks for feedback all! Here are the recent entries:

• https://kennykerr.ca/rust-getting-started/creating-your-first-dll.html
• https://kennykerr.ca/rust-getting-started/implement-win32-api.html

More to come...