rodrigocfd
commented
1 year ago Hi Tom,
This is more of discussion or feature request. But is there any interest in implementing the winsrv.h stuff like
StartServiceCtrlDispatcherand associalted api's?
Yes, I think it would be a nice addition to the library.
I find I am trying to implement wrappers around the winsrv api's from windows crate
That's pretty much how winsafe itself started: as safe wrapper to the good ol' winapi – the windows crate didn't even exist back in those days. Eventually winsafe evolved to completely remove winapi as a dependency, which made a lot of things easier and also boosted the compilation time (winsafe has zero dependencies).
and thought perhaps forking winsafe and implementing them in here.
Seems like a good idea. I would be glad to help you with your fork, until it's stable enough to be merged into the master branch.
the winsrv api's use a lot of types in the winuser.h. So I'm guessing all the consts and structs could be added to the
user/co/constsanduser/structstypes and maybe add a new feature folder forserviceapis inwinsrv.h?
The Cargo features of winsafe are based on the DLLs (kernel32, user32, etc.), and not on the C headers. But there is a very complicated story besides that...
My first attempt was very rigid about the Cargo features, with each item correctly placed according to its DLL. It was beautiful, a super organized library. But I quickly got a lot of headaches with the Windows API C headers. For example: the base of everything is kernel32; advapi32 is built on top of it. SECURITY_DESCRIPTOR is a struct which is used by many kernel32 calls, however, it is initialized via InitializeSecurityDescriptor which belongs to... advapi32. Yes, a circular dependency. And just one of many. I had no choice other than aglutinate advapi32 into kernel32 – you can read this note in the project README. And there are circular dependencies all over the place... it's unbelievable how careless those people were.
That said, let's dive onto your case.
As far as I could see, the winsrv.h functions belong to advapi32, which would place them into the kernel Cargo feature within winsafe. But you're telling me that they use constants and structs from user, which seems to be... another case of circular dependency. We would have to carefully evaluate each case, to see if we should downgrade the item from user to kernel, or upgrade the function from kernel to user.
Dealing with stuff like this can be pretty overwhelming, so I suggest you to start simple. Start with the first function call you need, then perform a Cargo check in isolation:
cargo check --features kernelThe proceed to the next function, until something weird appears.
And let me know of your progress, we can work together on this.
TomzBench
This is more of discussion or feature request. But is there any interest in implementing the winsrv.h stuff like
StartServiceCtrlDispatcherand associalted api's?I find I am trying to implement wrappers around the winsrv api's from windows crate and thought perhaps forking winsafe and implementing them in here. the winsrv api's use a lot of types in the winuser.h. So I'm guessing all the consts and structs could be added to the
user/co/constsanduser/structstypes and maybe add a new feature folder forserviceapis inwinsrv.h?is this correct way to go? Is this kind of PR welcome?