Add wincred.h

[hpoul]

I am interested in using wincred.h: https://docs.microsoft.com/en-us/windows/win32/api/wincred/nf-wincred-credwritea
to port my plugin to windows.

Do you have any plans to add support for it - or how much work is it? I'm not completely sure how much magic is autogenerated and what has to be manually added :-)

[domesticmouse]

Hey @hpoul,

I think you will find @timsneath's answer in #64 (comment) helpful on the autogeneration / hand coding front.

Do you have an idea of which specific API calls you want to make?

[hpoul]

@domesticmouse thanks for your fast reply, i think right now it's CredWrite, CredRead, CredDelete. I don't have experience with win32 APIs (yet), but those seem to be the closest to keychain read/write/delete :)

not sure if it's better to have a generic ffi bridge, or just use the specific C functions in my library (which is how i've implemented it for linux right now), but if it's easier to build on this package, it would be great ;-)

[timsneath]

Yeah, easy enough to add those functions, and they seem useful to others also. I'll put a quick pull request together.

As far as the latter question is concerned, you're obviously welcome to do what works best for you. But three reasons why you might consider a direct dependency on win32:

• With Dart tree shaking, you're not paying any additional 'tax' for the parts of win32 you're not using; only those typedefs that you actually use are compiled into your plugin;
• Obviously any improvements made to the Win32 package come for free (e.g. Dart finalizer support, or improvements to struct layout, when they arrive)
• If you ever choose to expose any of the credentials outside of your own package, it might be helpful if the Structs etc. are in a common package.

[hpoul]

cool thanks, that would be great.

To be honest my question was actually if it would be easier for me to work out how to add those APIs to win32 and make a PR vs. just doing it in my own plugin. If I just have to use the package, I'll certainly go for it 😅️

[timsneath]

You are very welcome to do so, if you want to get familiar with these APIs. A couple of tips:

• Use the Unicode ('W') variants of these APIs, rather than the ANSI ('A') variants, for example: https://docs.microsoft.com/en-us/windows/win32/api/wincred/nf-wincred-credwritew
• If you choose to do this work, the cred APIs go in advapi32.dart, the structs go in structs.dart and then the typedefs themselves go in typedefs.dart. The registry key read/write examples in advapi32.dart are a good pattern to build off.
• We'll want a sample (example folder) and some tests.

If you don't feel comfortable with doing this work, let me know; happy to investigate it at some point.

[domesticmouse]

@timsneath Can we promote your comment to a section in either the README? Seems like a useful getting started guide.

[timsneath]

Done: https://github.com/timsneath/win32/blob/master/CONTRIBUTING.md

[hpoul]

Thanks for the hints.. I've started adding the functions/structs and CredWrite seems to work as I can see the written credential in the Credential Manager, but CredRead returns success without filling my credential struct.
Do you have any idea what I could be doing wrong? I allocate a Pointer and pass it into the function, do I need to do something else to pass it by reference?

https://github.com/authpass/win32/blob/wincred/example/credentials.dart#L35-L43

  final cred = CREDENTIAL.allocate();
  final result = CredRead(
      TEXT(credentialName), CRED_TYPE_GENERIC, 0, cred.addressOf);
  if (result != TRUE) {
    final errorCode = GetLastError();
    print('Error ($result): $errorCode');
    return;
  }
  print('Success. size: ${cred.CredentialBlobSize}');

outputs:

Success. size: 0

(Even though I've written 10 bytes, which I can see in the Credential Manager)

[hpoul]

never mind, I somehow missed that it was PCREDENTIAL not CREDENTIAL. 🤦️ ie. I had to use Pointer<Pointer<CREDENTIAL>>

[timsneath]

Ah yes -- they're sneaky with that. The second * is masked in the typedef, so PCREDENTIAL *x is equivalent to CREDENTIAL **x. I spent days blocked on a similar issue when I built out the COM support, so the fact that you'd figured it out before I'd even looked at the code is something you can feel good about :)