tomasz86

If one wanted to have everything automated the tool would have to download Win7 SP1 (500MB), extract explorer.exe & explorer.exe.mui from there and then patch them.

@jvidal Because it's necessary to get the real value for %systemroot%. If you put %systemroot% in the reg file it will add it as "%systemroot%" while here it's required to be added as the real path. You can check the difference yourself between the one above (correct) and this one (incorrect): Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce] "KB2603381"="reg.exe ADD HKCR\\Package\\protocol\\StdFileEditing\\server /ve /d %systemroot%\\system32\\packager.exe /f"

What do you mean? Dexpot is free for personal use.

You do get the "not a valid Win32 application" error if you try to launch it in a stock Win2k... but then after UURollup is installed it still checks for the OS version and refuses to launch The registry setting from above does exactly the same thing as KDW. The problem is that it's not permanent. I'd be interested in modifying the dexpot.exe once and for all.

@Mim0 This reg file can be used instead of KB2603381 (HFSVCPACK_SW1): Windows2000-XP-2003-KB2603381-x86-XXX.reg Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce] "KB2603381"="cmd.exe /c \"reg.exe ADD HKCR\\Package\\protocol\\StdFileEditing\\server /ve /d %systemroot%\\system32\\packager.exe /f\""

The first test version of UURollup-v11 (UURollup-v11.20120722.142800) is ready. You can find it in the same location where .NET Framework test versions are available (see #1). Kernel32.dll has been replaced with the BWC version and some other files have been updated too. The newest XP updates (KB2655992 & KB2719985) have been added.

Yes. The error seems to be unrelated to the actual HDD space:

Yes, Opera 12.50 alpha works much better than the official "stable" 12.00 but it's still very far from perfect. By the way, the guys from http://dexpot.de/ did a lot of work to be sure that the new version of Dexpot 1.6 won't run in Win2k. It's built in VS2010 so by default it doesn't even launch in a stock Win2k... Normally the blockade is gone after installing unofficial kernel but not here. They even added a special "welcome" message which is displayed when trying to launch dexpot.exe after installing UURollup-v10b: I don't know how to patch the file (dexpot.exe) permanently but this reg files will let you switch dexpot.exe compatiblity on and off: Dexpot2k_ON.reg Dexpot2k_OFF.reg This is a temporary solution so if you reinstall the system or copy the Dexpot folder to a different system you'll have to add the registry entry again.

Opera 12 is extremely buggy in general, not only on Win2k. I think that it shouldn't have been released at all in the current form. In reality it seems to be still a beta, definitely not a stable version. And I knew it was buggy because I tried to use it as soon as the so called "stable" version was released... but it was impossible. At the moment the only version of Opera which can be used to browse the Web without experiencing (too many) problems is 11.64.

Well, frankly speaking, this is only my opinion but Opera for desktop seems to be almost dead anyway The only (really, not so called) stable version of Opera is 11.64 while the whole 12.xx series is extremely buggy. Opera has never been known for its stability (it used to crash on javascript / Flash a lot) but the current situation is just terrible. I always used Opera but recently have almost switched to Firefox as it's just much more stable, offers a lot of more functions and customisation, there are many more useful extensions available, etc. Opera's only advantage over Firefox is that it's faster (especially the fact that the UI is responsive even when many pages are being loaded which is a problem in Fx) but there are just too many other flaws.

@blackwingcat I wonder if it is possible to add DbgPrintEx to ntdll.dll. It's required by ABBYY FineReader and probably several other applications. The API is present in WildBill's ntdll.dll. Edit: Something is broken. I've tested Windows2000-KB935839-v17k-x86-ENU: 1. Installation -> no problem 2. Uninstallation -> no problem 3. Reinstallation-> and one more thing - you can't (un)register these files:

It was a typo. I meant Opera 12.50 The dependency was "GetUserGeoID" if my memory is right (I can't check at the moment). It's present in both unofficial kernels.

Corrected There exist browsers other than Chrome / Firefox / IE / Opera that do support Win2k. As for Opera 11.50 12.50: It requires uxtheme.dll and one dependency related to kernel32.dll in opera.dll to be fixed. It's still compiled in VS2008 (?) so no unofficial kernel is required to run.

You can use BlackWingCat's installer for newer versions of Firefox too, or use an alternative method: http://forums.mozillazine.org/viewtopic.php?f=23&t=2482475.

@blackwingcat I've tested different versions of your kernel32.dll: kernel32.dll 5.0.2195.7152 -> Firefox bug kernel32.dll 5.0.2195.7164 -> Firefox bug kernel32.dll 5.0.2195.7167 -> Firefox bug kernel32.dll 5.0.2195.7168 -> Firefox bug I've also checked Firefox itself: Firefox 14 (stable) -> no bug Firefox 15 (beta) -> bug Firefox 16 (aurora) -> bug It seems that all versions of Firefox newer than 14 have got this problem. On the other hand, there are no problems when WildBill's kernel32.dll (kernel32.dll 5.0.2195.7154 from KB2393802-v8) is used, regardless of Firefox' version. Please have a look at this issue when you've got some free time Edit: By the way, the problem from #202 still persists for the multiprocessor kernel.

I've been still working on UURollup-v11. Including files from BWC kernel is more difficult than I initially thought. The newest version of BWC's ntdll.dll adds support for RtlInitUnicodeStringEx which in consequence makes it possible to use httpapi.dll (What is httpapi?) in Win2k. This will influence .NET Framework because this function is used by both .NET 3.x and 4.x. At the moment I'm focused on integrating the files into UURollup, and after it is done I'm going to check its impact on .NET.

@blackwingcat Something seems to be broken in the newest versions of the kernel. If you start Firefox it will open two windows - a normal one and a second CMD window which doesn't close until you close Firefox itself. If you close the window then Firefox will also close. Edit: It's the new kernel32.dll to cause the problem.

As I said, I know nothing about VBS scripting You mean this, right? If WScript.Arguments.Count <> 2 then WScript.Quit end If Const ForReading = 1, ForWriting = 2 Dim i, j Set objFSO = CreateObject("Scripting.FileSystemObject") Set objInputFile = objFSO.OpenTextFile(WScript.Arguments.Item(0), ForReading) Set objOutputFile = objFSO.OpenTextFile (WorkingDir & WScript.Arguments.Item(1), ForWriting, True) Set objDict = CreateObject("Scripting.Dictionary") objDict.CompareMode = 1 j = 0 On Error Resume Next While Not objInputFile.AtEndOfStream arrinputRecord = split(objInputFile.Readline, "vbNewLine") strFirstField = arrinputRecord(0) If objDict.Exists(strFirstField) then j=j+1 Else objDict.add strFirstField, strFirstField End If Wend colKeys = objDict.Keys For Each strKey in colKeys objOutputFile.writeline objDict.Item(strKey) Next objInputFile.Close objOutputFile.Close

I've finally managed to make the script fully silent. Thanks, allen2 This is what I did. 1) I commented the following lines: WScript.Echo "usage: YankLines <input_filename> <output_filename>" WScript.Echo("Record: " & strFirstField) wscript.Echo "Total Records Writen: " & objDict.count wscript.Echo "Total Duplicates found: " & j and then changed: If scriptEngine = "WSCRIPT.EXE" Then to If scriptEngine = "CSCRIPT.EXE" Then After doing so there's no visible output anymore. This is a shrunken version of the whole script (all comments removed & case insensitive): RunMeWithCScript() If WScript.Arguments.Count <> 2 then WScript.Quit end If Const ForReading = 1, ForWriting = 2 Dim i, j Set objFSO = CreateObject("Scripting.FileSystemObject") Set objInputFile = objFSO.OpenTextFile(WScript.Arguments.Item(0), ForReading) Set objOutputFile = objFSO.OpenTextFile (WorkingDir & WScript.Arguments.Item(1), ForWriting, True) Set objDict = CreateObject("Scripting.Dictionary") objDict.CompareMode = 1 j = 0 On Error Resume Next While Not objInputFile.AtEndOfStream arrinputRecord = split(objInputFile.Readline, "vbNewLine") strFirstField = arrinputRecord(0) If objDict.Exists(strFirstField) then j=j+1 Else objDict.add strFirstField, strFirstField End If Wend colKeys = objDict.Keys For Each strKey in colKeys objOutputFile.writeline objDict.Item(strKey) Next objInputFile.Close objOutputFile.Close Public Sub RunMeWithCScript() Dim scriptEngine, engineFolder, Args, arg, scriptName, argString, scriptCommand scriptEngine = Ucase(Mid(Wscript.FullName,InstrRev(Wscript.FullName,"\")+1)) engineFolder = Left(Wscript.FullName,InstrRev(Wscript.FullName,"\")) argString = "" If scriptEngine = "CSCRIPT.EXE" Then Dim Shell : Set Shell = CreateObject("Wscript.Shell") Set Args = Wscript.Arguments For each arg in Args If instr(arg," ") > 0 Then arg = """" & arg & """" argString = argString & " " & Arg Next scriptCommand = "cmd.exe /c " & engineFolder & "cscript.exe //U """ & Wscript.ScriptFullName & """" & argString Shell.Run scriptCommand,,False Wscript.Quit Else Exit Sub End If End Sub

I guess I'll have to remake the .NET Framework installer from the beginning. The current version is affected by this issue. I've been doing my best to speed up the process of preparing USP5.2 but it won't be ready in the near future so... I've decided to keep updating UURollup (ENU) until the moment when the final version of USP5.2 is ready. UURollup-v11 is already prepared and I'm going to upload it in the next few days after I've done the final testing. UURollup-v11 is going to be a very important release because BWC kernel is used in it for the first time instead of WB kernel. Thanks to it many more applications should work correctly and much fewer "patches" will be required to run the other ones

I think that this line: ::Restore changes made to make the .inf "batch compatible" ::normalize "=" with one space on each side CALL :run_gsar :x3d :x20:x3d:x20 should be removed from beautify.cmd all together. It breaks lines like this one HKLM,"SOFTWARE\MozillaPlugins\@microsoft.com/WPF,version=3.5","GeckoVersion", ,"1.7.2" by putting spaces in it: HKLM,"SOFTWARE\MozillaPlugins\@microsoft.com/WPF,version = 3.5","GeckoVersion", ,"1.7.2"

Some programs require way more RAM than 3GB (even 32-bit programs if they use multiple processes)... I personally never disable pagefile. Windows shouldn't use it anyway as long as there's enough memory available.

The HAL shouldn't matter because even if you change from single CPU/core to multi-CPU/core you can always change the HAL in the Device Manager after doing so. I mean that if you change your CPU from a single-core to a multi-core one Windows will still see only one core until you change the HAL manually.

I don't use Windows 8 myself but I just want to say thank you Tihiy for this awesome patcher you've been developing

Well, the Win2k support has been dropped in the latest development snapshot of Opera 12 released yesterday It does work after changing the dependencies (no unofficial kernel/updates required) but the browser itself is still extremely buggy. Actually, it seems that Firefox 10 ESR is the only (stable) major browser officially supporting the system. Firefox 10 ESR is going to be supported until Firefox 19 is released (info). Standard versions of Firefox starting from v13 require the unofficial kernel to run. On the other hand, if someone doesn't want to / cannot use the unofficial kernel then there are other small browsers like Qupzilla which are actively developed and do work in a stock Win2k (Qupzilla uses Webkit engine so it's also very fast). Edit: If someone still wants to install the newest development build of Opera 12 without too much hassle then install BWC kernel first, and after that you will be able to run the Opera 12.50 alpha installer normally. One good thing is that the UI freezes so common in all previous builds of Opera 12 seem to be really gone in this one. Edit2: By the way, this development snapshot is way more stable then the "official" release.