tomasz86

I'm not sure if I understand the comment about UURollup, Update Rollup 1 and Update Rollup 2 correctly. Which version of UURollup did you install? The last stable version of UURollup requires only SP4+UR1 (or USP5.1) to be present but the new daily versions require SP4+UR1+UR2 (or USP5.1+UR2) to work. Update Rollup 2 itself requires SP4+UR1 (or USP5.1). The other topic about UR2 is about the old package which was completely different than the current one. That's why it says "suspended / discontinued" in the title so you should just ignore it. The offline installer of the latest Java 6 just works on my system (with UURollup-v10c installed).

I think that you should try to install the drivers manually through Device Manager. Could you download my own experimental version of the AMD 12.8 Display drivers from here? I've removed the bloatware and also modified the INF file so that it will be accepted by Windows 2000.

Yes It should be unmodified (the exception is SP integration).

This should be added to TXTSETUP.SIF: [FileFlags] regini.exe=16 It won't change anything if the setup is run from a CD but it makes a huge difference when installing it from HDD. Adding to TXTSETUP.SIF: [SourceDisksFiles] regini.exe = 1,,,,,,,2,0,0 will make regini.exe copied to %systemroot%\system32. In case of an HDD based installation the file is actually removed from the source at this point. The problem is that some system INF files will actually look for it in the source in the later part of GUI setup. Adding the line under [FileFlags] will prevent the file from being removed from source. I'm going to update the first post in the next few days in order to summarise everything. I'm still unsure about the Driver Signing settings and driver installation in a running system. Sometimes it doesn't show any warning and sometimes it still does, and I don't know the reason yet.

As you know, it's possible to slipstream REG files from the HFSVCPACK folder. The problem is that this only works if the system is installed from a CD / other removable device. HFSLIP creates a file called "HFSLIP.CMD" and this file is executed from SVCPACK. This is the problematic part: FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y Z) DO IF EXIST %%i:\I386\SVCPACK ( SET HFSLIP=%%i:\I386\ SET HFSLIPSVC=%%i:\I386\SVCPACK\ ) and the part responsible for adding REG files (example): START/WAIT %SYSTEMROOT%\REGEDIT.EXE /S "%HFSLIPSVC%IE6.0sp1-KB834158-x86-ENU.reg" START/WAIT %SYSTEMROOT%\REGEDIT.EXE /S "%HFSLIPSVC%IE6.0sp1-KB893627-Windows-2000-XP-x86-ENU.reg" The script checks for presence of I386\SVCPACK in the root of all drives and when it finds it then the two variables are set, ex. if the CD-ROM is "D:" then HFSLIPSVC will be set to "D:\i386\SVCPACK\". The problem is that when you install the system from HDD the path is different. It's not just "I386" but rather "$WIN_NT$.~LS\I386". I've modified the script like this: FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y Z) DO ( IF EXIST %%i:\I386\SVCPACK ( SET HFSLIP=%%i:\I386\ SET HFSLIPSVC=%%i:\I386\SVCPACK\ ) ELSE ( IF EXIST %%i:\$WIN_NT$.~LS\I386\SVCPACK ( SET HFSLIP=%%i:\$WIN_NT$.~LS\I386\ SET HFSLIPSVC=%%i:\$WIN_NT$.~LS\I386\SVCPACK\ ) ) ) Now it still checks for the presence of I386\SVCPACK but if it doesn't exist then it also checks for $WIN_NT$.~LS\I386\SVCPACK. That was HFSLIP.CMD and below is the HFSLIP script itself. Original: REM ======================UPDATE_INIT===================================================== :UPDATE_INIT ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD @ECHO OFF IF DEFINED CMDHIDE ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD %CMDHIDE% ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD Title HFSLIP ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD FOR %%%%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y Z) DO IF EXIST %%%%i:\%MBOOTPATH%I386\SVCPACK ( ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD SET HFSLIP=%%%%i:\%MBOOTPATH%I386\ ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD SET HFSLIPSVC=%%%%i:\%MBOOTPATH%I386\SVCPACK\ ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD ) GOTO :EOF REM ====================================================================================== Fixed: REM ======================UPDATE_INIT===================================================== :UPDATE_INIT ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD @ECHO OFF IF DEFINED CMDHIDE ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD %CMDHIDE% ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD Title HFSLIP ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD FOR %%%%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y Z) DO ( ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD IF EXIST %%%%i:\%MBOOTPATH%I386\SVCPACK ( ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD SET HFSLIP=%%%%i:\%MBOOTPATH%I386\ ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD SET HFSLIPSVC=%%%%i:\%MBOOTPATH%I386\SVCPACK\ ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD ) ELSE ( ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD IF EXIST %%%%i:\$WIN_NT$.~LS\I386\SVCPACK ( ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD SET HFSLIP=%%%%i:\$WIN_NT$.~LS\I386\ ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD SET HFSLIPSVC=%%%%i:\$WIN_NT$.~LS\I386\SVCPACK\ ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD ) ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD ) ECHO>>SOURCESS\I386\SVCPACK\HFSLIP.CMD ) GOTO :EOF REM ======================================================================================

