DarkShadows

What you posted was new to me--I learned something today! Which specific part of that script makes the variable permanent? <Edit> Can we combine these techniques (Set CDROM=%~d0 and the permanent variable portion of what you posted)? Is there a way to unset a permanet variable? </Edit>

@Yzöwl As to WMIC, I just typed in that command at my command line, and Windows had to install it first. I'm not too fond of that. Also, this technique goes back to the issue of having multiple optical drives. But in this case the issue would be if the user has media in more than one optical drive, two drive letters will be returned by WMIC. So you are back to looking for check files again to verify which media is the correct one. this is less risky than the For-In-Do Check file or label technique, but there is no such risks when using the Set CDROM=%~d0 technique (which to me appears faster as well). I may be wrong here but unless you set a permanent environment variable, due to the way each child cmd process automatically cleans-up on closing, your variable will only last until that specific window is closed. <{POST_SNAPBACK}> You are correct, variables set in any script launched from CmdLines.txt do not live past the life of that script. MapCD must be called from the top of each script launched from CmdLines.txt, as %CDROM% will destroyed after each script called from CmdLines.txt ends.My personal process was actually calling MakeMapCD.cmd from my first CmdLines.txt script (not CmdLines.txt as I've prescribed here for everyone). This is why MakeMapCD v1.1 contained a call to MapCD). When I posted MakeMapCD.cmd v1.1 for others to use, I should've cleaned the Call MapCD.cmd out of it. So all along I've been discussing with you on the basis of what my personal process was doing, not what the posted version of it should be doing. Sorry for the confusion! I've since modified my own process to be the same as the one I've posted. And now, I agree that Setlocal can go at the top of MakeMapCD.cmd. (Life is so much more clear when talking apples-to-apples). @Everyone I've updated MakeMapCD.zip download accordingly on the first post in thread (now v1.1.1). The changes I've made are mostly organizational and documentation. The original version I posted (v1.1) will still work just fine, so long as MapCD is called from the top of any of your scripts (which was my recommendation all along). The Zip includes a sample CmdLines.txt and SampleScript.cmd that I just tested on Virtual PC. SampleScript simply stops at T-12 and Echo's the %CDROM% value to the screen. [Edit] Here's a link[/Edit] MakeMapCD.zip

