Jump to content

Printing with KernelEx 4.5.1


diamant

Recommended Posts

Joe, please try MiKl's configuration:

  • comdlg32 from 3/21 in the Firefox 3.5 folder
  • and comdlg32 from 3/13 in the KernelEx folder.


"hould have no effect" was carefully worded. My ComDlg export-forwards PrintDlgW to the original ComDlg32.00 DLL which should be fine. However, back in Post #28 I wrote: "KernelEx also can't process ComDlg32 functions unless they are imported (not export-forwarded) from a DLL named ComDlg32.dll!" So, my ComDlg by export-forwarding PrintDlgW is bypassing KernelEx's Unicode processing....

To test this theory, try adding this line in Core.ini instead of using my ComDlg(s):


[NT2K.names]
ComDlg32.PrintDlgW=std

BTW, do OpenFile and SaveFileAs work? They should also be affected by my ComDlg32 implementation.

Perhaps I need to export-forward to Unicows.dll instead of ComDlg32. Unicows exports all the wide ComDlg32 functions. Or perhaps that is what Kex is doing.... I'll continue to research the issue.

Hi jumper,

To answer your last question first, the OpenFile and SaveFileAs functions were working fine with my previously described "post #27" hack. From memory, they were also working fine before any experimentation with ComDlg32.dll.

To implement the hybrid hack as suggested, I've done as follows :

1. Reverted to the original ComDlg32.dll in the System directory.

2. Copied the above as ComDlg00.dll (again in the System directory).

3. Placed the "post #13" version of ComDlg32.dll in the KernelEx directory.

4. Added the registry value : \HKLM\Software\KernelEx\KnownDLLs\COMDLG32="ComDlg32.dll".

5. Placed the "post #22" version of ComDlgEx.dll in the FF directory and renamed this as ComDlg32.dll.

6. Deleted the registry value \HKLM\System\CurrentControlSet\Control\SessionManager\KnownDLLs\COMDLG32.

Now if I attempt to print in FF, nothing happens but FF doesn't lock up (the first time). However if I attempt to print again, then FF locks up (no hourglass).

Also, OpenFile and SaveFileAs no longer function (nothing happens).

With regard the 'ComDlg32.PrintDlgW=std' line in Core.Ini, which configuration of ComDlg32.dll hack(s) should I use?

Joe.

Edited by jds
Link to comment
Share on other sites


With regard the 'ComDlg32.PrintDlgW=std' line in Core.Ini, which configuration of ComDlg32.dll hack(s) should I use?

Original FF35 with none of my ComDlg32's. This is to confirm that the only effect of my ComDlg32 was to inadvertantly bypass KernelEx processing of PrintDlgW. This should explicitly bypass KernelEx processing instead of using my ComDlg32.


I'm in the process of pushing ImportPatcher.37 and Ktree.8 out the door--It'll take a while for me to understand the rest of your tests. Don't worry about trying to reproduce MiKl's SeaMonkey results. Per loblo in Post #19, SeaMonkey prints fine with just KernelEx, but not with my ComDlg32 installed! Firefox 3.5 has other printing issues. :(


Something separate to try is to use Kexstubs to redirect PrintDlgW to the unicode version in Unicows:

[Comdlg32.dll]
PrintDlgW=>Unicows:

Link to comment
Share on other sites

With regard the 'ComDlg32.PrintDlgW=std' line in Core.Ini, which configuration of ComDlg32.dll hack(s) should I use?

Original FF35 with none of my ComDlg32's. This is to confirm that the only effect of my ComDlg32 was to inadvertantly bypass KernelEx processing of PrintDlgW. This should explicitly bypass KernelEx processing instead of using my ComDlg32.

OK, I undid everything then added the 'ComDlg32.PrintDlgW=std' line in KernelEx's "Core.Ini".

Now, attempt to print #1 -> nothing happened; attempt #2 -> nothing happened; attempt #3 -> FF locked up (no hourglass).

Something separate to try is to use Kexstubs to redirect PrintDlgW to the unicode version in Unicows:

[Comdlg32.dll]
PrintDlgW=>Unicows:

Next I removed the 'ComDlg32.PrintDlgW=std' line in "Core.Ini" and went looking for anything in the FF directory containing 'PrintDlgW', finding "xul.dll".

The KernelEx properties were W2K, set this to Disabled, selecting not to pass the setting to child processes. No good, FF refused to start. Next, set "xul.dll" properties to Default, deselecting the "do not pass settings" option. Now FF started OK and attempting to print resulted in a "print dialogue", after which clicking OK caused FF to lock-up (without hourglass).

So this change seems to have the same effect as when I used a patched version of your ComDlgEx/ComDlg32 from post #27. Later, I'll try the Unicows redirection (or patch "xul.dll"?) as you've suggested. I'll also try other versions such as from FF 8.01. However, now it's late, so I'm calling it a day.

Joe.

PS. Well, I've now tried the Unicows redirection with the following 'Kstub822.ini' setting, to no avail (FF hangs immediately on printing, no hourglass) :

[Comdlg32.dll]

PrintDlgExA=>ComDlgKs:

PrintDlgExW=>ComDlgKs:

