-
Notifications
You must be signed in to change notification settings - Fork 563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tweak(core): use si for process data #1027
base: develop
Are you sure you want to change the base?
Conversation
Hey @million1156, thanks for the (draft) PR. txAdmin uses a bunch of different ways to get a bunch of different host data, like windows / distro name, processor speeds, processes memory usage, etc. And all of that was built individually without much consideration for the overall. More recently I've thinking of just using thinking of refactoring those parts of code to use the Here is a copypaste from the devnotes about this subject:
|
Hey @tabarra, Thanks for the quick response! I've created a new commit that now uses EDIT: In the future I want to try and replace every stats, but I think this is a great start since this currently affects anyone who's using Windows Server 2025 or Windows 11 (i.e. a dev hosting a server from their home computer/server) |
This PR is still a draft. I am not sure if exec is the best possible implementation, but it seems okay enough to create a draft PR.
This PR fixes an issue that was introduced with Windows 11 & Windows Server 2025, which removed
wmic
.Instead of using the deprecated command, we instead call
Get-WmiObject
, whose documentation can be found here. The command we use to get the data is:, where:
Essentially, we're given the amount of memory (in bytes) that the process is currently consuming. So, we do the same division that we used to use for Linux processes.
The only concern I have here is that it may not be the best idea to use
exec
. However, I've tried my best to prevent any security issues. I'm curious if there's any better ways to go about this! But it seems like the most viable solution as of right now.