@Yzöwl The OEMSetup folder is a part of my larger OEMSetup process. I create this folder regardless, I direct all installation logs there. I set my %Temp% folders (for my OEMSetup Process, not Windows) to a subfolder inside of there. And I stage anything there that I may want to install from the hard drive, rather than directly from CD. I build PCs for customers, and I'm engineering the Unattended Installation for a system recovery CD. So I don't want files written to the root of %SystemDrive% in case something goes wrong, the customer cancels, they lose power, etc. I stick a readme.txt file in there instructing the customer what it is for, and that they can generally delete it freely with no consequence. (Unless they experience errors, in which case I want the log files!) OEMSetup was already in my process to keep things together in one folder.Folks here at MSFN who download MakeMapCD.zip can simply change one line in MakeMapCD.cmd to write MapCD.cmd to the Root of the system drive (or to any folder, or path on it they wish). I've already documented this in MakeMapCD.cmd. Change: Set MapCDPath=%SystemDrive%\OEMSetup to: Set MapCDPath=%SystemDrive%\Your\Path which could simply be Set MapCDPath=%SystemDrive% That's easy enough to do and well within the license I have provided. This script above you have posted might not work so well. Let me explain why I have the script I have: A portion of MakeMapCD must run inside of Setlocal enableextensions, and another portion must execute outside of it. This design is quite intentional. The reasons are: 1. I want MapCDPath set globally during my CmdLines.txt execution (remember I write files there) 2. MakeMapCD must create MapCD using command extensions, which (I believe) might be disabled by default in Windows 2000 (I didn't know, so I coded defensively). I know extensions are enabled by default in Windows XP, but from your first post in this thread it sounded like they may be disabled by default in 2000. Anyway command extensions are required to facilitate the %~d0 syntax, which MakeMapCD.cmd uses to obtain the CD/DVD drive letter. However, when this script ends or an Endlocal executes (whichever occurs first), command extensions should revert back to being disabled in Windows 2000 (if my assumption is correct). I had two variables that I want set globally, but I need a Setlocal in the middle of them to actually grab the CD/DVD drive letter. This is why Setlocal and Endlocal are where they are in MakeMapCD.cmd Chronologically: 1. Windows 2000 Command extensions disabled (again my defensive assumption) 2. MakeMapCD starts: 3. Set MapCDPath (Set globally for use in my other scripts) 4. Setlocal enableextensions (allows %~d0, but variables set after are local) 5. Create MapCD.cmd (now contains actual CD drive letter value, not a variable) 6. Endlocal (turns off local variables) 7. Call MapCD (sets %CDROM% Globally for other CmdLines.txt scripts) However, I still recommend start any script requiring %CDROM% with: Call %SystemDrive%\<your path if any>\MapCD.cmd Exactly correct. The reason why is documented under the section Other things to keep in mind at this link:MSFN's Unattended XP CD - Adv Methods - Running RunOnceEx from CD This is why I didn't assign a %MapCD% command, as your suggested script above does. (Normally I personally love to assign variable commands!) According to the MSFN guide, different stages of the Windows Setup process might not always keep Environmental Variables that we set from one stage of Windows Setup might not survive to the next (at least they won't survive a reboot). So %CDROM% and %MapCD% might not survive from CmdLines.txt going forward. So I want people who use this to have the habit of including it in their scripts (again a defensive coding posture). It won't hurt to call MapCD.cmd 200 times, but the one time you don't call might ruin your day. This is why I write the MapCD file to %SystemDrive%. Writing MapCD.cmd captures the actual CD/DVD drive letter, not the string "%~d0". That will survive a reboot or a media change, and can be run from any stage, up to any point where you re-letter your drives. But at that time, since you are re-lettering, you should know the new CD-Drive letter. By contrast, Set CDROM=%~d0 can only be run from the CD/DVD ROM. I didn't worry about adding @Echo Off to MapCD.cmd because, as you have inquired about, MapCD.cmd is intended to be called from within each of your own command scripts, which usually have @Echo Off in them. I'm essentially providing a command to assign the %CDROM% variable. However, this is really simple to add, and makes a lot of sense (again for coding defensively), so I have updated the script with this change and already reposted MakeMapCD.zip. I don't feel it is necessary to put messages on the screen inside of MapCD.cmd. You are executing MakeMapCD.cmd from the CD/DVD ROM--the drive is there, and the Windows shell will give you the letter reliably. Personally, I don't need to know what the CD/DVD drive letter is, in fact my screens are hidden from view anyway. I only need to know that MapCD.cmd will reliably set %CDROM% whenever I require it. If you want, you could always add If Defined Echo Message to your own script that you are calling MapCD.cmd from. As licensed and intended, nothing else is supposed to go inside of MakeMapCD, or MapCD. thus, a Goto :EOF isn't required--you are already at the end of file. MakeMapCD.cmd was not intended to be a piece of code to inject into your script, rather it is a free-standing script to be called from within CmdLines.txt. Some people will do nothing else with CmdLines.txt. MapCD.cmd can be called from any script and must be written to the hard drive, since we cannot write to CD-ROM during Windows Setup.

Your drivers are on this pageIntel® 852/855 Chipset Family If you are unsure which to use, download the Intel® Chipset Identification Utility

Try this Actually to get to pricegrabber paste this in as your Web address (this forum software cuts my URL in half) http://www.pricegrabber.com/search_attrib.php/page_id=11/vendors[]=HIT/popup4[]=30:392/popup3[]=10:144/popup1[]=160:393/sortby=priceA That will query drives in close to what you are looking for

I swear by the Hitachi Deskstar model line. 8MB of cache, 3 year warranty. good tools and great customer support web site. I will never use western digital again. Ive seen too many crash and burn and their customer service doesn't seem as responsive.

