Welcome to the September issue of the Rust for Windows newsletter! This newsletter covers news and events related to Rust for Windows, and particularly the windows-rs project.
Quick links
Release
The latest release provides a few notable additions and features.
First, there's a new option to disable the default agility for COM implementations (#3770). COM object implementations are agile and indicate this by implementing both IAgileObject and IMarshal. This is the default and suitable for the vast majority of implementations, whether or not you need support for COM apartments.
For C++/WinRT I provided a non_agile marker type that indicated that the object would not provide an implementation of IAgileObject or IMarshal directly. You are then free to implement them yourself or not at all. This supports the few cases where you need more control over the apartment model of the caller and callee.
The implement macro now provides an equivalent option to control the agility directly. Here is an example from the accompanying test:
// IAgileObject and IMarshal are implemented
#[implement(ITest)]
struct DefaultAgile;
// IAgileObject and IMarshal are *not* implemented
#[implement(ITest, Agile = false)]
struct AgileFalse;
// IAgileObject and IMarshal are implemented
#[implement(ITest, Agile = true)]
struct AgileTrue;
// IAgileObject is implemented while IMarshal is not
#[implement(ITest, Agile = false, IAgileObject)]
struct ExplicitAgile;
I have also improved code generation dependency targeting (#3763). Today it can be a little hard to manage your dependencies when windows-bindgen introduces dependencies in generated code. Although --no-deps is useful for raw or sys-style bindings to limit or eliminate dependencies, it is not so easy to limit or eliminate dependencies for the default richer bindings generated by windows-bindgen and required for more convenient access to COM and WinRT APIs. This update does two things:
- It improve consistency and convenience by default when
windows-core is required to avoid a growing set of dependencies by using windows-core uniformly for most dependencies where feasible.
- It allow for more granular and specific dependency targeting and avoids the
windows-core dependency unless required with the new --specific-deps option.
I have also added the ability to query the OS revision number (#3752). The windows-version crate provides reliable operating system version information without the need for application manifest files. The OsVersion struct provides the traditional OS version information for major, minor, service pack, and build number. Unfortunately, recent Windows versioning conventions have largely dropped the use of minor and service pack versions while adding a new revision number as you can see when you run commands like winver.exe or cmd.exe.
This update adds a revision function to the windows-version crate that lets you reliably get the same version information used by these OS tools.
And finally, @wmmc88 has added readme guidance on version ranges (#3754). This prominently displays an example for both the windows and windows-sys crates on how to use a dependency version range to avoid or reduce duplicate versions in the build tree.
Learning series
Part 3 of the Rust for Windows video series is now available on YouTube. This is a series for Windows developers wanting to learn how to make the most of Rust on the Windows platform.
Part 3 introduces some more of the individual crates published as part of Rust for Windows. As requested, part 4 will cover the windows-strings crate and various string-related topics.
Major version updates to existing crates
The windows-bindgen crate (0.64.0) provides improved dependency targeting support via the new --specific-deps option (#3763).
Minor version updates to existing crates
The windows-implement crate (0.60.1) adds the ability to disable the default agility for COM implementations (#3770).
The windows-version crate (0.1.6) adds the ability to query OS revision number (#3752).
The windows crate (0.62.1) crate has been updated to depend on the latest version of the windows-implement crate and update the readme with version range guidance.
The windows-collections crate (0.3.1) crate has been updated to depend on the latest version of the windows-implement crate.
The windows-core crate (0.62.1) crate has been updated to depend on the latest version of the windows-implement crate.
The windows-future crate (0.3.1) crate has been updated to depend on the latest version of the windows-implement crate.
The windows-sys crate (0.61.1) crate has an updated readme with version range guidance.
The windows-targets crate (0.53.4) crate has an updated readme indicating that windows-link should be preferred.
What's next
Work continues to improve the experience of Rust developers on Windows and more generally enabling and supporting a broad range of programming languages and frameworks by building the tools and services to enable cross-platform toolchains and frameworks to excel on Windows.
This includes a renewed focus on metadata for the canonical description of APIs and components, whether they ship inside the OS or in some other way. Metadata is the key to scaling up the generation of bindings for various languages including Rust. We must make it easier for app developers as well as language, library, and framework maintainers to approach Windows APIs so they can take advantage of what is distinctive and unique about Windows and light up those features as they are available.
Work has begun, particularly with the first complete ECMA-335 reader and writer for Rust. This gives us the ability to both read and write what are commonly referred to as .winmd files, popularized by .NET and WinRT, for describing APIs and components and has been extended to describe traditional Win32 and COM APIs as well.
The next steps include C/C++ header and IDL parsers that can generate high quality metadata so that we can more easily generate bindings for existing APIs that predate metadata. I am bringing up both an IDL and a RDL parser in tandem. The latter is an IDL dialect but based on Rust syntax and natively embeddable so that we can more easily support first-class component and API authoring in Rust without resorting to what is otherwise the very proprietary syntax that is IDL. The C/C++ header and IDL parsers will likely be somewhat tactical as those dialects are extremely complicated and extremely elusive respectively. The goal is to help developers bring older APIs and definitions forward to a supportable and open-source foundation.
With comprehensive metadata and API or ABI tooling easily accessible to Windows developers, the next step is to make Windows more accessible to non-Windows platforms by providing cross-platform fallback implementations of the various core windows-rs type system and support crates. This should allow developers to use the same languages and tools to build components and applications that necessarily communicate and interop across operating system boundaries. The windows-rs technology already supports this to some degree by allowing DirectWrite and DWriteCore, implemented with windows-rs, to support both Windows and non-Windows platforms. This is today limited to a thin slice of COM support but I hope to extend this to more of the foundational type system so that richer APIs can seamlessly work across different target platforms.
Wrapping up
And that's all for this update. Let me know what you think. What would you like to see more of? Are you interested in specific learning series topics? Are you using windows-rs today? Let me know so we can continue to prioritize investment in these tools and services.
Welcome to the September issue of the Rust for Windows newsletter! This newsletter covers news and events related to Rust for Windows, and particularly the windows-rs project.
Quick links
Release
The latest release provides a few notable additions and features.
First, there's a new option to disable the default agility for COM implementations (#3770). COM object implementations are agile and indicate this by implementing both
IAgileObjectandIMarshal. This is the default and suitable for the vast majority of implementations, whether or not you need support for COM apartments.For C++/WinRT I provided a
non_agilemarker type that indicated that the object would not provide an implementation ofIAgileObjectorIMarshaldirectly. You are then free to implement them yourself or not at all. This supports the few cases where you need more control over the apartment model of the caller and callee.The
implementmacro now provides an equivalent option to control the agility directly. Here is an example from the accompanying test:I have also improved code generation dependency targeting (#3763). Today it can be a little hard to manage your dependencies when windows-bindgen introduces dependencies in generated code. Although
--no-depsis useful for raw or sys-style bindings to limit or eliminate dependencies, it is not so easy to limit or eliminate dependencies for the default richer bindings generated bywindows-bindgenand required for more convenient access to COM and WinRT APIs. This update does two things:windows-coreis required to avoid a growing set of dependencies by usingwindows-coreuniformly for most dependencies where feasible.windows-coredependency unless required with the new--specific-depsoption.I have also added the ability to query the OS revision number (#3752). The windows-version crate provides reliable operating system version information without the need for application manifest files. The
OsVersionstruct provides the traditional OS version information for major, minor, service pack, and build number. Unfortunately, recent Windows versioning conventions have largely dropped the use of minor and service pack versions while adding a new revision number as you can see when you run commands likewinver.exeorcmd.exe.This update adds a
revisionfunction to thewindows-versioncrate that lets you reliably get the same version information used by these OS tools.And finally, @wmmc88 has added readme guidance on version ranges (#3754). This prominently displays an example for both the
windowsandwindows-syscrates on how to use a dependency version range to avoid or reduce duplicate versions in the build tree.Learning series
Part 3 of the Rust for Windows video series is now available on YouTube. This is a series for Windows developers wanting to learn how to make the most of Rust on the Windows platform.
Part 3 introduces some more of the individual crates published as part of Rust for Windows. As requested, part 4 will cover the windows-strings crate and various string-related topics.
Major version updates to existing crates
The windows-bindgen crate (0.64.0) provides improved dependency targeting support via the new
--specific-depsoption (#3763).Minor version updates to existing crates
The windows-implement crate (0.60.1) adds the ability to disable the default agility for COM implementations (#3770).
The windows-version crate (0.1.6) adds the ability to query OS revision number (#3752).
The windows crate (0.62.1) crate has been updated to depend on the latest version of the
windows-implementcrate and update the readme with version range guidance.The windows-collections crate (0.3.1) crate has been updated to depend on the latest version of the
windows-implementcrate.The windows-core crate (0.62.1) crate has been updated to depend on the latest version of the
windows-implementcrate.The windows-future crate (0.3.1) crate has been updated to depend on the latest version of the
windows-implementcrate.The windows-sys crate (0.61.1) crate has an updated readme with version range guidance.
The windows-targets crate (0.53.4) crate has an updated readme indicating that windows-link should be preferred.
What's next
Work continues to improve the experience of Rust developers on Windows and more generally enabling and supporting a broad range of programming languages and frameworks by building the tools and services to enable cross-platform toolchains and frameworks to excel on Windows.
This includes a renewed focus on metadata for the canonical description of APIs and components, whether they ship inside the OS or in some other way. Metadata is the key to scaling up the generation of bindings for various languages including Rust. We must make it easier for app developers as well as language, library, and framework maintainers to approach Windows APIs so they can take advantage of what is distinctive and unique about Windows and light up those features as they are available.
Work has begun, particularly with the first complete ECMA-335 reader and writer for Rust. This gives us the ability to both read and write what are commonly referred to as .winmd files, popularized by .NET and WinRT, for describing APIs and components and has been extended to describe traditional Win32 and COM APIs as well.
The next steps include C/C++ header and IDL parsers that can generate high quality metadata so that we can more easily generate bindings for existing APIs that predate metadata. I am bringing up both an IDL and a RDL parser in tandem. The latter is an IDL dialect but based on Rust syntax and natively embeddable so that we can more easily support first-class component and API authoring in Rust without resorting to what is otherwise the very proprietary syntax that is IDL. The C/C++ header and IDL parsers will likely be somewhat tactical as those dialects are extremely complicated and extremely elusive respectively. The goal is to help developers bring older APIs and definitions forward to a supportable and open-source foundation.
With comprehensive metadata and API or ABI tooling easily accessible to Windows developers, the next step is to make Windows more accessible to non-Windows platforms by providing cross-platform fallback implementations of the various core windows-rs type system and support crates. This should allow developers to use the same languages and tools to build components and applications that necessarily communicate and interop across operating system boundaries. The windows-rs technology already supports this to some degree by allowing DirectWrite and DWriteCore, implemented with windows-rs, to support both Windows and non-Windows platforms. This is today limited to a thin slice of COM support but I hope to extend this to more of the foundational type system so that richer APIs can seamlessly work across different target platforms.
Wrapping up
And that's all for this update. Let me know what you think. What would you like to see more of? Are you interested in specific learning series topics? Are you using
windows-rstoday? Let me know so we can continue to prioritize investment in these tools and services.