Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

Printing with KernelEx 4.5.1

- - - - -

  • Please log in to reply
82 replies to this topic

#76
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag

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.
 
"[S]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, 21 September 2012 - 04:05 AM.



How to remove advertisement from MSFN

#77
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 485 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag

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:

Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#78
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag


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, 24 September 2012 - 02:36 AM.


#79
MiKl

MiKl

    Member

  • Member
  • PipPip
  • 114 posts
  • Joined 01-December 11
  • OS:98SE
  • Country: Country Flag
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 ?

#80
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag

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.

#81
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 485 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
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, 24 September 2012 - 09:01 PM.

Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#82
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag

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.

#83
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag
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.

Attached File  Debug_FF3_Printing.cab   14.72KB   7 downloads




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users