The aim of this series is to re-implement dbghelp.EnumerateLoadedModules* in order to match Windows' behavior (especially in wow64 environments).
The serie includes: - a bunch of tests to compare 3 different sets of loaded modules: + the load DLL debug events (generated by kernel) + the output of dbghelp.EnumerateLoadedModules(), which is a wrapper around kernel32.EnumProcesModulesEx (yet modifying some information) + the actual list of loaded modules in dbghelp (SymEnumerateModules). => the later list can be populated automatically from the second if requested to dbghelp (this is what is tested). => for the record, winedbg uses the first set to populate the third set. We just test the content of first set, not the population to the third. - the reimplementation of EnumerateLoadedModules to match Window's behavior (especially regarding paths information)
Despite the three sets look similar, they have quite a few differences to be taken care of (especially in wow64 setup).
Note: having the correct paths (esp. in wow64) is important as dbghelp sometimes tries some wild guesses based on the path (like bitness <g>) or (in some other places) don't rely on path information and retries things on its own. The long target is to simplify the module lookup by relying on more solid information.
@julliard: the paths for wow64 modules returned from kernel32 don't match windows behavior: wine returns 32bit system modules from c:\windows\syswow64 whereas windows returns them from c:\windows\system32 (except a couple of exceptions: 32bit ntdll and exe main module). Implementation in dbghelp includes the correction of this. (I opted not to change ntdll at once: testing on windows show that kernel32.EnumProcesModulesEx returns exactly the ldr_data list, and I didn't feel like adding this burden to this patch ;-).
Let me know if you want ntdll to be fixed before this patch.