Native windows operating system

Native Operating System and Hardware Information

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

OSHI is a free JNA-based (native) Operating System and Hardware Information library for Java. It does not require the installation of any additional native libraries and aims to provide a cross-platform implementation to retrieve system information, such as OS version, processes, memory and CPU usage, disks and partitions, devices, sensors, etc.

Windows • Linux • macOS • Unix (AIX, FreeBSD, OpenBSD, Solaris)

• Computer System and firmware, baseboard
• Operating System and Version/Build
• Physical (core) and Logical (hyperthreaded) CPUs, processor groups, NUMA nodes
• System and per-processor load, usage tick counters, interrupts, uptime
• Process uptime, CPU, memory usage, user/group, command line args, thread details
• Physical and virtual memory used/available
• Mounted filesystems (type, usable and total space, options, reads and writes)
• Disk drives (model, serial, size, reads and writes) and partitions
• Network interfaces (IPs, bandwidth in/out), network parameters, TCP/UDP statistics
• Battery state (% capacity, time remaining, power usage stats)
• USB Devices
• Connected displays (with EDID info), graphics and audio cards
• Sensors (temperature, fan speeds, voltage) on some hardware

Stable Release Version	Current Development Version	Dependencies
oshi-core-5.7.1	oshi-core-5.7.2-SNAPSHOT	JNA • SLF4J

Java 11 (JPMS) Version	Current Development Version
oshi-core-java11-5.7.1	oshi-core-java11-5.7.2-SNAPSHOT

Include OSHI and its dependencies on your classpath. We strongly recommend you add OSHI as a dependency to your project dependency manager such as Maven or Gradle. You can find the appropriate syntax to include OSHI here.

Create a new instance of SystemInfo

Use the getters from SystemInfo to access hardware or operating system components, such as:

See the PERFORMANCE document for general CPU/Memory tradeoffs and specific Windows (WMI) recommendations depending upon your application.

See the FAQ document for common implementation and calculation questions.

Some settings are configurable in the oshi.properties file, which may also be manipulated using the GlobalConfig class. This should be done at startup, as configuration is not thread-safe and OSHI does not guarantee re-reading the configuration during operation.

The oshi-demo artifact includes several proof-of-concept examples of using OSHI to obtain information, including a basic Swing GUI.

Note: OSHI uses the latest version of JNA. If you experience a NoClassDefFoundError or NoSuchMethodError issues with JNA artifacts, you likely have an older version of either jna or jna-platform in your classpath from a transitive dependency on another project. Consider one or more of the following steps to resolve the conflict:

• Listing OSHI earlier (or first) in your dependency list
• Specifying the most recent version of JNA (both jna and jna-platform artifacts) in your pom.xml as dependencies.
• If you are using the Spring Boot Starter Parent version 2.2 and earlier that includes JNA as a dependency:
  • Upgrade to version 2.3 which does not have a JNA dependency (preferred)
  • If you must use version 2.2 or earlier, override the jna.version property to the latest JNA version.

• For bug reports, feature requests, or general questions about OSHI’s longer term plans, please create an issue.
• For help integrating OSHI into your own project or maintainer code review of your PRs, tag @dbwiddis in issues or pull requests on your project site.
• For «how to» questions regarding use of the API, consult examples in the oshi-demo project, create an issue, or search on Stack Overflow using the oshi tag, asking a new question if it hasn’t been answered before.
• To say thanks to OSHI’s primary maintainer, you can sponsor him or buy him a coffee.

OSHI for enterprise

Available as part of the Tidelift Subscription

The maintainers of OSHI and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use. Learn more.

Security contact information

To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.

OSHI provides output directly via Java methods for each of its interfaces.
By periodically polling dynamic information (e.g., every second), users can calculate and track changes.

You can see more examples and run the SystemInfoTest and see the full output for your system by cloning the project and building it with Maven:

In addition, the oshi-demo project includes an OshiGui class implementing a basic Swing GUI offering suggestions for potential visualizations using OSHI in a UI, monitoring, or alerting application, as shown below:

