tomasz86 Posted October 8, 2012 Posted October 8, 2012 @PROBLEMCHYLDHow 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.1DBGENG.DLL 5.1.2430.1IMAGEHLP.DLL 5.1.2430.1These 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.
PROBLEMCHYLD Posted October 9, 2012 Posted October 9, 2012 How do you exactly check compatibility in Win9x?The first thing I do is a clean install. After that, I register files whether its needed or not. This way I see if any new keys are added or if there is any corruption. I then test windows only apps [NOT ALL] because I use 98lite. If all apps are working, no memory leaks, no pop ups, no resource leaks etc... the list goes on.......... I then start adding the software I use. If I don't find any problems within a week or so, I'll call it Golden As I said earlier, I might overlook things. This is when the testers come in.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?Problem:Dependency Walker shows unresolved imports even if program works correctly.Solution:This behaviour is expected by design. Don't depend on Dependency Walker.This is one of the reason I don't use it. Its like a bad virus scanner that gives a lot of false positives. If yes then you could try checking:IMAGEHLP.DLL 5.1.2430.1I already I have this included. I'll test the other files and see how they go. Thank you very much for your input.
tomasz86 Posted October 10, 2012 Posted October 10, 2012 Problem:Dependency Walker shows unresolved imports even if program works correctly.Solution:This behaviour is expected by design. Don't depend on Dependency Walker.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:EnumerateLoadedModulesEnumerateLoadedModules64ExtensionApiVersionFindDebugInfoFileFindDebugInfoFileExFindExecutableImageFindExecutableImageExFindFileInSearchPathGetTimestampForLoadedLibraryImageDirectoryEntryToDataImageDirectoryEntryToDataExImagehlpApiVersionImagehlpApiVersionExImageNtHeaderImageRvaToSectionImageRvaToVaMakeSureDirectoryPathExistsMapDebugInformationSearchTreeForFileStackWalkStackWalk64symSymCleanupSymEnumerateModulesSymEnumerateModules64SymEnumerateSymbolsSymEnumerateSymbols64SymEnumerateSymbolsWSymEnumerateSymbolsW64SymFunctionTableAccessSymFunctionTableAccess64SymGetLineFromAddrSymGetLineFromAddr64SymGetLineFromNameSymGetLineFromName64SymGetLineNextSymGetLineNext64SymGetLinePrevSymGetLinePrev64SymGetModuleBaseSymGetModuleBase64SymGetModuleInfoSymGetModuleInfo64SymGetModuleInfoExSymGetModuleInfoEx64SymGetModuleInfoWSymGetModuleInfoW64SymGetOptionsSymGetSearchPathSymGetSymbolInfoSymGetSymbolInfo64SymGetSymFromAddrSymGetSymFromAddr64SymGetSymFromNameSymGetSymFromName64SymGetSymNextSymGetSymNext64SymGetSymPrevSymGetSymPrev64SymInitializeSymLoadModuleSymLoadModule64SymMatchFileNameSymRegisterCallbackSymRegisterCallback64SymRegisterFunctionEntryCallbackSymRegisterFunctionEntryCallback64SymSetOptionsSymSetSearchPathSymUnDNameSymUnDName64SymUnloadModuleSymUnloadModule64UnDecorateSymbolNameUnmapDebugInformationWinDbgExtensionDllInitDBGHELP.DLL 5.1.2430.1DbgHelpCreateUserDumpDbgHelpCreateUserDumpWdhEnumerateLoadedModulesEnumerateLoadedModules64ExtensionApiVersionFindDebugInfoFileFindDebugInfoFileExFindExecutableImageFindExecutableImageExFindFileInPathFindFileInSearchPathGetTimestampForLoadedLibraryImageDirectoryEntryToDataImageDirectoryEntryToDataExImagehlpApiVersionImagehlpApiVersionExImageNtHeaderImageRvaToSectionImageRvaToValmlmiMakeSureDirectoryPathExistsMapDebugInformationMiniDumpReadDumpStreamMiniDumpWriteDumpomapseSearchTreeForFileStackWalkStackWalk64symSymCleanupSymEnumerateModulesSymEnumerateModules64SymEnumerateSymbolsSymEnumerateSymbols64SymEnumerateSymbolsWSymEnumerateSymbolsW64SymEnumSymSymEnumSymbolsSymEnumTypesSymFindFileInPathSymFromAddrSymFromNameSymFunctionTableAccessSymFunctionTableAccess64SymGetFileLineOffsets64SymGetLineFromAddrSymGetLineFromAddr64SymGetLineFromNameSymGetLineFromName64SymGetLineNextSymGetLineNext64SymGetLinePrevSymGetLinePrev64SymGetModuleBaseSymGetModuleBase64SymGetModuleInfoSymGetModuleInfo64SymGetModuleInfoExSymGetModuleInfoEx64SymGetModuleInfoWSymGetModuleInfoW64SymGetNextEnumListMemberSymGetOptionsSymGetSearchPathSymGetSymbolInfoSymGetSymbolInfo64SymGetSymFromAddrSymGetSymFromAddr64SymGetSymFromNameSymGetSymFromName64SymGetSymNextSymGetSymNext64SymGetSymPrevSymGetSymPrev64SymGetTypeFromNameSymGetTypeInfoSymInitializeSymLoadModuleSymLoadModule64SymMatchFileNameSymRegisterCallbackSymRegisterCallback64SymRegisterFunctionEntryCallbackSymRegisterFunctionEntryCallback64SymSetContextSymSetOptionsSymSetSearchPathSymSetSymWithAddr64SymUnDNameSymUnDName64SymUnloadModuleSymUnloadModule64UnDecorateSymbolNameUnmapDebugInformationWinDbgExtensionDllInitAPIs present only in DBGHELP.DLL 5.0.2195.6613:noneAPIs present only in DBGHELP.DLL 5.1.2430.1:DbgHelpCreateUserDumpDbgHelpCreateUserDumpWdhFindFileInPathlmlmiMiniDumpReadDumpStreamMiniDumpWriteDumpomapSymEnumSymSymEnumSymbolsSymEnumTypesSymFindFileInPathSymGetFileLineOffsets64SymGetNextEnumListMemberSymGetTypeFromNameSymGetTypeInfoSymSetContextSymSetSymWithAddr64In 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:SymGetModuleInfoExSymGetModuleInfoEx64SymGetSymbolInfoSymGetSymbolInfo64
PROBLEMCHYLD Posted October 10, 2012 Posted October 10, 2012 Thanks, but the WinXP Beta version lacks a lot more functions than the newer versions after compared. I would assume Microsoft removed those functions because they were not needed or superceded by newer functions. Also, if I use a newer version, I don't need to add DBGENG.DLL 5.1.2430.1 because the newer files is not depended on the others. Thanks again. I'll be testing DBGHELP.DLL 6.8.4.0. This version seems to be the last one working for Win98.
tomasz86 Posted October 10, 2012 Posted October 10, 2012 Thanks, but the WinXP Beta version lacks a lot more functions than the newer versions after compared. I would assume Microsoft removed those functions because they were not needed or superceded by newer functions.But you never know if there aren't any other system files relying on those functions unless you check ALL of them with Dependency Walker (which is likely impossible).
Drugwash Posted October 10, 2012 Posted October 10, 2012 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:SymGetModuleInfoExSymGetModuleInfoEx64SymGetSymbolInfoSymGetSymbolInfo64Those four API are (apparently) exported by IMAGEHLP.DLL 5.00.2178.1. Later XP-SP3 version 5.1.2600.5512 does not export them anymore. Therefore best combination seems to be IMAGEHLP.DLL 5.00.2178.1 and DBGHELP.DLL 6.8.0004.0, unless there's other intermediary version that still exports them APIs.I'm working on a tool that'd automatically find best choice, but it's still in alpha stage, incomplete and with a few bugs. Please bear with me, I'm well-intended but very slow.
PROBLEMCHYLD Posted October 10, 2012 Posted October 10, 2012 (edited) Thanks Drugwash and tomasz86.What do you SP users think about me adding this registry keyREGEDIT4[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA]"LMCompatibility"=dword:00000003;It is essential to Win98 networking. It applies to any operating system that uses NTLM security. It will not break anything on the system. The reason I'm asking is because everyone don't have a network. Just to have it there is good incase needed in the future. Edited October 10, 2012 by PROBLEMCHYLD
Drugwash Posted October 10, 2012 Posted October 10, 2012 I say: unless it breaks anything, let it in. I got it there as part of my home network (which does involve Win7 and is not perfect but still workable using simple workaround - see my input in the Win98-Win7 connection thread).Let's hear from other people now.
tomasz86 Posted October 10, 2012 Posted October 10, 2012 Those four API are (apparently) exported by IMAGEHLP.DLL 5.00.2178.1. Later XP-SP3 version 5.1.2600.5512 does not export them anymore. Therefore best combination seems to be IMAGEHLP.DLL 5.00.2178.1 and DBGHELP.DLL 6.8.0004.0, unless there's other intermediary version that still exports them APIs.I'm looking forward to test the tool The last version of IMAGEHLP.DLL I know of which still supports the APIs is IMAGEHLP.DLL 5.1.2430.0 which I've already mentioned above.
PROBLEMCHYLD Posted October 10, 2012 Posted October 10, 2012 BindImage BindImageEx CheckSumMappedFile EnumerateLoadedModules EnumerateLoadedModules64 FindDebugInfoFile FindDebugInfoFileEx FindExecutableImage FindExecutableImageEx GetImageConfigInformation GetImageUnusedHeaderBytes GetTimestampForLoadedLibrary ImageAddCertificate ImageDirectoryEntryToData ImageDirectoryEntryToDataEx ImageEnumerateCertificates ImageGetCertificateData ImageGetCertificateHeader ImageGetDigestStream ImagehlpApiVersion ImagehlpApiVersionEx ImageLoad ImageNtHeader ImageRemoveCertificate ImageRvaToSection ImageRvaToVa ImageUnload MakeSureDirectoryPathExists MapAndLoad MapDebugInformation MapFileAndCheckSumA MapFileAndCheckSumW ReBaseImage ReBaseImage64 RemovePrivateCvSymbolic RemovePrivateCvSymbolicEx RemoveRelocations SearchTreeForFile SetImageConfigInformation SplitSymbols StackWalk StackWalk64 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 TouchFileTimes UnDecorateSymbolName UnMapAndLoad UnmapDebugInformation UpdateDebugInfoFile UpdateDebugInfoFileExThe last version of IMAGEHLP.DLL I know of which still supports the APIs is IMAGEHLP.DLL 5.1.2430.0 which I've already mentioned above.The version IMAGEHLP.DLL 5.00.2178.1 is from Win ME and Drugwash is right. The Win ME versions has 99 export functions and the Win XP Beta cersion has 111 export functions. The Win XP Beta files are depended of each others while the others are not. I use the tool DLL Export Viewer v1.60 in case you were wondering
Drugwash Posted October 10, 2012 Posted October 10, 2012 I think tomasz86's IMAGEHLP.DLL 5.1.2430.0 version is safe to use (roughly checked though). Some of the API are either duplicated between imagehlp and dbghelp, or forwarded from one-another - my tool still cannot differentiate between original exports and forwardings.I'll make the tool available as soon as I clean the current bugs. Certain options will need much more work but at least basic functionality will be there in first public version.I'll need some more attachment space here, otherwise it'll have to go through e-mail.
PROBLEMCHYLD Posted October 10, 2012 Posted October 10, 2012 (edited) But then what about DBGENG.DLL 5.1.2430.1? This means we couldn't use the new DBGHELP.DLL 6.8.4.0 which IMO serves no purpose with only DBGENG.DLL 5.1.2430.1IMAGEHLP.DLL 5.1.2430.1or am I missing something? Or should I avoid using DBGENG.DLL 5.1.2430.1 altogether?I do have the following running on a test machine now DBGHELP.DLL 5.1.2430.1DBGENG.DLL 5.1.2430.1IMAGEHLP.DLL 5.1.2430.1 Edited October 10, 2012 by PROBLEMCHYLD
Drugwash Posted October 11, 2012 Posted October 11, 2012 Since DBGENG.DLL 5.1.2430.1 will only load DBGHELP.DLL with the same version and nothing else (it most likely performs an internal version check on the available dependencies and discards anything that doesn't match version and/or location), I'd say just forget about it.I do have a newer version of DBGENG here (from Debugging Tools for Windows) - namely 6.6.0007.5, but I have a hunch it may not be fully compatible with Win9x since it only imports the Unicode versions of certain API from other modules and that usually is a sign that ANSI compatibility does not exist (at least in portions of the internal code). Might not even be redistributable, if I read the licence correctly.Now, all XP flavors I've looked into, used DBGENG.DLL 5.1.2600.0 and it was also bound to its own paired DBGHELP.DLL, so that one is a no-no too. However, a couple of Windows 2003 versions - namely 5.2.3790.1830 and 5.2.3790.3959 - loaded fine with the default DBGHELP 6.8.0004.0 from my System folder, which means they're not bound to any particular version, therefore any of them may be a worthy replacement for the "stubborn" 5.1.x.x series.In regard to the four missing APIs, I've performed a couple of searches on my 98SE machine (Program Files and Windows\System) and on a XP-SP3 machine (whole C drive). Query keyword was "SymGetModuleInfoEx", which is one of the missing APIs.• On the 98SE machine I found it mentioned in ApiViewer 2004's database. Opening the application, I found all four APIs complete with prototypes but no details on them.• On the XP machine I found it mentioned inside a virtual machine image (.vhd) that holds a long forgotten Windows 95 test installation.• MSDN 2005 doesn't list it, nor is it mentioned anywhere (a search turned out empty). Actually none of the four appear anywhere in my local MSDN.Based on the above, I would safely assume that the four missing APIs in IMAGEHLP.DLL are not widely used - if at all - and might be safe enough to upgrade this library to a newer version, provided it matches its dependencies. If anyone else knows better, please come forward with details.
erpdude8 Posted October 12, 2012 Posted October 12, 2012 U98SESP3.9 coming in a few weeks This will give you guys some time while I work on configuring my Win 7.DBGHELP.DLL 6.0.17.0 ??? Need some more info on this file. Google runs me in circles JSCRIPT.DLL 5.6.0.8850 Windows Server 2003 SP2VBSCRIPT.DLL 5.6.0.8850 Windows Server 2003 SP2you could also include the modified VCACHE.VXD v4.10.0.2223 file dated 9/20/2012 from the Vcache fix attempt forum thread into the next release of your SP as QFECheck and ME explorer shell from 98SE2ME will correctly identify the version number as build 2223.
tomasz86 Posted October 12, 2012 Posted October 12, 2012 Based on the above, I would safely assume that the four missing APIs in IMAGEHLP.DLL are not widely used - if at all - and might be safe enough to upgrade this library to a newer version, provided it matches its dependencies. If anyone else knows better, please come forward with details.I can only say that in the past I did try to replace Win2k's DBGHELP.DLL with the one from XP SP3. The system became unstable (Explorer was restarted randomly). Everything was fixed after restoring the original version.
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now