PrintDlgW=>Unicows:

I've also tried to incorporate different versions of 'xul.dll', however, FF has checks for the exact Ghecko version of files, which means 3.5.xx won't allow this.

Edited by jds
Link to comment
Share on other sites

Hi Joe,

if you can/like please try my configuration again but this time do not add the registry fix. I don't have it either.

Then at first open the print preview only ... wait a few seconds ... close the preview ... now try to print.

Also, in case you have the FF cache on a RAM-disc, try printing with the cache located on harddisc.

I also remember that I changed some entries in SeaMonkey's 'about:config'.

Since both FF and SM use the same engine I think FF have this also, right ?

Link to comment
Share on other sites

if you can/like please try my configuration again but this time do not add the registry fix. I don't have it either.

Then at first open the print preview only ... wait a few seconds ... close the preview ... now try to print.

Also, in case you have the FF cache on a RAM-disc, try printing with the cache located on harddisc.

I also remember that I changed some entries in SeaMonkey's 'about:config'.

Since both FF and SM use the same engine I think FF have this also, right ?

Hi MiKl,

OK, I may try again. Which registry fix should I omit?

Joe.

Link to comment
Share on other sites

I've been rebuilding a test machine the last few days and now have Firefox 3.5.19 installed and SeaMonkey Setup 2.6.1 ready to go next.

I'm not getting a hang when printing with FF3.5, but rather a crash. Sometimes the error message is from the Mozilla Crash Reporter:

Firefox had a problem and crashed.
...
Details: The application did not leave a crash dump file.

and sometimes a standard system error dialog:

FIREFOX caused an invalid page fault
in module Kernel32.dll at 016f:bff7a388.
...

and sometimes both!

The source code is "only" 46466 KB, so I'll see if it might be helpful:

Index of ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.5.19/source
Up to higher level directory
File: firefox-3.5.19.bundle 105198 KB 4/20/11 12:00:00 AM
File: firefox-3.5.19.bundle.asc 1 KB 4/20/11 12:00:00 AM
File: firefox-3.5.19.source.tar.bz2 46466 KB 4/20/11 12:00:00 AM
File: firefox-3.5.19.source.tar.bz2.asc 1 KB 4/20/11 12:00:00 AM


Edit: While waiting for the download, I found the Mozilla Cross-Reference site.

This search in the FF3.5 source for "PrintDlg" indicates that FF3.5 is supposed to be using PrintDlgExA:


* line 101 -- // For PrintDlgEx
* line 104 -- #define GetPrintDlgExQuoted "PrintDlgExA"
...
* line 188 -- return GetProcAddress(lib, GetPrintDlgExQuoted);
...
* line 967 -- BOOL result = ::PrintDlgW(&prntdlg);
...
* line 1301 -- HRESULT result = ::PrintDlgEx(&prntdlg);

Edited by jumper
Link to comment
Share on other sites

I've been rebuilding a test machine the last few days and now have Firefox 3.5.19 installed and SeaMonkey Setup 2.6.1 ready to go next.

I'm not getting a hang when printing with FF3.5, but rather a crash.

The cavalry to the rescue! Fantastic! :thumbup

Perhaps the crash you're getting vs. the lock-up I'm getting is due to the differences between 3.5.19 and 3.5.20pre. I don't know what the differences are, but the respective packages are 7.9M and 11.1M in size, so that suggests lots of changes/additions. However, I'm sure the root problem will be the same.

While waiting for the download, I found the Mozilla Cross-Reference site.

This search in the FF3.5 source for "PrintDlg" indicates that FF3.5 is supposed to be using PrintDlgExA:


* line 101 -- // For PrintDlgEx
* line 104 -- #define GetPrintDlgExQuoted "PrintDlgExA"
...
* line 188 -- return GetProcAddress(lib, GetPrintDlgExQuoted);
...
* line 967 -- BOOL result = ::PrintDlgW(&prntdlg);
...
* line 1301 -- HRESULT result = ::PrintDlgEx(&prntdlg);

Aren't "PrintDlgW" and "PrintDlgEx" also being used, according to the above?

Joe.

Link to comment
Share on other sites

  • 1 month later...

Some little progress ...

I tried printing in FF 3.5.20pre by loading it via Dependency Walker and clicking the "Start Profiling" function. When there were pauses in this process, I copied the information from the DW log and saved this away. To my surprise, the first time I tried this, it actually printed. It was the google page, and printed a bit strange - the google graphic and the two button texts were printed up-side-down. This was "Run 1" in the attached logs.

I then tried the same thing a few more times, including reboots, but FF always crashed. Two runs were captured, these are "Run 2" and "Run 3" in the attached logs.

I noticed for example that when function "IsTNT" is called in one instance, there was one (probably bogus) error code, whereas in another instance, there was a different (probably bogus) error code. From this I conclude that the error codes returned for missing functions in general are garbage, which may explain why I succeeded in printing once but not again.

The attached logs are in RTF format to preserve the colour coding and bold text from DW.

Joe.

Debug_FF3_Printing.cab

Link to comment
Share on other sites

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
  • Recently Browsing   0 members

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