Internal Developer Server or Workstation for Windows XP
University of Washington FTP site
SGI FTP Site with agent99 ssh key
You need a 600 gigabyte virtual machine to complete this turorial.
hereI'm still reading all on the XP/2003 Batch files for all the shares and source depot views.
The Original Code Center Priemium Site had a Site had a Source Directory. Put your Windows SDK's, DDK's, OPK's, AIK's in eack coresponding version from Windows 1.0 to 2022. Until Russia hacks Code Center Primeium some more. Or until Microsoft gives Sphinx Logic's Founder a MVP for Building XP/2003. We are taking courses in ethical hacking.
Microsoft Acedemic Program
Microsoft UNIX Code Migration Guide
Microsoft Visual Studio.net Academic Version 2003
Setting up Interix
The Offical Build Number of the XP/2003 leak or SSILP if the truth be known; source is 5.1.2600.6000.240228-0756 is revision 6000 the same as the 2009 Embedded RTM.
This revision does not come with sdinit.cmd the source depot initalization script, so therefore source depot might not be fuctional. You may read razzle.cmd for further details.
You might also need Cygnus-2.7.2-970404 for XP/2003
You might want to cache sorceware.org and have a cache or Code Plex from the internet archive.
Go to Active State and my buy Perl 5.28 installer for enterprise.
Setting up Windows Server 2003
If you need to use 'expand /r' to X:\ENGLISH\WIN2003\ENT\I386\* D:\binaries.x86fre from a retail DVD.
- Setting Up a Windows Remote Installation Services Server
- Remote Installation Services
- Building Goliath
- Borland Turbo Assembler
- coming soon....
Make a Boot Floppy and build Goliath
Setting up the folder shares
depot,fxdev,retail,vsbuilt,symbols,vs,debug,xpclient,sdkdrop
Setting up VSBUILT
In the root of %NTROOT% make a 'vsbuilt' directory and copy every VC or Visual C/C++ Tools directory to 'VSBuilt' with the coresponding 'PlatformSDK' in the same ex. 'Vc7' directory for each version of Visual C/C++ 4.0-2008
You may search the revision for a directory called 'crts' and use windiff or sdkdiff and put together a nice C Runtime from the revision. Compare it to the 2003 VC++ RTM In the 'crts' directory you can study algorithms like heap sort and standard input and output. The revision is just a build, the 2003 VC++ CRT RTM is more recent and the 2002 VC++ RTM is too old. All of the files are in the build you just have to put together a SDK, DDK, Ifskit, and VC drop. The 'lib' files are in the 'NT' public sdk and ddk directories.
You might be missing four $ files the 'checkclr.c', 'nochkclr.c' and 2 printer files. You might want to hook up your professors printer on UNIX/LINUX per Donald Knuth. These files are only in the RTM Gold Visual Studio master. There should be no copying from the RTM files only copy to 'VSBuilt' from the NT Directory or revsion. and maybe make a Vc7b directory. If you have betas of Visual Studio 2002 make a beta drop, just be careful not to make incomaptable versions.
sdkdiff is in the Begin directory of the Platform SDK Samples and windiff is in SDKTools use build utility to built windiff and the vsvar32.bat to set the VC Tools and use namke to build sdkdiff and your off and running. Vc7 (2002 Platform SDK) Vc8 (2005 Platform SDK).
The point being the Samples are a good spring board on learning Windows Technologies to Build Windows in your career.
- Change the 127.0.0.1 localhost to 127.0.0.1 sourcedepot the the machines host file.
- You might want to try and use Perl ISAPI to configure the Source Depot Documentation in the tools/x86/perl directory.
- In the enlistment directory there are source depot templates sd.ini.txt and sdclient.ini.txt. Rename appropriately and place them in the /tools directory.
- Copy intlview.map from the tools directory and rename it SD.MAP and place it in the NT Root or %SDXROOT%
set sdxroot=D:\NT
You can try to run sdx.cmd
enlist projects ex: sdx enlist NT main com -c
tools\ntnewver.cmd
- Start in the NT\sdktools\vs\enlistment directory. Read the envvs.cmd file and make a Visual Studio Drop. From the %SDXROOT%\public directory. And Visual Studio 2002 or 2003 VC7
- Start in the debuggers directory after you leave the enlistment directory there are source depot templates.
run envvs.cmd The default background is green.
You might want to buy this C++ Book below or Project Euler and you also might want a Detiel How to Program Textbook in C++ for GNU cross platform porting to Win32 make a private directory for NT projects. NT Projects. Or Begin writing acedemic papers and join the IEEE or ACM I was ACM Vice President at my college.
Put your Detial Examples, XP Samples and your DDK & SDK Samples in private.
Building the Internal IDW SDKBuild or find xcopy and findstr from the RTM DVD and place on path
Setting the Path:
path %path%;D:\NT\tools\perl\bin;D:\binaries.x86fre;D:\NT\tools\sp;D:\NT\tools\x86
Set the Signing Certificate
run buildnum.exe in sdktools you may have to build it, to get the machine name and build numer of the operating system.
certmgr -add D:\NT\tools\testpca.cer -r localMachine -s ca
cd D:\NT
Begin building 'Diff' in SDK tools, 'SDKdiff' and 'Windiff' to merge DDK and SDK include and lib directories.
tools\checktestroot.cmd and tools\checktestpca.cmd
2. Setting Razzle
tools\razzle free offline or tools\razzle win64 amd64 free offline or for checked tools\razzle offline or tools\razzle win64 amd64 offline
Rename 'projects.map' in the tools directory to 'sd.map' and place in the root of the NT directory.
\\PATSTYLESVS.main.x86.fre
\\%COMPUTERNAME%.main.x86.fre in BuildMachine.txt
We look in BuildMachines.txt for the machine name, branch, architecture,and build type. If we find a match, then we set OFFICIAL_BUILD_MACHINE to the appropriate value ("primary" or "secondary") look for the the offical build machine client in sdktools->debuggers->vs->enlistment->sd.ini.txt.
tools\verifybuildmachine.cmd
perl xcopy2binplace.pl
You can compile the Lab 01 down to about 8 errors the rest of the Labs and Operating System shouldn't have any errors. You should have the research kernel to muck around with also from college, needing to comment out the Longhorn additions in revision 6000, files beginning with 'dp' are Longhorn files. The 'dp' files are not in the 'Longhorn' beta LDK they maybe in a IDW or internal developer workstation release if I can find one. Maybe look in Embedded 2009 for supported hardware and maybe learning what PCI hardware and coding the plug n' play to support in the NT Kernel. The PCI codes you can use now a days in 2024 is Linux and you might want to remove some of the cheap hardware.
Lab01: Base Services
Copy the base\ntos directory and all of it's files to Lab01 it might be a virtual lab in source depot and it is a physical lab.
CD to base\busdrv\isapnp and use the message compiler to generate 'message.h'
Make pcicodes.h using the message compiler too. This file goes in base\busdrv\pci
build -cz
delobj.cmd to clean the source tree
Lab02: Networking
For OS/2-based servers, the Net functions supported by Microsoft LAN Manager provided much of the functionality required for a network operating system; this functionality was missing from the local operating system. Windows NT, Windows 95, and Windows 98 have much of this network functionality built in. Therefore, some of the original Net functions are no longer supported.
Windows NT, Windows 95, and Windows 98 support a variety of networking functions. The set of Net functions provide additional capability not covered by other networking functions. In addition, you may use these functions to monitor and administer OS/2-based LAN Manager servers
Copy the NT\net directory to Lab02. The Network Stack or Lab will build without error in the Vitrual Lab.
You might have issues in the Pysical Lab
build -cz
delobj.cmd to clean the source tree
Lab03: Server
Copy the Entire Server folder from nt5src.7z to Lab03
The entire Server build should build with about 20 shipping errors and take about 6 hrs for a free build and 12 hrs for a checked.
build -cz
delobj.cmd to clean the source tree
Lab04: Terminal Services
Copy NT\termsrv directory to Lab04. The Terminal Services Stack should build without error in the Virtual Lab. You might have issues in the Physical Lab.
build -cz
delobj.cmd to clean the source tree
Lab05: The Component Object Model Stack Including the Common Language Infustructure
The Component Object Model The Component Object Model (COM) is a platform-independent, distributed, object-oriented, system for creating binary software components that can interact. COM is the foundation technology for Microsoft's OLE (compound documents), ActiveX (internet enabled components), as well as others.
To understand COM (and therefore all COM-based technologies), it is crucial to bear in mind that it is not an object-oriented language, but a standard. Nor does COM specify how an application should be structured. Language, structure, and implementation details are left to the application programmer. COM does specify an object model and programming requirements that enable COM objects (also called COM components, or sometimes simply objects) to interact with other objects. These objects can be within a single process, in other processes, even on remote machines. They can have been written in other languages, and may be structurally quite dissimilar. That is why COM is referred to as a binary standard - it is a standard that applies after a program has been translated to binary machine code.
The only language requirement for COM is that code is generated in a language that can create structures of pointers and, either explicitly or implicitly, call functions through pointers. Object-oriented languages such as C++ and Smalltalk provide programming mechanisms that simplify the implementation of COM objects, but languages such as C, Pascal, Ada, Java, and even BASIC programming environments can create and use COM objects.
COM defines the essential nature of a COM object. In general, a software object is made up of a set of data and the functions that manipulate the data. A COM object is one in which access to an object's data is achieved exclusively through one or more sets of related functions. These function sets are called interfaces, and the functions of an interface are called methods. Further, COM requires that the only way to gain access to the methods of an interface is through a pointer to the interface.
Besides specifying the basic binary object standard, COM defines certain basic interfaces that provide functions common to all COM-based technologies. It also provides a small number of API functions that all components require. COM has now expanded its scope to define how objects work together over a distributed environment, and added security features to ensure system and component integrity.
However the Beta Wiki doesn't list a Lab 05 I believe it's either the SSCLI or the COM Stack. With the .NET Framework.
To build the SSCLI you need Visual Studio 2005 Professional or higher in a 2000 or 2003 Virtual Machine. And Active State Perl ActivePerl-5.16.3.1603-MSWin32-x86-296746.msi or ActivePerl-5.16.3.1603-MSWin32-x64-296746.msi for 64-Bit
extract the sscli20_20060311.tgz for 2.0 or 1.0 sscli_20021101.tgz sscli_ref_20021101.tgz and and Gyro Genetrics with 1.0 and execute env.bat at the root of the directory. To set the free or checked environment then execute buildall.cmd.
To build the COM stack run build -cz in the root of the COM directory or lab.
Lab06: User interface
Copy NT\shell directory to Lab06. The UI Stack should build without error in the Virtual Lab. You might have issues in the Physical Lab. With the GNUmakfile
build -cz
delobj.cmd to clean the source tree
Lab07: Internet Information Services/COM+
:Copy NT\inetsrv directory to Lab07. The IIS Stack should build without error in the Virtual Lab. You might have issues in the Physical Lab.
build -cz
delobj.cmd to clean the source tree
build individual projects
in the directory of a makefile with build -cz
or
build the whole operating system
perl tools\timebuild.pl -NOCLEANBUILD -NOSYNC -NOSCORCHIf you want to wait 6 to 12 hours for a new clean build you'll type this:
perl tools\timebuild.pl -!NOCLEANBUILD -NOSYNC -NOSCORCH -NOPOSTBUILD
build -cz
POSTBUILD:
Template for the postbuild scripts:
SD Location: %sdxroot%\tools\postbuildscripts
1 Code section description:
PreMain - Developer adaptable code. Use this model and add your script params
Main - Developer code section. This is where your work gets done.
PostMain - Logging support code. No changes should be made here.
2 GetParams.pm - Usage
run perl.exe GetParams.pm /? for complete usage
3 Reserved Variables -
lang - The specified language. Defaults to USA.
logfile - The path and filename of the logs file.
logfile_bak - The path and filename of the logfile.
errfile - The path and filename of the error file.
tmpfile - The path and filename of the temp file.
errors - The scripts errorlevel.
script_name - The script name.
script_args - The arguments passed to the script.
CMD_LINE - The script name plus arguments passed to the script.
_NTPostBld - Abstracts the language from the files path that
postbuild operates on.
4 Reserved Subs -
Usage - Use this sub to discribe the scripts usage.
ValidateParams - Use this sub to verify the parameters passed to the script.
8 Do not turn echo off, copy the 3 lines from the beginning of the template
instead.
9 Use setlocal/endlocal as in this template.
10 Have your changes reviewed by a member of the US build team (ntbusa) and
by a member of the international build team (ntbintl).
We only create boot floppy images on fre compressed i386 builds.
tools\postbuildscripts\sanitycheckunicodefiles.cmd
Generate the winnt32.msi for different SKUs
make a 'symbol' share with symbol and build subdirectories.
symbolcd.cmd
setupw95.cmd
tools\postbuildscripts\winnt32msi.cmd
tools\postbuildscripts\makebuildname.cmd
tools\postbuildscripts\cdimage.cmd -d Full -C Comp -l USA your langauge codes are in codes.txt
tools\postbuildscripts\burncopy.cmd 2600 USA ....... you do need a release share which well cover soon. The Build number is in Buildname.txt
move delobj.cmd the the tools directory to the NT Root and clean the source tree by deleting all the object files. After the build
Close Razzle Window run the VC7 vcvars32.bat from the VCBuilt share and set _NTTREE environment variable. Which is the binaries directory.
path %path%;D:\binaries.x86fre\bldtools
Copy the 'copyddkfiles.cmd' the the NT\base\ddk directory for the tools directory run:
copyddkfiles.cmd ddk_base.ini ddk D:\NT\base
It should begin to copy the ddk files you will need to edit the ddk, hal, IFS INI files to fit your kit needs.
You might want to learn how to make a service pack.
cd to D:\NT\tools\postbuildscripts\svcpack\ and open spcab.cmd and set the FILELIST CABNAME and EVENTNAME using the gold directory text files as a FILENAME
After the build run the post build batch file in the tools directory and read the error log you shouldn't get any errors in Windows XP/2003 Professional Edition.
certmgr.msc, go to Trusted Root Certification Authorities\Certificates and remove the Microsoft Test Root Authority certificate, Sign out and Sign in again. The 'For Testing Purposes' Watermark should now be removed.
It takes 6 hours to build a Free Build and 12 hrs a Checked.
Themes
To test the defualt Visual Styles build and execute UXBUD.EXE in the shell->themes directory
Build packthem, cd to the themedir and build 'mallard' read the Powerpoints use Office XP, And Adobe CS2.
Here's is a Mallard Screenshot
After the build the Active Directory Migration Tools and Debugging Tools should be built. After the post build very edition and every supported language should be built. In the binaries directory the usa default build should be revision 6000 leading up to Windows Embedded 2009. After the Windows 6000 revision source build you might want to use the SLD files in the 'mantis' folder with XP embedded and make a Embedded Windows repository and engineer 2003 revision 6000 which was released in Embedded 2009. You can compile the Operating System down to about 16 errors needing to remove the Longhorn additions in revision 6000 maybe look in Embedded 2009 for supported hardware and maybe learning what PCI hardware and coding the plug n' play to support in the NT Kernel. The PCI codes you can use now a days in 2024 is Linux and you might want to remove some of the cheap hardware.
Building a Windows XP Embedded Runtime Image
To build MSMQ in NT->inetserv->MSMQ install Visual C++ 6.0 with MSDN Library put the Build Utlity from NT->tools->x86 in the exacutables PATH in the Options tab in Visual C++ 6.0 and set NTMAKEENV in the Control Panel to the 2003 DDK Bin. The Workspace is a Visual C++ 6.0 workspace. From the CMD Prompt run 'scortch.cmd' to set %FROOT%. Please make sure the SDXROOT is set. This Workspace has more environment varables to set and Microsoft used MINGW in the building of XP not PTC. Download GetGNUWin32-Legacy-Install from Sourceforge.
here to build MINGW 1.0 for source.
The Boot Process for XP/2003 is:
Use Bootsect to write MBR and boot sector.
bootsect /nt52. e:
NTLDR, Ntdetect.com, Ntbootdd.sys, Ntoskrnl.exe, hal.dll, smss.exe, winlogon.exe, Service Contol Manager SCM
In a free build the kernel may not build you may have to to use the Windows Research Kernel. Microsoft does not give you the source to WinLogon even in the SSLIP. It's named Winlogon.exe.lc
A build lab (or simply a lab) commonly refers to a Microsoft Windows source code branch. By extension, it can also refer to the team that works on this branch.
Microsoft has used multiple prefixes to refer to feature branches over time:
Setting up a Public Symbol Server
You can use the Symchk tool to check to see if the Symbol file is public or private.
To get WMI support, you need at least the XP SP2 OPK CD. It has updated tools to build the source for WinPE. If you have this OPK CD, just add /WMI to the MKIMG command.
To start migrating to Longhorn you need the 'Avalon' and 'Indigo' Tech Preview