stanislav-tkach / os_info

Rust library to detect the operating system type
MIT License
174 stars 52 forks source link

Add possibility to get OS-specific data #347

Open Korne127 opened 1 year ago

Korne127 commented 1 year ago

Hey, this project is really good to get system information. However, currently, you can only get the same specific set of information about every operating system. The functions you use to return this often get much more information about the OS, but translate those into this general information struct that fits for all operating systems. That is easy to use and good in many cases, but there can be cases where you want to get related specific information about the OS version (which this crate even gets by itself, but doesn't give any possibility to retrieve).

Here is an example: In the Windows code, version_info.wProductType is retrieved (which determines if the version is a server version or not). This is used to return the edition string, but there is no possibility to directly access it, even if there are plenty of use-cases where you might want to know if the system is a server version or not.

My idea on how to solve this would be that there are new functions getWindowsInfo(), getMacOsInfo(), getLinuxInfo(), etc. for each currently supported operating system. The function could return an individual struct for each OS which can contain all the special information about the corresponding OS. (It would return None if it's called on a different OS, and Some(…) for the actual values on the correct OS.) There could also be one additional general getOS() function returning a value of an enum with the supported operating systems. You can call it prior to know if you need to call an OS-specific function. What this OS-specific function could return for e.g. Windows would be all the return values from the general Info struct, plus additionally the wProductType, the product name and edition string (currently you don't know which one you are getting, which makes parsing it very hard), the Windows type as an enum and more.

This would also have one big advantage about the OS version. It's a pretty common use-case to retrieve the version of an OS, and this crate is pretty good for it, but currently you don't know if you receive a tuple out of three numbers, a string or something else (without looking at the source code). With this way, you could set one type for each OS in the return struct so it's clear if you use the function. Additionally, you could return the OS edition as an enum. This would be really helpful, as e.g. for Windows you currently can't easily obtain the specific Windows version through this crate: The version number doesn't contain the separation between the home and the server versions, the wProductType isn't accessible and the edition string isn't clear either (since, if you use the crate, it's unknown to you whether the Microsoft product name string or your custom edition string is returned, and looking up all possibilities and parsing them is quite a hassle). So you could just easily return an enum value describing the specific OS version, which would significantly improve the simplicity of how you can get the specific OS version (and as I described, especially for Windows).

So yeah, I think it would be a real improvement to also implement such functions so people can obtain this additional information, and this should be really easy (to implement and use) and not add much complexity to the code since the information is already retrieved. What do you think about the idea?

stanislav-tkach commented 1 year ago

Sorry for the terribly late reply! It is an interesting idea, but I'm not sure if it is really that useful. For example for Windows there are a lot of details regarding version, edition, etc. Currently this library uses only some of that information and perhaps this should be improved, but getting all the existing information can be tedious and most users don't need it. I believe that it is easier to directly use the corresponding api (the winapi crate in this case) if some additional platform-dependent details are required.

I'm not going to close this issue, because I would like to hear your and other people's opinion, but right now I'm somewhat skeptical. 🙃