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

#26
snuz2

snuz2

    Junior

  • Member
  • Pip
  • 54 posts
  • OS:98SE
  • Country: Country Flag
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, 24 March 2012 - 06:27 PM.



How to remove advertisement from MSFN

#27
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 476 posts
  • OS:98SE
  • Country: Country Flag
Plan E: Attached File  ComDlgEx.7z   1.18KB   57 downloads
  • 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! :yes:

ComDlgEx.c:
Spoiler

ComDlgEx.def:
Spoiler

Ssync_ANSI_UNICODE_Struct_For_WOW has been removed.

Edited by jumper, 25 March 2012 - 12:26 AM.

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

#28
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 476 posts
  • OS:98SE
  • Country: Country Flag
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.dllPosted Image

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


Posted Image 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.
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

#29
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,093 posts
  • OS:98SE
  • Country: Country Flag

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.dllPosted Image

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


Posted Image 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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#30
snuz2

snuz2

    Junior

  • Member
  • Pip
  • 54 posts
  • OS:98SE
  • Country: Country Flag
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.

#31
schwups

schwups

    schwups

  • Member
  • PipPipPip
  • 417 posts
  • OS:ME
  • Country: Country Flag
Great, I can print with Sumatra PDF 1.9 (method 4b / ImportPatcher). :thumbup

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

Firefox 3.5.19 crashed once during testing.

Seamonkey 2.0.14 isn't stable in order to print.

Edited by schwups, 26 March 2012 - 07:06 PM.


#32
MiKl

MiKl

    Member

  • Member
  • PipPip
  • 110 posts
  • OS:98SE
  • Country: Country Flag

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

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 ??

Edited by MiKl, 27 March 2012 - 04:26 AM.


#33
schwups

schwups

    schwups

  • Member
  • PipPipPip
  • 417 posts
  • OS:ME
  • Country: Country Flag
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


Edited by schwups, 27 March 2012 - 06:58 AM.


#34
schwups

schwups

    schwups

  • Member
  • PipPipPip
  • 417 posts
  • OS:ME
  • Country: Country Flag
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.

#35
schwups

schwups

    schwups

  • Member
  • PipPipPip
  • 417 posts
  • OS:ME
  • Country: Country Flag
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.

#36
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 476 posts
  • OS:98SE
  • Country: Country Flag

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!).
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

#37
schwups

schwups

    schwups

  • Member
  • PipPipPip
  • 417 posts
  • OS:ME
  • Country: Country Flag
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 Files



#38
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 476 posts
  • OS:98SE
  • Country: Country Flag

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

According to this link:

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

#39
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,859 posts
  • OS:98SE
  • Country: Country Flag

Donator

According to this link:

	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 Files


Edited by dencorso, 06 April 2012 - 02:42 AM.
Replaced buggy app with fixed one.


#40
snuz2

snuz2

    Junior

  • Member
  • Pip
  • 54 posts
  • OS:98SE
  • Country: Country Flag
@dencorso:

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

#41
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,859 posts
  • OS:98SE
  • Country: Country Flag

Donator

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

:blink: No, you're doing nothing wrong.
I forgot to link it the way 9x/ME likes... My bad, sorry! :blushing:
Redownload, please, I've fixed it now.

Thanks for the swift feedback. You rock! :thumbup

#42
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,859 posts
  • OS:98SE
  • Country: Country Flag

Donator


According to this link:

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


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

So now we have:

	LoadLibraryA("KERNEL32.DLL") - returns BFF70000h on Win 95 OSR2.5 (determined by LoneCrusader)
                                     - returns BFF70000h on Win 98SE (confirmed by dencorso and snuz2)
				     - returns BFF60000h on Win ME (confirmed by loblo)
				     - returns 77E80000h on Win 2k
                                     - returns 7C570000h on Win 2k Adv Srv (determined by tomasz86) 
				     - returns 7C800000h on Win XP Pro SP3 (determined by dencorso)

:angel Well, now that LOADDR.EXE is working right...
@LoneCrusader: would you please determine the value for Win 95 OSR2.5,?
@loblo: would you please confirm the value for Win ME?
@jaclaz: would you please confirm/determine the value for Win XP Pro SP2?
@tomasz86: would you please confirm the value for Win 2k (or determine a new value, since you use a server version, right?)?

#43
loblo

loblo

    Oldbie

  • Member
  • PipPipPipPipPip
  • 757 posts
  • OS:ME
  • Country: Country Flag

@loblo: would you please confirm the value for Win ME?

It returns 0xBFF60000, OK.

#44
LoneCrusader

LoneCrusader

    Resistere pro causa resistentiam.

  • MSFN Sponsor
  • 810 posts
  • OS:98SE
  • Country: Country Flag

Donator

@LoneCrusader: would you please determine the value for Win 95 OSR2.5,?