It's been awhile since I registered there. But make sure you create a .net passport (or use your existing one if you have one). If you follow the link the I have in the post above you'll see: Click the "Register in the Partner Program today!" link Which takes you to: Welcome to the Microsoft Partner Program Not a member yet Already a member Explore partner member benefits Become a member now <---Look for this link If you are not signed in with your ..net passport, you will be prompted to do so, or create one at this step. Afterward you go here: https://partners.microsoft.com/partnerprogram/Welcome.aspx Click on "Click Here to begin the enrollment process. " Give them your information. I simply put "My Name DBA"" which means Doing Business As in the company blank. Make sure you select the Registered level.. The next screen prompts you to digitally sign the agreement. I'm not going to go farther into the registration process, because I am already registered. Eventually you are a registered partner. I remember selecting system builder along the way--that is important. But I never had to give a MCP-Id (that I'm aware of anyway). Once you are registered, you simply sign into the site with .Net passport. There is also a great page at the site with all of the hot fixes in there as well as the silent install switches for each one!

What is best for you is what works for you. There are usually no less than 3 ways to accomplish anything. It's just that each way has its own advantages and disadvantages.As to having issues with code at top and bottom, that is just a well-structured coding best practice. The code at the bottom is a function that is called within your code (at the top). You still set the drive at the top and your code follows. But the called function is located below your code. In fact, this structure will actually make reading your own code easier, because the function doesn't get in the way. The templates many have provided here, just help clarify what goes where. You could always stick the function up top in-line with your code. What works for me is code that allows me to stick in a UA XPCD in and go work on something else while the PC installs itself. And in this, I still vote Set CDROM=%~d0. All other techniques will create system dialogs if one has more than one CD/DVD drive in the PC. The For-In-Do loop checks, always check every letter from C-Z, looking for something. It doesn't matter what they are looking for, it is the very fact that they check every drive (including my second empty CD drive) that causes a problem. The empty CD drives generate errors when the Windows shell tries to check them for a file, or a label or whatever, and this error puts a dialog up on the screen and halts the installation. In my opinion this behavior just chopped the "Unattended " off of "Unattended Installation." To counter this I use Set CDROM=%~d0 as my first command. Since I've received questions on this offline, I've created a script people can plug-in and use that solves all ambiguity as to how this technique should be employed. It is tested on Windows XP, and should work well on Windows 2000. If someone could test it and report back to everyone, that would be helpful. I do not own a Windows 2000 license. Download the .zip file, extract it, open the .cmd and read it. It should explain everything in sufficient detail. Post any questions to this thread. MakeMapCD.zip

Microsoft has made the OPK (OEM Preinstallation Kit) more available and legally accessible to people building their own PCs, or those just getting into building PCs. They have now included the OPK as a download on the OEM System Builder's website. Registration is required in the Microsoft Partner Program to gain access to it, but registration at the free level will suffice. (That is all I have, and I was able to download the OPK .ISO file just fine.) You can register with the Microsoft OEM System building website as a system builder. You do not need to give a tax ID or anything like that. To clear up any legal issues, read this: Quoted from OEM System Builder Packaging, Licensing, and COA Changes Frequently Asked Questions: Thus, if you are building your own PC from the ground up, you are a system builder/assembler. Which means you can legally purchase a Windows XP OEM license (now without the requirement that the vendor needs to ship you some old internal PC part). This also satisfies the legal requirements to be able to use the OPK.Also, MS now offers Windows XP OEM licenses in 1-Packs. Before you had to purchase a 3-pack of OEM licenses which, if purchased through official channels, included the OPK. That and the 10-pack were the only methods I was aware of to obtain the OPK. Now MS will lets you download the OPK. Here's the link: Download the Windows OEM Preinstallation Kit - NEW You will be prompted for a Passport user ID and password. If you register at the link below, that should take care of you. Registering for the OEM System Builder Web Site NOTE: One cannot legally redistribute the OPK, without being an authorized distributor. So let me be upfront in saying, "no I will not send you a copy". If you register at the link above, you can obtain your own copy. EDIT 2005-10-06 EDIT 2005-10-06

