======================= ORIGINAL POST ======================= It seems like the older post (Windows NT Source Compiled!) was locked, so I decided to start a new one- with the announcement of a significant progress from the previous post.
At this stage, all kernel and subsystem components (ntoskrnl.exe, ntdll.dll, win32k.sys, hal***.dll, csrss.exe, smss.exe, lsass.exe, ...., and even mvdm!) are compiled. The only missing component that prevents the full compilation of the source code is the implementation of DES/CBC cryptographic functions and rsa32.lib (rsa32.lib is only available in compiled form, no source is known to be available for it at this time).
All Win32 subsystem DLLs (kernel32.dll, user32.dll, ...) are also fully built and verified to be functional; however, the advapi32.dll cannot be built because it relies on the DES/CBC functions and rsa32.lib. The compilation proceeds with rsa32.foo (available in lsa) renamed to rsa32.lib, however its source is still missing.
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Sat Dec 27, 2014 7:53 pm
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
I'm planning to publish a full diff between my repository to the original source once I fix a few problems (for obvious reasons, I cannot link the full repository). At this time, the problems are:
1. nt\private\ntos\boot\startup, the compiled executable (STARTUP.COM) is of an invalid size, must manually pad it to the end of DGROUP (BSS section in this case) offset to get the OSLOADER.EXE to load. 2. nt\private\ntos\boot\detect, NTDETECT successfully builds and executes up to "Detecting Floppy Component ..." part. The floppy detection function is missing a return statement on one of its branches. If a return statement with an adequate value is provided for the other branch, it proceeds to the NTOSKRNL, but NTOSKRNL will report INACCESSIBLE_BOOT_DEVICE. An in-depth analysis on the process is required. 3. OLEAUTO needs to be built for all components that rely on OLE; otherwise, we are stuck with the public OLE components to complete the build. 4. NTRSA32 (rsa32.lib) source code is missing. We can use the rsa32.foo under lsa for now, but this makes the source tree incomplete. 5. des.c and cbc.c are missing. These are required by ADVAPI32 and a number of components under nt\private\net.
Meanwhile, if you are an experienced developer and interested in getting this source tree fully built, please let me know through PM.
Last edited by Stephanos on Sun Dec 28, 2014 10:44 am, edited 1 time in total.
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Sun Dec 28, 2014 4:57 am
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
voidp wrote:
I wonder if looking at the 2K, Windows Research Kernel, or ReactOS sources would help?
Yes, I'm aware of other sources. Unfortunately, they won't be much of help as the leaked 2k source only contains a minor portion of the source tree that are not related to the issues I listed above, and Windows Research Kernel only contains the kernel (a small portion of nt\private\ntos). ReactOS is a completely different codebase.
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Sun Dec 28, 2014 11:17 am
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
louisw3 wrote:
Wow looks awesome!! Have you tried a null object file for RSA to get the missing functions?
I suspect they may not be NT specific.
I got a bit confused over the ADVAPI issue as the last time I worked on it was a month ago. The ADVAPI is missing cryptapi.c, not DES/CBC (iirc, net is missing those). With rsa32.foo from lsa and it can be compiled only if cryptapi.c is provided. I created a dummy (empty) cryptapi.c to see exactly what implementations are missing- the following is from \nt\private\windows\base\advapi build log (for full build log, see http://pastebin.com/NYWVRij5).
Code:
advapi32.def : error LNK2001: unresolved external symbol CryptAcquireContextA advapi32.def : error LNK2001: unresolved external symbol CryptAcquireContextW advapi32.def : error LNK2001: unresolved external symbol CryptCreateHash advapi32.def : error LNK2001: unresolved external symbol CryptDecrypt advapi32.def : error LNK2001: unresolved external symbol CryptDeriveKey advapi32.def : error LNK2001: unresolved external symbol CryptDestroyHash advapi32.def : error LNK2001: unresolved external symbol CryptDestroyKey advapi32.def : error LNK2001: unresolved external symbol CryptEncrypt advapi32.def : error LNK2001: unresolved external symbol CryptExportKey advapi32.def : error LNK2001: unresolved external symbol CryptGenKey advapi32.def : error LNK2001: unresolved external symbol CryptGenRandom advapi32.def : error LNK2001: unresolved external symbol CryptGetHashParam advapi32.def : error LNK2001: unresolved external symbol CryptGetKeyParam advapi32.def : error LNK2001: unresolved external symbol CryptGetProvParam advapi32.def : error LNK2001: unresolved external symbol CryptGetUserKey advapi32.def : error LNK2001: unresolved external symbol CryptHashData advapi32.def : error LNK2001: unresolved external symbol CryptHashSessionKey advapi32.def : error LNK2001: unresolved external symbol CryptImportKey advapi32.def : error LNK2001: unresolved external symbol CryptReleaseContext advapi32.def : error LNK2001: unresolved external symbol CryptSetHashParam advapi32.def : error LNK2001: unresolved external symbol CryptSetKeyParam advapi32.def : error LNK2001: unresolved external symbol CryptSetProvParam advapi32.def : error LNK2001: unresolved external symbol CryptSetProviderA advapi32.def : error LNK2001: unresolved external symbol CryptSetProviderW advapi32.def : error LNK2001: unresolved external symbol CryptSignHashA advapi32.def : error LNK2001: unresolved external symbol CryptSignHashW advapi32.def : error LNK2001: unresolved external symbol CryptVerifySignatureA advapi32.def : error LNK2001: unresolved external symbol CryptVerifySignatureW W:\NT\public\sdk\lib\i386\advapi32.lib : fatal error LNK1120: 28 unresolved externals
The implementations of the functions listed above (supposed to be implemented in cryptapi.c, which is missing) are missing. Though, I think these functions will be relatively easy to re-implement. I'll be putting this for later as I work on the boot side issues (STARTUP.COM padding issue and NTDETECT INACCESSIBLE_BOOT_DEVICE issue).
On a side note, I have only re-implemented the RC4 functions (which were originally missing) for now on crypto side. I will post another reply soon with detailed status on the net or whatever else that relies on the missing crypto functions.
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Sun Dec 28, 2014 12:45 pm
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
==== ISSUE 0 The following is from \nt\private\lsa\crypt\engine\sources:
Code:
SOURCES=md4c.c des.c cbc.c ecb.c rc4c.c
des.c, cbc.c, cbc.c and rc4c.c are missing from the repository. I re-implemented the rc4c.c in asm (based on rc4fast.asm in other libraries), but we are still missing the rest. For now, that line has been commented out and the following was used instead:
Code:
SOURCES=md4c.c
The RC4 implementation was specified under i386 directory.
The lsass builds fine without them and is verified to be functional. The object files built from them are referenced throughout the entire source tree and are required by a number of different builds.
==== ISSUE 1
Code:
Compiling w:\nt\private\windows\netdde\src\netdde directory ******************** 'nmake.exe /c BUILDMSG=Stop. -i NTTEST= UMTEST= NOLINK=1 NOPASS0=1 386=1' NMAKE : U1073: don't know how to make 'obj\i386\des.obj' Stop. BUILD: nmake.exe failed - rc = 2
netdde is supposed to contain des.c, but it's missing one. The following functions are exported from des.c.
Code:
/* Functions exported from des.c */
void setkey(unsigned char *key);
void InitKey(const char FAR *Key);
void des(unsigned char *inbuf, unsigned char *outbuf, int crypt_mode); void desf(unsigned char FAR *inbuf, unsigned char FAR *outbuf, int crypt_mode);
Note that this is a special case where des.c is locally provided in the local build source dir, rather than the lsa directory. This des.c implementation is identical to the des.c that is supposed to be under lsa.
==== ISSUE 2
Code:
Linking w:\nt\private\inet\ohnt\ie\security\msnsspc directory ******************** 'nmake.exe /c BUILDMSG=Stop. -i LINKONLY=1 NOPASS0=1 NTTEST= UMTEST= MAKEDLL=1 386=1' NMAKE : U1073: don't know how to make 'W:\NT\private\lsa\crypt\engine\obj\i386\des.obj' Stop.
Yes, des.obj from lsa is required to complete the above build. As for net, rc4c.c was required from lsa and this has already been re-implemented.
==== NOTE Missing implementation reference:
ecb.c
Code:
unsigned FAR _CRTAPI1 DES_ECB( unsigned Option, const char FAR * Key, unsigned char FAR * Src, unsigned char FAR * Dst);
unsigned FAR _CRTAPI1 DES_ECB_LM( unsigned Option, const char FAR * Key, unsigned char FAR * Src, unsigned char FAR * Dst);
cbc.c
Code:
unsigned FAR _CRTAPI1 DES_CBC( unsigned Option, const char FAR * Key, unsigned char FAR * IV, unsigned char FAR * Source, unsigned char FAR * Dest, unsigned Size);
unsigned FAR _CRTAPI1 DES_CBC_LM( unsigned Option, const char FAR * Key, unsigned char FAR * IV, unsigned char FAR * Source, unsigned char FAR * Dest, unsigned Size);
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Mon Dec 29, 2014 5:54 am
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
voidp wrote:
I wonder if missing functions could be replaced by disassembling them from an NT4 RTM, then adding them to the build as inline assembly?
That would be the last resort. We can extract them from either known checked build images, or preferably from static libraries if available. Simply disassembling, however, would not be an option. The disassembled code will need to be de-compiled/reconstructed into C equivalent to allow the source tree to be built by all architectures (if not, we will have to provide assembly implementation of the missing functions for each arch and this would rather be tedious).
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Mon Dec 29, 2014 6:52 am
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
I have received a few questions about the build environment/tools used for this build, so I decided to post it.
Most of the build tools were built from \nt\private\sdktools. The compiler tools were mostly extracted from the 2000 source tree (it contains the compiler executables as well if you search through it carefully).
Internal Development Tools
Code:
Volume in drive W is NT4Src Volume Serial Number is 7852-865B
>nmake Microsoft (R) Program Maintenance Utility Version 1.50.4048 Copyright (c) Microsoft Corp 1988-93. All rights reserved.
>masm Microsoft (R) Macro Assembler Version 5.NT.02 Copyright (C) Microsoft Corp 1981, 1989. All rights reserved.
>ml Microsoft (R) Macro Assembler Version 6.11d Copyright (C) Microsoft Corp 1981-1995. All rights reserved.
>cl Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 10.20.6166 for 80x86 Copyright (C) Microsoft Corp 1984-1996. All rights reserved.
>link Microsoft (R) 32-Bit Incremental Linker Version 4.20.6164 Copyright (C) Microsoft Corp 1992-1996. All rights reserved.
>lib Microsoft (R) 32-Bit Library Manager Version 4.20.6164 Copyright (C) Microsoft Corp 1992-1996. All rights reserved.
>rc Microsoft (R) Windows 32 Resource Compiler, Version 4.00 - Build 1381
>midl Microsoft (R) MIDL Compiler Version 3.00.44 Copyright (c) Microsoft Corp 1991-1995. All rights reserved.
>mktyplib Microsoft (R) Type Library Generator Version 2.20.4048 Copyright (c) Microsoft Corp. 1993-1995. All rights reserved.
>cvtres Microsoft (R) Windows Resource To Object Converter Version 4.00 Copyright (C) Microsoft Corp 1992-1995. All rights reserved.
>mc Microsoft (R) Message Compiler Version 1.00.5239 Copyright (c) Microsoft Corp 1992-1995. All rights reserved.
>mapsym Microsoft (R) Symbol File Generator Version 6.00 Copyright (C) Microsoft Corp 1984 - 1995. All rights reserved.
Version information of major x86 16-bit tools:
Code:
>cl16 Microsoft (R) C/C++ Optimizing Compiler Version 8.00x Copyright (c) Microsoft Corp 1984-1993. All rights reserved.
>link16 Microsoft (R) Segmented Executable Linker NTGroup Version 5.60.220 Dec 28 1999 Copyright (C) Microsoft Corp 1984-1993. All rights reserved.
>lib16 Microsoft (R) Library Manager Version 3.40 Copyright (C) Microsoft Corp 1983-1993. All rights reserved.
>implib Microsoft (R) Import Library Manager Version 1.50.132 Copyright (C) Microsoft Corp 1984-1993. All rights reserved.
>rc16 Microsoft (R) Windows Resource Compiler Version 3.11 Copyright (C) Microsoft Corp. 1985-1992. All rights reserved.
The razzle build environment is initialised from \nt\public\tools\sizzle.cmd (sizzle.cmd is my version of the razzle.cmd adopted to my build environment). The original razzle.cmd sets the _NTDRIVE based on its argument (main, hotfix_free, hotfix_checked). It seems they had different source trees on different drives for each of those builds. It also sets the USERNAME to (ARCH)fre so that the razzle environment builds the free build.
Code:
:START REM goto SET_BINARIES_DIR
if "%PROCESSOR_ARCHITECTURE%" == "ALPHA" set USERNAME=alphafre if "%PROCESSOR_ARCHITECTURE%" == "MIPS" set USERNAME=mipsfre if "%PROCESSOR_ARCHITECTURE%" == "PPC" set USERNAME=ppcfre if "%PROCESSOR_ARCHITECTURE%" == "x86" set USERNAME=x86fre
if "%PROCESSOR_ARCHITECTURE%" == "ALPHA" set LOGNAME=HALPHAFIX if "%PROCESSOR_ARCHITECTURE%" == "MIPS" set LOGNAME=HMIPSFIX if "%PROCESSOR_ARCHITECTURE%" == "PPC" set LOGNAME=HPPCFIX if "%PROCESSOR_ARCHITECTURE%" == "x86" set LOGNAME=HX86FIX
set _MSVCVER=MSVC2k if not "%1" == "" set _MSVCVER=%1
if "%_MSVCVER%" == "MSVC15" set _MSVCDIR=W:\tools\msvc15 if "%_MSVCVER%" == "MSVC20" set _MSVCDIR=W:\tools\msvc20 if "%_MSVCVER%" == "MSVC40" set _MSVCDIR=W:\tools\msvc40 if "%_MSVCVER%" == "MSVC2k" set _MSVCDIR=W:\tools\msvc2k if "%_MSVCVER%" == "MSVC71" set _MSVCDIR=W:\tools\msvc71
set PATH=%PATH%;W:\tools\mstools;W:\tools\idw;%_MSVCDIR%;W:\tools\etcutil
set _NTDRIVE=W:
:SET_BINARIES_DIR
rem shift
if "%PROCESSOR_ARCHITECTURE%" == "ALPHA" set _ntALPHAboot=%_ntdrive%\binaries if "%PROCESSOR_ARCHITECTURE%" == "MIPS" set _ntMIPSboot=%_ntdrive%\binaries if "%PROCESSOR_ARCHITECTURE%" == "PPC" set _ntPPCboot=%_ntdrive%\binaries if "%PROCESSOR_ARCHITECTURE%" == "x86" set _nt386boot=%_ntdrive%\binaries
sizzle.cmd is essentially equivalent to razzle.cmd, but it only targets the main build and provides additional command line parameter to set the VC version. This was used during the very early development stage to verify the compiler compatibility of various components. I originally had a bit of success getting things built with MSVC40, but after tons of compiler issues, I confirmed that MSVC2k (extracted from the Windows 2000 source tree) is the one to be used.
Other than that, ntenv.cmd performs most of the magic. The source tree is not currently verified with *chk (e.g. x86chk) builds and only valid for x86fre. It have just confirmed that I get a few errors here and there for x86chk build on ntos and mvdm. I will be looking into this in a near future.
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Mon Dec 29, 2014 11:25 pm
Joined Wed Dec 21, 2011 1:22 am
Posts 49
I'm not sure if these are the right files your looking for....There is three 'des.c' files located at the following locations: \private\net\sfm\atalk2\atalkp\ \private\net\sfm\atalk2\pacermp\ \private\net\sfm\atalk2\portable\
The same holds true for the 'md4c.c' file: \private\lsa\crypt\engine\ \private\net\lsapi\md4\
In addition, there is a 'md4c.ccp' file at: \private\net\svcdlls\lls\ccfapi32\
EDIT: Mistakenly wrote 'rc4c.c and rc4c.ccp' when I should have wrote 'md4c.c and md4c.ccp'.
Last edited by MM-DD-YY on Tue Dec 30, 2014 4:17 pm, edited 1 time in total.
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Tue Dec 30, 2014 7:47 am
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
MM-DD-YY wrote:
I'm not sure if these are the right files your looking for....There is three 'des.c' files located at the following locations: \private\net\sfm\atalk2\atalkp\ \private\net\sfm\atalk2\pacermp\ \private\net\sfm\atalk2\portable\
The same holds true for the 'rc4c.c' file: \private\lsa\crypt\engine\ \private\net\lsapi\md4\
In addition, there is a 'rc4c.ccp' file at: \private\net\svcdlls\lls\ccfapi32\
Thanks for the input. Unfortunately, that des.c is not the des.c I'm looking for. They are different from the lsa implementation. For rc4c.c file, I don't have it under the paths you provided, nor could I find rc4c.cpp under ccfapi32 directory.
I think you may have a different/more complete copy of the source tree. Could you please advise through PM?
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Wed Dec 31, 2014 12:18 am
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
Quick update:
1. rc4c.c is still not available. As of now, I'm using my own rc4c in i386 asm implementation. If it is concluded that there is no leaked version available for this file, I will rewrite the asm implementation in C for all archs. 2. des.c under atalk2 cannot be used as a direct replacement for the lsa des.c. They may partially be reused if we have to write our own lsa des.c. The compiled object files (they survived because their extension names were not .obj) are available under \nt\private\rpc\runtime\security\ntlmssp. des.i16 contains the i386 16-bit implementation, while mac and mppc contain 68k and PPC implementations, respectively.
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Sun Jan 04, 2015 7:41 am
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
Update 2015-01-04:
1. rc4c.c is now available (details to be released later). des.c and ecb.c reconstruction still pending. 2. STARTUP.COM is now properly padded. CONST section was forced to be aligned at 16-byte boundary.
For now, I'm trying to get NTOS built in x86chk mode so that I can debug the kernel with full symbols. This is necessary to get the NTDETECT INACCESSIBLE_BOOT_DEVICE issue resolved.
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Sun Jan 04, 2015 7:47 am
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
NTDETECT Error Screenshots:
All we know at this time is that: 1. the NTDETECT.COM built from the unmodified source will hang during GetFloppyInformation()- that is, this function will never return. The function is missing a return statement in one of the branches. With a return statement manually added to the branch, the function will successfully return; however, NTOSKRNL will report an error as shown in the second screenshit. 2. SCSI Disk Controller is detected as shown in the first screenshot, and this makes the PCI detection issue unlikely. Also note BUSLOGIC.SYS and SCSIPORT.SYS in the second screenshot, which are indeed correct. 3. 0x0000007B / INACCESSIBLE_BOOT_DEVICE, 0xC0000034 STATUS_OBJECT_NAME_NOT_FOUND.
NOTE: This is an issue with our NTDETECT.COM. Everything else (including NTOSKRNL) will function properly with the original (released by MS) NTDETECT.COM.
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Mon Jan 05, 2015 8:20 pm
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
Now that the holidays ended, I will have much less time to work on this. For that reason, I will make the full SVN repository available to those are willing to contribute. Please send requests through PM only. Do not post requests here.
Along with the repository disclosure, I will make clear what I am trying to achieve from this project: 1. Fully build-able source tree on all architectures 2. Potential use in legacy system maintenance (in particular, Alpha, MIPS, PPC systems ...) 3. Full checked build/debug symbol/source package for research/learning (similar to the concept of Windows Research Kernel, but covers a significantly larger portion of the OS)
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Sat Jan 10, 2015 2:07 pm
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
Update 2015-01-10:
1. \nt\private\developr Razzle profiles were modified and refactored 2. x86fre and x86chk profiles were reconfigured with more appropriate settings 3. \nt\private\crtlib, crt32*, fp32* repositories were deleted. These CRT repositories are deemed obsolete and superseded by \nt\private\sdktools\vctools\crt. The exact CRT tree details are unknown as of now. It seems like the source tree was released in the middle of the CRT tree refactoring phase. For build completion and stability build, the CRT tree should be fully refactored. For now, we're sticking with the libs and dlls built from the current tricky build process. Debug CRT is not used for x86chk build. This decision is based on that of the original NT development team, which seems to have abandoned the use of Debug CRT in checked builds a while before the timestamp of this source tree. After all, it is almost never necessary to step into the internal CRT source anyway .. 4. NTOS now fully builds with both x86fre and x86chk. 5. (to those who have access to the repository) The SDK libraries (\nt\public\sdk\lib) in the repository were updated with those built from x86chk. If you're building x86fre, you must either keep the current rev. SDK libraries or build -c
Post subject: Re: Windows NT 4 Source Compiled! version 2 Posted: Sat Jan 10, 2015 3:36 pm
Joined Fri Dec 26, 2014 5:38 am
Posts 297
Favourite OS NT 4
MVDM Build Issue on x86chk (NOTE: MVDM builds without any problems under x86fre)
\nt\private\mvdm A quick intro to how the build is performed-when the Build Utility is launched, makefil0 is invoked first. The makefil0 build script builds all wow16 components (that is, MS-DOS and Windows 3.1 codebase). We are having some issues at this stage.
The following is the error output of nmake -f makefil0:
Code:
cd ..\..\wow16 nmake
Microsoft (R) Program Maintenance Utility Version 1.50.4048 Copyright (c) Microsoft Corp 1988-93. All rights reserved.
cd kernel31 nmake d386
Microsoft (R) Program Maintenance Utility Version 1.50.4048 Copyright (c) Microsoft Corp 1988-93. All rights reserved.
NMAKE 386P=1 DEST=DEBUG3
Microsoft (R) Program Maintenance Utility Version 1.50.4048 Copyright (c) Microsoft Corp 1988-93. All rights reserved.
cd DEBUG3 link16 /LI @..\krnl386.lnk,..\kernel.def
Microsoft (R) Segmented Executable Linker NTGroup Version 5.60.220 Dec 28 1999 Copyright (C) Microsoft Corp 1984-1993. All rights reserved.
Note that the makefil0 executes 'nmake d386'. This will lead to DEST=DEBUG3, which forces a debug build. In x86fre build profile, the makefil0 executes 'nmake r386', which sets DEST=RETAIL3.
Based on this, it seems that the DEBUG3 build adds a few extra objects to the link stage compared to RETAIL3 build and this causes the IGROUP (basically code section) to be larger than one segment (64K), causing a linker error.
This is as far as we know at this time. As I mentioned earlier, I'm focusing on the NTDETECT issue for now and I will start the actual debugging process as we now have the x86chk NTOS built.
Those who have access to the repository are encouraged to look into this issue. If you do not have access to the repo and would like to troubleshoot it, please let me know through the PM.
Users browsing this forum: No registered users and 13 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum
All views expressed in these forums are those of the author and do not necessarily represent the views of the BetaArchive site owner.