jumper

fwd: DLL forwarder For inserting new exports into a primary DLL that forward to a secondary DLL Also: Correct the Link Checksum of any PE file fwd.03.zip Features: Displays Export Table and corrects Link Checksum of primary DLL or PE file. Adds forwarders to the primary DLL for all functions exported by name from the secondary DLL. Original primary file is backed up if changed. TimeDateStamp and MinorVersion fields of IMAGE_EXPORT_DIRECTORY are bumped by one per function added. Usage: fwd primary.dll [secondary.dll] Outputs:primary.dll, fwd.log, primary.<nnn> Notes: For drag-and-drop launching, select one or two DLLs and then drag the primary onto fwd.exe. For SendTo launching, select one or two DLLs and then right-click on the primary DLL. To do: Expand size of physical section containing export table when needed. Append ".DLL" to filenames when needed for easier command-line launching. Dialog box for interactive selection of functions by name or ordinal, with renaming option. Older versions:fwd.01.exe fwd.02.zip

I've been working hard on this problem and should have a major announcement by tonight (bigger than just PrintDlgEx). <edit>Today didn't go as planned and I've been away from my computer all day. So here's a sneak preview: fwd. </edit>

Perhaps we should consider a bi-level development effort that include a heavy-duty build environment for the maintainer(s) (or anyone wishing to do a full build), and a light-weight development system for contributors. Has anyone used LCC, Lcc-win32, or Pelles C? Actually, any language could be used for contributed modules. Any compiler/linker that can produce a PE32 DLL would do. The core would just need to be modified to scan all DLLs in the KernelEx folder for a function before using an internal stub or failing.