I don't know how to manually create such shortcuts in the registry (and if anyone does, please post!). However, I do know of two utilities that will allow you to set system-wide hotkey assignments that use the Windows Key (also referred to as "WinKey," pronounced win-key, not winky).The first utility is Winkey, by Copernic. Winkey uses about 4 MB of RAM with a full list of hotkey assignments. I've used version 2.8 for about three years without issue on Windows XP. Unfortunately, as of July 2005, Copernic has ceased development and support of Winkey; they no longer distribute Winkey at The Copernic website. However, you can still download it from PC World. The second utility is Directory Opus, by GPSoftware (known to registered users affectionately as DOpus). DOpus has its roots back in the days of the Commodore Amiga, when application developers strove to make their software small, terse, efficient, customizable, and powerful. DOpus was ported to Windows with version 6.x, and it's current version 8.1, is the most powerful Windows-based application that you will find anywhere...period. DOpus 8.1 functionality completely replaces the functionality of the following software: • Windows Explorer (Windows Explorer is a complete joke next to DOpus) • FTP client • WinKey • Various Photo viewing software packages (e.g. Ulead Photo Explorer, which I am a registered user of.) • WinZip (however, not the WinZip self-extractor) • And many others DOpus uses multi-threading to increase program efficiency. The user doesn't have to wait for file copies to complete before continuing. It uses tabbed layouts, and dual file lists, and has too many features to list here. A word of caution, DOpus isn't like Windows Explorer, which is so dumbed down that it does next to nothing; rather it is an extremely powerful application, in which the user may customize nearly everything about the software. But with great power comes great responsibility. DOpus is configured out-of-the-box to work similar to Windows Explorer. But to get real value out of it, I suggest new users read the manual, join the Yahoo user group, and participate in the User Resource Center online Forum. Also patience is recommended, you have a lot to learn. But once you get your feet wet, you'll really wonder why more software applications aren't built this well! The DOpus feature you are most interested in is called "Customize". Within Customize, you will see a Keys tab, where you set your hotkey assignments. DOpus hotkey assignments could be used only within DOpus (for its internal functions), or system-wide across your operating system (for launching external programs). I like to have a Winkey assignment to launch all my heavy-hitting productivity software, like Word, Access, Outlook, Quicken, etc. You can test drive a fully functional evaluation version of Directory Opus 8.1 free for 60 days. Afterward, a single license costs $85.00 Australian (about $65 US). This may seem expensive, but I promise that this one software package that provides incredibly more value than it charges for. The development team does participate online in the User Resource Centre, and they do take user suggestions (I've personally submitted several that have been added, or improved.) B) GPSoftware also sells two-PC and 5 PC license packages that are slightly discounted. While you can find DOpus downloads at shareware sites like Download.com, don't rely on them, many such sites still have version 6.x. Instead, download version 8.x directly from GPSoftware.

Look closer at his code, it comes from the Set command in the IF condition:

@vcBlackBox: I never compile my batch scripts, so this isn't an issue for me. However, this is really good information for people to know. Thanks for bringing it forward! @Yzöwl: I like this script to automatically find my unslipstreamed Windows XP CD when I'm running my slipstream.cmd. (This is an example scenario when using Set CDROM=%~d0 will simply not work.)@Yzöwl and/or Martin Zugec: Now I have a question. In the line above, I understand nearly every technique you two have applied in your code there except one segment. The "">nul 2>&1&&set" Portion. The ">nul" just redirects output to the Nul device correct? So how does the remaining portion of the code get executed? The "&" is usually used to concatenate another command to the command line. But why do you have two of them before your Set command? It's a little off topic, but could you break down this a little?

