Build - Revision history

Ashific at 07:43, 15 February 2026

2026-02-15T07:43:32Z

← Older revision		Revision as of 07:43, 15 February 2026
Line 91:		Line 91:
	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.		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]

			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:<syntaxhighlight lang="ini" line="1">
			[boot loader]

	timeout=30		timeout=30
Line 101:		Line 104:
	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

	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.)		multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /debug /debugport=COM1 /baudrate=115200
			</syntaxhighlight>(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.		<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.
Line 110:		Line 114:

	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.		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 ===		=== VMware setup ===
Line 132:		Line 134:
	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)		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>.

			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)<syntaxhighlight lang="registry">
			HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter
			</syntaxhighlight>Then create a DWORD value named the component you want to enable (e.g. <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)		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)
Line 141:		Line 147:

	=== x64 build OS support ===		=== 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.		<code>prepatched.zip v9</code> 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.		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.
Line 147:		Line 153:
	Huge thanks to the anon who initially worked on fixing the 16-bit tools over at <nowiki>https://rentry.co/16bit-msbuild</nowiki>!		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 ===		=== 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.		As of update v10 an amd64 build can be created by initializing razzle with the <code>win64 amd64</code> options, the build should mostly complete without errors, but note that post-build+ 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.		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.		Some anonymous users from 4chan have been slowly working on AMD64 back in 2020, 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...)		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.		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.

Ashific at 07:41, 15 February 2026

2026-02-15T07:41:12Z

