Added GetSecurityInfo

[nils-tekampe]

Hi there,
I guess that this branch will currently not compile.
I would appreciate some advice with this. As you can see, I'm trying to integrate GetSecurityInfo into the crate. However, I'm a little bit lost with some details:

1. Where should an enum like SE_OBJECT_TYPE go? Is this (src/advapi32.rs) the correct place?
2. Is the way, I added the function to testing, correct?
3. The enum for SE_OBJECT_TYPE seems to contain a set of constants but I cannot find them defined anywhere. (neither under https://msdn.microsoft.com/en-us/library/windows/desktop/aa379593(v=vs.85).aspx nor elsewhere in the net) Do you have any idea, how to proceed on this?
   I'm looking forward to your advice. I'd really like to adde some more functions that I would like to use.
   Thanks

[retep998]

1. Windows SDK 10.0.14393.0, um/AccCtrl.h.

//
// Definition:
// This enumerated type defines the objects supported by the get/set API within
// this document.  See section 3.1, Object Types for a detailed definition of the
// supported object types, and their name formats.
//
typedef enum _SE_OBJECT_TYPE
{
    SE_UNKNOWN_OBJECT_TYPE = 0,
    SE_FILE_OBJECT,
    SE_SERVICE,
    SE_PRINTER,
    SE_REGISTRY_KEY,
    SE_LMSHARE,
    SE_KERNEL_OBJECT,
    SE_WINDOW_OBJECT,
    SE_DS_OBJECT,
    SE_DS_OBJECT_ALL,
    SE_PROVIDER_DEFINED_OBJECT,
    SE_WMIGUID_OBJECT,
    SE_REGISTRY_WOW64_32KEY,
    SE_REGISTRY_WOW64_64KEY,
} SE_OBJECT_TYPE;

Therefore you would put this enum definition into src/accctrl.rs.

2. Yes.
3. Enum variants automatically get assigned a value depending on the value of the previous variant. So if a literal isn't assigned to a variant in the original definition in C/C++, then don't assign a value in Rust either, and it'll work correctly.

[retep998]

This PR will need to be updated for the winapi 0.3 new world order. #316

[Susurrus]

@nils-tekampe I don't know if most of these changes aren't already covered by a lot of the work that's already been done in dev, but if so, do you have any interest in pushing this PR forward towards merging?

[nils-tekampe]

@Susurrus In theory I would be willing to merge/push those changes that I made last year towards the main branch. My problem is however that most of the requirements mentioned under #316 are beyond my knowledge and experience in rust. I can merge the files and use the crates but I'm still a newbie with rust :-(

[Susurrus]

@nils-tekampe Well this is an excellent opportunity to keep working with Rust, because you've actually done the hard part already, creating the declarations! The only thing wrong with this PR is that the declarations are in the right place! Instead of declaring things in the DLLs that they're compiled into, this project is instead mimicing the windows headers directly. So all you need to do is move the code into the right places as described in #316. If you look at any of the other pending PRs, and read the CONTRIBUTING.md document, it should be straightforward. I'm also happy to help.

I should note that some of the changes you're already doing are resolved by #447. So reduce the scope of this PR down to just adding the accctrl header in src/um. Your commit would then be something like this.

[retep998]

Closing due to inactivity. If anything from this PR is still missing in the current winapi, feel free to redo those changes for the current structure and submit a fresh PR.