-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Deno.osRelease()
in Windows
#9862
Comments
Demo.osRelease()
in WindowsDeno.osRelease()
in Windows
And according to the documentation -
Deno needs to be a manifested application. See https://docs.microsoft.com/en-us/windows/win32/sysinfo/targeting-your-application-at-windows-8-1 Solution is to use |
Thanks for your interest .. I tried to suggest this code but I don't know if it works in a practical way async function getWindowsVersion() {
const procces = Deno.run({
cmd: ["wmic", "os", "get", "Version", "/value"],
stdout: "piped",
stderr: "piped",
});
return new TextDecoder().decode(await procces.output()).split("=")[1].trim();
}
console.log(await getWindowsVersion()) based on |
@littledivy unfortunately, making deno a "manifested application" won't solve the issue: if deno is manifested for some version X of Windows, then |
Aside for a WMI-based option like @moncefplastin07 suggested, a few other options are: But perhaps we should just post a bug at the |
@Spoonbender Yup, using RtlGetVersion and falling back to GetVersionEx sounds good? It better aligns with Node's |
Fixes #9862 `loadavg` | Target family | Syscall | Description | | ------------- | ------- | ----------- | | Linux | `sysinfo` | - | | Windows | - | Returns `DEFAULT_LOADAVG`. There is no concept of loadavg on Windows | | macOS, BSD | `getloadavg` | https://www.freebsd.org/cgi/man.cgi?query=getloadavg | `os_release` | Target family | Syscall | Description | | ------------- | ------- | ----------- | | Linux | `/proc/sys/kernel/osrelease` | - | | Windows | [`RtlGetVersion`](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-rtlgetversion) | dwMajorVersion . dwMinorVersion . dwBuildNumber | | macOS | `sysctl([CTL_KERN, KERN_OSRELEASE])` | - | `hostname` | Target family | Syscall | Description | | ------------- | ------- | ----------- | | Unix | `gethostname(sysconf(_SC_HOST_NAME_MAX))` | - | | Windows | `GetHostNameW` | - | `mem_info` | Target family | Syscall | Description | | ------------- | ------- | ----------- | | Linux | sysinfo | - | | Windows | `sysinfoapi::GlobalMemoryStatusEx` | - | | macOS | <br> <pre> sysctl([CTL_HW, HW_MEMSIZE]); <br> sysctl([CTL_VM, VM_SWAPUSAGE]); <br> host_statistics64(mach_host_self(), HOST_VM_INFO64) </pre> | - |
Fixes denoland#9862 `loadavg` | Target family | Syscall | Description | | ------------- | ------- | ----------- | | Linux | `sysinfo` | - | | Windows | - | Returns `DEFAULT_LOADAVG`. There is no concept of loadavg on Windows | | macOS, BSD | `getloadavg` | https://www.freebsd.org/cgi/man.cgi?query=getloadavg | `os_release` | Target family | Syscall | Description | | ------------- | ------- | ----------- | | Linux | `/proc/sys/kernel/osrelease` | - | | Windows | [`RtlGetVersion`](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-rtlgetversion) | dwMajorVersion . dwMinorVersion . dwBuildNumber | | macOS | `sysctl([CTL_KERN, KERN_OSRELEASE])` | - | `hostname` | Target family | Syscall | Description | | ------------- | ------- | ----------- | | Unix | `gethostname(sysconf(_SC_HOST_NAME_MAX))` | - | | Windows | `GetHostNameW` | - | `mem_info` | Target family | Syscall | Description | | ------------- | ------- | ----------- | | Linux | sysinfo | - | | Windows | `sysinfoapi::GlobalMemoryStatusEx` | - | | macOS | <br> <pre> sysctl([CTL_HW, HW_MEMSIZE]); <br> sysctl([CTL_VM, VM_SWAPUSAGE]); <br> host_statistics64(mach_host_self(), HOST_VM_INFO64) </pre> | - |
hi guys I think there is a problem extracting the OS version via the
Deno.osRelease()
method in Windows because when I run this code,I get
6.2.9200
in the console even though I am using Windows 10Deno: v1.8.1
Windows: 10.0.19042
The text was updated successfully, but these errors were encountered: