[snuz2]

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

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.

This post has been edited by snuz2: 20 March 2012 - 11:00 PM

[jumper]

Two better versions to try:  ComDlgEx.7z (1.32K)
Number of downloads: 32

• 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]

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?

This post has been edited by snuz2: 21 March 2012 - 11:45 PM

[jumper]

snuz2, on 21 March 2012 - 11:43 PM, said:

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].

snuz2, on 21 March 2012 - 11:43 PM, said:

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.

This post has been edited by jumper: 22 March 2012 - 03:26 AM

[schwups]

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]

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.

This post has been edited by snuz2: 24 March 2012 - 06:27 PM

[jumper]

Plan E:  ComDlgEx.7z (1.18K)
Number of downloads: 43

• 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
  • <system> folder (for multiple apps)
    
  • 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!

ComDlgEx.c:

Spoiler

// 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:

Spoiler

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.

This post has been edited by jumper: 25 March 2012 - 12:26 AM

[jumper]

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.dll

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.]


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]

jumper, on 25 March 2012 - 04:02 PM, said:

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.dll

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.]


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]

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.

[schwups]

Great, I can print with Sumatra PDF 1.9 (method 4b / ImportPatcher).

I have printed successfully with Firefox 3.6.28 and Seamonkey 2.6.1, too.

Firefox 3.5.19 crashed once during testing.

Seamonkey 2.0.14 isn't stable in order to print.

This post has been edited by schwups: 26 March 2012 - 07:06 PM

[MiKl]

schwups, on 26 March 2012 - 06:07 PM, said:

I have printed successfully with Firefox 3.6.28 and Seamonkey 2.6.1, too.

Seamonkey 2.0.14 isn't stable in order to print.

Hi Schwups,

based on my previous experiences in getting Seamonkey 2.0.14 reliably to print and since I don't want to play around with the registry I did the following.
1) In <winsysdir>, copy original COMDLG32.DLL to COMDLG00.DLL.
2) Place ComDlg32.dll in app folder AND into Windows Kernel Ex folder !!!
When SM 2.0.14 is running open the print preview - wait a few seconds - close the preview and after that I can print without any problems. But this may be working only for me because I changed many things on my system before finding this awesome board !!

Thank you very much Jumper and everybody else !!

Oh by the way Schwups, on higher versions than 2.0.14 websites look like crap on my system !! Is it working for you ??

This post has been edited by MiKl: 27 March 2012 - 04:26 AM

[schwups]

Higher versions of SeaMonkey work for me with comp. mode Win XP (Win ME / KernelEX 4.5.2 / CPU SSE2 or 3). Recently visited addresses, history, bookmarks and the Java Sun plugin don't work.




Fixed with KernelEX 4.5.2: Firefox 4+ : Freeze when drawing a non-blank page. Seamonkey versions 2.1 - 2.6.1 are based on the same Gecko engines as Firefox 4 - 9.0.1 and should work. KernelEX Wiki

This post has been edited by schwups: 27 March 2012 - 06:58 AM

[schwups]

It doesn't work for PDF XChangeViewer. The progam crashes in order to print. Tested with versions 2.5.201, 2.5.192, 2.0.42.3. Pdfxcview has caused an error in unknown module. It is the same error as before without the update.

[schwups]

I get an error message in order to print with Palemoon. It can also be after printing of one page. Palemoon caused an error in Kernel32.dll. Palemoon will now close. Tested on some ME machines.

[jumper]

schwups, on 03 April 2012 - 09:01 AM, said:

I get an error message in order to print with Palemoon. It can also be after printing of one page. Palemoon caused an error in Kernel32.dll. Palemoon will now close. Tested on some ME machines.

What were the error details and Kernel32.dll version?

If we cross-reference the instruction address/EIP value with Kernel32.dll function export addresses using a PE viewer, we should be able to determine what function was running. (In the case of your previous post, the Stack dump should reveal what module--and possibly function--might have jumped into unknown memory.)

If you have VC++ installed, click on [Debug] in the error dialog to launch it. Then View->Debug Windows->Call Stack to see the calling sequence.

I'll try to write a JIT debugger (based on FineSSE) that looks up the call sequence (and maybe offers a live recovery attempt!).

[schwups]

What were the error details and Kernel32.dll version? It is the orig. Win ME Kernel32.dll 4.90.0.3000  / 08.06.2000 17:00

Attached File(s)

•  Palemoon error.png (7.45K)
  Number of downloads: 5
•  Palemmoon error2.png (6.78K)
  Number of downloads: 4

[jumper]

schwups, on 04 April 2012 - 08:01 AM, said:

It is the orig. Win ME Kernel32.dll 4.90.0.3000 / 08.06.2000 17:00

According to this link:

Quote

	LoadLibraryA("KERNEL32.DLL") - returns BFF70000h on w98se
				     - returns BFF60000h on winME
				     - returns 77E80000h on w2k

Google translates the error message to:

Palemoon caused an error by a
invalid page
in module KERNEL32.DLL at 01ef: bff6a4e9
...
Stack dump:
00650050 00000000 004c000c 004c0000 004c985c
00000040 00000000 00000b19 000004ca 0095e748
bff6a6b1 004c0000 004c985c 00000018 00000040
00000013

Subtracting bff60000 from bff6a4e9 and bff6a6b1 and looking up those addresses for Kernel32.dll in Dependency Walker indicates that the error happened in a support function called by IsBadWritePtr.

Apps usually load at 00400000, so all those 0040xxxx values on the stack are probably data pointers within Palemoon.

[dencorso]

jumper, on 04 April 2012 - 05:54 PM, said:

According to this link:

Quote

	LoadLibraryA("KERNEL32.DLL") - returns BFF70000h on w98se
				     - returns BFF60000h on winME
				     - returns 77E80000h on w2k

Here's a small app that returns the load address of any library.
Usage: loaddr libraryname.dll
Hope it may be useful.

It returns kernel32.dll's load address = 0x7C800000 on XP SP3.

@all: Please do test it on 9x/ME, to confirm it works OK.

Attached File(s)

•  LOADDR.7z (959bytes)
  Number of downloads: 20

This post has been edited by dencorso: 06 April 2012 - 02:42 AM
Reason for edit: Replaced buggy app with fixed one.

[snuz2]

@dencorso:

Maybe I'm using it incorrectly, but W98SE loader reports it is improperly linked with alignment less than 0x1000 and refuse to load.