General information about the operating system and computer system hardware:

By measuring ticks (user, nice, system, idle, iowait, and irq) between time intervals, percent usage can be calculated. Per-processor information is also provided.

Process information including CPU and memory per process is available.

Memory and swapfile information is available.

Statistics for the system battery are provided:

The EDID for each Display is provided. This can be parsed with various utilities for detailed information. OSHI provides a summary of selected data.

Disks and usage (reads, writes, transfer times) are shown, and partitions can be mapped to filesystems.

Sensor readings are available for some hardware (see notes in the API).

Attached USB devices can be listed:

Where are we? How can I help?

OSHI originated as a platform-independent library that did not require additional software and had a license compatible with both open source and commercial products. We have developed a strong core of features on major Operating Systems, but we would love for you to help by:

• Testing! Our CI testing is limited to a few platforms. Download and test the program on various operating systems/versions and hardware and help identify gaps that our limited development and testing may have missed. Particular testing needs include:
  • Windows systems with over 64 processors
  • Raspberry Pi
  • Less common Linux distributions
• Contributing code. See something that’s not working right or could work better? Help us fix it! New contributors are welcome.
• Documenting implementation. Our Wiki is sparse and the oshi-demo artifact is a place to host proof-of-concept ideas. Want to help new users follow in your footsteps?
• Suggesting new features. Do you need OSHI to do something it doesn’t currently do? Let us know.

Many thanks to the following companies for providing free support of Open Source projects including OSHI:

• SonarCloud for a range of code quality tools
• Travis CI for continuous integration testing
• The jProfile Java Profiler used to eliminate cpu bottlenecks

Windows Native Applications and Acronis Active Restore

We continue telling you about our cooperation with Innopolis University guys to develop Active Restore technology. It will allow users to start working as soon as possible after a failure. Today, we will talk about Native Windows applications, including details on their development and launch. Under the cut, you will find some information about our project, and a hands-on guide on developing native apps.

In previous posts, we have already written about Active Restore, and how Innopolis students develop the service. Today I would like to focus on native apps. We want to «bury» our active restoration service to their layer. If we succeed, we can:

• Launch the service much earlier
• Connect with a cloud containing a backup a bit earlier
• Identify system boot mode, normal or safe, much earlier
• Restore much fewer files in advance
• Allow a user to start work even faster.

What is a Windows Native app?

To answer this question, let us look at the call stack, e. g. when someone tries to create a file.

Pavel Yosifovich — Windows Kernel Programming (2019)

A programmer uses the function CreateFile declared in fileapi.h header file and implemented in Kernel32.dll. However, the function itself does not create a file. It just checks input arguments and calls NtCreateFile function (prefix Nt shows that this function is native). This function is declared in winternl.h header file and implemented in ntdll.dll. It prepares the jump into the kernel space and then makes a system call to create a file. In this case, Kernel32 is just a shell for Ntdll. One of the reasons for this is that this way Microsoft can change native functions without affecting standard interfaces. Microsoft does not recommend calling native functions directly and does not document most of them. However, undocumented functions can be found here.

The main advantage of native apps is that ntdll is uploaded to the system much earlier than kernel32. This makes sense because kernel32 requires ntdll to operate. As a result, apps that use native functions can start working much earlier.

Therefore, Windows Native Applications are programs that can be launched early in the Windows boot process. They use functions ONLY from ntdll. An example of such an application: autochk, which runs chkdisk utility to check disk errors before the main services are launched. This is the layer where we want Active Restore to be.

What will we need?

What about the code?

Let us practice and write a simple example app that:

• Displays a message
• Allocates some memory
• Waits for keyboard input
• Frees allocated memory

In native applications, the entry point is not main or winmain. We have to implement the NtProcessStartup function because we start the new process directly in the system.

Let us start by displaying a message. To do that we have a native function, NtDisplayString, which accepts a pointer to UNICODE_STRING object as an argument. We will use RtlInitUnicodeString to initialize it. As a result, to display the text, we can write a tiny function:

Remember that we have access to functions only from ntdll. There are simply no other libraries loaded in the memory, so we will have problems with memory allocation. The “new” operator does not exist yet (it is from the way-too-high C++ world), there is also no malloc function (it needs runtime C libraries). Of course, we can use a stack. However, if we want to allocate the memory dynamically, we will need a heap. Let us create a heap to allocate memory from there wherever we need it.

We are going to use the RtlCreateHeap function. Then we will use RtlAllocateHeap and RtlFreeHeap to allocate and free the memory.

Implementation of keyboard input wait.

All we need is to use NtReadFile on the opened device, and wait for the keyboard to return a keystroke. We keep working until the ESC button is not pressed. To open the device, we have to call NtCreateFile (we will need to open \Device\KeyboardClass0). Calling NtCreateEvent function will initialize the wait object. We declare KEYBOARD_INPUT_DATA structure that provides keyboard data.

The native apps end with a call NtTerminateProcess, because we simply kill our process.

The whole code of our tiny app:

PS: We can easily use DbgBreakPoint() to break in a debugger. It is better to connect WinDbg to the virtual machine for kernel debugging. The guide on how to do it is here. Alternatively, we can use VirtualKD.

Compilation and build

The easiest way to build a native app is to use a DDK (Driver Development Kit). We need an «ancient» version 7.1 because newer versions have a different approach and work closely with Visual Studio. In the case of DDK, our project will only need Makefile and sources.

Your Makefile will be the same. Let us take a closer look at sources. This file contains sources of your program (.c files), build options and other parameters.

• TARGETNAME is the name of the output executable file.
• TARGETTYPE is an executable file type. It can be a driver (.sys), then the field value should be DRIVER, or the library (.lib) and then the value should be LIBRARY. We need an executable file (.exe), so we set PROGRAM value.
• UMTYPE. Possible values: console for console application, windows for window mode. However, we need to set nt to get a native app.
• BUFFER_OVERFLOW_CHECKS is checking the stack for buffer overflow. Unfortunately, this is not our case, it is too early to check it in the system, so we turn it off.
• MINWIN_SDK_LIB_PATH. This value refers to the SDK_LIB_PATH variable. Don’t worry that this system variable is not declared. When we run a checked build script from DDK, this variable will be declared and will reveal the required libraries.
• SOURCES is the list of your program’s sources.
• INCLUDES is the header files required for the build. Here we usually state the path to the files that are part of DDK, but you can set any additional files.
• TARGETLIBS is a list of libraries to be linked.
• USE_NTDLL is a required field that must be set to position 1. This is quite obvious.
• USER_C_FLAGS means any flags that you can use in preprocessor directives when preparing application code.

So, for the build we need to launch x86 (or x64) Checked Build, change the working directory to the project folder, and run Build. The screenshot shows that we built one executable file.

Unfortunately, you cannot just run this file. The system argues and tells us to go and think about behavior with the following error:

How to launch a native app?

When the autochk is running, the program boot sequence is set by the registry key:

The session manager executes programs from this list in a predefined sequence. The manager looks for executable files in system32. The registry key has the following format:

The value must be hexadecimal, not the regular ASCII, so the above key will have the following value:

To convert the name, you can use any online services (e.g. this).

So, to launch a native app we have to:

1. Copy an executable file to system32
2. Add a key to the registry
3. Reboot the machine

UPD: or check this out, it may help to run native apps at host machine even later than at boot time: link.

To make your life easier, here is a script to install a native application:

After installation and reboot, even before choosing users, we get the following:

Conclusion

The example of this tiny app showed us that it is possible to launch an app as Windows Native. Next, we and the guys from Innopolis University will continue building the service that will initiate driver interaction much earlier than the previous version of the project. When the Win32 shell will be loaded by the system, it makes sense to transfer the control to a fully working service that has already been developed (more about this here).

In the next post, we will get to another Active Restore component, the UEFI driver. Subscribe to our blog to make sure you see the next post.