Tested with 95C OSR2.5 with all official USB updates installed (USB Updates contain a major KERNEL32 version change)
And using the last KERNEL32.DLL for Windows 95, v4.03.1216.

loaddr v.0.1, freeware by dencorso, 2012

kernel32.dll's load address = 0xBFF70000

When I get a chance I will test again on an installation without USB (=v4.00.1112)
Tested on Pre-USB OSR2. Result is the same.


EDIT - Added Pre-USB 95 test results.

Edited by LoneCrusader, 07 April 2012 - 08:05 PM.


#45
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,859 posts
  • OS:98SE
  • Country: Country Flag

Donator

Thanks a lot to you both for your swift replies! :thumbup
I've updated that table in my previous post to reflect your results.
You rock! :thumbup

#46
tomasz86

tomasz86

    www.windows2000.tk

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,520 posts
  • OS:XP Pro x86
  • Country: Country Flag

@tomasz86: would you please confirm the value for Win 2k (or determine a new value, since you use a server version, right?)?

I've got 0x7C570000 here (W2K Adv Srv).
Posted Image
Unofficial Service Pack 5.2 for MS Windows 2000 <- use this topic if you need help with UURollup, Update Rollup 2 and other unofficial packages

#47
snuz2

snuz2

    Junior

  • Member
  • Pip
  • 54 posts
  • OS:98SE
  • Country: Country Flag
0xBFF70000 on 98SE confirmed.

#48
Joseph_sw

Joseph_sw

    Member

  • Member
  • PipPip
  • 217 posts
  • OS:98SE
  • Country: Country Flag
i happened to find a winXP pro sp2 (x86) in my works (build 2600.xpsp_sp2_qfe.061030-0020 : Service Pack 2)
and i tried the loaddr on that machine.
the result was:

loaddr v.0.1, freeware by dencorso, 2012

kernel32.dll's load address = 0x7C800000



#49
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,859 posts
  • OS:98SE
  • Country: Country Flag

Donator

OK! :) So now we have:

	LoadLibraryA("KERNEL32.DLL") - returns BFF70000h on Win 95 OSR2.5 (determined by LoneCrusader)
                                     - returns BFF70000h on Win 98SE (confirmed by dencorso and snuz2)
				     - returns BFF60000h on Win ME (confirmed by loblo)
				     - returns 77E80000h on Win 2k Pro
                                     - returns 7C570000h on Win 2k Adv Srv (determined by tomasz86)
                                     - returns 7C800000h on Win XP Pro SP2 (determined by Joseph_sw)
	                             - returns 7C800000h on Win XP Pro SP3 (determined by dencorso)

My most wholehearted thanks to those who helped test LOADDR so swiftly! :yes:
I think, by now, my program LOADDR.EXE is suffciently tested and validated to be used reliably, whenever necessary, with any dll. It is intended to be used as a tool, together with Dependency Walker, to help finding out more info from Program Error Message Boxes, as outlined by jumper in post #38.

However, interestingly, the originally intended purpose of LOADDR notwithstanding, the small collection of load addresses for Kernel32.dll collected here do, in fact, appear to show that:
1) It may possible to differenciate the Windows OS families based solely on the kernel32's the load address, since Win 9x/ME use 0xBFFX0000, while the NT-family prefer 0x7XXX0000;
2) Service packs seem not to influence the load address used, but Client as opposed to Server variants do.


And Happy Easter to you all!

#50
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 476 posts
  • OS:98SE
  • Country: Country Flag

My most wholehearted thanks to those who helped test LOADDR so swiftly! :yes:
I think, by now, my program LOADDR.EXE is suffciently tested and validated to be used reliably, whenever necessary, with any dll. It is intended to be used as a tool, together with Dependency Walker, to help finding out more info from Program Error Message Boxes, as outlined by jumper in post #38.

However, interestingly, the originally intended purpose of LOADDR notwithstanding, the small collection of load addresses for Kernel32.dll collected here do, in fact, appear to show that:
1) It may possible to differenciate the Windows OS families based solely on the kernel32's the load address, since Win 9x/ME use 0xBFFX0000, while the NT-family prefer 0x7XXX0000;
2) Service packs seem not to influence the load address used, but Client as opposed to Server variants do.

And Happy Easter to you all!

I've been using this batch file with LOADDR to avoid opening DOS boxes:
@%0\..\LOADDR.EXE %1
I'm on SE (BFF7) and realized the Kernel32 base on ME must be different per the error info. Kernel32 doesn't contain relocation data, so must load at its preferred base. Clearly that's different for many versions and apparently in the NT-family has been moved from the Reserved System Arena (Holds ring-0 components) Shared Arena down to the Shared Private Arena [MSKB 125691].

Could you possibly extend LOADDR to also report the preferred base if different?

EDIT: Thanks RLoew! :thumbup

Edited by jumper, 09 April 2012 - 10:44 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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN