An exercise in directly exercising winapi-rs
for fun and profit.
- "0" dependencies (well, minus
winapi-rs
of course) - I'll want to do interop with existing C++ rendering pipelines someday for middleware
bgfx-rs
shows that even just maintaining C++ builds is as painful as always, why not try a pure 100% Rust stack?
- Using
winapi-rs
's COM interop is nicer than expected (mostly thanks to powerful macro codegen). - Dealing with
winapi-rs
's explosion of modules is an exercise in annoyance. Fortunately this is something of a one-time cost, since I can simply collapse them back into a single module: src\win32.rs - RLS intellisense doesn't work on COM interfaces. Probably because of all the macros. Boo! I've been keeping a
copy of
winapi-rs
open in another VS Code instance andCtrl+Shift+F
ing through the source instead. - Default rust panic/assert behavior is lame, doesn't even breakpoint on the correct source line.
Especially annoying for multithreaded work (
bgfx-rs
), where panics noop until rethrown fromthread.join()
. Easy to write your ownexpect!(...)
macros, although trailing.unwrap!()
might not be possible. winapi-rs
COM interfaces practice interior mutability (all methods are implemented vs&self
).- Hygenic macros are hygenic. Specifically, a macro can apparently return
[a, b, c]
(single AST node?) but nota, b, c
. Error messages for early versions ofinput_layout!
were quite opaque before I realized this. - Lack of
StaticMutex
orlazy_static!
in stable stdlib gets annoying fast for shared internal resources like win32WNDCLASS
registration, but can be worked around with manualAtomicUsize
spinlocks and the like. - Directly using
winapi-rs
is mostly an exercise in wrapping everything inunsafe { ... }
.