ratijas/windows-rust-counters

Windows Performance Counters written in Rust

Windows performance counters in Rust

This all started as a simple university assignment on building a custom Windows performance counters object provider written in C++. Guess what? Not it's in Rust. And it's not merely a simple counter, but a framework for building them.

Windows + Rust = <3

This is an umbrella project for libs and tools used to build Windows performance counters provider and consumer which exchange text data through Morse code additionally encoded with custom protocol for robustness and synchronization.

Cargo workspace includes the following sub-projects (highest to lowest importance):

Target	Path	Description
example-provide-morse-counter	examples.d/provide-morse-counter	Compile and install and register dll which provides "Morse code" performance counters object.
example-consume-morse-counter	examples.d/consume-morse-counter	Terminal user interface (TUI) for consumer of "Morse code" performance counters object.
win-high	win-high/	High-level safe bindings and wrappers for the winapi.
win-low	win-low/	Low-level bindings for winapi which are missing from the winapi crate.
signal-flow	signal-flow/	Tx/Rx abstractions and common useful implementations. Provides blocking senders and receivers.
morse-stream	morse-stream/	Streaming encoder and decoder of Morse code. Supports ITU dialect with most of punctuation included.
rtsm-proto	rtsm-proto/	Ratijas Slow-Mode protocol, designed to prevent synchronization problems, built on top of signal-flow primitives.

Several examples are contained in a separate project. This is done to facilitate dependency management of the examples.

Check this out

To install provider and test it with consumer:

1. > cargo build --package example-provide-morse-counter
2. Install script copies debug target. To use release instead, change path manually in the scripts/install.bat.
   • Right-click install.bat, 'Run as Administrator'.
   • Or run examples.d\provide-morse-counter\scripts\install.bat from the administrator's console.
3. Open "Registry Editor" (Press Win+R, type "regedit.exe" then hit Enter).
4. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Morse.
5. Customize message, number of instances (0xffffffff for no instances) and tick interval in milliseconds to your liking.
   To test it performance monitor, tick interval should be at least a little more than a second to prevent accidental skips.
6. Open "Performance Monitor" (Win+R "perfmon.exe"), add counter object named "Morse code".
7. > cargo run --bin example-consume-morse-counter WITHOUT administrator privileges.

Gallery

SOS in Performance Monitor

Custom message

Message of the day in Performance Monitor

Random joke about CHUCK NORRIS

RegEdit.exe settings

windows-rust-counters's Issues

Morse code error handling

<ITU as Dialect>::encode_unknown should really handle encoding errors instead of being an empty slice of code points.

This is our current implementation:

    fn encode_unknown(&self) -> KnownCodePoints {
        Self::EMPTY
    }

According to the Wikipedia, the protocol defines the following sequence for error under the Prosigns section:

· · · · · · · · 

Not sure if it is applicable for encoding unknown characters though.

Timestamps

Things to do about timestamps:

• learn how to use timestamps
• build such TimeProvider that would be recognized correctly by Performance Monitor, which is the ultimate Oracle of truth
• store history in client with timestamps, and use them to build dataset, so that graph won't get stretched up by holding any key down (which leads to sort of 'increase' of tick rate).

Experiment with more optimal Morse letters encoding

According to the telegram chat, Morse code letters can be stored and processed much more efficiently. Sequence of code points representing individual letters may fit in a single u64 or even u32 which are much easier and faster to compare.

TODO: experiment with encoding, compare the results.

Publish counters as a framework

At the moment, counters "framework" only consists of a single trait with some default methods. And those default methods is what actually does most of the job. Real framework should extract them into separate trait + impl struct pair, thus effectively separating those implementation details.

Next, manual preprocessing of raw FFI arguments, calling provider, and post-processing the response — all that is too complicated, and should be simplified in the following ways:

• functions should be added for pre-/post-processing FFI arguments, maybe to the provider itself
• macros definitions should take care of registering exported functions and calling given provider
• registering multiple counters providers should be as easy as working with single one, although it may not be needed at all, since user's provider implementation may opt to support multiple object types.

After that, add some documentation and basic examples.

Finally, when all of the above is done, a crate should be published at crates.io, and documentation at docs.rs.