tomasz86

A meant something different While checking for unresolved imports is also important, Dependency Walker also lists all APIs used by a file and you can easily copy them to a text file and then compare the text files of two different versions of the same file to check what the differences are. For example: Original Win2k SP4 DBGHELP.DLL 5.0.2195.6613: EnumerateLoadedModules EnumerateLoadedModules64 ExtensionApiVersion FindDebugInfoFile FindDebugInfoFileEx FindExecutableImage FindExecutableImageEx FindFileInSearchPath GetTimestampForLoadedLibrary ImageDirectoryEntryToData ImageDirectoryEntryToDataEx ImagehlpApiVersion ImagehlpApiVersionEx ImageNtHeader ImageRvaToSection ImageRvaToVa MakeSureDirectoryPathExists MapDebugInformation SearchTreeForFile StackWalk StackWalk64 sym SymCleanup SymEnumerateModules SymEnumerateModules64 SymEnumerateSymbols SymEnumerateSymbols64 SymEnumerateSymbolsW SymEnumerateSymbolsW64 SymFunctionTableAccess SymFunctionTableAccess64 SymGetLineFromAddr SymGetLineFromAddr64 SymGetLineFromName SymGetLineFromName64 SymGetLineNext SymGetLineNext64 SymGetLinePrev SymGetLinePrev64 SymGetModuleBase SymGetModuleBase64 SymGetModuleInfo SymGetModuleInfo64 SymGetModuleInfoEx SymGetModuleInfoEx64 SymGetModuleInfoW SymGetModuleInfoW64 SymGetOptions SymGetSearchPath SymGetSymbolInfo SymGetSymbolInfo64 SymGetSymFromAddr SymGetSymFromAddr64 SymGetSymFromName SymGetSymFromName64 SymGetSymNext SymGetSymNext64 SymGetSymPrev SymGetSymPrev64 SymInitialize SymLoadModule SymLoadModule64 SymMatchFileName SymRegisterCallback SymRegisterCallback64 SymRegisterFunctionEntryCallback SymRegisterFunctionEntryCallback64 SymSetOptions SymSetSearchPath SymUnDName SymUnDName64 SymUnloadModule SymUnloadModule64 UnDecorateSymbolName UnmapDebugInformation WinDbgExtensionDllInit DBGHELP.DLL 5.1.2430.1 DbgHelpCreateUserDump DbgHelpCreateUserDumpW dh EnumerateLoadedModules EnumerateLoadedModules64 ExtensionApiVersion FindDebugInfoFile FindDebugInfoFileEx FindExecutableImage FindExecutableImageEx FindFileInPath FindFileInSearchPath GetTimestampForLoadedLibrary ImageDirectoryEntryToData ImageDirectoryEntryToDataEx ImagehlpApiVersion ImagehlpApiVersionEx ImageNtHeader ImageRvaToSection ImageRvaToVa lm lmi MakeSureDirectoryPathExists MapDebugInformation MiniDumpReadDumpStream MiniDumpWriteDump omap se SearchTreeForFile StackWalk StackWalk64 sym SymCleanup SymEnumerateModules SymEnumerateModules64 SymEnumerateSymbols SymEnumerateSymbols64 SymEnumerateSymbolsW SymEnumerateSymbolsW64 SymEnumSym SymEnumSymbols SymEnumTypes SymFindFileInPath SymFromAddr SymFromName SymFunctionTableAccess SymFunctionTableAccess64 SymGetFileLineOffsets64 SymGetLineFromAddr SymGetLineFromAddr64 SymGetLineFromName SymGetLineFromName64 SymGetLineNext SymGetLineNext64 SymGetLinePrev SymGetLinePrev64 SymGetModuleBase SymGetModuleBase64 SymGetModuleInfo SymGetModuleInfo64 SymGetModuleInfoEx SymGetModuleInfoEx64 SymGetModuleInfoW SymGetModuleInfoW64 SymGetNextEnumListMember SymGetOptions SymGetSearchPath SymGetSymbolInfo SymGetSymbolInfo64 SymGetSymFromAddr SymGetSymFromAddr64 SymGetSymFromName SymGetSymFromName64 SymGetSymNext SymGetSymNext64 SymGetSymPrev SymGetSymPrev64 SymGetTypeFromName SymGetTypeInfo SymInitialize SymLoadModule SymLoadModule64 SymMatchFileName SymRegisterCallback SymRegisterCallback64 SymRegisterFunctionEntryCallback SymRegisterFunctionEntryCallback64 SymSetContext SymSetOptions SymSetSearchPath SymSetSymWithAddr64 SymUnDName SymUnDName64 SymUnloadModule SymUnloadModule64 UnDecorateSymbolName UnmapDebugInformation WinDbgExtensionDllInit APIs present only in DBGHELP.DLL 5.0.2195.6613: none APIs present only in DBGHELP.DLL 5.1.2430.1: DbgHelpCreateUserDump DbgHelpCreateUserDumpW dh FindFileInPath lm lmi MiniDumpReadDumpStream MiniDumpWriteDump omap SymEnumSym SymEnumSymbols SymEnumTypes SymFindFileInPath SymGetFileLineOffsets64 SymGetNextEnumListMember SymGetTypeFromName SymGetTypeInfo SymSetContext SymSetSymWithAddr64 In this case it's clear that the latter is just an extension of the former. However, if you compare check DBGHELP.DLL 5.1.2600.5512 from XP SP3 you will see it lacks these four APIs from the original Win2k's DBGHELP.DLL: SymGetModuleInfoEx SymGetModuleInfoEx64 SymGetSymbolInfo SymGetSymbolInfo64

