neophyte

Some people here think they are so 1337. Anyway. Longhorn is the best version of Windows since...... ......the last one.

No. It doesn't matter whether the license was supersceded or not. The simple fact is, that no matter what version of the OS you are using, it is still copyright protected. It doesn't matter if 4 billion other licenses have been released, it's still copyright protected, and the license for that version is applicable (unless an updated license is released for that particular version). How bloody hard is it to understand? An updated license only superscedes a previous license if that license was specifically released for that version. So whether or not a new version of the software comes out, the license is still valid.

No probs. Glad that sorted the issue. Oh, and BTW, if you place Winnt.sif and Winnt.cmd (or .bat) into the i386 folder, the setup process will automatically load those (using Windows XP), and complete the setup process.

Why not just activate it once It's not like it will kill you. Once you've done that, simply go to C:\Windows\system32 (or wherever your system32 directory is located) and make a backup copy of wpa.dbl and store it in a safe place. In the future, if you need to do a re-install, and you haven't changed CD keys, or too much hardware, you can copy that back over. Saves you s*** loads of hassle. On a side note, why people are afraid of PA is beyond me. If you've legally purchased it, you've got nothing to fear.

I don't think it would be your script. I think it could possibly be an issue with RAM. If you have more than one stick, try installing it with only one stick in it at a time (if it fails, just repeat the process until it works). I've had a similar issue (and seen it many times as well), and it was caused by a faulty RAM stick.

You obviously don't know much about copyright. Anything published in any medium is copyrightable by the publisher (the publisher can also be the author). Simply because previous versions are "released" doesn't mean that the copyright for the previous version is nullified. A copyright exists on any published medium for as long as the author is alive, and then some (it may vary from country to country, and in some countries, you may be required to apply for copyright permission). In Australia, if you publish something, and you are the author, it is copyright exclusively for you. You are now entitled to license it to any other person with any sort of restrictive rights or so forth. The copyright will only expire after (I am not to sure on this) 70 or so years after your death. The copyright will still be applicable to previous version/s of software whether an "update" or a new version is released or not. Putting it simply, it doesn't matter what build number of Longhorn you have (or any other pre-release/alpha/beta software from any company, for that matter), it will still have a copyright applicable to it.

I'd like to remove a language (English - US) from my XP installation during the processing of my batch file (for some reason, even though I've specified that only English - Australia be the default language and locale, the US one is also installed with it). I've searched the registry for that sort of information, but can't find it. I know you can set it via the Regional and Language settings in the control panel, but I would prefer not to do so. Any ideas?

%SYSTEMROOT% == c:\windows (or the root windows directory) %SYSTEMDRIVE% == the drive windows is installed to (eg, C:\)

So? AaronXP was incorrect. I am simply stating facts. Whether MS intentionally "leak" the alphas/betas or not, is not the point. It is still illegal to use them if you haven't been given license to do so. As such, if MS choose to do so, they can (and I think they did so at one stage) take legal action.

Regardles of the type of release the software is (alpha/beta etc) it is still a copyrighted material. Therefore, it is still goverened by the terms and conditions of the license attached to it. It is a violation of copyright laws to be using the software if you have not been granted a license for it, or a license is not available for it. If you really want a copy, you must become a member of the beta team, or be lucky enough to be given an evaluation copy. If you have an evaluation license, or an alpha/beta license, you are granted use of that software as dictated by the terms of the copyright contract.

I have tried setting the registry setting for the Driver Signing Policy as mentioned in this thread, however, it simply doesn't work for me (I'm still asked if I want to install the unsigned driver).

WinCDMan (the very latest version) caused errors with my test CD's. NTDLL.DLL (I think that was the dll) claimed to have an "Invalid entry point" error. I tried several times to fix this, but failed.

So now I know! Wheee! I guess I might try it after all. Perhaps a more complete guide on this is in order though. So that DOSNET.INF file is all that needs updating? What about the SVCPACK.IN_ file?

Yes, a lot of "IT Pros" still use Windows 2000, but it may not necessarily be simply because it may appear to be more stable. It could be because their software install lifecycle hasn't come around yet. I know of several large companies that have only recently moved over to a Windows 2000 base, after running Windows NT 4.0 and 98SE for over 5 years. Sadly, your view on Windows XP's stability is not perfectly accurate, as Windows XP can be stable, as well as unstable. So can Windows 2000. I recall having several issues with Windows 2000 that I simply could not fix, yet Windows XP ran like a dream on the same hardware. Of course, the reverse is also true. Given that there is a lot of hardware out there, and the amount of combinations that can be created, it is a little "unfair" to call something "unstable" if you've only ever used it for a brief period of time on a very small PC base. All in all, the probability of Windows XP and Windows 2000 crashing, is equal, as is the probability of it not crashing.

Meh. rmdir /Q /S works just as well. I'm still curious as to why those randomly named folders are placed on my secondary hard disk and not on my primary (C:) as one would assume.

Never fear. Apparently rebooting the system clears all the folders out that it uses. However, to delete the folder that is created by the $OEM$ directory on the cd, you do need to do an rmdir /Q /S %systemdir%\<folder>

It's pretty much like webmedic's post. However, I'm still having problems working out why these folders are created after running them. They only occur for files in which the /Q /U /Z switches are run. This is driving me insane, as I don't want to have all those icky folders floating about. Anyway, I guess I'll just have to test it some more.

I have my hotfixes sorted into folders so that those requiring the /Q:A /R:N switches are in a seperate folder to this. I then run one batch file, and then run the other.

I'm using a batch file to run a whole lot of critical updates (I found it in one of the threads here) after installing XP. However, it is creating a series of folders in my d: drive (a secondary hard drive) that do not remove themselves after the patches have been run. Any reasons why? This is the batch file: CLS @ECHO OFF ECHO ECHO Installing All Pre-SP2 Hotfixes... ECHO Please Wait... CD %systemdrive%\install\crits for %%i in (*.exe) do start /wait %%i /Q /Z /U /N ECHO Done. EXIT

Yes, that page is fine, however, earlier on in the guide, there is a contradicting quote. http://www.MSFN.org/unattended/xp/batch_commands.htm < it mentions this: start /wait %systemdrive%\$OEM\$1\path\to\setup.exe /switches Obviously, this is not the case. As it would be start /wait %systemdrive%\<path>\setup.exe It would also appear that when I read the article, I didn't quite see it properly, so that was my mistake. However, thank you for claryifying that One other thing. When installing the hotfixes, I've noticed that they generate a lot of folders in the root location of the drive they were stored in (well, they did in my test run). Are there any switches that can tell the updater to remove those files? Or are they going to be placed within the %systemdrive%\install folder, and then I can remove them with an rmdir /Q /S ?

I'm trying to figure out where exactly the $OEM$ directory is located. Does it go into the root of the CD, or does it go under the i386 folder? And once that's done, do you use %systemdrive%\<directory> in all batch files, or do you use %systemdrive%\$OEM$\$1\<directory ? The guide is not very clear on this, and neither are the Microsoft KB articles, and help files.

Ok. In the guides, it is telling the user to place anything that they want (ie, critical updates etc), into a folder called $OEM\$1\<bla> - This is fine. But what it fails to mention, is that if you don't locate it and name it like this: i386\$OEM$\$1, then it won't work. It will, however, work if you supply this in addendum to the [unattended] section: OemFilesPath =path_to_$OEM$_folder Example: OemFilesPath = "%SYSTEMDRIVE%\OEM_Files" (The last bit I have not actually tested yet, and will know a tad more in a day or so). Could this possibly be added to the guide?