OpenWin: Difference between revisions
mNo edit summary |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
OpenWin also combines additional projects that will be developed in parallel, to enhance OpenWin with additional functionality, ultimately replacing Windows NT ones. These projects will use same development principles and will be tied with OpenWin as additional dependencies. | OpenWin also combines additional projects that will be developed in parallel, to enhance OpenWin with additional functionality, ultimately replacing Windows NT ones. These projects will use same development principles and will be tied with OpenWin as additional dependencies. | ||
== | == Principles of development == | ||
OpenWin development is laying on several principles, which are used in order to make further progress easier to approach and quickly add new features and capabilities into system: | |||
* '''Cross-platform compilers''', which will be modified by time to be used on older versions of Windows NT operating system family, such as Windows XP, Windows Server 2003, Windows NT 4.0 and older, | |||
* '''Memory-safe code''' with proper checks, which are possible on C/C++ programming languages and almost possible in 16-bit mode. Who said that only Rust can do that? | |||
* '''Modularity and portability''', to make OpenWin and it's relative projects possible to load on base of existing Windows NT operating systems and not only, | |||
* '''Proper documenting and describing''', with which any newcomer can easily orient what's going on on this project, it's structure and ability to improve and enhance existing functionality, as well as adding new one. | |||
== Components == | |||
=== OpenKernel === | === OpenKernel === | ||
Originally OpenKernel's need have been raised in order to replace the Windows Server 2003's kernel with structurally same but different in approach kernel, which will fix most of compatibility issues for both old and new machines. This project doesn't have similar aims as ReactOS does, however, OpenKernel tends to be free for use and open-source. This approach will make OK eventually replace NT. | Originally OpenKernel's need have been raised in order to replace the Windows Server 2003's kernel with structurally same but different in approach kernel, which will fix most of compatibility issues for both old and new machines. This project doesn't have similar aims as ReactOS does, however, OpenKernel tends to be free for use and open-source. This approach will make OK eventually replace NT. | ||
The pure basis of the OpenKernel | The pure basis of the OpenKernel will be the Server 2003 RTM + Windows Research Kernel. In contrary of original one, the IA-64 native support will be removed entirely, due to absence of this architecture and very rare opportunity of Intel Itanium machines. Also, the approach similar to Linux and MinWin is planned: kernel will turn more modular and expandable, among with dealing with culprits of undocumented routines and internally improving all sub-modules of kernel. The precise construction of kernel is following: | ||
* <code>'''ntoskrnl.exe'''</code> - unified kernel which combines all features of multi/uniprocessor machines. This will turn as ultimate replacement for <code>ntkrnlmp.exe</code> for multiprocessors too. The additional kernels will be added, but they will support relatively newer processor features, | * <code>'''ntoskrnl.exe'''</code> - unified kernel which combines all features of multi/uniprocessor machines. This will turn as ultimate replacement for <code>ntkrnlmp.exe</code> for multiprocessors too. The additional kernels will be added, but they will support relatively newer processor features, | ||
| Line 14: | Line 22: | ||
* <code>'''kernelSchema.dll'''</code> - schema orchestrating mechanism for adding additional APIs into system. This allows for third-party sides to create their custom Kernel Extension modules and therefore, use them when OpenKernel is loaded. Approach will allow to port newer Windows DLLs and functionality directly into OpenKernel without recompiling or rebuilding entire project, | * <code>'''kernelSchema.dll'''</code> - schema orchestrating mechanism for adding additional APIs into system. This allows for third-party sides to create their custom Kernel Extension modules and therefore, use them when OpenKernel is loaded. Approach will allow to port newer Windows DLLs and functionality directly into OpenKernel without recompiling or rebuilding entire project, | ||
* <code>'''hal.dll'''</code> - enhanced and updated Hardware Abstraction Layer. Updated HAL will allow to run OpenKernel under ancient and modern hardware, by implementing custom HALs and adding new capabilities of ACPI, AHCI and many more components, | * <code>'''hal.dll'''</code> - enhanced and updated Hardware Abstraction Layer. Updated HAL will allow to run OpenKernel under ancient and modern hardware, by implementing custom HALs and adding new capabilities of ACPI, AHCI and many more components, | ||
* <code>'''halSchema.dll'''</code> - same approach of orchestrating custom HALs and their management for <code>hal.dll</code>, with practically same ability levels, only for Hardware Abstraction Layers. | * <code>'''halSchema.dll'''</code> - same approach of orchestrating custom HALs and their management for <code>hal.dll</code>, with practically same ability levels, only for Hardware Abstraction Layers, | ||
* <code>'''win32k.sys'''</code> - optional kernel-mode driver for adding bare-bones graphical capabilities like VESA BIOS 3.0 support with it's predecessors, as well as refactored yet optimized graphical accelerations. | |||
==== Compilers ==== | ==== Compilers ==== | ||
OpenKernel will be implemented by switching compilers stack: thus, the NASM will turn the direct replacement for Microsoft's MASM, which is proprietary and have Microsoft-specific instructions set. Also, the compiler will be switched into Tiny CC (aka TCC), in order to be cross-platform compatible and allow more enhanced ports into foreign architectures, e.g. ARM and RISC-V. | OpenKernel will be implemented by switching compilers stack: thus, the [https://nasm.us NASM] will turn the direct replacement for Microsoft's MASM, which is proprietary and have Microsoft-specific instructions set. Also, the compiler will be switched into Tiny CC (aka TCC), in order to be cross-platform compatible and allow more enhanced ports into foreign architectures, e.g. ARM and RISC-V. | ||
Also the ability to make ELF-compatible kernel is in plans too, for leveraging work in easier way and allowing better hot-patching mechanism for OpenKernel. | Also the ability to make ELF-compatible kernel is in plans too, for leveraging work in easier way and allowing better hot-patching mechanism for OpenKernel. | ||
=== OpenCRT === | === OpenCRT === | ||
OpenWin C(++) Language Runtime is a one-in replacement for MSVC Runtime, with extra functionality such as support for newer C(++) standards and libraries, cross-platform source code and easy integration in other operating systems, such as Linux-based ones, macOS and more. As a compatibility layer, <code>msvcrt.dll</code> and <code>ucrtbase.dll</code> will be provided as stubs linking to OpenCRT DLL files, additionally making runtime more reliable and faster. | |||
=== OpenLdr === | |||
A spin-off for modern Windows Boot Manager - Open Loader (or BootMan, in several occasions) is planned, in order to fully replace rusty and old-fashioned NTLDR. The problems with NTLDR are it's structural dispositions, which makes it unmaintainable in several cases, such as enhancements of porting boot loader into newer versions of (U)EFI and x64 systems. | |||
The boot loader will be implemented from scratch, by using NASM as a compiler for initializing it's boot sector, and the main boot loader which will pair C/C++ and handle kernel drivers and boot options, under separate boot options by using Windows registry. | |||
== Utilities == | == Utilities == | ||