MSDN - Using Common Dialog Boxes Displaying the Print Dialog Box Using the Print Property Sheet HRESULT WINAPI PrintDlgExA (PRINTDLGEX *pPdex) { PRINTDLG pd; pd.lStructSize = sizeof(PRINTDLG); pd.hwndOwner = pPdex->hwndOwner; pd.hDevMode = pPdex->hDevMode; pd.hDevNames = pPdex->hDevNames; pd.hDC = pPdex->hDC; pd.Flags = PD_USEDEVMODECOPIESANDCOLLATE | PD_RETURNDC; // pPdex->Flags; pd.nCopies = 1; pd.nFromPage = 0xFFFF; pd.nToPage = 0xFFFF; pd.nMinPage = pPdex->nMinPage; pd.nMaxPage = pPdex->nMaxPage; pd.nCopies = pPdex->nCopies; pd.hInstance = pPdex->hInstance; pd.lCustData = 0; pd.lpfnPrintHook = NULL; pd.lpfnSetupHook = NULL; pd.lpPrintTemplateName = pPdex->lpPrintTemplateName; pd.lpSetupTemplateName = NULL; pd.hPrintTemplate = NULL; pd.hSetupTemplate = NULL; if (PrintDlgA (&pd)) { pPdex->dwResultAction = 1; // Print //pPdex->lStructSize; //pPdex->hwndOwner; pPdex->hDevMode = pd.hDevMode; pPdex->hDevNames = pd.hDevNames; pPdex->hDC = pd.hDC; //pPdex->Flags; //pPdex->Flags2; //pPdex->ExclusionFlags; pPdex->nPageRanges = 0; pPdex->nMaxPageRanges = 0; pPdex->lpPageRanges = NULL; pPdex->nMinPage = pd.nMinPage; pPdex->nMaxPage = pd.nMaxPage; pPdex->nCopies = pd.nCopies; //pPdex->hInstance; //pPdex->lpPrintTemplateName; //pPdex->lpCallback; //pPdex->nPropertyPages; //pPdex->*lphPropertyPages; //pPdex->nStartPage; } else { pPdex->dwResultAction = 0; // Cancel } return 0; // S_OK; } I haven't researched and doubled checked every field yet--some are guesses. What am I missing before I try to compile it? Does anyone know if PRINTDLG is packed? If so, all DWORDs after the five WORDs are misaligned!

As previously mentioned in the SP3 thread, six files in SP3 contain references to PrintDlgEx: - tweakui.cpl, hypertrm.dll, mfc70.dll, mfc70u.dll, mfc71.dll, mfc71u.dll Dependency Walker reports "Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module." in all but hypertrm.dll. I've searched all my local exe and dll files and can't find any meaningful references to PrintDlgEx other than in mfc7*. I'm searching now for references to mfc7--if I don't find much, it might not be much of an issue for apps that don't otherwise need Kex. mfc7 references found in: - video2smv.exe / smv.dll - SUPERsetup.exe - vdm_free.exe - avformat-52.dll (ffmpeg) I'm on my way out the door right now--I'll post translation code for review tonight.

I've removed NT Services from the wish list. If anyone wants it back on, they'll need to be very specific about what feature they want to see and very persuasive as to why it can only be implemented as a service.

Patching the KernelEx stub does nothing for those who don't use KernelEx. Having the KernelEx stub source is only useful if I do recompile it. The safest and most efficient strategy would be to recompile rather than patch KernelEx. Since I'm still working on getting KernelEx to compile, I should probably finish that step first.

Several weeks ago I was investigating this exact problem. PrintDlgEx uses a new PRINTDLGEX parameter structure that is incompatible with PrintDlg's new PRINTDLG. If we can implement an even semi-functional PrintDlgEx, it would probably go a long way towards solving printing issues in many new apps. KernelEx currently has a stub for PrintDlgEx that just returns an error. That stub could be rewritten to call PrintDlg, translating between parameter structures. I think I can patch comdlg32.dll to export PrintDlgEx instead of PrintDlg and inject the needed translation code into the existing function. This patched version would no longer export PrintDlg, so would have to be stored local to the app (not in <system>); or it could be renamed comdlgex.dll and apps would need to have their imports patched to access it. I have also been considering ways to inject the needed translation code directly into the calling app. Another possibility is to redirect the call, not to PrintDlg, but to the custom print dialog of another (MS?) app. If we can find one that uses the new PRINTDLGEX structure, that would be ideal. Research in this area would be very helpful MSDN: PRINTDLG typedef struct tagPD { DWORD lStructSize; HWND hwndOwner; HGLOBAL hDevMode; HGLOBAL hDevNames; HDC hDC; DWORD Flags; WORD nFromPage; WORD nToPage; WORD nMinPage; WORD nMaxPage; WORD nCopies; HINSTANCE hInstance; LPARAM lCustData; LPPRINTHOOKPROC lpfnPrintHook; LPSETUPHOOKPROC lpfnSetupHook; LPCTSTR lpPrintTemplateName; LPCTSTR lpSetupTemplateName; HGLOBAL hPrintTemplate; HGLOBAL hSetupTemplate; } PRINTDLG, *LPPRINTDLG; MSDN: PRINTDLGEX typedef struct tagPDEX { DWORD lStructSize; HWND hwndOwner; HGLOBAL hDevMode; HGLOBAL hDevNames; HDC hDC; DWORD Flags; DWORD Flags2; DWORD ExclusionFlags; DWORD nPageRanges; DWORD nMaxPageRanges; LPPRINTPAGERANGE lpPageRanges; DWORD nMinPage; DWORD nMaxPage; DWORD nCopies; HINSTANCE hInstance; LPCTSTR lpPrintTemplateName; LPUNKNOWN lpCallback; DWORD nPropertyPages; HPROPSHEETPAGE *lphPropertyPages; DWORD nStartPage; DWORD dwResultAction; } PRINTDLGEX, *LPPRINTDLGEX;

VidEdit (search for videdit.zip)

MS intended NtQueryInformationProcess to be an internal function for OS use only. Their tools don't let us static link to it, but they do. NtQueryInformationProcess provides process and thread details that cannot all be obtained through other APIs. As NtQueryInformationProcess is not available on 9x (and can't be simulated) any DLLs (or apps) that call it should be avoided! In your case it appears to be the version of ntdll.dll you are using that is the one to be avoided. If you really must use this version for a given app, unregister it from "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs" and put a copy of the dangerous version directly into the folder of any app that really needs it. The version in <system> should be a 9x-safe version! Also, KernelEx comes with a version of USERENV.dll; try copying it from <windir>\KernelEx to <system> to resolve that missing dependency issue.

