tomasz86

Maybe this? There are probably better ways to adjust CPU speed by 3rd party applications though. I use K10stat for my AMD CPU. I actually even undervolted it a little bit. It's good to save some energy since you don't really need full CPU performance when doing some light activities such as browsing the web, etc. (unless you're viewing a Flashy website on a Pentium III ).

I want to remove duplicates, ex. HKCR,"TypeLib\{662901fc-6951-4854-9eb2-d9a2570f2b2e}\5.1","",0x00000002,"Microsoft WinHTTP Services, version 5.1" HKCR,TypeLib\{662901fc-6951-4854-9eb2-d9a2570f2b2e}\5.1,"",0x00000002,"Microsoft WinHTTP Services, version 5.1" HKCR,TypeLib\{662901fc-6951-4854-9eb2-d9a2570f2b2e}\5.1,,0x00000002,"Microsoft WinHTTP Services, version 5.1" HKCR,TypeLib\{662901fc-6951-4854-9eb2-d9a2570f2b2e}\5.1,,0x00000002, "Microsoft WinHTTP Services, version 5.1" etc. so I'd like to deconstruct and then reconstruct such lines so that they are exactly the same and can be deduped by the yanklines script.

SETUPAPI.DLL is language independent. The file is English, no matter what language version of Windows 2000 you use (the only exception may be Windows 2000 for NEC98 because it's a different architecture but I don't know).

How about Avast 7.x? It should work fine. Avast still releases database updates even for v4.8 Edit: Avast 8 does work in my test machine... Are you sure that you installed all of the packages which I mentioned above in #26? Avast 8 basically requires Windows 2000 SP4 + IE6 + Update Rollup 1 to work. It makes system unbootable after restart I need to do more tests.

That's right. "Normally" it would be easy to just divide everything by commas but these kind of fields: "MSGOTHIC.TTC,MS UI Gothic" are problematic. As for the script you suggested, isn't it going to be the same situation as there? That's why I'm thinking of gsar because the script just has to work in Windows 2000 with its default cmd.exe.

I'm trying to divide and then relink registry entries like this one... 1.txt HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink",,0x10000, "MSGOTHIC.TTC,MS UI Gothic" into HKLM "SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink" 0x10000 "MSGOTHIC.TTC,MS UI Gothic" I've come up with this script: @ECHO OFF SETLOCAL ENABLEDELAYEDEXPANSION set tokens= CD.>temp.txt :TEST SET/A tokens+=1 FOR /F "delims=" %%A IN (1.txt) DO ( FOR /F "tokens=%tokens% delims=," %%B IN ("%%A") DO ( FOR /F "tokens=1* delims= " %%C IN ("a %%B") DO ( SET STRING= ECHO %%D|FINDSTR/V ^"^"^" >NUL && SET STRING=%%D IF NOT DEFINED STRING ECHO %%D|FINDSTR/B ^"^"^"|FINDSTR/E ^"^"^" >NUL && SET STRING=%%D IF NOT DEFINED STRING ECHO %%D|FINDSTR/B ^"^"^" >NUL && SET STRING1=%%D IF NOT DEFINED STRING ECHO %%D|FINDSTR/E ^"^"^" >NUL && SET STRING2=%%D IF DEFINED STRING ( ECHO>>temp.txt !STRING! ) ELSE ( IF DEFINED STRING1 IF DEFINED STRING2 ( ECHO>>temp.txt !STRING1!,!STRING2! SET STRING1= SET STRING2= ) ) GOTO :TEST ) ) FOR /F "delims=" %%A IN (temp.txt) DO <NUL SET/P="%%A,">>2.txt ) The result is: 2.txt HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink",0x10000,"MSGOTHIC.TTC,MS UI Gothic", I know it's not pretty and I need to work on it more but the biggest problem here is that the FOR /F loop: FOR /F "tokens=%tokens% delims=," %%B IN ("%%A") DO ( done on HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink",,0x10000, "MSGOTHIC.TTC,MS UI Gothic" makes the empty token before "0x10000" disappear. I've done some Googling but couldn't really find any simple solution to this default behaviour of FOR /F. Is there simple way to preserve it other than using gsar before running the script to replace ",," with something else like ","","?

I don't think SFCDisable disable works any more. There's a way to disable it through the registry but it's too easy to change back. The problem is that many of the so called "registry clean-up" tools will see it as an error and try to "fix" it, i.e. enable SFC again. Patching the file directly is a kind of permanent way to do it. BUT How about using the registry to disable SFC (using the FDV's method) and then setting registry permissions for those keys to "read only"? I think it's worth testing Another thing to concern is that SFC should be disabled also during Windows installation and it's not possible currently if you only use the registry. It would be possible in case of a Service Pack where you can modify the HIVE*.INF files directly but in cased of an update rollup it's impossible.

Right but it still shouldn't be like that The file is indeed replaced automatically when using official updates and it will be the same in UURollup. I'll probably need some time to test everything because I need to play around with update.ver and compare the results. Normally it's not recommended but in this case the two are very similar so there won't be any problems with installing the weekly release over the daily one from 20130319. By the way, due to lack of time from now on I want to concentrate 100% on fixing / updating UURollup and preparing USP5.2. I may not be able to check other forum topics related to Windows 2000 so if you've got questions about the unofficial packages or need support, please use this topic. I've changed my signature accordingly.

It may not work with new drivers In case of Nvidia drivers I can get it work only with v.270.x or older. Have you tried to restart the system after trying to enable the second display? I had to do it twice in order to finally get it working.

Can't you enable multi-monitor support in AMD Catalyst Control Center? I use Nvidia and you must enable "DualView" in order to be able to configure the two displays separately. I'll try to check Avast in the next few days.

Feel free to ask all kinds of questions if there's anything unclear in what I've written HAL.DLL = hal.dll (the case doesn't matter) There are 8 different HALs in Windows 2000: How to Troubleshoot Windows 2000 Hardware Abstraction Layer Issues hal.dll halaacpi.dll halacpi.dll halapic.dll halborg.dll halmacpi.dll halmps.dll halsp.dll All of them are copied into "%windir%\driver cache\i386". Only one of them is renamed and copied into "%windir%\system32" as "hal.dll". In case of UURollup these files are used: hal.dll 5.0.2195.6693 halaacpi.dll 5.0.2195.6991 halacpi.dll 5.0.2195.6990 halapic.dll 5.0.2195.6803 halborg.dll 5.0.2195.6694 halmacpi.dll 5.0.2195.7011 halmps.dll 5.0.2195.7010 halsp.dll 5.0.2195.6694 Your "%windir%\system32\hal.dll" is actually halmacpi.dll renamed to hal.dll. It should have version number 5.0.2195.7011 but has only 5.0.2195.7007 since the new one wasn't installed by UURollup due to the problem which I described above. I hope that everything is clear now

There's a reason why I recommended to use my HFSLIP package. Slipstreaming all of the required updates is way easier than installing them manually in a running system If you wanted to have a fully updated system then you should install everything what is included in the HFSLIP archive but in reality you can just do this to update system core components. Install: USP5.1 from here (w2ksp51.7z) KB2797052 (I know that there's a newer IE Cumulative Update available but I haven't been able to add it to the Download Archive yet) Update Rollup 2 the latest weekly release of UURollup-v11 (available here). After that you can play around with XP drivers (but need to modify their INF files in most cases) and also try to enable PAE: Intel Physical Addressing Extensions (PAE) in Windows 2000

There's a very serious issue in all versions of UURollup (including v10 and older). The problem is that %windir%\system32\hal.dll isn't updated at all. The installer doesn't replace it and I don't know why (yet). The same problem exists in blackwingcat's kernel core package. The HAL related files from "%windir%\driver cache\i386" get updated but the one located in "%windir%\system32" does not. On the other hand, the official M$ hotfix KB835730 does replace it correctly. I've got some possible reasons for this situation in mind but I need to test them and find one which one is true. I know why it doesn't work... It's a technical issue so this information will be useful only for people who know how the M$ hotfix installer operates. The HAL files must be listed in update.ver in order to replace HAL.DLL from %windir%\system32. This issue does not affect slipstreaming, only manual installation.

How did you install the system exactly? Did you manage to use my HFSLIP package? If yes then the last weekly release of UURollup-v11 was already integrated in it and there's no need to install it separately.

The difference between "updates" and "hotfixes" is that the former fix security issues while the latter fix bugs. Also M$ don't test hotfixes as thoroughly as they test updates.

I think that I know why the driver may not work. It seems to caused be a bug in UURollup's installer @bluebolt Could you check file version of your HAL.DLL (%windir%\system32\hal.dll)?

I uploaded a new weekly version of UURollup-v11 just yesterday so you can use it instead of the daily one Have you tried Cobian Backup? It's free for both personal and commercial use and allows several different types of backups (differential, incremental, etc.).

What kind of source are you using? It should be a clean Windows 2000 (Service Pack number doesn't matter).

You don't install it. You need to copy your Windows 2000 source (=contents of your Windows 2000 CD) into the SOURCE folder. After that you can run the script. Check http://mimo.zxq.net/hfslip-basics.htm (Step 2).

That's why I started to add the "UU" prefix like when I was still preparing single unofficial updates, ex. Windows2000-UU-KB927489-v3-x86-Global.exe. This way you know that it's an unofficial package as soon as you look at its name. It's also very easy to filter when searching.

@jaclaz Well, the original question is: and my package is supposed to be an answer to that question The 48-bit LBA support is also included there.

I'd suggest a simple "one-click" solution. Just download my HFSLIP_ia.7z package, unpack it, copy your Windows 2000 source into the SOURCE folder and run the HFSLIP script. You need to do it under Windows NT 5.x (2000/XP/2003). After it's finished you'll have an (almost) fully updated Windows 2000 source ready to be installed. You can add SATA drivers for your controller using nLite and I'd suggest doing that instead of IDE mode. In order to use up to 8GB of memory you'll have to enable PAE but there may be actually a problem with the graphics driver. In the past I experienced a situation when the AMD graphics driver just wouldn't start when PAE was enabled. You should still try though. In the worst case the system will work without PAE and use between 2.75-3.75 GBs of memory. @Tommy With blackwingcat's core files you can use up to 8GB of RAM in any Windows 2000 edition

I have uploaded two new test releases of UURollup-v11. The first one is a new daily. I've added only one file which is Calculator (calc.exe) from Windows 2003 Server. I think that it just looks more elegant than the original one. The second one is a new weekly release. It's almost exactly the same as the previous daily but I've added an older version of urlmon.dll because the current one used in the daily releases is a Japanese file and the old one is in English. I've messaged blackwingcat about it. I've also uploaded a new HFSLIP_ia.7z package. It utilises the new weekly release of UURollup-v11. The new UURollup-v11 weekly can be also safely installed over UURollup-v10d. It's actually very likely that it will be possible to finally release a stable version of UURollup-v11 soon

Please let me know if you need more help with your Windows 2000 installation. I'd also strongly recommend reading this topic before using any of my unofficial packages

Could you check what hardware IDs of the devices are? Have a look at this post for a simple method describing how to do it. I included a simple manual for Application Compatibility Launcher on my website here. As for UURollup, just remember that it's recommended to have a fully updated system and Update Rollup 2 installed before applying it.