com-rs VS winsdk-10

regarding COM - check https://github.com/microsoft/com-rs

I'm building a crate to show a progress indicator in the icon of the taskbar of the app using it, I already began the implementation for Linux, but I want to support Windows also, for that I need to access ITaskBarList3, I don't knew anything about COM interfaces before find this. The point is that I'm pretty confused about what to do. They said I would implement the functions, but I want to call them, and this thing com-rs, I'm not sure if I would redefine the interface that is already defined in winapi.

> Is this something you have to sign an NDA with Microsoft to get access to the headers and docs for it? Or will I find the headers hidden away in the WDK somewhere?

Turns out the header file is included in the Windows 10 SDK, as km/nthalext.h

Not the very latest version, but someone posted it on GitHub here: https://github.com/tpn/winsdk-10/blob/master/Include/10.0.16...

(You can download the multi-gigabyte Windows 10 SDK to get a more recent one.)

Still doesn't seem to be any public documentation. The header includes very detailed comments, but (as you'd expect for header file comments) they concentrate on the nitty-gritty and omit the big picture.

Searching "nthalext.h" on GitHub finds (what appears to be) source code for a number of HAL extensions, so at least there is some (third party) sample code to look at.

I'm looking at windows-rs and finding what I think is a good relevant and representative example of how EventSys is implemented, which has several IDispatch interfaces. I think this gives me a good starting point, thanks for pointing me in this direction.

I think that the author hasn't checked them all. Even this isn't checking them all.

The MUSL C library' sscanf() does not do this, but does call memchr() on limited substrings of the input string as it refills its input buffer, so it's not entirely free of this behaviour.

* https://git.musl-libc.org/cgit/musl/tree/src/stdio/vsscanf.c

The sscanf() in Microsoft's C library does this because it all passes through a __stdio_common_vsscanf() function which uses length-counted rather than NUL-terminated strings internally.

* https://github.com/tpn/winsdk-10/blob/master/Include/10.0.16...

* https://github.com/huangqinjin/ucrt/blob/master/inc/corecrt_...

The GNU C library does something similar, using a FILE structure alongside a special "operations" table, with a memchr() in the initialization.

* https://github.com/bminor/glibc/blob/master/libio/strops.c#L...

* https://github.com/bminor/glibc/blob/master/libio/strfile.h#...

The FreeBSD C library does not use a separate "operations" table.

* https://github.com/freebsd/freebsd-src/blob/main/lib/libc/st...

A glib summary is that sscanf() in these implementations has to set up state on every call that fscanf() has the luxury of keeping around over multiple calls in the FILE structure. They're setting up special nonce FILE objects for each sscanf() call, and that involves finding out how long the input string is every time.

It is food for thought. How much could life be improved if these implementations exported the way to set up these nonce FILE structures from a string, and callers used fscanf() instead of sscanf()? How many applications are scanning long strings with lots of calls to sscanf()?