OpenWin

2025-08-26T12:49:34Z

Ashific:

OpenWin

2025-08-25T11:48:15Z

Ashific: openkernel start

'''OpenKernel''' (short name` ''OK''), is an internal attempt to rewrite/rejuvenate Windows NT kernel to turn it more capable and modern, by integrating similar solutions implemented in [[MinWin]] and adding more features which doesn't exist in original NT project.

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.

Welcome

2025-08-21T09:25:45Z

Ashific:

{{DISPLAYTITLE:Welcome to The OpenXP Wiki!}}
Welcome to the [[OpenXP]] Project's official wiki! Here you can find useful guides to compile Windows XP/Server 2003 leaked source code, as well as to master in following stuff:

* [[Getting Started|Getting started]] on configuring [[Razzle|environment]], [[Certificate Generation|generating certificates]] and performing successful build,
* Adjusting source code with custom patches, enhancements and tweaks,
* Knowing more about [[Windows Internals]] (in most real way), as well as to introducing more fundamentals,
* And waffles! 🧇

== Community ==
If you want to stay connected with OpenXP, you can join our official [https://discord.com/invite/vS4bNfsZgh Discord server], as well to download source codes from our [[Download Center]] in safest way!

Build

2025-08-19T17:55:09Z

Ashific:

This guide tested under Windows XP, 7 SP1, 8.1 & 10 x86/x64, results may vary under other operating systems (if you will copy/paste source code at many times). For legacy version of the guide visit [https://rentry.co/build-win2k3 build-win2k3].

== Preparing for Build ==
Disable any AV (and Windows Defender) before extracting and building, as both of those actions create a lot of new files, and AV scans for execution of them all - this also counts for any other tools that monitor files, such as voidtools' Everything, but they aren't impacting much as your antivirus does. Also disable User Account Control. This can be accomplished via Control Panel, or via Registry Key: navigate to <code>HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System</code> and set <code>EnableLUA</code> to <code>0</code>. Some versions may require restart after registry apply.

After preparing your machine, extract source tree to a folder named <code>srv03rtm</code>, or <code>srvrtm</code> on the root of a drive, drive letter doesn't seem to matter (just don't use C:\ drive as that has some extra security). It is recommended to use <code>D:\srvrtm\</code> as the path to match RTM binaries.

=== For 2000/XP/2003 Users ===
Before initializing Razzle, you should update your build machine. If you're using Windows XP/Server 2003, and you haven't updated it yet with [https://legacyupdate.net Legacy Update], it's mandatory to install .NET Framework 1.1, because without it Razzle will fail to initialize environment normally (despite that two versions of .NET 1.1 are included in <code>tools\x86</code>). The installation files are included in <code>tools\prereq</code> folder.

=== Running environment ===

* Run command-prompt as administrator (can usually be done by typing <code>cmd</code> into start menu, or by right click <code>Command Prompt</code> -> <code>Run as administrator</code>)
* In the command-prompt, change to the source folder: <code>cd /d D:\srvrtm</code>
* Now start razzle: <code>tools\razzle.cmd free offline</code> for 32-bit clients, and <code>tools\razzle64.cmd free offline</code> for 64-bits. This initiates retail build of x86. The first time you run razzle inside that copy of the source code it'll need to initialize a few things, give it a few minutes, after a while a Notepad window will appear - make sure to close this for the initialization to continue.
* '''Important for first time!''' Run the prebuild script, if you're initiating source code for first time: <code>tools\prebuild</code>. This scripts sets all read-only attributes for necessary stuff and makes 16-bit stuff workable for x64 environments.
If you want to have official builds, append <code>official</code> argument. This argument is modified and removed <code>OfficialBuild</code> argument, which previously checked build machine for eligibility of building official builds. <code>official</code> argument sets necessary values for official build independently of your machine eligibility, because of it's moot behavior and requirement to be connected into legacy build servers.

=== Build ===
Start to build via <code>build /cZP</code> or <code>bcz</code> (which is alias to first, so doesn't matter). '''Important:''' Build.exe doesn't seem to play well when building with many (up to 8) threads. If your build machine has more than that it's recommended to cap it to 8 threads maximum via the <code>-M 8</code> switch, added to the build command (eg. <code>build /cZP -M 8</code>, or <code>bcz -M 8</code>). Use 8 threads if your host/virtual machine CPU have allocated 8 cores (or less). More than 8 threads build may lead to unforeseen behavior, such as inconsistent linkage and invalid generation of pieces of code, since some build programs were written back at time when CPUs should be limited in order to preserve proper frequency.

As an alternative, you can use <code>tools\buildx.cmd</code> script, which allows to build not only retail (fre) and debug (checked, or chk) builds, but also profile and meter builds, additionally by disabling compiler optimizations and specifically building for AMD64/IA64 architectures. The purpose of profile and meter builds is in investigations, as of time of guide enhancement.

=== Post-build ===

* Download the Missing Binaries pack from OpenXP Download Center, which contains missing binaries both for AMD64 and x86 builds.
* Extract the contents of the binaries folder for the build type you're building into your build trees binaries folder (e.g. <code>D:\binaries.x86fre</code>, should have been created during the build), the 7z should contain files for all SKUs (uses <code>pidgen.dll</code> from Win2003 Enterprise, so your builds should accept Enterprise product keys), '''When asked during extraction to overwrite folders select <code>Yes</code>, but when asked to overwrite files, make sure to select <code>No</code>!'''
* Inside the razzle window run <code>tools\postbuild</code>. You can use <code>-sku:{sku}</code> if you want to process only specific one (no brackets!), expect <code>filechk</code> errors, if you haven't extracted missing binaries from <code>misbin.7z</code>. If you have a wish to do a full post-build, append <code>-full</code> argument

==== Issues ====

* Once post-build has finished, assuming you used the <code>misbin.7z</code> file above and followed the guide properly, it should have hopefully succeeded without errors, and there shouldn't be any <code>binaries.x86fre\build_logs\postbuild.err</code> file!
* Otherwise take a look inside the <code>postbuild.err</code> - most messages in here are negligible, but if you see <code>filechk</code> errors associated with the edition you want to use, you may need to re-run <code>tools\missing.cmd</code>, or extract <code>misbin.7z</code> again.
* If <code>postbuild.err</code> contains messages like <code>(crypto.cmd) ERROR</code> or <code>(ntsign.cmd) ERROR</code> try re-importing the <code>tools\driver.pfx</code> key-file (double-click it, press Next through the prompts, password is empty), and make sure your system date is set to the current date.
* If postbuild.err has filechk errors about missing <code>hwcomp.dat</code> files, try copying the following into a batch script and run it in a razzle prompt (after using postbuild once already)<syntaxhighlight lang="bat" line="1">
@echo off
hwdatgen -i:%_NTPOSTBLD%\pro\i386 -o:%_NTPOSTBLD%\.\hwcomp.dat
hwdatgen -i:%_NTPOSTBLD%\per\i386 -o:%_NTPOSTBLD%\perinf\hwcomp.dat
hwdatgen -i:%_NTPOSTBLD%\bla\i386 -o:%_NTPOSTBLD%\blainf\hwcomp.dat
hwdatgen -i:%_NTPOSTBLD%\sbs\i386 -o:%_NTPOSTBLD%\sbsinf\hwcomp.dat
hwdatgen -i:%_NTPOSTBLD%\srv\i386 -o:%_NTPOSTBLD%\srvinf\hwcomp.dat
hwdatgen -i:%_NTPOSTBLD%\ads\i386 -o:%_NTPOSTBLD%\entinf\hwcomp.dat
</syntaxhighlight>

=== Creating ISO files ===
Execute <code>tools\oscdimg {sku} [destination-file (optional)]</code> where <code>{sku}</code> is one of:
* <code>srv</code> - Windows Server 2003 Standard Edition
* <code>sbs</code> - Windows Server 2003 Small Business Edition
* <code>ads</code> - Windows Server 2003 Enterprise Edition
* <code>dtc</code> - Windows Server 2003 Datacenter Edition
* <code>bla</code> - Windows Server 2003 Web Edition
* <code>per</code> - Windows XP Home Edition
* <code>pro</code> - Windows XP Professional
* <code>winpe</code> - Windows Preinstallation Environment
ISO will be saved to <code>{build-drive}\{build-tag}_{sku}.iso</code>, unless <code>[destination-file]</code> is provided as a parameter.

=== Troubleshooting ===
If you get any problems during the build hopefully your problem might be answered in our Discord server, by lurking

====== Certificate Import Wizard: An internal error occurred... ======
It's likely your PFX certificate isn't generated properly and you need to regenerate them. For that you should follow these steps:

* Check out the <code>tools\prereq</code> and install from there <code>MSYS 1.0.11.exe</code>, then hop up into your architecture folder (x32 or x64) and install <code>VC_redist</code> and then <code>OpenSSL</code>. Make sure OpenSSL is in your path (cause installer doesn't set it by default).
* Download the zip or do a <code>git clone</code> of CertUtil repository, or regenerate them using the original guide.
* Open MSYS and switch to directory where you extracted/cloned the repo.
* Attach all attributes via <code>chmod -r 0777 *</code> and convert .sh to UNIX format with <code>dos2unix *.sh</code>
* Execute <code>./generate.sh</code>
* Copy the files from <code>srv03rtm.certs</code> into source code tree (<code>D:\srv03rtm</code>)

====== After running razzle it shows a bunch of errors, "tfindcer not recognized" etc ======
You're likely on a 64-bit system but running <code>razzle.cmd</code> directly, you should use <code>razzle64.cmd</code> instead, this'll set things up so that razzle will use the correct tools for you. Hopefully with that the <code>tfindcer not recognized</code> & other errors should go away.

====== After a full build I get 1000+ errors, build.err has <code>has bad storage class</code> errors inside ======
Seems to be caused by your locale, this is reported to happen with Simplified Chinese language, but can probably happen with other languages too.

Besides changing your locale/language settings, you could also try editing the source files to remove the characters that cause problems, an anon posted a list of the files that need changes here

====== I get a <code>TAPI.RES</code> error during the build. ======
Try moving your source code folder closer to the root of the drive, ideally it should only be one folder up from the drive root (eg. <code>D:\srv03rtm\</code>)

====== On Windows 7 and later I get NTVDM crashes while building ======
All NTVDM errors should have hopefully been solved in the v8 release of this guide/ZIP, but if you still run into any NTVDM error a copy of your build.log file would help a lot to figure out what caused it, if you ZIP that up and post in the thread hopefully we can figure something out. We consider to build code on Windows 10 build 1809 or newer, or use operating systems up to Windows Vista.

== Debugging ==
Kernel debugging can be enabled by editing the <code>C:\boot.ini</code> file in your installed build, and adding <code>/debug /debugport=COM1 /baudrate=115200</code> to the end of a config line.

For example here's a <code>boot.ini</code> with two choices, one with debugging & one without, with this NTLDR will show an OS boot choice menu at startup:<blockquote>[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /debug /debugport=COM1 /baudrate=115200</blockquote>(even though they're named the same <code>Windows Server 2003, Enterprise</code>, NTLDR will add a <code>[debugger enabled]</code> tag to it on the OS selection menu.)

<code>chk (checked)</code> builds are preferred for debugging as they enable asserts & debug messages, though <code>chk</code> will run a lot slower than <code>fre</code> builds. <code>fre</code> builds can also be debugged fine, but usually with a lot less debug output.

Ideally you should also configure WinDbg to use the <code>binaries.{buildtype}\symbols.pri\retail</code> & <code>binaries.{buildtype}\symbols\retail</code> symbols folders too, if WinDbg is running on the same machine that compiled the build it should then also be able to do source-level debugging against the actual source files.

Note that if you're using a VM to host your build on you'll have to pass-through the emulated COM port over to a pipe somehow, for WinDbg/KD/IDA/etc to make use of.

There is apparently a way to get KDNET working on 2003 too (see <nowiki>https://github.com/MovAX0xDEAD/KDNET</nowiki>), but this is as-of-yet untested with our builds, seems like it should have support for VMware's emulated network hardware at least.

(TODO: add more VM guides here... if anyone wants to post one in the thread I'm happy to add it here)

=== VMware setup ===

* For a VMware VM, just open the VM hardware options, '''remove the printer hardware''', then click <code>Add...</code> and choose <code>Serial Port</code>.
* In the serial-port config panel, set it to <code>Use named pipe</code>, and enter a pipe name into the textbox, eg. <code>\\.\pipe\vm</code>. The pipe should be setup as <code>This end is the server</code> & <code>The other end is a virtual machine</code>.
* It's apparently recommended to use the <code>Yield CPU on poll</code> option, but I've had success without it, it's up to you.
* With that setup now just open WinDbg, choose <code>Attach to kernel</code>, open the <code>COM</code> tab and enter the baud-rate and pipe name you selected for your VM, then hit OK.
* Now WinDbg should start with <code>Waiting for reconnect</code> text showing, and hopefully when you next boot up your VM it'll connect up to WinDbg by itself.

=== Debugging Setup/Installation ===
A debugger can be attached to setup by pressing F8 at the right time - for text-mode setup the right time is when asked <code>Press F6 if you need to install a third party SCSI or RAID driver</code>, spamming it while that message is showing should make it connect to COM1 with 19200 baud-rate (debug options can be changed inside <code>txtsetup.sif</code>, the <code>SetupDebugOptions</code> line specifies options to apply when F8 is pressed). After debug connection is made it might take a couple extra minutes for it to pass the <code>Setup is starting Windows</code> stage.

Similarly, GUI setup can be debugged by pressing F8 before the Windows bootloader starts (progress bar etc), this should bring up a menu with options for <code>Safe Mode</code>, <code>Debugging Mode</code>, etc. Choosing <code>Debugging Mode</code> will make it attach to COM1 before starting setup, again at 19200 baudrate.

=== Changing default baudrate ===
The default 19200 baudrate can be changed by editing the <code>base\boot\kdcom\xxkdsup.c</code> file, search for <code>BD_19200</code> inside there and change it to e.g. <code>BD_115200</code>, now it should use that by default without needing any <code>/baudrate</code> parameter, or eg. when using <code>Debugging Mode</code> from the boot options menu.

=== Un-filtering kernel messages ===
Even with a chk build you may notice that the kernel doesn't seem to output much over KD, this seems to be because most of the kernel components use <code>KdPrintEx</code>, which allows filtering KD messages to certain components (although MS's docs seem to suggest KdPrintEx filtering was only used in Vista, it does seem that 2003 makes use of it too)

To enable components you'll need to open the registry of your installed build to the following key (or create it if it doesn't exist)<blockquote>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter</blockquote>Then create a DWORD value named the component you want to enable (eg. <code>LDR</code>), and set the value to hexadecimal <code>FFFFFFFF</code>.

A list of the component registry names can be found inside <code>base\published\obj\i386\dpfiltercm.c</code> after a build. This also contains the symbol names for the component (eg. <code>Kd_LDR_Mask</code>), which can be set directly through WinDbg/KD via the symbol name. (eg. <code>ed nt!Kd_LDR_Mask 0xFFFFFFFF</code>, with symbols loaded this should set the LDR components filter value in real-time)

The <code>WIN2000</code> components value (default <code>1</code>) is added to every components value, essentially making <code>WIN2000</code> the default value for all components - so setting this to <code>FFFFFFFF</code> should make every component print to KD. You'll get a ton more debug output from this, but all the KD prints will likely slow down the system a lot (unfortunately it doesn't seem possible to disable a component when using WIN2000 to enable them all)

If you need to enable components before your build is installed (eg. kernel is having problems before setup is completed), you'll need to edit the <code>mergedcomponents\setupinfs\hivesys.inx</code> file, anon made a post about that here, though it hasn't been tried yet afaik.

=== x64 build OS support ===
prepatched.zip v9 adds support for using x64 build OS's such as Win10 x64, this is done by wrapping certain 16-bit tools using <code>MS-DOS Player</code>, using .bat files to redirect calls to use the player, changing some makefiles to use 32-bit equivalents, etc.

Unfortunately some of the wrapped 16-bit tools can still randomly error without rhyme or reason for it, as a workaround the .bat files of the worst offenders will give it 5 attempts before failing, hopefully this should be enough to allow builds to complete fine, but there's still a chance one of the other 16-bit tools could error too... maybe in future I'll apply this 5-attempts bandaid over all the 16-bit tools.

Huge thanks to the anon who initially worked on fixing the 16-bit tools over at <nowiki>https://rentry.co/16bit-msbuild</nowiki>!

=== amd64 build support ===
As of update v10 an amd64 build can be created by initialising razzle with the <code>win64 amd64</code> options, the build should mostly complete without errors, but note that postbuild+ hasn't been updated at all to work properly with amd64 yet.

Unfortunately as the leak didn't come with exinit.obj/systime.obj for amd64 these need to be built from anon's decompilations instead. v10a adds newer exinit.c/systime.c decompilations that are apparently an exact match to the x86 .obj files included in the leak, hopefully these should work well with other architectures too.

Some anons have been slowly working on amd64, being able to get past text-mode setup and start booting GUI-mode setup, though sadly as of this release nobody has been able to actually get GUI mode to fully start up.

Note that this source code is from around ~2 years before amd64 was officially released by MS as Server2003 SP1, so there's likely a lot missing. (WRK may have some newer kernel-mode parts, being both based on SP1 and including support for amd64, though note that WRK also has many things removed too...)

However there's also many indications in the leak that MS did have amd64 running at this point, so it should eventually be possible for us to get it working too.

=== Timebomb ===

* Time can be adjusted by editing <code>DAYS</code> variable inside <code>\tools\postbuildscripts\timebomb.cmd</code> (line 44)
* Setting <code>DAYS</code> to <code>0</code> will disable the timebomb.
* Only certain <code>DAYS</code> parameters are valid (0, 5, 15, 30, 60, 90, 120, 150, 180, 240, 360, 444)

=== Different build options ===
You can modify your razzle shortcut (or execute it manually inside your source folder) to include (or remove) additional argument(s):

* <code>free</code> - build 'free' bits (production, omitting it will generated checked bits)
* <code>chkkernel</code> - build 'checked' (testing) kernel/hal/ntdll when building 'free' bits
* <code>no_opts</code> - disable binary optimization (useful for debugging, but will most likely fail a full build, some code can't be built without optimization)
* <code>verbose</code> - enable verbose output of the build process
* <code>binaries_dir <basepath></code> - specifies custom output directory (default is <code>binaries</code>, the suffix added after <code>.</code> is non-customizable)
* <code>officialbuild</code> - sets razzle to build this as an "official" build, requires updating BuildMachines.txt, see the section below
* <code>win64</code> - builds for Intel Itanium-64 machines
* <code>win64 amd64</code> - builds for amd64 instead of x86, see <code>amd64 build support</code> section above
* <code>pocketpc</code> - builds for ARMv4 targets. Currently there are no any supportive headers and libraries for AMD clients, and work is undergoing.

Other options are not described here, see <code>razzle.cmd /?</code> for details.

=== 'OfficialBuild' parameter / BuildMachines.txt ===
The <code>OfficialBuild</code> razzle parameter changes a few things in the build, which will make it match up closer to the retail builds, should be useful if you need to compare against retail for any reason.

For a list of things affected by the OfficialBuild parameter see <nowiki>https://pastebin.com/VgVph3Xv</nowiki> & <nowiki>https://pastebin.com/gYzWGLM5</nowiki>, thanks to the anon that compiled them! (note that these aren't complete lists, and not all things mentioned here are guaranteed to take effect).

'''However, using this parameter requires a file to be updated with info about your build machine first!'''

An easy way to update the file required is to run the following command inside a razzle window, at the root of the source tree:

<code>echo %COMPUTERNAME%,primary,%_BuildBranch%,%_BuildArch%,%_BuildType%,ntblus >> tools\BuildMachines.txt</code>

After that you can run <code>tools\verifybuildmachine</code> to make sure it was setup correctly, if there's any problem an error message will show, otherwise the command will return without any message.

With that in place you should now be able to use the <code>OfficialBuild</code> parameter next time you init razzle, eg. <code>tools\razzle.cmd free offline officialbuild</code>

Some small notes to be aware of:

* if you change build arch or build type (eg. to amd64, or to a checked build) you'll need to run the echo command again to add your machine for that build arch/type combination
* if you see <code>Clearing OFFICIAL_BUILD_MACHINE variable</code> after initializing razzle, rerun the echo command and then close down/re-initalize razzle again, else the build won't properly count itself as official.

=== Building specific components ===
Most components can be built seperately. For example, if you wish to rebuild <code>ntos</code> component, perform these steps:

* <code>cd base\ntos</code> (you can also use <code>ntos</code> alias that razzle has set up for you)
* <code>bcz</code> (alias for <code>build /cPZ</code>)

Generally <code>postbuild.cmd</code> is clever enough to include your changes properly without needing fresh build as it uses <code>bindiff</code> to find differences.

=== Generating new build number/name ===
Version information is stored in <code>\public\sdk\inc\ntverp.h</code>

You can also use <code>m0 set_builddate set_buildnum set_buildname</code> to generate new build name quickly.

=== Original CD filenames ===

* <code>5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-standard_retail_en-us-NRMSFPP_EN.iso</code> (SHA1: A600409482A5678EF6AF2B26D3576D6D9894178D)
* <code>5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-datacenter_retail_en-us-NRMDOEM_EN.iso</code> (SHA1: E2B47A7CE45C6C6305594CEE4C1B64894805AAF4)
* <code>5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-enterpriseserver_retail_en-us-NRMEFPP_EN.iso</code> (SHA1: 0309FFB4181BA5122C692A6E1079E9FC1D53FCE4)
* <code>5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-webserver_retail_en-us-NRMWFPP_EN.iso</code> (SHA1: 46C1CCB2CFC96803E304A35BEF50CD71B2C1DE38)
* <code>sbs.iso</code> (converted from mdf; SHA1: CDB30C80FDE314C16CA11F5CD31650ECBEC7A214)
* <code>5.2.3790.0.srv03_rtm.030324-2048_x86chk_server-enterpriseserver_retail_en-us-NRMECHK_EN.iso</code> (SHA1: EEF5F921CC8FC20FB29A862E1E132359E0D151BB)
* <code>5.2.3790.1830.srv03_sp1_rtm.050324-1447_amd64fre_server-enterprise_retail_en-us-ARMEXFPP_EN.iso</code> (SHA1: 076EDCF017EDE0B2D0D8067FA52CF3D44EEEF79A)
* <code>5.2.3790.1830.srv03_sp1_rtm.050324-1447_amd64chk_server-enterprise_retail_en-us-AX2EXCFPP_EN.iso</code> (SHA1: 8916DFBB1D93A9CECB1FE8600BE2E2C752E85E7F)
* <code>5.1.2600.0.xpclient.010817-1148_x86fre_client-home_retail_en-us-WXHFPP_EN.iso</code> (SHA1: B273C8D41E3844E3E46722F52F5A4CF9F206C8D0)
* <code>5.1.2600.0.xpclient.010817-1148_x86fre_client-professional_retail_en-us-WXPFPP_EN.iso</code> (SHA1: 1400DED4402D50F3864ED3D8DCF5CC52BA79A04A)
* <code>5.1.2600.0.xpclient.010817-1148_x86chk_client-professional_retail_en-us-WXPFPP_EN.iso</code> (SHA1: 017F10E4555D1A9280874B9B0243442F045F1B2D)

=== Product keys ===

* Evaluation (for all editions, if you set a timebomb. Default it set to 360 days):
** <code>99999-99999-99999-99999-99999</code>
** <code>DDDDD-DDDDD-DDDDD-DDDDD-DDDDD</code>
* Standard Edition: <code>M6RJ9-TBJH3-9DDXM-4VX9Q-K8M8M</code>
* Enterprise Edition: <code>QW32K-48T2T-3D2PJ-DXBWY-C6WRJ</code>
* Enterprise Edition (x64): <code>KK2WD-BFYJ6-77X87-8TRBF-9B343</code>

[[Category:Development]]

Build

2025-08-19T17:21:06Z

Ashific: buildX

This guide tested under Windows XP, 7 SP1, 8.1 & 10 x86/x64, results may vary under other operating systems (if you will copy/paste source code at many times). For legacy version of the guide visit [https://rentry.co/build-win2k3 build-win2k3].

== Preparing for Build ==

* Disable any AV (and Windows Defender) before extracting and building, as both of those actions create a lot of new files, and AV scans for execution of them all - this also counts for any other tools that monitor files, such as voidtools' Everything, but they aren't impacting much as your antivirus does.
* Also disable User Account Control. This can be accomplished via Control Panel, or via Registry Key: navigate to <code>HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System</code> and set <code>EnableLUA</code> to <code>0</code>. Some versions may require restart after registry apply.
* Extract source tree to a folder named <code>srv03rtm</code> on the root of a drive, drive letter doesn't seem to matter (just don't use C:\ drive as that has some extra security). It is recommended to use <code>D:\srv03rtm\</code> as the path to match RTM binaries.

=== For 2000/XP/2003 Users ===
Before initializing Razzle, it's mandatory to install .NET Framework 1.1, because without it Razzle will fail to initialize environment normally (despite that two versions of .NET 1.1 are included in <code>tools\x86</code>). The installer is included at <code>tools\prereq</code>.

=== Running environment ===

* Run command-prompt as administrator (can usually be done by typing <code>cmd</code> into start menu, right click <code>Command Prompt</code> -> <code>Run as administrator</code>)
* In the command-prompt, change to the source folder: <code>cd /d D:\srv03rtm</code>
* Now start razzle: <code>tools\razzle.cmd free offline</code> for 32-bit clients, and <code>tools\razzle64.cmd free offline</code> for 64-bits. This initiates retail build of x86. The first time you run razzle inside that copy of the source code it'll need to initialize a few things, give it a few minutes, after a while a Notepad window will appear - make sure to close this for the initialization to continue.
* '''Important for first time!''' Run the prebuild script, if you're initiating source code for first time: <code>tools\prebuild</code>. This scripts sets all read-only attributes for necessary stuff and makes 16-bit stuff workable for x64 environments.

=== Build ===
Start to build via <code>build /cZP</code> or <code>bcz</code> (which is alias to first, so doesn't matter). '''Important:''' Build.exe doesn't seem to play well when building with many (up to 8) threads. If your build machine has more than that it's recommended to cap it to 8 threads maximum via the <code>-M 8</code> switch, added to the build command (eg. <code>build /cZP -M 8</code>, or <code>bcz -M 8</code>). Use 8 threads if your host/virtual machine CPU have allocated 8 cores (or less). More than 8 threads build may lead to unforeseen behavior, such as inconsistent linkage and invalid generation of pieces of code, since some build programs were written back at time when CPUs should be limited in order to preserve proper frequency.

As an alternative, you can use <code>tools\buildx.cmd</code> script, which allows to build not only retail (fre) and debug (checked, or chk) builds, but also profile and meter builds, additionally by disabling compiler optimizations and specifically building for AMD64/IA64 architectures. The purpose of profile and meter builds is in investigations, as of time of guide enhancement.

=== Post-build ===

* Download the Missing Binaries pack, which contains missing binaries both for AMD64 and x86 builds.
* From that 7z, extract the contents of the binaries folder for the build type you're building into your build trees binaries folder (eg. <code>D:\binaries.x86fre</code>, should have been created during the build), the 7z should contain files for all SKUs (uses pidgen.dll from Win2003 Enterprise, so your builds should accept Enterprise product keys), '''When asked during extraction to overwrite folders select <code>Yes</code>, but when asked to overwrite files, make sure to select <code>No</code>!'''
* Inside the razzle window run <code>tools\postbuild</code> (use <code>-sku:{sku}</code> if you want to process only specific one (no brackets!), expect <code>filechk</code> errors if you ignore this and didn't use missing.7z / missing.cmd with every sku). For first time you can use <code>tools\postbuild -full</code>, altrough it isn't necessary.

==== Issues ====

* Once postbuild has finished, assuming you used the <code>misbin.7z</code> file above and followed the guide properly, it should have hopefully succeeded without errors, and there shouldn't be any <code>binaries.x86fre\build_logs\postbuild.err</code> file!
* Otherwise take a look inside the <code>postbuild.err</code> - most messages in here are negligible, but if you see <code>filechk</code> errors associated with the edition you want to use, you may need to re-run <code>tools\missing.cmd</code>, or extract <code>misbin.7z</code> again.
* If <code>postbuild.err</code> contains messages like <code>(crypto.cmd) ERROR</code> or <code>(ntsign.cmd) ERROR</code> try re-importing the <code>tools\driver.pfx</code> key-file (double-click it, press Next through the prompts, password is empty), and make sure your system date is set to the current date.
* If postbuild.err has filechk errors about missing <code>hwcomp.dat</code> files, try copying the following into a batch script and run it in a razzle prompt (after using postbuild once already)<syntaxhighlight lang="bat" line="1">
@echo off
hwdatgen -i:%_NTPOSTBLD%\pro\i386 -o:%_NTPOSTBLD%\.\hwcomp.dat
hwdatgen -i:%_NTPOSTBLD%\per\i386 -o:%_NTPOSTBLD%\perinf\hwcomp.dat
hwdatgen -i:%_NTPOSTBLD%\bla\i386 -o:%_NTPOSTBLD%\blainf\hwcomp.dat
hwdatgen -i:%_NTPOSTBLD%\sbs\i386 -o:%_NTPOSTBLD%\sbsinf\hwcomp.dat
hwdatgen -i:%_NTPOSTBLD%\srv\i386 -o:%_NTPOSTBLD%\srvinf\hwcomp.dat
hwdatgen -i:%_NTPOSTBLD%\ads\i386 -o:%_NTPOSTBLD%\entinf\hwcomp.dat
</syntaxhighlight>

=== Creating ISO files ===

* Execute <code>tools\oscdimg {sku} [destination-file (optional)]</code> where <code>{sku}</code> is one of:
** <code>srv</code> - Windows Server 2003 Standard Edition
** <code>sbs</code> - Windows Server 2003 Small Business Edition
** <code>ads</code> - Windows Server 2003 Enterprise Edition
** <code>dtc</code> - Windows Server 2003 Datacenter Edition
** <code>bla</code> - Windows Server 2003 Web Edition
** <code>per</code> - Windows XP Home Edition
** <code>pro</code> - Windows XP Professional
** <code>winpe</code> - Windows Preinstallation Environment
* ISO will be saved to <code>{build-drive}\{build-tag}_{sku}.iso</code>, unless <code>[destination-file]</code> is provided as a parameter.

=== Troubleshooting ===
If you get any problems during the build hopefully your problem might be answered here, if it's not feel free to post in the thread.

====== Certificate Import Wizard: An internal error occurred... ======
It's likely your PFX certificate isn't generated properly and you need to regenerate them. For that you should follow these steps:

* Check out the <code>tools\prereq</code> and install from there <code>MSYS 1.0.11.exe</code>, then hop up into your architecture folder (x32 or x64) and install <code>VC_redist</code> and then <code>OpenSSL</code>. Make sure OpenSSL is in your path (cause installer doesn't set it by default).
* Download the zip or do a <code>git clone</code> of CertUtil repository, or regenerate them using the original guide.
* Open MSYS and switch to directory where you extracted/cloned the repo.
* Attach all attributes via <code>chmod -r 0777 *</code> and convert .sh to UNIX format with <code>dos2unix *.sh</code>
* Execute <code>./generate.sh</code>
* Copy the files from <code>srv03rtm.certs</code> into source code tree (<code>D:\srv03rtm</code>)

====== After running razzle it shows a bunch of errors, "tfindcer not recognized" etc ======
You're likely on a 64-bit system but running <code>razzle.cmd</code> directly, you should use <code>razzle64.cmd</code> instead, this'll set things up so that razzle will use the correct tools for you. Hopefully with that the <code>tfindcer not recognized</code> & other errors should go away.

====== After a full build I get 1000+ errors, build.err has <code>has bad storage class</code> errors inside ======
Seems to be caused by your locale, this is reported to happen with Simplified Chinese language, but can probably happen with other languages too.

Besides changing your locale/language settings, you could also try editing the source files to remove the characters that cause problems, an anon posted a list of the files that need changes here

====== I get a <code>TAPI.RES</code> error during the build. ======
Try moving your source code folder closer to the root of the drive, ideally it should only be one folder up from the drive root (eg. <code>D:\srv03rtm\</code>)

====== On Windows 7 and later I get NTVDM crashes while building ======
All NTVDM errors should have hopefully been solved in the v8 release of this guide/ZIP, but if you still run into any NTVDM error a copy of your build.log file would help a lot to figure out what caused it, if you ZIP that up and post in the thread hopefully we can figure something out. We consider to build code on Windows 10 build 1809 or newer, or use operating systems up to Windows Vista.

== Debugging ==
Kernel debugging can be enabled by editing the <code>C:\boot.ini</code> file in your installed build, and adding <code>/debug /debugport=COM1 /baudrate=115200</code> to the end of a config line.

For example here's a boot.ini with two choices, one with debugging & one without, with this NTLDR will show an OS boot choice menu at startup:<blockquote>[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /debug /debugport=COM1 /baudrate=115200</blockquote>(even though they're named the same <code>Windows Server 2003, Enterprise</code>, NTLDR will add a <code>[debugger enabled]</code> tag to it on the OS selection menu.)

<code>chk (checked)</code> builds are preferred for debugging as they enable asserts & debug messages, though <code>chk</code> will run a lot slower than <code>fre</code> builds. <code>fre</code> builds can also be debugged fine, but usually with a lot less debug output.

Ideally you should also configure WinDbg to use the <code>binaries.{buildtype}\symbols.pri\retail</code> & <code>binaries.{buildtype}\symbols\retail</code> symbols folders too, if WinDbg is running on the same machine that compiled the build it should then also be able to do source-level debugging against the actual source files.

Note that if you're using a VM to host your build on you'll have to pass-through the emulated COM port over to a pipe somehow, for WinDbg/KD/IDA/etc to make use of.

There is apparently a way to get KDNET working on 2003 too (see <nowiki>https://github.com/MovAX0xDEAD/KDNET</nowiki>), but this is as-of-yet untested with our builds, seems like it should have support for VMware's emulated network hardware at least.

(TODO: add more VM guides here... if anyone wants to post one in the thread I'm happy to add it here)

=== VMware setup ===

* For a VMware VM, just open the VM hardware options, '''remove the printer hardware''', then click <code>Add...</code> and choose <code>Serial Port</code>.
* In the serial-port config panel, set it to <code>Use named pipe</code>, and enter a pipe name into the textbox, eg. <code>\\.\pipe\vm</code>. The pipe should be setup as <code>This end is the server</code> & <code>The other end is a virtual machine</code>.
* It's apparently recommended to use the <code>Yield CPU on poll</code> option, but I've had success without it, it's up to you.
* With that setup now just open WinDbg, choose <code>Attach to kernel</code>, open the <code>COM</code> tab and enter the baud-rate and pipe name you selected for your VM, then hit OK.
* Now WinDbg should start with <code>Waiting for reconnect</code> text showing, and hopefully when you next boot up your VM it'll connect up to WinDbg by itself.

=== Debugging Setup/Installation ===
A debugger can be attached to setup by pressing F8 at the right time - for text-mode setup the right time is when asked <code>Press F6 if you need to install a third party SCSI or RAID driver</code>, spamming it while that message is showing should make it connect to COM1 with 19200 baud-rate (debug options can be changed inside <code>txtsetup.sif</code>, the <code>SetupDebugOptions</code> line specifies options to apply when F8 is pressed). After debug connection is made it might take a couple extra minutes for it to pass the <code>Setup is starting Windows</code> stage.

Similarly, GUI setup can be debugged by pressing F8 before the Windows bootloader starts (progress bar etc), this should bring up a menu with options for <code>Safe Mode</code>, <code>Debugging Mode</code>, etc. Choosing <code>Debugging Mode</code> will make it attach to COM1 before starting setup, again at 19200 baudrate.

=== Changing default baudrate ===
The default 19200 baudrate can be changed by editing the <code>base\boot\kdcom\xxkdsup.c</code> file, search for <code>BD_19200</code> inside there and change it to e.g. <code>BD_115200</code>, now it should use that by default without needing any <code>/baudrate</code> parameter, or eg. when using <code>Debugging Mode</code> from the boot options menu.

=== Un-filtering kernel messages ===
Even with a chk build you may notice that the kernel doesn't seem to output much over KD, this seems to be because most of the kernel components use <code>KdPrintEx</code>, which allows filtering KD messages to certain components (although MS's docs seem to suggest KdPrintEx filtering was only used in Vista, it does seem that 2003 makes use of it too)

To enable components you'll need to open the registry of your installed build to the following key (or create it if it doesn't exist)<blockquote>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter</blockquote>Then create a DWORD value named the component you want to enable (eg. <code>LDR</code>), and set the value to hexadecimal <code>FFFFFFFF</code>.

A list of the component registry names can be found inside <code>base\published\obj\i386\dpfiltercm.c</code> after a build. This also contains the symbol names for the component (eg. <code>Kd_LDR_Mask</code>), which can be set directly through WinDbg/KD via the symbol name. (eg. <code>ed nt!Kd_LDR_Mask 0xFFFFFFFF</code>, with symbols loaded this should set the LDR components filter value in real-time)

The <code>WIN2000</code> components value (default <code>1</code>) is added to every components value, essentially making <code>WIN2000</code> the default value for all components - so setting this to <code>FFFFFFFF</code> should make every component print to KD. You'll get a ton more debug output from this, but all the KD prints will likely slow down the system a lot (unfortunately it doesn't seem possible to disable a component when using WIN2000 to enable them all)

If you need to enable components before your build is installed (eg. kernel is having problems before setup is completed), you'll need to edit the <code>mergedcomponents\setupinfs\hivesys.inx</code> file, anon made a post about that here, though it hasn't been tried yet afaik.

=== x64 build OS support ===
prepatched.zip v9 adds support for using x64 build OS's such as Win10 x64, this is done by wrapping certain 16-bit tools using <code>MS-DOS Player</code>, using .bat files to redirect calls to use the player, changing some makefiles to use 32-bit equivalents, etc.

Unfortunately some of the wrapped 16-bit tools can still randomly error without rhyme or reason for it, as a workaround the .bat files of the worst offenders will give it 5 attempts before failing, hopefully this should be enough to allow builds to complete fine, but there's still a chance one of the other 16-bit tools could error too... maybe in future I'll apply this 5-attempts bandaid over all the 16-bit tools.

Huge thanks to the anon who initially worked on fixing the 16-bit tools over at <nowiki>https://rentry.co/16bit-msbuild</nowiki>!

=== amd64 build support ===
As of update v10 an amd64 build can be created by initialising razzle with the <code>win64 amd64</code> options, the build should mostly complete without errors, but note that postbuild+ hasn't been updated at all to work properly with amd64 yet.

Unfortunately as the leak didn't come with exinit.obj/systime.obj for amd64 these need to be built from anon's decompilations instead. v10a adds newer exinit.c/systime.c decompilations that are apparently an exact match to the x86 .obj files included in the leak, hopefully these should work well with other architectures too.

Some anons have been slowly working on amd64, being able to get past text-mode setup and start booting GUI-mode setup, though sadly as of this release nobody has been able to actually get GUI mode to fully start up.

Note that this source code is from around ~2 years before amd64 was officially released by MS as Server2003 SP1, so there's likely a lot missing. (WRK may have some newer kernel-mode parts, being both based on SP1 and including support for amd64, though note that WRK also has many things removed too...)

However there's also many indications in the leak that MS did have amd64 running at this point, so it should eventually be possible for us to get it working too.

=== Timebomb ===

* Time can be adjusted by editing <code>DAYS</code> variable inside <code>\tools\postbuildscripts\timebomb.cmd</code> (line 44)
* Setting <code>DAYS</code> to <code>0</code> will disable the timebomb.
* Only certain <code>DAYS</code> parameters are valid (0, 5, 15, 30, 60, 90, 120, 150, 180, 240, 360, 444)

=== Different build options ===
You can modify your razzle shortcut (or execute it manually inside your source folder) to include (or remove) additional argument(s):

* <code>free</code> - build 'free' bits (production, omitting it will generated checked bits)
* <code>chkkernel</code> - build 'checked' (testing) kernel/hal/ntdll when building 'free' bits
* <code>no_opts</code> - disable binary optimization (useful for debugging, but will most likely fail a full build, some code can't be built without optimization)
* <code>verbose</code> - enable verbose output of the build process
* <code>binaries_dir <basepath></code> - specifies custom output directory (default is <code>binaries</code>, the suffix added after <code>.</code> is non-customizable)
* <code>officialbuild</code> - sets razzle to build this as an "official" build, requires updating BuildMachines.txt, see the section below
* <code>win64</code> - builds for Intel Itanium-64 machines
* <code>win64 amd64</code> - builds for amd64 instead of x86, see <code>amd64 build support</code> section above
* <code>pocketpc</code> - builds for ARMv4 targets. Currently there are no any supportive headers and libraries for AMD clients, and work is undergoing.

Other options are not described here, see <code>razzle.cmd /?</code> for details.

=== 'OfficialBuild' parameter / BuildMachines.txt ===
The <code>OfficialBuild</code> razzle parameter changes a few things in the build, which will make it match up closer to the retail builds, should be useful if you need to compare against retail for any reason.

For a list of things affected by the OfficialBuild parameter see <nowiki>https://pastebin.com/VgVph3Xv</nowiki> & <nowiki>https://pastebin.com/gYzWGLM5</nowiki>, thanks to the anon that compiled them! (note that these aren't complete lists, and not all things mentioned here are guaranteed to take effect).

'''However, using this parameter requires a file to be updated with info about your build machine first!'''

An easy way to update the file required is to run the following command inside a razzle window, at the root of the source tree:

<code>echo %COMPUTERNAME%,primary,%_BuildBranch%,%_BuildArch%,%_BuildType%,ntblus >> tools\BuildMachines.txt</code>

After that you can run <code>tools\verifybuildmachine</code> to make sure it was setup correctly, if there's any problem an error message will show, otherwise the command will return without any message.

With that in place you should now be able to use the <code>OfficialBuild</code> parameter next time you init razzle, eg. <code>tools\razzle.cmd free offline officialbuild</code>

Some small notes to be aware of:

* if you change build arch or build type (eg. to amd64, or to a checked build) you'll need to run the echo command again to add your machine for that build arch/type combination
* if you see <code>Clearing OFFICIAL_BUILD_MACHINE variable</code> after initializing razzle, rerun the echo command and then close down/re-initalize razzle again, else the build won't properly count itself as official.

=== Building specific components ===
Most components can be built seperately. For example, if you wish to rebuild <code>ntos</code> component, perform these steps:

* <code>cd base\ntos</code> (you can also use <code>ntos</code> alias that razzle has set up for you)
* <code>bcz</code> (alias for <code>build /cPZ</code>)

Generally <code>postbuild.cmd</code> is clever enough to include your changes properly without needing fresh build as it uses <code>bindiff</code> to find differences.

=== Generating new build number/name ===
Version information is stored in <code>\public\sdk\inc\ntverp.h</code>

You can also use <code>m0 set_builddate set_buildnum set_buildname</code> to generate new build name quickly.

=== Original CD filenames ===

* <code>5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-standard_retail_en-us-NRMSFPP_EN.iso</code> (SHA1: A600409482A5678EF6AF2B26D3576D6D9894178D)
* <code>5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-datacenter_retail_en-us-NRMDOEM_EN.iso</code> (SHA1: E2B47A7CE45C6C6305594CEE4C1B64894805AAF4)
* <code>5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-enterpriseserver_retail_en-us-NRMEFPP_EN.iso</code> (SHA1: 0309FFB4181BA5122C692A6E1079E9FC1D53FCE4)
* <code>5.2.3790.0.srv03_rtm.030324-2048_x86fre_server-webserver_retail_en-us-NRMWFPP_EN.iso</code> (SHA1: 46C1CCB2CFC96803E304A35BEF50CD71B2C1DE38)
* <code>sbs.iso</code> (converted from mdf; SHA1: CDB30C80FDE314C16CA11F5CD31650ECBEC7A214)
* <code>5.2.3790.0.srv03_rtm.030324-2048_x86chk_server-enterpriseserver_retail_en-us-NRMECHK_EN.iso</code> (SHA1: EEF5F921CC8FC20FB29A862E1E132359E0D151BB)
* <code>5.2.3790.1830.srv03_sp1_rtm.050324-1447_amd64fre_server-enterprise_retail_en-us-ARMEXFPP_EN.iso</code> (SHA1: 076EDCF017EDE0B2D0D8067FA52CF3D44EEEF79A)
* <code>5.2.3790.1830.srv03_sp1_rtm.050324-1447_amd64chk_server-enterprise_retail_en-us-AX2EXCFPP_EN.iso</code> (SHA1: 8916DFBB1D93A9CECB1FE8600BE2E2C752E85E7F)
* <code>5.1.2600.0.xpclient.010817-1148_x86fre_client-home_retail_en-us-WXHFPP_EN.iso</code> (SHA1: B273C8D41E3844E3E46722F52F5A4CF9F206C8D0)
* <code>5.1.2600.0.xpclient.010817-1148_x86fre_client-professional_retail_en-us-WXPFPP_EN.iso</code> (SHA1: 1400DED4402D50F3864ED3D8DCF5CC52BA79A04A)
* <code>5.1.2600.0.xpclient.010817-1148_x86chk_client-professional_retail_en-us-WXPFPP_EN.iso</code> (SHA1: 017F10E4555D1A9280874B9B0243442F045F1B2D)

=== Product keys ===

* Evaluation (for all editions, if you set a timebomb. Default it set to 360 days):
** <code>99999-99999-99999-99999-99999</code>
** <code>DDDDD-DDDDD-DDDDD-DDDDD-DDDDD</code>
* Standard Edition: <code>M6RJ9-TBJH3-9DDXM-4VX9Q-K8M8M</code>
* Enterprise Edition: <code>QW32K-48T2T-3D2PJ-DXBWY-C6WRJ</code>
* Enterprise Edition (x64): <code>KK2WD-BFYJ6-77X87-8TRBF-9B343</code>

[[Category:Development]]

2025-07-19T07:59:37Z

Ashific: ported my article, which will be improved HERE

Category:NT OS/2

2025-07-05T14:03:21Z

Ashific: Created page with "Articles here are related to NT OS/2 Design Workbook, a book which references all internal capabilities and technical descriptions of original NT kernel. The hardcopy have been released to Smithsonian Institute, therefore the digital iteration have been published with Windows Research Kernel for non-commercial and academic use under the latter agreement."

Articles here are related to [[NT OS/2]] Design Workbook, a book which references all internal capabilities and technical descriptions of original NT kernel. The hardcopy have been released to Smithsonian Institute, therefore the digital iteration have been published with Windows Research Kernel for non-commercial and academic use under the latter agreement.

NT OS/2

2025-07-05T13:58:35Z

Ashific: Created page with "The '''NT OS/2''' system is a portable implementation of OS/2 developed in a high-level language. The initial release of NT OS/2 is targeted for Intel 860-based hardware, which includes both personal computers (''Frazzle'') and servers (''Dazzle''). The first systems based on a RISC microprocessor will be available for testing in the fall of 1990. The ultimate goal of the NT OS/2 project is to develop a portable implementation of OS/2 executing on the Intel 860 and to e..."

The '''NT OS/2''' system is a portable implementation of OS/2 developed in a high-level language. The initial release of NT OS/2 is targeted for Intel 860-based hardware, which includes both personal computers (''Frazzle'') and servers (''Dazzle''). The first systems based on a RISC microprocessor will be available for testing in the fall of 1990.

The ultimate goal of the NT OS/2 project is to develop a portable implementation of OS/2 executing on the Intel 860 and to establish this combination of hardware and software as the standard for high-performance personal computers and server systems.

== Goals ==
NT OS/2 has the following overall project goals (though not all these goals will be attained by the first implementation of NT OS/2):

* Portability to a variety of hardware architectures. Though the first implementation is targeted to the Intel 860, the overall system design isolates the machine-dependent portions for portability to other architectures.
* Support for multiple processors with shared memory via symmetric multiprocessing. This provides performance improvements for multiprocessor workstations and servers.
* Compatibility with the OS/2 V2.0 32-bit application programming interface (API). Because the initial target system is not an Intel x86 architecture, all applications will have to be recompiled and relinked. In addition, any assembly language code will have to be rewritten or converted to a higher level language such as C.
* Security at the C2 level with future versions achieving higher levels of security. This includes login/logout options on the personal computer and the server system, and declaration and enforcement of protection attributes for shareable resources (files, IPC, memory objects, etc.).
* Support for a POSIX-compliant API interface that passes the POSIX validation suites.
* Support for internationalization.
* Support for LANMAN networking and management of personal computers and servers.
* Support for the current Presentation Manager API running in both the OS/2 environment and the POSIX environment.
* Support for distributed applications. The network is integrated into the system to allow transparent distribution of applications and services within a network.
* Support for object-oriented file systems and object-oriented presentation manager.
* Easy extensibility by layering new features on the existing system without modifying the underlying system.
* Simultaneous execution by multiple users, each with a unique security profile.
* Interoperability and data interchange between OS/2 and POSIX applications.
* High reliability that prevents errant user programs from causing a system crash or exhausting system-wide resources. Resource quotas, a protected kernel, and protected objects are used to improve reliability.

== Components ==
NT OS/2 consists of a highly integrated kernel / executive that executes in kernel mode. It provides the necessary services to allow the emulation of OS/2 and POSIX APIs via protected subsystems executing in user mode. Both the OS/2 and POSIX subsystems provide these services through remote procedure calls from a client to the server subsystem. The server subsystem, in turn, emulates the desired operation locally or by calling the executive, and returns the results to the caller. The following diagram illustrates the structure of NT OS/2.

=== Functional Specifications ===
The following specifications are contained within this design workbook. Each specification contains an abstract of the component it describes, how that component fits into the system, the various APIs that are used to access the functionality, and enough detail to ensure the defined capability can be implemented.

The goal of the specifications is to allow someone to understand the functionality provided by a particular piece of the system. It is NOT a goal to describe the actual implementation.

Each specification addresses Cruiser and POSIX compatibility, if appropriate. The following is a list of design specifications included in this version of the workbook:

# Kernel - Describes the function of the kernel, the objects implemented, and the various interfaces provided to manipulate these objects. This specification contains implementation details, where necessary, to reveal how multiprocessing and processor dispatching take place. This specification also describes synchronization, scheduling/dispatching, and Asynchronous Procedure Calls (APCs).
# Object Management - Describes how the executive deals with objects, what they are for, how they are protected, how they are named, how they are allocated, how they are accounted for, and how they are deleted. This specification also addresses object directories and how to access them using the file system directory operations.
# Process Structure - Describes the process and thread objects and the operations that can be performed on them. This specification also explains signals and how OS/2 compatibility and POSIX compliance are addressed.
# Virtual Memory - Describes the virtual memory objects and the operations that can be performed on these objects.
# I/O Management - Describes the APIs and objects available for I/O operations.
# Security - Describes how security is provided in the system, the ACL format, ACL access checking rules, login/logout, the authorization file, and the partial closure of covert channels. This specification also describes audit and alarm logging.
# Local Process Communication - Describes the client/server protected subsystem model, client impersonation, port objects, and connection/disconnection operations.
# Remote Procedure Call - Describes a transport-independent interface to remote procedure calls.
# Session Manager - Describes how the subsystems for OS/2 and POSIX are created, and how they interact with each other.
# File System - Describes the file systems, how they are put together, the functions they perform, and how they accomplish the tasks that they are given.
# Semaphores and Events - Describes the APIs and objects available for synchronization.
# Argument Validation - Describes the argument probing and capture requirements for system services.
# Timers - Describes the timer object, which is used to mark time, and the functions available to manipulate it.
# Coding Guidelines - Describes the naming and structure of NT OS/2 code.
# LAN Manager Software - Describes the network capabilities of the system, how network drivers fit together, and how the protocol stacks are managed.
# Exceptions - Describes the dispatching of hardware exceptions to the condition dispatcher and the arguments that accompany each exception. It also explains guard page handling, automatic stack expansion, and access violations on the user stack, as well as how signals are handled at the user level.
# OS/2 Emulation Subsystem - Describes the requirements and methods used to design and build the OS/2 emulation subsystem.
# Status values - Describes the format for status values return by NT OS/2 APIs.
# Subsystem Design Rational - Describes the rationale for designing OS/2 and POSIX emulation as subsystems as opposed to supporting the APIs directly in the executive.
# Shared Resource Specification - Describes the routines that implement multiple-readers, single-writer access to a share resource.
# Executive Support Routines - Describes executive support routines which are available in kernel mode and not documented in other chapters.
# Driver Model - Describes the device driver model, how I/O is managed throughout the system, how the file system and network capabilities fit into the system, and the objects and operations that are available to help manage the I/O system. It also presents I/O validation, queueing, page lockdown, double mapping, I/O completion, and error logging.
# POSIX Emulation Subsystem - Describes the requirements and methods used to design and build the POSIX emulation subsystem.
# Time Conversion Specification - Describes the APIs available for viewing time and converting to and from different formats.
# Mutant Specification - Describes the mutant object and services which operate upon the object.
# Transport Driver Interface - Describes the interface for the network transport layer.
# Network Driver Interface Specification - Describes the interface for the network physical layer.
# Lan Manager Server - Describes the design of the Lan Manager server and the operations supported.
# C Structured Exception Handling - Describes the extensions to C in the MS 860 compiler to support structured exception handling.
# NT C User's Guide - Describes the command syntax and language issues for the MS 860 C compiler.
# Prefix Table - Describes the prefix table package.
# System Startup Design Note - Describes system startup after phase one initialization.
# Debug Architecture - Describes the debug architecture for NT OS/2.
# Linker/Librarian - Describes the NT OS/2 linker, librarian, and image format.
# Caching Design Note - Describes the system-wide file caching implementation.
# Utility Design Specification - Describes the basic support routines for NT OS/2 utilities.
# OS/2 Environment Subsection Security - Describes the security features of the OS/2 environment subsystem.
# Security Account Manager Protected Server - Describes the security account manager which maintains user and group account information.

[[Category:NT OS/2]]

Category:OneCore API

2025-06-28T06:23:25Z

Ashific: Created page with "This is the category for OneCore API and it's affiliate projects."

This is the category for [[OneCore API]] and it's affiliate projects.

OneCore API

2025-06-28T06:23:07Z

Ashific:

'''OneCore API''' is an extended wrapper to Windows XP/Server 2003 operating systems, intended for adding compatibility and missing functionality from later versions of Windows. Project is based on ReactOS, and uses the latter's build environment. As a result, project is compatible with Windows Server 2003 SP2, Windows XP SP3 and Windows XP x64 SP2.

OneCore API was created in 2016 by Skulltrail as a part of Shorthorn Project, which later started to dynamically grow up into separate one.

== Description ==
OneCore API aims to extend compatibility with later versions of Windows, including Vista, 7, 8(.1) and beyond. By backporting ReactOS implementations, OneCore lets Windows XP/Server 2003 to impersonate later Windows versions and run programs, along with required but missing functionality. For running additional programs set, it is recommended to install Visual C++ distributives, 2015-2022 of which are possible to run with OneCore API.

For running games and other heavy-graphics based applications, OneCore API also provides D3D-wrapper which allows to run applications for newer DirectX versions (9.0 and after). Partially, ReactOS based implementations for graphics also utilized, but they're not guaranteed as stable yet.

== Installation ==
For installing OneCore API, you should navigate to project's [https://github.com/shorthorn-project/One-Core-API-Binaries official GitHub repository for binaries], go to "Releases" page, and download latest one. OneCore provides following architectures:

* x86,
* x86 for AVX,
* x86 for PAE,
* x64.

Then after, extract the .zip installation file into your Windows XP/Server 2003 machine. You need to ensure that you haven't any OneCore API older installations. If you have, you must '''uninstall it'''. Otherwise, stability may be highly decreased and it is not guaranteed.
[[Category:OneCore API]]

2025-06-03T17:21:44Z

Ashific:

Welcome to the [[OpenXP]] Project's official wiki! Here you can find useful guides to compile Windows XP/Server 2003 leaked source code, as well as to master in following stuff:

* [[Getting Started|Getting started]] on configuring [[Razzle|environment]], [[Certificate Generation|generating certificates]] and performing successful build,
* Adjusting source code with custom patches, enhancements and tweaks,
* Knowing more about [[Windows Internals]] (in most real way), as well as to introducing more fundamentals,
* And waffles! 🧇

== Community ==
If you want to stay connected with OpenXP, you can join our official Discord server, as well to download source codes from our [[Download Center]] in safest way!

{{DISPLAYTITLE:Welcome to The OpenXP Wiki!}}

MediaWiki:Common.js

2025-06-03T17:18:46Z

Ashific: Created page with "/** * Keep code in MediaWiki:Common.js to a minimum as it is unconditionally * loaded for all users on every wiki page. If possible create a gadget that is * enabled by default instead of adding it here (since gadgets are fully * optimized ResourceLoader modules with possibility to add dependencies etc.) * * Since Common.js isn't a gadget, there is no place to declare its * dependencies, so we have to lazy load them with mw.loader.using on demand and * then execu..."

/**
* Keep code in MediaWiki:Common.js to a minimum as it is unconditionally
* loaded for all users on every wiki page. If possible create a gadget that is
* enabled by default instead of adding it here (since gadgets are fully
* optimized ResourceLoader modules with possibility to add dependencies etc.)
*
* Since Common.js isn't a gadget, there is no place to declare its
* dependencies, so we have to lazy load them with mw.loader.using on demand and
* then execute the rest in the callback. In most cases these dependencies will
* be loaded (or loading) already and the callback will not be delayed. In case a
* dependency hasn't arrived yet it'll make sure those are loaded before this.
*/

/* global mw, $ */
/* jshint strict:false, browser:true */

mw.loader.using( [ 'mediawiki.util' ] ).done( function () {
/* Begin of mw.loader.using callback */

/**
* Map addPortletLink to mw.util
* @deprecated: Use mw.util.addPortletLink instead.
*/
mw.log.deprecate( window, 'addPortletLink', mw.util.addPortletLink, 'Use mw.util.addPortletLink instead' );

/**
* @source www.mediawiki.org/wiki/Snippets/Load_JS_and_CSS_by_URL
* @rev 6
*/
var extraCSS = mw.util.getParamValue( 'withCSS' ),
extraJS = mw.util.getParamValue( 'withJS' );

if ( extraCSS ) {
if ( extraCSS.match( /^MediaWiki:[^&<>=%#]*\.css$/ ) ) {
mw.loader.load( '/w/index.php?title=' + extraCSS + '&action=raw&ctype=text/css', 'text/css' );
} else {
mw.notify( 'Only pages from the MediaWiki namespace are allowed.', { title: 'Invalid withCSS value' } );
}
}

if ( extraJS ) {
if ( extraJS.match( /^MediaWiki:[^&<>=%#]*\.js$/ ) ) {
mw.loader.load( '/w/index.php?title=' + extraJS + '&action=raw&ctype=text/javascript' );
} else {
mw.notify( 'Only pages from the MediaWiki namespace are allowed.', { title: 'Invalid withJS value' } );
}
}

/**
* Collapsible tables; reimplemented with mw-collapsible
* Styling is also in place to avoid FOUC
*
* Allows tables to be collapsed, showing only the header. See [[Help:Collapsing]].
* @version 3.0.0 (2018-05-20)
* @source https://www.mediawiki.org/wiki/MediaWiki:Gadget-collapsibleTables.js
* @author [[User:R. Koot]]
* @author [[User:Krinkle]]
* @author [[User:TheDJ]]
* @deprecated Since MediaWiki 1.20: Use class="mw-collapsible" instead which
* is supported in MediaWiki core. Shimmable since MediaWiki 1.32
*
* @param {jQuery} $content
*/
function makeCollapsibleMwCollapsible( $content ) {
var $tables = $content
.find( 'table.collapsible:not(.mw-collapsible)' )
.addClass( 'mw-collapsible' );

$.each( $tables, function ( index, table ) {
// mw.log.warn( 'This page is using the deprecated class collapsible. Please replace it with mw-collapsible.');
if ( $( table ).hasClass( 'collapsed' ) ) {
$( table ).addClass( 'mw-collapsed' );
// mw.log.warn( 'This page is using the deprecated class collapsed. Please replace it with mw-collapsed.');
}
} );
if ( $tables.length > 0 ) {
mw.loader.using( 'jquery.makeCollapsible' ).then( function () {
$tables.makeCollapsible();
} );
}
}
mw.hook( 'wikipage.content' ).add( makeCollapsibleMwCollapsible );

/**
* Add support to mw-collapsible for autocollapse, innercollapse and outercollapse
*
* Maintainers: TheDJ
*/
function mwCollapsibleSetup( $collapsibleContent ) {
var $element,
$toggle,
autoCollapseThreshold = 2;
$.each( $collapsibleContent, function ( index, element ) {
$element = $( element );
if ( $element.hasClass( 'collapsible' ) ) {
$element.find( 'tr:first > th:first' ).prepend( $element.find( 'tr:first > * > .mw-collapsible-toggle' ) );
}
if ( $collapsibleContent.length >= autoCollapseThreshold && $element.hasClass( 'autocollapse' ) ) {
$element.data( 'mw-collapsible' ).collapse();
} else if ( $element.hasClass( 'innercollapse' ) ) {
if ( $element.parents( '.outercollapse' ).length > 0 ) {
$element.data( 'mw-collapsible' ).collapse();
}
}
// because of colored backgrounds, style the link in the text color
// to ensure accessible contrast
$toggle = $element.find( '.mw-collapsible-toggle' );
if ( $toggle.length ) {
// Make the toggle inherit text color (Updated for T333357 2023-04-29)
if ( $toggle.parent()[ 0 ].style.color ) {
$toggle.css( 'color', 'inherit' );
$toggle.find( '.mw-collapsible-text' ).css( 'color', 'inherit' );
}
}
} );
}

mw.hook( 'wikipage.collapsibleContent' ).add( mwCollapsibleSetup );

/* End of mw.loader.using callback */
} );
/* DO NOT ADD CODE BELOW THIS LINE */