Yzöwl I like that script. Very nice. (It's the first time I've even heard of fsutil.) Can you tell us if fsutil will be available when we are installing Windows XP from an Unattended Installation CD? I have 2 CD ROM drives and an Iomega Rev drive (which appears to the OS as a CD-ROM drive) So I end up seeing three drive letters when the script executes on my PC. If I where installing Windows unattended, this code would show me all the drive letters. So wouldn't I still have to make a human decision as to which one to use? However, it seems that this would be an excellent addition to my batch script which enables me to build my XPCDs (like to prompt the user which drive should be used). One reason I do not like using file checks is that I try to write modular code so when I move to my next project, I copy and past code modules from my previous scripts. When you check for a specific file or a folder, then you must make damned sure that it is actually on the CD, and you must also make damned sure it is not on any other drive that you may have. What happens when you rebuild your PC, but you leave your other HDD partitions intact? The code you posted searches all drives looking for its check file--it does not stop when it has found the first instance. So if you had the same check file in more than one drive, you may not get the correct drive letter assigned to your %CDROM% variable. And sure, you could easily be careful enough to ensure that no two drives have the same check file. However, there is still more to deal with. Even more critical is something that could happen if you have more than one CD-ROM drive (which I do). Because the code you posted searches all drives, it will also search my second CD drive that I do not have CD in. At which time Windows will generate a dialog with a message stating that media is not ready in the drive (or something like that). I personally find this problematic. That's what makes the technique I started this topic with so powerful. It doesn't require a check file or folder, and it simply doesn't care how many drives you have--it's not looking for any of them. When any script with Set CDROM=%~d0 in it runs (again running from the CD ROM itself), that script will automatically and programmatically know which drive letter the script is running from; and since it runs from the CD-ROM, we automatically and programmatically know the CD-ROM drive letter that we are executing from. It's just sooo much simpler to type, takes less time to execute, and is much less problematic. All the upside in the world, and no downside. If you prefer to execute your scripts from %SystemDrive%, then you need only execute one short script from the CD-ROM to set the %CDROM% variable and then launch your %SystemDrive% scripts. Keep in mind, I posted my technique to be used from your XPCD when installing Windows and executing your Cmdlines.txt-launched (or other method-launched) batch scripts, not to create the XPCD itself.

Whoops! Thanks for pointing that out! I'll edit the first post accordingly Thank you. Glad it helps. Sorry Nois3! But for a small ransom, I won't reveal your secret identity, nor the location of your hideout!

See my methods of finding your CD-Rom drive here: http://www.msfn.org/board/index.php?showto...45entry344845