← Older revision		Revision as of 07:41, 15 February 2026
Line 7:		Line 7:

	=== For 2000/XP/2003 Users ===		=== 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.		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. Current certificates chain haven't tested with Windows 2000 at the moment of writing.

			=== For modern Windows Server Users ===
			Currently there are issues regarding .NET Framework installation on Windows Server 2022/2025 versions, which may potentially disallow you from compiling source code. In order to fix those issues, you should switch to older known Windows Server versions (at the moment of writing it's Windows Server 2003) or use client versions of Windows instead (from Windows XP to Windows 11).

	=== Running environment ===		=== Running environment ===
Line 17:		Line 20:
	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.		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 ===		== 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.		Start to build via <code>build /cZP</code> or <code>bcz</code> (which is alias to first, so doesn't matter).

	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.		'''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 (<code>fre</code>) and debug (checked, or <code>chk</code>) 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 ===		=== Post-build ===
			Download the Missing Binaries pack from [https://theopenxp.org/download 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>!'''

	* Download the Missing Binaries pack from OpenXP Download Center, which contains missing binaries both for AMD64 and x86 builds.		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
	* 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 ====		==== Issues ====

Ashific: Ashific moved page Getting Started to Build without leaving a redirect: Getting Started must be a roadmap

2026-02-12T06:47:40Z

Ashific moved page Getting Started to Build without leaving a redirect: Getting Started must be a roadmap

← Older revision		Revision as of 06:47, 12 February 2026
(No difference)

Iamgonnatouchyou at 15:34, 4 September 2025

2025-09-04T15:34:50Z

← Older revision		Revision as of 15:34, 4 September 2025
Line 174:		Line 174:

	=== Private builds ===		=== Private builds ===
	To compile your very own private build along with a branch, open git administrator and <code>cd</code> to your source tree. There execute: <code>git init</code>, which initializes an empty <code>.git</code> folder. Without this it won't compile the built branch. ~~The~~ execute: <code>git checkout -b {name_of_your_branch}</code>, don't forget to remove the brackets!. Download this modified [https://drive.google.com/file/d/12UAYflPRiMpuZO1IafaEbcMDHRiEnNsO/view?usp=sharing razzle script] which has been edited to allow the detection of a created branch.		To compile your very own private build along with a branch, open git administrator and <code>cd</code> to your source tree. There execute: <code>git init</code>, which initializes an empty <code>.git</code> folder. Without this it won't compile the built branch. Then execute: <code>git checkout -b {name_of_your_branch}</code>, don't forget to remove the brackets!. Download this modified [https://drive.google.com/file/d/12UAYflPRiMpuZO1IafaEbcMDHRiEnNsO/view?usp=sharing razzle script] which has been edited to allow the detection of a created branch.
	=== Official builds ===		=== Official builds ===
	The <code>official</code> parameter sets global definitions for official builds, which will make it match up closer to the retail builds, should be useful if you need to compare against retail for any reason. In difference of <code>offline</code> and similar flags, all binaries in this mode are built in retail mode and won't contain any private information, as well as postbuild logging will be enabled.		The <code>official</code> parameter sets global definitions for official builds, which will make it match up closer to the retail builds, should be useful if you need to compare against retail for any reason. In difference of <code>offline</code> and similar flags, all binaries in this mode are built in retail mode and won't contain any private information, as well as postbuild logging will be enabled.

Iamgonnatouchyou: /* Private builds */ some fixes

2025-09-04T15:34:01Z

Private builds: some fixes

← Older revision		Revision as of 15:34, 4 September 2025
Line 174:		Line 174:

	=== Private builds ===		=== Private builds ===
	To compile your very own private build along with a branch, open git administrator and <code>cd</code> to your source tree. There execute: <code>git init</code>, which initializes an empty <code>.git</code> folder. Without this it won't compile the built branch. The execute: <code>git checkout -b {name_of_your_branch}<code>, don't forget to remove the brackets!. Download this modified [https://drive.google.com/file/d/12UAYflPRiMpuZO1IafaEbcMDHRiEnNsO/view?usp=sharing razzle script] which has been edited to allow the detection of a created branch.		To compile your very own private build along with a branch, open git administrator and <code>cd</code> to your source tree. There execute: <code>git init</code>, which initializes an empty <code>.git</code> folder. Without this it won't compile the built branch. The execute: <code>git checkout -b {name_of_your_branch}</code>, don't forget to remove the brackets!. Download this modified [https://drive.google.com/file/d/12UAYflPRiMpuZO1IafaEbcMDHRiEnNsO/view?usp=sharing razzle script] which has been edited to allow the detection of a created branch.

	=== Official builds ===		=== Official builds ===
	The <code>official</code> parameter sets global definitions for official builds, which will make it match up closer to the retail builds, should be useful if you need to compare against retail for any reason. In difference of <code>offline</code> and similar flags, all binaries in this mode are built in retail mode and won't contain any private information, as well as postbuild logging will be enabled.		The <code>official</code> parameter sets global definitions for official builds, which will make it match up closer to the retail builds, should be useful if you need to compare against retail for any reason. In difference of <code>offline</code> and similar flags, all binaries in this mode are built in retail mode and won't contain any private information, as well as postbuild logging will be enabled.

Iamgonnatouchyou: Added private builds

2025-09-04T15:32:31Z

Added private builds

← Older revision		Revision as of 15:32, 4 September 2025
Line 172:		Line 172:

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

			=== Private builds ===
			To compile your very own private build along with a branch, open git administrator and <code>cd</code> to your source tree. There execute: <code>git init</code>, which initializes an empty <code>.git</code> folder. Without this it won't compile the built branch. The execute: <code>git checkout -b {name_of_your_branch}<code>, don't forget to remove the brackets!. Download this modified [https://drive.google.com/file/d/12UAYflPRiMpuZO1IafaEbcMDHRiEnNsO/view?usp=sharing razzle script] which has been edited to allow the detection of a created branch.

	=== Official builds ===		=== Official builds ===

Ashific: Official builds

2025-09-03T17:27:24Z

Official builds

← Older revision		Revision as of 17:27, 3 September 2025
Line 1:		Line 1:
	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].		This guide tested under Windows XP, Server 2003, 7 SP1, 8.1 & 10 and 11 (all architectures). For version of the guide made by anons, visit [https://rentry.co/build-win2k3 build-win2k3]. Note that the guide provided by anons isn't supported in any way by OpenXP developers.

	== Preparing for Build ==		== Preparing for Build ==
Line 173:		Line 173:
	Other options are not described here, see <code>razzle.cmd /?</code> for details.		Other options are not described here, see <code>razzle.cmd /?</code> for details.

	=== ~~'OfficialBuild' parameter / BuildMachines.txt~~ ===		=== Official builds ===
	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.		The <code>official</code> parameter sets global definitions for official builds, which will make it match up closer to the retail builds, should be useful if you need to compare against retail for any reason. In difference of <code>offline</code> and similar flags, all binaries in this mode are built in retail mode and won't contain any private information, as well as postbuild logging will be enabled.

	~~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).~~		In latest patch kit from OpenXP, the useless checks of build machines in <code>''BuildMachines.txt''</code> have been '''removed completely''', and instead, any machine which is considered as "verified" is able to construct official builds. Also, the <code>OfficialBuild</code> parameter have been shortened to simply <code>official</code>, in order to make things more consistent.

	'''~~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 ===		=== Building specific components ===

Ashific at 17:55, 19 August 2025

2025-08-19T17:55:09Z

← Older revision		Revision as of 17:55, 19 August 2025
Line 2:		Line 2:

	== Preparing for Build ==		== 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.

	* 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.~~		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.
	* 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 ===		=== 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>.		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 ===		=== 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>)		* 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:\~~srv03rtm~~</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.		* 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.		* '''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 ===		=== Build ===
Line 24:		Line 24:
	=== Post-build ===		=== Post-build ===

	* Download the Missing Binaries pack, which contains missing binaries both for AMD64 and x86 builds.		* Download the Missing Binaries pack from OpenXP Download Center, 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>!'''		* 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> (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.~~		* 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 ====		==== 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!		* 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.		* 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 <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.
Line 44:		Line 44:

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

	=== Troubleshooting ===		=== 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.~~		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... ======		====== Certificate Import Wizard: An internal error occurred... ======
Line 86:		Line 85:
	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.		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]		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		timeout=30

Ashific: buildX

2025-08-19T17:21:06Z

buildX

← Older revision		Revision as of 17:21, 19 August 2025
Line 16:		Line 16:
	* 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.		* 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.		* '''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.
	* 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.
			=== 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 ===		=== Post-build ===

Ashific at 18:35, 23 July 2025

2025-07-23T18:35:16Z

← Older revision		Revision as of 18:35, 23 July 2025
Line 16:		Line 16:
	* 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.		* 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.		* '''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.
	* 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 (~~over 4~~) threads. If your build machine has more than that it's recommended to cap it to 4 threads maximum via the <code>-M 4</code> switch, added to the build command (eg. <code>build /cZP -M 4</code>, or <code>bcz -M 4</code>)		* 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.

	=== Post-build ===		=== Post-build ===