search

chipsenkbeil / service-manager-rs

Provides adapters to communicate with various operating system service managers like launchd and systemd
Apache License 2.0
179 stars 15 forks source link

[feature request] use windows-service crate rather than sc.exe #2

Closed xuyang2 closed 1 year ago

xuyang2 commented 1 year ago
chipsenkbeil commented 1 year ago

I'm aware of the crate as I use it for the actual service implementation in my system tests as seen here.

Is there a reason you would prefer the implementation to use that crate over talking to sc.exe? My reason for not using it for the installation was to avoid another unnecessary dependency.

chipsenkbeil commented 1 year ago

Closing out due to lack of input.

nu11ptr commented 1 year ago

One reason to prefer it would be to have a less brittle interface to the system. If sc.exe changes parameter names in an upcoming version of Windows, this crate would break where as using something that uses the underlying win32 API would not.

In my rust_format crate I did the same when calling out to rustfmt, however, in that case it was a HUGE dependency and it relied on nightly if I recall. In this case, I would think calling the API would be a good trade off for another dependency to prevent brittleness, a moved or deleted sc.exe file, etc.. My 2 cents only.

chipsenkbeil commented 1 year ago

One reason to prefer it would be to have a less brittle interface to the system. If sc.exe changes parameter names in an upcoming version of Windows, this crate would break where as using something that uses the underlying win32 API would not.

In my rust_format crate I did the same when calling out to rustfmt, however, in that case it was a HUGE dependency and it relied on nightly if I recall. In this case, I would think calling the API would be a good trade off for another dependency to prevent brittleness, a moved or deleted sc.exe file, etc.. My 2 cents only.

@nu11ptr Do you expect a core service binary like sc.exe to change its arguments that often? And if it did, would we expect the win32 API to be much more resilient? Honest question here since I don't use Windows! 😄

I have some experience using the crate referenced since I've written two windows services using it, and this could potentially be a feature flag to unlock an additional option that uses windows-service instead of sc.exe, but I'd say it's of a lower priority than adding other platforms like runit.

I'm also not opposed to a PR that adds this!

Thoughts?

nu11ptr commented 1 year ago

Do you expect a core service binary like sc.exe to change its arguments that often?

No, but I don't think Microsoft would hestitate to change it either if they had a need to do it. It is designed to be used by a human, not a program (or at least not as much). Windows culture is different this way.

And if it did, would we expect the win32 API to be much more resilient?

Yes, win32 doesn't break backwards compatibility. It has been eons since I coded on windows, but Win32 has been around forever... and changes are backwards compatible always AFAIK (which is why they keep adding Ex suffix functions when a similar function needs new params)

The culture on unix is that generally core programs are stable parameter-wise because they are called from scripts. Windows does not have this culture to the same extent. The closest they now have is Powershell, but that uses objects/apis as well, not programs AFAIK.

I also am not an expert here, but drawing from past knowledge. I don't have a huge need to change this or opinion just more surprised since I've never seen Windows Services implemented programatically this way (every lang binding I've seen uses the API, doesn't make it better, just what I've seen).