One problem in building our XPCDs is that we cannot know the CD-ROM's drive letter in advance. This is because we may have several hard drive partitions, optical drives, and other removable drives. Windows Setup Text Mode assigns it's own letters to these volumes. And from PC to PC the assigned letters will be different, based on a number factors: drive type; volume format; partition is active, primary, or extended; et. al. To counter this you may have seen many command script examples at this web site and others which include a routine to identify the CDROM drive letter. Most of these techniques rely on checking for the existence of a known file on the CD-ROM at each possible drive letter (checking all letters C through Z inside of a For-In-Do loop). There are also other variations on these technique (many you will see in this thread). But there are issues with such techniques: • The code is less modular. I prefer modular code so when I move to my next project, I copy and past modules from previous scripts to new ones. When you check for a specific file, folder, or volume label, then you must make damned sure it is actually on your XPCD, and you must also make damned sure it is not on any other drive that may be attached at the time you install from your XPCD. What happens when you rebuild your PC, but you leave your other HDD partitions intact? The For-In-Do Loop Checks search all drives looking for its check file/folder/label. Such a check doesn't stop once it has found the first instance. So if you have the same check file/folder/label in more than one drive, you will not get the correct drive letter assigned to the %CDROM% variable. • Even more critical is something that happens if you have more than one CD-ROM drive installed (which I do). A For-In-Do with a File/folder/volumename check searches all drives (C-Z), including a second CD drive that you may or may not have a CD in. It doesn't matter what these techniques are looking for, it is the very fact that they check every drive C-Z that causes the problem. Empty CD drives (and other drive types such as Iomega Rev) will cause errors when the Windows shell tries to check them for a file, or a label or whatever. Windows will put a dialog up on the screen and halt the installation until you respond: "'Windows No Disk' 'There is no disk in the drive. [Cancel] [Try Again] [Continue]" I personally find this problematic. In my opinion the behavior above just chopped the "Unattended " off of "Unattended Installation." I don't know about you, but I want code that allows me to stick in a XPCD and go work on something else while the PC installs itself. But, there is a much simpler technique provided by the Windows XP Command Prompt script language, if one is executing a command script from the CD-ROM itself (as opposed to first copying the script to the hard drive and executing it from there). Assuming you are using Windows XP, or later, you can use Batch Parameter Expansion (search for "Using batch parameters" in the Windows XP Help and Support Center). When any command script executes, its first parameter, %0, equals the command script file name. However using parameter expansion, we can derive the CD-ROM drive letter from %0 by using: %~d0. For a simple practical example, simply copy the code below and paste it into a command file and execute it: @Echo OFF SetLocal enableextensions CLS Echo. Echo I am file (not yet expanded): %0 Echo My Expanded File Name: %~n0 Echo My Expanded Extension: %~x0 Echo My Expanded Name and Extension: %~nx0 Echo My Expanded Drive: %~d0 Echo The Expanded Root of My Drive: %~d0\ Echo Some Other Expanded Path on My Drive: %~d0\SomeOtherPath Echo My Expanded Path: %~p0 Echo My Expanded Drive and Path: %~dp0 Echo. Pause EndLocal GoTo :EOFLike Yzöwl states below for Windows 2000, the Endlocal, and Goto:EOF at the end are not strictly required (but they are great programming structure). There is always one implicit EndLocal at the end of each command script in Windows XP. However, if you nest Setlocals, you should definitely use matching EndLocal statements. While undocumented in the Windows XP Help and Support Center (surprise ), testing reveals that command extensions also NEED to be enabled in Windows XP for batch parameter expansion to work (but they are enabled by default in XP). There are two methods available to enable command extensions. One is to use: SetLocal enableextensions The other is to start your command script with the following command: Cmd /e:on ScriptName.cmd the code above to shows the first method. This technique allows you programmatically account for differing CD/DVD-ROM drive letters from PC to PC. It only works because the command script resides on the CD-ROM drive. If you move the script above to another volume, you will get different values. To illustrate, copy the sample script above to different volumes and execute it from each--all the values above that use the d modifier will change. You cannot manipulate batch parameters in the same manner that you can manipulate environment variables. You cannot search and replace values or examine substrings. However, you can assign the parameter to an environment variable, and then manipulate the environment variable. What makes the technique so powerful is that it doesn't require a check file, folder, or label. It doesn't care how many drives you have--it's not looking for any of them. When any script with Set CDROM=%~d0in it runs from the CD/DVD drive your XPCD is in, it will automatically and programmatically know the CD-ROM drive letter. It's just so much simpler to type, takes less time to execute, and is much less problematic. All the upside in the world, and no downside. [Edit: 2005-09-22] Since I've received questions about this original topic offline, I've decided to create and share a script people can plug into their XPCDs that solves all ambiguity as to how this technique should be employed. It is tested on Windows XP, and should work as well on Windows 2000. Download the .zip file, extract it, open the .cmd and read it. It should explain everything in sufficient detail. Post any questions to this thread. Variables set in any script launched from CmdLines.txt do not live past the life of that script. MapCD must be called from the top of each script launched from CmdLines.txt, as %CDROM% will destroyed after each script called from CmdLines.txt ends. [/Edit: 2005-09-22] [Edit: 2005-09-23] MakeMapCD.zipCurrent Version: v1.1.1 Changes from v1.1 are mostly organizational and documentation. The original version I posted (v1.1) will still work just fine, so long as MapCD is called from the top of any of your scripts (which was my recommendation all along). [/Edit: 2005-09-23] Hope you find this useful! B) If you have a script tip or trick that applies to unattended XPCDs post it to this thread. Keywords: CD CD-ROM DVD DVD-ROM drive drives letter letters find locate assign obtain acquire get set %CDROM% unattended installation XPCD windows xp 2000 batch command script tip tips trick tricks technique techniques