I would open the file and map it as an array of dwords (using an existing function). If the data was presorted, a simple binary search would quickly find the count. Otherwise you're right, 73KB would still be too big for the PrivateProflle functions: Each line in an INI file would need one byte for the '=', one byte for the count, and one byte for the EOL marker. That leaves less than one byte for the name/hash/crc string! We might be able to get to 24 bits if we can: get below 16k functions by removing those with the most common count (1 or 2 maybe?); that count would become the default for functions not found group functions into sections and reclaim the '=' and <count> bytes. Early versions of ImportPatcher could batch process multiple files. When I added INI support, I found SE wasn't letting me access multiple PrivateProfile INI files. Once I picked one, I had to stick with it. So I dropped batch processing. Unless I can figure out how to easily work around this issue, even a single INI (in addition to the main #.ini) might not be an option. I don't think NtQueryInformationProcess can be static linked to--no import library for it. Though for completeness, a good idea to add it. Thanks.

Here is the aforementioned INI file with 18301 API parameters counts: APIParameterCounts.zip Last week I did try accessing it from IP using GetPrivateProfileString and it worked great--the first 64KB that is. The other 406KB - 64KB can't be accessed that way. I converted it to a REG file, hoping to be able to access it from the transient portion of the registry with RegQueryValue, but REG files can only add to the on-disk keys and that also takes several minutes. The current plan is to do a quick 27-bit hash or crc on the function names to reduce the data size (27+5 for the [0..23] count = 32). Or I might just split the data over seven INI files.

The trailing spaces are an indentation for a missing log message. This only happens when wsprintf encounters an error (usually an access violation in one of the parameters) and emits no text. I was able to reproduce this condition in a way that resembled divad's log file by intentionally using an invalid pointer for the delay-import ILT address. I then modified my PEfinder test app to search my local drives for apps with invalid delay-import ILT addresses. I found five. All had been UPX'ed. UPX compression abbreviates the import tables and corrupts the delay-import table (if any). This works because the system loader doesn't check the delay-import table and the UPX decompressor restores it for normal use later. Tools like Dependency Walker can only report that the address is invalid. Other compressors may also corrupt the delay-import table, but I found no such examples on my local drives. PEfinder also uncovered one app that stored the parallel ILT and IAT tables in different sections. In this case it wasn't a problem, but theoretically it could be. So I rewrote the rva-to-pointer routine to lookup every address in the section tables without making any assuptions, no matter how reasonable they might seem to be! Well, PEfinder only opens one file at a time, while ImportPatcher opens two (or more if walking) at a time. So the new rva-to-pointer routine was difficult to port and required lots of extra support code and modifications. However, IP.35 now seems to be working and will be released as soon I finish regression testing it.

I don't follow. The hypertrm.dll is from Winxp. I don't use kernelex. I only install it when testing the service pack. On December 19, I extracted all files from all four cabinets of the 'final' version of U98SESP3. These six files were in there. If you haven't removed HYPERTRM.DLL (and *.EXE, *.CHM, *.HLP) from SP3.CAB, then they are still in there. BTW, how did U98SESP3 go from "final" last month to "beta" this month? Shouldn't this beta be 3.1?

Yes, it's a great wish. I've quoted the entire discussion and replied on the 2012 Project Wish List thread in post #39.

The following discussion has Wish List written all over it. Would it be possible to limit the resources available to an app in any way other than to hook the various allocation and creation APIs to fail if the calling process has reached its limit?

These files all make delay-load calls to PrintDlgExA in COMDLG32.DLL which requires KernelEx (or a 2K version, not in this pack): HYPERTRM.DLL MFC70.DLL MFC70U.DLL MFC71.DLL MFC71U.DLL TWEAKUI.CPL

Have you tried FineSSE?

I use TaskInfo2000 v2.1 by Igor Arsenin Amongst many other things, for each process it lists: Data KB (total, in memory, in use) Code KB (total, in memory, in use) Handles count Windows It uses low resources itself, updates every two second, and shows most of what VWin32 reports (and much more).

As it turns out, the loader will append '.dll' to an import DLL name as needed, so 'msvrt.dll' can be replaced with 'msvcr70' without needing to rename it to 'msvcr7.dll'. Ignore the mention of ordinals for now. IP won't support replacement-by-ordinal until the next version. If you modify your Inkscape patch to use IPstub.dll, it should work. Otherwise try patching a copy of IP itself as I showed. IPstub.dll works the same as your dnsapi.dll/stub.dll, but with a wider variety of stubs and diagnostics functions to choose from. Function names are all two characters to ensure they're not too long: p1 p2 p3 p4 p5 p6 p7 p8 p9 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 o0 o1 o2 o3 o4 o5 o6 o7 o8 o9 t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 yn op bp If the functions aren't being called, any function will work (just like in your dnsapi.dll). Otherwise choose a stub with the desired return code and parameter count. (A quick search of MSDN should yield these.) If you run IP.34 on Inkscape you should be able to make this replacement in the .ini file: [DLL substitutions] dnsapi.dll=IPstub.dll Then [ Retry ] and: [IPstub.dll] DnsQuery_A=f6 DnsRecordListFree=f2 [ Retry ] again to patch. IPstub.dll can be in the app folder, <system>, <windows>, or anywhere in the normal PATH. Just the type of feedback I love to hear! It was always optional (editable in .ini), but defaulted to 'Y' if walking and 'N' if not.

Searching for "windows api parameter count" lead me to these header resources: Jeremy Gordon's Go Tools site -> #headers Donkey's Stable -> GoAsm Headers -> HEADERS.ZIP Bryant Keller's header files: WIN32A.zip Expanding WIN32A.ZIP, I found WIN32P.INC and the following: _LocalEnroll() requires 23 arguments. _LocalEnrollNoDS() requires 23 arguments. These seem to be from CRYPTUI.dll I've used DOS FIND to extract the lines containing 'requires' and then the DevStudio '97 text replace function to create an .ini file with 17986 18300 API parameter counts: [ParameterCounts] CreateSecurityPage=1 EditSecurity=2 IID_ISecurityInformation=1 ADsBuildEnumerator=2 ...

Fortunately CreateFontA has been in GDI32 since Win32s so we don't need a stub for it. We can cross other bridges when we come to them. Do you know of any recent comprehensive lists of functions similar to the old WIN32API.CSV? I may need to bite the bullet and download a recent platform SDK, then look at the header files.

IPstub.dll is a library of 42 small functions that can be used to plug holes left by missing imports. There are four basic stub families and three debugging stubs. Basic stub families: n = 0..9 (0 to 9 32-bit parameters) pn (p1..p9): return <parameter 1> fn (f0..f9): return flast / 0 on (o0..o9): return one / 1 tn (t0..t9): return true / -1 Ordinal assignment (@1..@39): 4*n + { pn:0 | fn:1 | on:2 | tn:3 } (There is no p0: can't return 1 of 0 parameters, ordinals start at 1) Debugging stubs: yn @ 40 : Yes/No/Cancel messagebox [ Yes ] returns true [ No ] returns false [ Cancel ] calls ExitProcess(-1) - zero parameters op @ 41 : Cascading Yes/No/Cancel messageboxes [ Yes ] returns true [ No ] returns false [ Cancel ] invokes 2nd messagebox [ Yes ] returns <param1> [ No ] returns 1 [ Cancel ] calls ExitProcess(-1) - one parameter [*] bp @ 42 : calls MessageBeep (MB_ICONHAND), returns 0, zero parameters Tested with IP.7 (first to display usage MessageBox): [ImportPatcher.34] ;Edit parameters and replacement strings, then Retry or run again to patch. <= [Parameters] Walk dependencies=N Link to copies=N Unbind broken bindings=N Target OS=4.10 [DLL substitutions] USER32.dll=IPstub.dll [IPstub.dll] MessageBoxA=op wsprintfA=yn [Patch list] ip7.exe=DLLs, Functions Fun, fun! Did I mention it comes with source code?

After modding PEfinder to search for local files without ILTs, I discovered it's not just a few files from old linkers (as mentioned in one of the classic '90s PE guides). Many new apps (including a .NET installer!) suffer from this malady. So I quickly added support for missing ILTs and a related unbinding issue last night and posted IP.34 a few minutes ago. I don't think this was the problem, but uninitialized variables and bad pointers are leading causes of sporadic program behavior. In the course of this investigation, I also noticed that DW reports that COMCTL32.DLL and USER32.DLL both want to load at the same preferred base! That means every time the second one loads, there is a performance hit as it is relocated.

It looks like either your overclocked memory glitched or your copy of shell32.dll has been corrupted. ... Importing from module: 'SHELL32.dll' TimeDateStamp: 3c106ecb Target OS: 4.0 (300) Shell_NotifyIconA (288) ShellExecuteExA (224) SHGetSpecialFolderPathA Importing from module: 'KERNEL32.DLL' TimeDateStamp: 3caba233 Target OS: 4.0 Clues: These TimeDateStamps for Shell32 and Kernel32 match those in SP3. Kernel32 is processed higher in the log with no problems. I can successfully walk Shell32 directly with IP.33 and also indirectly via Explorer. Shell32 should be importing from GDI32 first, not Kernel32 (confirmed with DW and other sources). Please try analyzing Shell32 directly, with and without walking dependencies. Also see if you can analyze coretemp10rc2_1236.exe (Walk=N), then try to reproduce the error with Walk=Y. Meanwhile, I'll continue to investigate the twelve trailing spaces that don't seem to jive with the rest of the clues....