XP can be also "unbloated" and configured in a way that it will look and behave similar to Windows 2000. Of course you can't make it as slim as 2K but it still can be a usable OS. A lot of tweaking is required though. Most of the things you're interested in can be probably done in nLite. What do you mean by "flash"?

@Tihiy Just a short question. Once your patch has been applied and the explorer.exe from Windows 7 is being used, would it be possible to restore the Windows Classic theme too?

Well, I did install Windows 7 through USB 1.1 once It wasn't that bad - something about ~2 hours if I remember correctly.

Good point Although if it's USB 1.1 then I'd STRONGLY recommend a HDD based installation.

It's just a typo of mine You can safely ignore it.

As long as it's possible to boot from a USB stick on that laptop (which is probably quite old).

Thank you I meant simpler when compared to the other options where other tools must be used. It should be possible in case of these HIVE*.INF files because they utilise only English and Korean characters but how about unicode files where a lot of different languages are used like this one? Netrtle.7z If you check the [strings.*] sections you'll see that there are a lot of them for several different languages. If I try to convert such a file to ANSI then many characters are lost.

My hardware is actually pretty new (not the most recent one but still): AMD Athlon II X4 631 (FM1) ASRock A55 Pro3 Samsung DDR3 1333MHz 8 GB nVIDIA GeForce 6600 (I don't play any games or use any graphic intensive applications so no need for a newer one). 1xSSD / 4x HDD (some connected to the built-in controller and the rest to a PCI-E SAS controller) SoundBlaster Live! 24-bit I must say that not all of the drivers work in Win2k, ex. the ASMedia SATA3 drivers don't (but AMD SATA2 do) and USB3.0 drivers don't work too. Personally I've always liked nVIDIA because they provide far better drivers support than ATI/AMD. My GF6600 card was manufactured in 2004 and the latest drivers still support it despite the fact that the card is 8 years old.

How about starting the setup from DOS using WINNT.EXE? Check this topic.

@PROBLEMCHYLD How do you exactly check compatibility in Win9x? In Windows 2000 the first thing I do is to use Dependency Walker to check the dependencies and then, if everything seems to be OK, I try to test the file in a real environment. Is DBGHELP.DLL from Win2k compatible with Windows 98? If yes then you could try checking: DBGHELP.DLL 5.1.2430.1 DBGENG.DLL 5.1.2430.1 IMAGEHLP.DLL 5.1.2430.1 These files come from XP Beta ("Whistler") and are the last versions where all Win2k APIs are present together with some new APIs from XP. In the newer versions some of the original Win2k APIs are not present any more. The three files are interdependent so you need to install all of them at the same time. You can find them in UURollup-v10c.

In order to make the drivers' INF file work you need to change these lines: [Manufacturer] %ATI% = ATI.Mfg, NTx86 [ATI.Mfg.NTx86] to [Manufacturer] %ATI% = ATI.Mfg [ATI.Mfg]

This question is somewhat related to this topic but not exactly because now I'm just trying to set permissions in a running system. Does anyone know why this INF doesn't work? [Version] Signature="$Windows NT$" [DefaultInstall] AddReg=Test.AddReg [Test.AddReg] HKLM,"SOFTWARE\TEST" [Test.AddReg.Security] "D:P(D;;GA;;;SY)" The key itself is added to the registry but the permission settings don't work at all Edit: Some references from M$ which I've managed to find: http://msdn.microsoft.com/en-gb/library/aa379567.aspx http://msdn.microsoft.com/en-gb/library/aa377450.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/gg487483.aspx

I think that one very important thing to consider before switching to a x64 version of Windows is whether there exist x64 drivers for your hardware. In many cases there are NO x64 drivers for older devices like printers, scanners, etc.

Well, in this particular script the only "non-Windows" tool is gsar.exe... But at the moment I actually managed to solve this specific problem with this very simple checking: SETLOCAL ENABLEDELAYEDEXPANSION FINDSTR/IL "[Version]" I386\hivedef.inf >NUL IF !ERRORLEVEL! EQU 0 ( TYPE temp.txt>>I386\hivedef.inf ) ELSE ( CMD /U /C "TYPE temp.txt>>I386\hivedef.inf" ) FINDSTR can't find "[Version]" if the file is encoded in UCS-2 Little Endian.

It was a mistake You can find older versions of Catalyst drivers here. I wish I could help you more but I've got no hardware to test the drivers myself. I use a nVIDIA graphic card and even if I install just the driver (without all the additional panels, etc.) I can still adjust the resolution without any problems.

The latest drivers do work but require the unofficial kernel (the latest weekly/daily of UURollup or the BWC kernel). I've tested them on my computer with an old nVIDIA GF6600. I don't know yet about Dual Display support though.

Thanks for you suggestions! @allen2 It would be nice to be able to do it without any external application although I'll have a look at it if I can't manage to do it with just the Windows default tools. @jaclaz Can you view a text file in hex in the command-line? After googling the only "method" which I've managed to find is to use "debug.exe" but it actually displays "00"s in ANSI files too. I wonder what you think about this. If you ECHO something to a text file coded in UCS-2 Little Endian from CMD (without the /U switch) the text will be completely broken. I'm thinking about ECHOing a specific string to those HIVE*.INF files and then just search for it with FINDSTR. If it can't find it then it will mean that the file is UCS-2 Little Endian.

Is there any simple way to check text file encoding from command-line? I'm working on a script which adds lines to the I386\HIVE*.INF files in Windows 2000/XP source. In an English system those HIVE*.INF files are coded in ANSI but in a Korean Windows XP they're coded in UCS-2 Little Endian. I don't really need to know the specific encoding. I'd just like to know whether the file is ANSI or not.

Is there an exclamation mark next to the graphic card in the Device Manager? You may want to try installing one of the older drivers (11.x or 10.x). You'll also have to do it manually.

I don't know which version of the official drivers was the last one to support Win2k but the drivers ver. 10.x support only XP+. There are unfixed dependencies in them and they won't work in Win2k unless you: Install the unofficial kernel or Use BlackWingCat's drivers where the dependencies are fixed using files from KDW. You didn't explain any details about the BSOD related to UURollup but my wild guess is that IE5 might be a problem (you haven't mentioned anything about installing IE6). You might want to install either IE6 or USP5.1 (IE6 is included in it) and then try to install UURollup again.

I've uploaded a new weekly version of UURollup-v11. It's very similar to the last daily. I just added some cosmetic fixes and tested it more thoroughly. Important! It's impossible to slipstream it directly but you can put it in HFSVCPACK_SW1 while UURollup-v10c must be placed in HF at the same time.

Edit: Wrong topic

The unofficial kernels play this role. You've installed the daily version of UURollup-v11 in which the BlackWingCat's kernel its included. There's also KDW where you can manually change dependencies, change the User Agent, etc. The driver itself has been modified in order to work in Win2k. The problem here seems to be different. It seems that your graphic card's hardware ID is not supported by them. First of all, please try to download and install the other versions which I've just uploaded (12-6 and 11-12). This time I didn't remove any files, just changed the INF file in order to make it work in Win2k. Actually I believe that the newest driver may not be compatible with your graphic card... but 12-6 should work!

jaclaz How about this one SET tokens=1 :yanks FOR /F "tokens=%tokens% delims=;" %%A IN ("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") DO IF NOT "%%A"=="" (ECHO>>yanklines.vbs %%A& SET /a tokens+=1& GOTO :yanks) It's smaller (924 bytes vs. 998 bytes) and you also don't need to use any carets. The lines are merged into one and separated using semicolons.