According to Microsoft, non-critical update KB884020.exe is no longer required since the release of critical update KB893066.exe, which includes the fix contained in KB884020.exe. Therefore, KB884020.exe can be removed from the list. See the MS KB article quoted below for more information.

One of the easiest answers to your question is money versus the perceived return on investment (ROI) for spending it. Organizations spend a lot of time, money, and labor on: purchasing new OS licenses for all their workstations, testing all of their in-house applications to ensure compatibility and business continuity, and the project to implement the new OS. They may even have to (or chose to) upgrade some of their applications. (Although the recent versions of Windows have done a lot for application compatibility.) And on top of these expenditures, even if all goes well (which it never does), there is the cost of the disruption of your business productivity while the new technology is absorbed by the people in the organization. It takes time to learn to get the value out of new technology. Plus, I believe that M$ is pushing "Modern computers" for their new OS, which may mean increased hardware costs for organizations. So now you have to ask, is it worth all that expenditure just to move up one version? Will we get a positive return on our investment? Do you think most people in an organization will get any value out of the new gadgets and gizmos? One could argue that any value they get is completely offset by the cost of the upgrade or the productivity lost while learning the new technology, especially if the new version of the technology doesn't take a quantum leap forward. I know many companies that intentionally skip Windows and Office Versions for these reasons. Look at the time line of the release of Windows 2000 and Windows XP--they are fairly close together. Now look at the functionality difference between them. Would you say they are more than 30% different? Even if you think this variation is more, is it enough to justify the price you would have to pay to move up one version? To be fair to Microsoft, 2000 was the next version of NT , whereas XP is designed to replace both NT and the 95/98/Me OS line. (Going forward it's now all one Windows.) Still, not many organizations are going to pay to roll out successive versions, if they have to pay for the next version. The same with the Office 2000, XP, 2003 suites. The cost of a license is in the hundreds of dollars per seat for Windows and Office. The upgrade prices aren't much less expensive than the full versions. So it gets pretty expensive to always purchase the next big thing. One has to ask the question: Am I getting any return on my investment when I purchase the next big thing? If you are always an early adopter, you pay for it. There is less documentation available, less books written, less information on web sites like these in the first year of an OS. Less in-house resources trained up on the new version. You'll also have to install more service packs and more hot-fixes across your ownership period of your license. And as experience shows, each M$ hot-fix and service pack can create its own problems. On the contrary, if you wait a year on an Office or Windows version, you'll most likely will come aboard with the release of the first service pack, not to mention better books and resources. This makes implementation up to a more stable version of the newest less expensive and less labor-intensive. Personally, I alternate upgrading both my Office and Windows OS purchases. I currently have Windows XP, but only Office 2000. I don't plan to purchase the Office suite again until they release the version designed for Longhorn. This enables me to skip from 2000 straight to whatever the next Office version is. I miss out on spending $200.00-$400.00 US on Office 2003, on top of having already skipped the same cost for Office XP. Both of which would only have to be replaced a year or two from now anyway. And since I do not require Sharepoint, there isn't much in the way of improvement (in my opinion) between Office 2000 and Office 2003, at least not $400.00 worth of improvement. Now when I eventually have to convert all those Access Databases I've developed, I don't need to convert from 2000 to XP to 2003 to <insert new version here>. My total cost of ownership is much lower than the early adopters who jump on each new version as it is released. Then there is also the price factor. Demand is always highest in the first year of a new software package (or hardware component). Now most of the arguments above were primarily about an organization's consideration. But most home users also tend to stick with what they have at home. The average mom and pop want a PC that dad can work on the family finances, junior can do his homework on, send email to grandma, and maybe mom will use the PC to work on the family photo album, home movie, or plan the next family vacation, and everyone gets to use the Internet. Windows XP already provides all of this in spades. So most people will wait several years to upgrade their PCs. They tend to get their OS with their new PC, and they don't purchase PCs all the time. It is only the technophiles, like us, and the gaming community that tend to consistently be early adopters. And history has even shown some of these people that patience is often a necessity, if not a virtue. I know a few gamers who keep their old OS around just to play a favorite game that just doesn't seem to work on the new OS.