Here you go http://www.microsoft.com/en-us/download/details.aspx?id=17155 Download "sql2ksp3.exe".

Inside HIVESFT.INF you can also change the path to "Documents and Settings". Go to [strings] and change: [Strings] DEFAULT_PROFILES_DIR="%SystemDrive%\Documents and Settings"

There seems to be a problem with the USP5.1 integration. Could you: Download and unpack "HFSLIP_ia.7z" once again (I've updated some files). Copy your source files to "SOURCE". Remember that the source must be clean, without any modifications. Before running the script open a command line window and type: HF\w2ksp51 /integrate:C:\HFSLIP_ia\SOURCE What happens? Does the integration of USP5.1 work?

@Molecule Frankly speaking, I've got no idea about USBPORT.INF. In the past I did try to prepare such an installation which would be able to run from a USB memory stick but in the end it didn't work. At that time I tried to follow instructions from this website: http://www.techit.pl/Artykuly/Instalacja-systemow-Windows-XP-i-Windows-Server-2003-na-zewnetrznych-dyskach-USB,1125.html It's for XP/2003 and it's in Polish so you need to use a translator. One important thing to know is that the files have different names in 2K and XP/2003, ex. XP [InputDevicesSupport.Load] usbehci = usbehci.sys usbohci = usbohci.sys usbuhci = usbuhci.sys usbhub = usbhub.sys usbstor = usbstor.sys but in 2K: [InputDevicesSupport.Load] openhci = openhci.sys uhcd = uhcd.sys usbhub = usbhub.sys usbstor = usbstor.sys I'm guessing that: XP usbohci = 2K openhci XP usbuhci = 2K uhcd XP usbhub = 2K usbhub + 2k usbhub20 XP usbstor = 2K usbstor XP usbehci = 2K usbehci There's a different number of files in 2K and XP and some of them have got different names, so you can't just follow the guidelines for XP/2003.

I've found an issue in HFSLIP which breaks HDD based installation when certain files are added through the "HFEXPERT" folder. I'll explain the problem which happens when preparing an updated Win2k source. Three files included in USP5.1 (usbd.sys, usbhub.sys & usbser.sys) are buggy. Therefore I want to replace them through the "HFEXPERT\WIN\system32" folder with older versions of the same files coming from Update Rollup 1. Before running the script open "I386\DOSNET.INF" and search for "usbd.sys". It will be located in the following sections: [FloppyFiles.1] d1,usbd.sys [Files] d1,usbd.sys Do the same thing in "I386\TXTSETUP.SIF". "Usbd.sys" is located here: [SourceDisksFiles] usbd.sys = 2,,,,,,2_,4,1,3 [files.openhci] usbd.sys,4 Now run the HFSLIP script and check the files after that: DOSNET.INF [Files] d1,usbd.sys TXTSETUP.SIF [SourceDisksFiles] usbd.sys = 1,,,,,,,2,0,0 As you can see, the other lines have been removed! And this breaks HDD based installation! It will also break using system floppy disks for booting. The solution is very simple. If you just want to replace files already present in Windows then you should use REPLACE because it doesn't change anything in DOSNET.INF / TXTSETUP.SIF. You should use HFEXPERT only when adding completely new files (or when you want to intentionally change the default location of a file).

Something seems to get broken at this stage of integrating addons:

I must say that this looks very strange. It looks as if USP5.1 wasn't integrated properly by HFSLIP. Could you tell me what version of IE is installed in the system? Also if you open the properties window of My Computer, is there any info related to USP5.1 displayed?

I found a very strange bug and don't really know why it occurs. I do know how to fix it though. In the HFSLIP's script you can find the following lines: ECHO.&ECHO Locating compressed files in I386 subfolders SET BASEDIR=%~dp0SOURCESS\I386\ DIR/B/AD SOURCESS\I386>WORK\SSSI386SUB0.TXT FINDSTR/VBI "SVCPACK" WORK\SSSI386SUB0.TXT>WORK\SSSI386SUB.TXT FOR /F "DELIMS=" %%Z IN (WORK\SSSI386SUB.TXT) DO DIR/B/S/A-D/ON "SOURCESS\I386\%%Z">>WORK\SSSI386SUBALL.TXT Add a PAUSE at the end of it: ECHO.&ECHO Locating compressed files in I386 subfolders SET BASEDIR=%~dp0SOURCESS\I386\ DIR/B/AD SOURCESS\I386>WORK\SSSI386SUB0.TXT FINDSTR/VBI "SVCPACK" WORK\SSSI386SUB0.TXT>WORK\SSSI386SUB.TXT FOR /F "DELIMS=" %%Z IN (WORK\SSSI386SUB.TXT) DO DIR/B/S/A-D/ON "SOURCESS\I386\%%Z">>WORK\SSSI386SUBALL.TXT PAUSE Now run the script. After it has paused, open the "WORK\SSSI386SUBALL.TXT" file. It will look like this: R:\HFSLIP_test1\SOURCESS\I386\COMPDATA\3COM.HTM R:\HFSLIP_test1\SOURCESS\I386\COMPDATA\3COM.TXT R:\HFSLIP_test1\SOURCESS\I386\COMPDATA\AACRAID.HTM R:\HFSLIP_test1\SOURCESS\I386\COMPDATA\AACRAID.TXT R:\HFSLIP_test1\SOURCESS\I386\COMPDATA\ACCELPRO.HTM etc. Download one of the OnePiece's .NET Framework addons, ex. Onepiece's Microsoft .NET Framework 1.1 SP1 for Windows 2000 with GDR updates TRUE Addon and place it in HFAAO (you may need to rename it to something shorter, ex. "NETFX20.CAB"). Run the script again and wait until it has paused. Check "WORK\SSSI386SUBALL.TXT" again. It will look like this: R:\HFSLIP~1\SOURCESS\I386\COMPDATA\3COM.HTM R:\HFSLIP~1\SOURCESS\I386\COMPDATA\3COM.TXT R:\HFSLIP~1\SOURCESS\I386\COMPDATA\AACRAID.HTM R:\HFSLIP~1\SOURCESS\I386\COMPDATA\AACRAID.TXT R:\HFSLIP~1\SOURCESS\I386\COMPDATA\ACCELPRO.HTM etc. For some reason the short names are used and I can't figure out why (the switched used is just a standard "DIR/B/S/ON"). Now the real problem is that this completely breaks updating files from the I386\UNIPROC folder which happens later. The files located in in I386\UNIPROC are the following ones (in Win2k): KERNEL32.DL_ MP2UP.CAT MP2UP.INF NTDLL.DLL WIN32K.SY_ WINSRV.DL_ Normally HFSLIP should just update them with the newer versions. Now when the problem from 6) occurs they are not updated. After the script finishes the folder looks like this: KERNEL32.DLL KERNEL32.DL_ MP2UP.CAT MP2UP.INF NTDLL.DLL WIN32K.SYS WIN32K.SY_ WINSRV.DLL WINSRV.DL_ The first KERNEL32.DLL is the newly added file while KERNEL32.DL_ is the original one. Unfortunately Windows setup installs the latter which means that the new version is not installed. I don't know why such a strange bug occurs but I do know how to fix it. The following line: FOR /F "DELIMS=" %%Z IN (WORK\SSSI386SUB.TXT) DO DIR/B/S/A-D/ON "SOURCESS\I386\%%Z">>WORK\SSSI386SUBALL.TXT must be changed to: FOR /F "DELIMS=" %%Z IN (WORK\SSSI386SUB.TXT) DO DIR/B/S/A-D/ON "%~dp0SOURCESS\I386\%%Z">>WORK\SSSI386SUBALL.TXT I would call this bug critical and want to ask for a quick fix (Mim0?) because this completely breaks Win2k installation.

Direct links seem to be the ultimate source. For example, at the moment it's impossible to download Win2k updates for JPN-NEC98 using the M$ website. They're still present on the servers but you must know the URLs to download them (or use http://catalog.update.microsoft.com but not all updates are available there).

Thanks jaclaz for quoting me I haven't tested it yet but I think that it should be possible to set all variables in HIVEDEF.INF including %programfiles%, etc.

This workaround will work on any system (including non-Windows) and browser. It's just an URL As far as I know, the pirated copies of Windows XP use hacked WGA files and can access Windows Update in the same was as legit ones anyway. I hope not Like I've already said above, this is the only way to download these files under Windows 2000 as there's no WGA for it. Before you could use GenuineCheck.exe but now they can be downloaded only through confirmation links (or direct links once you know them).

Very strange I've never seen this kind of error before. The system you're using is the one installed from an ISO created using the script from "HFSLIP_ia.7z", right? Could you try to uninstall the daily version of UURollup and tell me if the situation is back to normal? You can uninstall it using the Add/Remove Programs applet or just go to your Windows directory and there will be a UURollup folder starting with "$" (it's hidden by default). There's an uninstaller inside.

Does the problem occur after you install the daily version of UURollup or after trying to install the graphics driver?

If anyone's interested, you can also also change the location of user folders through HIVEDEF.INF. Just go to [strings] and change these lines as you wish: U_SHELL_FOLDERS_APPDATA="%USERPROFILE%\Application Data" U_SHELL_FOLDERS_DESKTOP="%USERPROFILE%\Desktop" U_SHELL_FOLDERS_FAVORITES="%USERPROFILE%\Favorites" U_SHELL_FOLDERS_NETHOOD="%USERPROFILE%\NetHood" U_SHELL_FOLDERS_PERSONAL="%USERPROFILE%\My Documents" U_SHELL_FOLDERS_PRINTHOOD="%USERPROFILE%\PrintHood" U_SHELL_FOLDERS_PROGRAMS="%USERPROFILE%\Start Menu\Programs" U_SHELL_FOLDERS_RECENT="%USERPROFILE%\Recent" U_SHELL_FOLDERS_SENDTO="%USERPROFILE%\SendTo" U_SHELL_FOLDERS_START_MENU="%USERPROFILE%\Start Menu" U_SHELL_FOLDERS_STARTUP="%USERPROFILE%\Start Menu\Programs\Startup" U_SHELL_FOLDERS_TEMPLATES="%USERPROFILE%\Templates" U_SHELL_FOLDERS_COOKIES="%USERPROFILE%\Cookies" U_SHELL_FOLDERS_MYPICTURES="%USERPROFILE%\My Documents\My Pictures" U_SHELL_FOLDERS_LOCAL_SETTINGS="%USERPROFILE%\Local Settings" U_SHELL_FOLDERS_LOCAL_APPDATA="%USERPROFILE%\Local Settings\Application Data" U_SHELL_FOLDERS_CACHE="%USERPROFILE%\Local Settings\Temporary Internet Files" U_SHELL_FOLDERS_HISTORY="%USERPROFILE%\History" These are taken directly from Win2k's HIVESYS.INF so they may differ a little bit in case of XP/2003.

Apart from the trick I'm also almost sure that in Windows XP you can avoid the validation process once you've installed Windows Genuine Advantage Notifications. Edit: But of course it's only for IE and won't work in other browsers. In case of Win2k the only way to download these updates is to use the "confirmation" links.

The updates list which was hosted by bristols is now located at http://www.windows2000.tk/updates I myself use http://www.000webhost.com/ for hosting and haven't really experienced any serious problems so far.

Thanks for a quick fix

How about checking one of the older drivers? http://support.amd.com/us/gpudownload/windows/previous/Pages/radeonaiw_xp.aspx You could try the latest of the 11.x versions and if it works then go up one by one (12.1, 12.2, etc.) to see which work and which don't work.

@erpdude8 Yes, that post of mine is quite old. Check #25 for the updated info.

Well, this means that you did NOT follow the instructions There is a reason why I asked you to install the daily version: UURollup-v10c is already integrated in the source ("HFSLIP_ia.7z"). UURollup-v10c uses the WildBill's kernel which may not be enough to run these graphic drivers. UURollup-v10c does not support PAE on Win2k Pro so you can't use 8 GB RAM with it. The daily version of UURollup uses the BlackWingCat's kernel together with a lot of other new files. They add many more APIs and other functionalities. That's why I asked you to install the daily version, not the stable one. How come you're saying that there's no daily? Try here (download the latest one). Edit: Don't even look at UURollup (Global) !!!