Jump to content

Printing with KernelEx 4.5.1

diamant

By diamant
in Windows 9x Member Projects

 Share

Recommended Posts

schwups

schwups

Posted
Posted

Hello jumper,

I tried your second way  to update without success on two ME machines (KernelEX 4.5.2). First I pasted your ComDlg32.dll file in the KernelEX folder. Then I copied the original WinME COMDLG32.dll to the desktop and renamed the copy  to ComDlg00.dll. I pasted ComDlg00.dll in the system folder. So that there are both files in the system folder. At last I added the string ([HKEY_LOCAL_MACHINE\Software\KernelEx\KnownDLLs]"COMDLG32"="ComDlg32.dll") to the registry.  What's wrong? 

SumatraPDF 1.9: Error message - sumatrapdf.exe is linked to missing export-COMDLG32.DLL:PrintDlgExW.   Sumatra doesn't run. And I can't print with Seamonkey. 

If it makes sense I will try ways one and three.


jumper

jumper

Posted
Posted

I tried your second way to update without success on two ME machines (KernelEX 4.5.2). First I pasted your ComDlg32.dll file in the KernelEX folder. Then I copied the original WinME COMDLG32.dll to the desktop and renamed the copy to ComDlg00.dll. I pasted ComDlg00.dll in the system folder. So that there are both files in the system folder. At last I added the string ([HKEY_LOCAL_MACHINE\Software\KernelEx\KnownDLLs]"COMDLG32"="ComDlg32.dll") to the registry. What's wrong?

SumatraPDF 1.9: Error message - sumatrapdf.exe is linked to missing export-COMDLG32.DLL:PrintDlgExW. Sumatra doesn't run. And I can't print with Seamonkey.

This update currently only addresses the missing PrintDlgExA function in ComDlg32.dll. Try testing with SumatraPDF 0.9 instead.

With Seamonkey loaded, try deleting <system>\ComDlg00.dll. If you get a file-in-use error, that will confirm that the new ComDlg32.dll is correctly installed and in use.

Does Seamonkey display a Print Dialog at all? If not, Seamonkey must not be calling PrintDlgExA and has another issue not addressed by this update. Please search the Seamonkey folder for files with text "PrintDlgExA". If none are found, Seamonkey cannot be used to test this update. Instead, use ImportPatcher to test Seamonkey for missing imports and post results here. Thanks!

Tonight I will try to implement PrintDlgExW and update the update.

loblo

loblo

Posted
Posted
SumatraPDF 1.9: Error message - sumatrapdf.exe is linked to missing export-COMDLG32.DLL:PrintDlgExW.   Sumatra doesn't run. And I can't print with Seamonkey. 

Either hex the string PrintDlgExW to the string PrintDlgExA in SumatraPDF or the string PrintDlgExA to the string PrintDlgExW in jumper's comdlg32.dll and it should work after that with any method. :lol:

loblo

loblo

Posted
Posted

Seamonkey (2.7) appears to use the function PrintDlgW and it prints fine here (to adobe pdf writer as I don't have a real printer installed right now).

However it doesn't seem to print anymore if it uses jumper's comdlg32 so I think the recommended way to use it now should be on a per application basis and remove the comdlg32 entry in the system knowndll registry key.

jumper

jumper

Posted
Posted

Seamonkey (2.7) appears to use the function PrintDlgW and it prints fine here (to adobe pdf writer as I don't have a real printer installed right now).

A Google search for "SeaMonkey +PrintDlgW" yields antivirus scans showing that SeaMonkey 1.9 and 5.0 use PrintDlgW. :thumbup And Firefox 9.0 too!

However it doesn't seem to print anymore if it uses jumper's comdlg32 so I think the recommended way to use it now should be on a per application basis and remove the comdlg32 entry in the system knowndll registry key.

Method 2 seems to cause Kex to bypass its internal ComDlg32 support. Methods 1 and 3 should be complementary to Kex--use one of them with the current ComDlg32 update to prevent apps that need PrintDlgExW from failing to load.

This is excellent feedback. It made me realize that if I add a stub for PrintDlgExW that returns success instead of failure (as Kex does), the default parameters will be used unchanged and something might print for those apps (like SumatraPDF 1.9) that need PrintDlgExW!

snuz2

snuz2

Posted
Posted (edited)

I can confirm it works with Sumatra 1.8. I placed the translation dll in the folder with sumatra, cloned the comdlg32 in \system and removed the reference from "known dlls" in the registry. I hexed the translation dll to replace PrintDlgExA with PrintDlgExW.

I tried it with Sumatra 1.1 and didn't have much luck, flagrant abuse of memory ensued and I don't think I got a readable output in several tries. But it did link up okay :yes::}

I don't think this has anything to do with Mozilla apps though, they always pop the print dialog, just output mostly blank pages....

Edit// the previous post in the thread popped up as i wrote this, sorry for the duplication.

Edited by snuz2
jumper

jumper

Posted
Posted

Two better versions to try: ComDlgEx.7z

  1. ComDlgEx.dll - supports all three new functions:
    • PrintDlgExA - uses PRINTDLGA struct to call PrintDlgA
    • PrintDlgExW - uses PRINTDLGW struct to call PrintDlgW
    • Ssync_ANSI_UNICODE_Struct_For_WOW - stub: SetLastError(ERROR_CALL_NOT_IMPLEMENTED)

[*]ComDlgEx2.dll - as before, but support for both flavors

  • PrintDlgExA - uses PRINTDLGA struct to call PrintDlgA
  • PrintDlgExW - redirects to PrintDlgExA

Recommended installation method: 1b.

snuz2

snuz2

Posted
Posted (edited)

Yeah, good idea, put all them in there! I notice that the other dialogs like save and open are broken now... I used method 3 to install. Any way to get them to map through to comdlg00 as well?

Sorry for my ignorance but what does Ssync_ANSI_UNICODE_Struct_For_WOW - stub: SetLastError(ERROR_CALL_NOT_IMPLEMENTED) do for us?

Edited by snuz2
jumper

jumper

Posted
Posted (edited)

Yeah, good idea, put all them in there! I notice that the other dialogs like save and open are broken now... I used method 3 to install. Any way to get them to map through to comdlg00 as well?

All original functions are mapped through to ComDlg00.dll. Nothing should be broken--the open and save dialogs are working for me using methods 1b and 2[edit] in Notepad and SumatraPDF 0.9 (with Kex). In SumatraPDF 1.9 with Kex, however, the open dialog fails to appear. I have an idea of how to fix this that I'll try in the morning[/edit].

Sorry for my ignorance but what does Ssync_ANSI_UNICODE_Struct_For_WOW - stub: SetLastError(ERROR_CALL_NOT_IMPLEMENTED) do for us?

If an app is linked to this function, it will load instead of reporting a link error. If the app calls this function and checks the error code using GetLastError, it will see that the function is not actually implemented. The function is probably for NT's internal use in 16-bit "Windows on Windows" emulation. It is unlikely to ever be called in Win9x.

Edited by jumper
schwups

schwups

Posted
Posted

I've not much tested so far, but I've successfully printed with SumatraPDF 0.9 ( method 1.b, latest update ComDlgEx.dll). After that printing with Firefox 2.0.0.20 failed. Maybe at the weekend I'll report more detailed results.

snuz2

snuz2

Posted
Posted (edited)

Just adding some more info on the broken save/open dialogs:

Doesn't matter which version of the translation dll is used, doesn't matter if it is located in \system\ or local to the application. The Sumatra open save dialogs don't work.

Using the latest comdlgex.dll ( 3 functions) also doesn't pop the print dialog in sumatra. comdlgex2.dll does enable the print dialog to pop.

Installing ComDlgEx.dll ( 3 functions again) in \system\ broke open and save dialogs in Kmeleon1.6. although some apps still had their open/save dlgs working.

And.... I am using the portable version of Sumatra1.8.

Edited by snuz2
jumper

jumper

Posted
Posted (edited)

Plan E: ComDlgEx.7z

  • Like the original plan A, but with wrappers for all functions.
  • Works for opening and saving files as well as printing in SumatraPDF 0.9 and 1.9
  • Requires no '00' dll...
  • ...however requires ImportPatcher (or hex editor) to patch apps.

Installation Method 4:

  • put ComDlgEx.dll in
    1. <system> folder (for multiple apps)
    2. app folder (for single or portable app)

    [*] use hex editor or ImportPatcher on app to change import dependency:

    [DLL replacements]
    COMDLG32.DLL=ComDlgEx.dll

Build environment: MS DevStudio 97 / VC++ 5.0 sp3 / Win98se

Please try others! :yes:

ComDlgEx.c: 


// PrintDlgExA.c - jumper, Mar 24, 2012

//***** Standard #define and #include statements *****//

//#define WIN32_LEAN_AND_MEAN
#define STRICT
//#define _USER32_
#include <windows.h>
#include "commdlg.h"


//***** DLL entry point *****//

BOOL APIENTRY _DllMainCRTStartup (HANDLE hInst, DWORD ul_reason_being_called, LPVOID lpReserved)
{
  return 1;
}


//***** Export functions *****//

typedef struct tagPRINTPAGERANGE {
   DWORD  nFromPage;
   DWORD  nToPage;
} PRINTPAGERANGE, *LPPRINTPAGERANGE;

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;


HRESULT WINAPI PrintDlgExA (PRINTDLGEX *pPdex)
{
  PRINTDLGA pd;
  pd.lStructSize = sizeof(PRINTDLG);
  pd.hwndOwner   = pPdex->hwndOwner;
  pd.hDevMode    = pPdex->hDevMode;
  pd.hDevNames   = pPdex->hDevNames;
  pd.hDC         = pPdex->hDC;
  pd.Flags       = (pPdex->Flags & PD_RETURNDC)? pPdex->Flags | PD_USEDEVMODECOPIESANDCOLLATE: pPdex->Flags;
  pd.nFromPage   = 0xFFFF; 
  pd.nToPage     = 0xFFFF; 
  if (pPdex->nMaxPageRanges) {
    pd.nFromPage = (WORD)pPdex->lpPageRanges[0].nFromPage;
    pd.nToPage   = (WORD)pPdex->lpPageRanges[0].nToPage;
  }
  pd.nMinPage    = (WORD)pPdex->nMinPage;
  pd.nMaxPage    = (WORD)pPdex->nMaxPage;
  pd.nCopies     = (WORD)pPdex->nCopies;
  pd.hInstance   = NULL; //for templates
  pd.lCustData   = 0;
  pd.lpfnPrintHook = NULL; //pPdex->lpCallback; //
  pd.lpfnSetupHook = NULL;
  pd.lpPrintTemplateName = NULL;
  pd.lpSetupTemplateName = NULL;
  pd.hPrintTemplate = NULL;
  pd.hSetupTemplate = NULL;

  if (PrintDlgA (&pd)) {
    pPdex->dwResultAction = 1; // Print
    pPdex->hDevMode       = pd.hDevMode;
    pPdex->hDevNames      = pd.hDevNames;
    pPdex->hDC            = pd.hDC;
    pPdex->Flags          = pd.Flags;
    if (pPdex->nMaxPageRanges) {
      pPdex->nPageRanges    = 1;
      pPdex->lpPageRanges[0].nFromPage  = pd.nFromPage;
      pPdex->lpPageRanges[0].nToPage    = pd.nToPage;
    }
    pPdex->nCopies        = pd.nCopies;
  } else {
    pPdex->dwResultAction = 0; // Cancel
  }
  return 0; // S_OK;
}


HRESULT WINAPI PrintDlgExW (PRINTDLGEX *pPdex)
{
  PRINTDLGW pd;
  pd.lStructSize = sizeof(PRINTDLG);
  pd.hwndOwner   = pPdex->hwndOwner;
  pd.hDevMode    = pPdex->hDevMode;
  pd.hDevNames   = pPdex->hDevNames;
  pd.hDC         = pPdex->hDC;
  pd.Flags       = (pPdex->Flags & PD_RETURNDC)? pPdex->Flags | PD_USEDEVMODECOPIESANDCOLLATE: pPdex->Flags;
  pd.nFromPage   = 0xFFFF; 
  pd.nToPage     = 0xFFFF; 
  if (pPdex->nMaxPageRanges) {
    pd.nFromPage = (WORD)pPdex->lpPageRanges[0].nFromPage;
    pd.nToPage   = (WORD)pPdex->lpPageRanges[0].nToPage;
  }
  pd.nMinPage    = (WORD)pPdex->nMinPage;
  pd.nMaxPage    = (WORD)pPdex->nMaxPage;
  pd.nCopies     = (WORD)pPdex->nCopies;
  pd.hInstance   = NULL; //for templates
  pd.lCustData   = 0;
  pd.lpfnPrintHook = NULL; //pPdex->lpCallback; //
  pd.lpfnSetupHook = NULL;
  pd.lpPrintTemplateName = NULL;
  pd.lpSetupTemplateName = NULL;
  pd.hPrintTemplate = NULL;
  pd.hSetupTemplate = NULL;

  if (PrintDlgW (&pd)) {
    pPdex->dwResultAction = 1; // Print
    pPdex->hDevMode       = pd.hDevMode;
    pPdex->hDevNames      = pd.hDevNames;
    pPdex->hDC            = pd.hDC;
    pPdex->Flags          = pd.Flags;
    if (pPdex->nMaxPageRanges) {
      pPdex->nPageRanges    = 1;
      pPdex->lpPageRanges[0].nFromPage  = pd.nFromPage;
      pPdex->lpPageRanges[0].nToPage    = pd.nToPage;
    }
    pPdex->nCopies        = pd.nCopies;
  } else {
    pPdex->dwResultAction = 0; // Cancel
  }
  return 0; // S_OK;
}


// Wrappers for classic functions that KernelEx supports
BOOL  APIENTRY  exChooseColorA    (LPCHOOSECOLORA  a) { return ChooseColorA (a); }
BOOL  APIENTRY  exChooseColorW    (LPCHOOSECOLORW  a) { return ChooseColorW (a); }
BOOL  APIENTRY  exChooseFontA     (LPCHOOSEFONTA   a) { return ChooseFontA  (a); }
BOOL  APIENTRY  exChooseFontW     (LPCHOOSEFONTW   a) { return ChooseFontW  (a); }
DWORD APIENTRY  exCommDlgExtendedError(VOID)       { return CommDlgExtendedError (); }
HWND  APIENTRY  exFindTextA       (LPFINDREPLACEA  a) { return FindTextA    (a); }
HWND  APIENTRY  exFindTextW       (LPFINDREPLACEW  a) { return FindTextW    (a); }
short APIENTRY  exGetFileTitleA   (LPCSTR  a, LPSTR  b, WORD c) { return GetFileTitleA (a, b, c); }
short APIENTRY  exGetFileTitleW   (LPCWSTR a, LPWSTR b, WORD c) { return GetFileTitleW (a, b, c); }
BOOL  APIENTRY  exGetOpenFileNameA(LPOPENFILENAMEA a) { return GetOpenFileNameA (a); }
BOOL  APIENTRY  exGetOpenFileNameW(LPOPENFILENAMEW a) { return GetOpenFileNameW (a); }
BOOL  APIENTRY  exGetSaveFileNameA(LPOPENFILENAMEA a) { return GetSaveFileNameA (a); }
BOOL  APIENTRY  exGetSaveFileNameW(LPOPENFILENAMEW a) { return GetSaveFileNameW (a); }
HBITMAP WINAPI  LoadAlterBitmap   (int id, DWORD rgbReplace, DWORD rgbInstead);
HBITMAP WINAPI  exLoadAlterBitmap (int a, DWORD b, DWORD c) { return LoadAlterBitmap (a, b, c); }
BOOL  APIENTRY  exPageSetupDlgA   (LPPAGESETUPDLGA a) { return PageSetupDlgA (a); }
BOOL  APIENTRY  exPageSetupDlgW   (LPPAGESETUPDLGW a) { return PageSetupDlgW (a); }
BOOL  APIENTRY  exPrintDlgA       (LPPRINTDLGA     a) { return PrintDlgA     (a); }
BOOL  APIENTRY  exPrintDlgW       (LPPRINTDLGW     a) { return PrintDlgW     (a); }
HWND  APIENTRY  exReplaceTextA    (LPFINDREPLACEA  a) { return ReplaceTextA  (a); }
HWND  APIENTRY  exReplaceTextW    (LPFINDREPLACEW  a) { return ReplaceTextW  (a); }

ComDlgEx.def: 


LIBRARY  ComDlgEx
VERSION 4.20.1.1
;BASE 0x7FE00000

EXPORTS
  nn100=ComDlg32.@100  @100 NONAME
  ChooseColorA=exChooseColorA  @101
  ChooseColorW=exChooseColorW  @102
  ChooseFontA=exChooseFontA  @103
  ChooseFontW=exChooseFontW  @104
  CommDlgExtendedError=exCommDlgExtendedError  @105
  FindTextA=exFindTextA  @106
  FindTextW=exFindTextW  @107
  GetFileTitleA=exGetFileTitleA  @108
  GetFileTitleW=exGetFileTitleW  @109
  GetOpenFileNameA=exGetOpenFileNameA  @110
  GetOpenFileNameW=exGetOpenFileNameW  @111
  GetSaveFileNameA=exGetSaveFileNameA  @112
  GetSaveFileNameW=exGetSaveFileNameW  @113
  LoadAlterBitmap=exLoadAlterBitmap  @114
  PageSetupDlgA=exPageSetupDlgA  @115
  PageSetupDlgW=exPageSetupDlgW  @116
  PrintDlgA=exPrintDlgA  @117
  PrintDlgW=exPrintDlgW  @118
  ReplaceTextA=exReplaceTextA  @119
  ReplaceTextW=exReplaceTextW  @120
  WantArrows=ComDlg32.WantArrows  @121
  dwLBSubclass=ComDlg32.dwLBSubclass  @122
  dwOKSubclass=ComDlg32.dwOKSubclass  @123
  PrintDlgExA
  PrintDlgExW

Ssync_ANSI_UNICODE_Struct_For_WOW has been removed.

Edited by jumper
jumper

jumper

Posted
Posted

The problem turned out to be that KernelEx is needed for GetOpenFileNameW, but undesired for PrintDlgExW (and vice versa for ComDlgEx) . KernelEx also can't process ComDlg32 functions unless they are imported (not export-forwarded) from a DLL named ComDlg32.dllicon13.gif

So the solution was two-fold:

  • switch from export-forwarding to wrappers of imported functions
  • use dependency order App->ComDlgEx->ComDlg32

Using the previous test versions, KernelEx processing was either fully enabled or fully disabled--meaning it allowed GetOpenFileNameW to work but returned an error for PrintDlgExW, or the new PrintDlgExW worked but GetOpenFileNameW was not patched to work. This affected apps that use the Wide functions: SumatraPDF 1.8, 1.9, and apparently FireFox 3.

Apps (like SumatraPDF 0.9) that use the Ansi functions don't need a KernelEx patch for GetOpenFileNameA, so could print and open files under some install methods (when redirected).

[if requested, I'll expand the above to explain in more detail why each function worked (or didn't) on each app for each method.]

icon11.gif Because KernelEx 4.5.1 does some processing of most of the functions in ComDlg32, I will next try to break out all of that code into a stand-alone DLL into which I can add the new PrintDlgEx code. If successful, this new DLL would be installed using an easier Method 2 (without the renaming or copying). It would also be an example of how KernelEx can be extended without recompiling the full core package.

rloew

rloew

Posted
Posted

The problem turned out to be that KernelEx is needed for GetOpenFileNameW, but undesired for PrintDlgExW (and vice versa for ComDlgEx) . KernelEx also can't process ComDlg32 functions unless they are imported (not export-forwarded) from a DLL named ComDlg32.dllicon13.gif

So the solution was two-fold:

  • switch from export-forwarding to wrappers of imported functions
  • use dependency order App->ComDlgEx->ComDlg32

Using the previous test versions, KernelEx processing was either fully enabled or fully disabled--meaning it allowed GetOpenFileNameW to work but returned an error for PrintDlgExW, or the new PrintDlgExW worked but GetOpenFileNameW was not patched to work. This affected apps that use the Wide functions: SumatraPDF 1.8, 1.9, and apparently FireFox 3.

Apps (like SumatraPDF 0.9) that use the Ansi functions don't need a KernelEx patch for GetOpenFileNameA, so could print and open files under some install methods (when redirected).

[if requested, I'll expand the above to explain in more detail why each function worked (or didn't) on each app for each method.]

icon11.gif Because KernelEx 4.5.1 does some processing of most of the functions in ComDlg32, I will next try to break out all of that code into a stand-alone DLL into which I can add the new PrintDlgEx code. If successful, this new DLL would be installed using an easier Method 2 (without the renaming or copying). It would also be an example of how KernelEx can be extended without recompiling the full core package.

I was able to print with SumatraPDF 1.9 using a DLL containing PrintDlgExW and my DLLHOOK redirector.

I used a debugged version of jumper's code from Post #8 to create the DLL.

snuz2

snuz2

Posted
Posted

Confirming the latest works for me on Sumatra 1.8. I don't see any way it could possibly break anything else either. Thanks very much.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...