Printing with KernelEx 4.5.1

[tomasz86]

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

[snuz2]

0xBFF70000 on 98SE confirmed.

[Joseph_sw]

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

[dencorso]

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!

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!

[jumper]

My most wholehearted thanks to those who helped test LOADDR so swiftly!

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!

Edited April 10, 2012 by jumper

[rloew]

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 prefered 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) down to the Shared Arena [MSKB 125691].

BFF70000 and BFF60000 are in the Shared Arena. The System Arena is C0000000-FFFFFFFF. The NT Bases are in the Private (Per-User) Arena, meaning that each Process gets it's own copy.

[dencorso]

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

Yes. But I think it best to always report the preferred base. It's added to my to-do list.

BFF70000 and BFF60000 are in the Shared Arena. The System Arena is C0000000-FFFFFFFF. The NT Bases are in the Private (Per-User) Arena, meaning that each Process gets it's own copy.

True. For the sake of completeness, this MS document presents the Virtual Address Space Layout for the NT-Family OSes. In it, the Arena nomenclature is not used, but it in fact still applies (unless the /3G switch is used, because it changes the layout).

[tomasz86]

True. For the sake of completeness, this MS document presents the Virtual Address Space Layout for the NT-Family OSes. In it, the Arena nomenclature is not used, but it in fact still applies (unless the /3G switch is used, because it changes the layout).

Does the /3GB switch affect the output of LOADDR? I've got /3GB enabled here.

[dencorso]

No. Not in for LOADDR. /3G extends the Shared Arena by reducing the System Arena. Even in a machine with 8 GiB, IMHO, /3G is not beneficial because most applications are not prepared to actually use the bigger Shared Arena, while the Kernel of the system and the kernel-mode drivers are caused to make do with less space in the System Arena. If I had a 2k Adv Srv, and 8 GiB RAM, I'd configure it with /PAE but without /3G. Of course, this is just my 2¢. YMMV.

[tomasz86]

I find /3GB useful as I tend to have a lot of tabs open in my browser (Opera) and sometimes the RAM usage gets extremely high. Without /3G it crashes around ~1.6 GB used and with /3GB enabled it runs fine up to ~2.4 GB

And I do have 8 GB of RAM but 50% of it is used for a RAM disk.

Edited April 15, 2012 by tomasz86

[vilyathegreat]

I'm running Win98SE & tried Plan E, method 4a. I have KernelEx ver 4.5.2 installed. I can now print with Sumatra 2.0.1 (the ver compiled with VS2008), however, the Advanced tab doesn't appear (fit pages to printable area, etc). BUT, being able to print at all is wonderful!

I could not get Firefox 3.6.28 to print however. I'm using the installed version of Firefox. After following the install procedure, (same as Sumatra) neither firefox.exe, nor any dlls got modified.

Any suggestions would be appreciated.

[schwups]

I'm running Win98SE & tried Plan E, method 4a. I have KernelEx ver 4.5.2 installed. I can now print with Sumatra 2.0.1 (the ver compiled with VS2008), however, the Advanced tab doesn't appear (fit pages to printable area, etc). BUT, being able to print at all is wonderful!

I could not get Firefox 3.6.28 to print however. I'm using the installed version of Firefox. After following the install procedure, (same as Sumatra) neither firefox.exe, nor any dlls got modified.

Any suggestions would be appreciated.

Hallo vilyathegreat,

I tested it again. For Firefox 3.6.28 I have to walk the dependencies (click yes in the first step).

Paste the downloaded ComDlgEx.dll (25.03.12) in

a. <system> folder (for multiple apps)

b. app folder (for single or portable app)

Drag and Drop the Firefox.exe on the ImportPatcher.exe. Click yes. In the first step the ImportPatcher generates two files (ini and log - marked with #) in the program folder. Open the ini file with the editor (NotePad) and paste COMDLG32.DLL=ComDlgEx.dll under [DLL replacements] and save it. After that (second step) press the retry button of the ImportPatcher. Then you cancel the ImportPatcher.

This works for me. Also I can't print if I click the no button.

Edited April 18, 2012 by schwups

[vilyathegreat]

Thanks much Schwups

I tried your procedure, but when I try printing, Firefox still crashes. After performing your procedure, 3 dlls did get altered (new ones with # in the filename):

1) xu.dll in the mozilla install directory

2) and strangely, comdlgex.dll & shlwapi.dll in \\windows\system

Perhaps the problem has something to do with fixing Sumatra first?

Did you modify a Firefox portable or installable version? Do you remember which dlls, exes got changed?

Thanks

[rloew]

I'm running Win98SE & tried Plan E, method 4a. I have KernelEx ver 4.5.2 installed. I can now print with Sumatra 2.0.1 (the ver compiled with VS2008), however, the Advanced tab doesn't appear (fit pages to printable area, etc). BUT, being able to print at all is wonderful!

SumatraPDF uses tabbed Property Sheets to provide the "Advanced" tab.

The Windows 98 PrintDlg Function does not support Property Sheets. It only supports alternative Dialog Boxes.

A much more substantial Patch would be required to add this support.

[schwups]

Thanks much Schwups

I tried your procedure, but when I try printing, Firefox still crashes. After performing your procedure, 3 dlls did get altered (new ones with # in the filename):

1) xu.dll in the mozilla install directory

2) and strangely, comdlgex.dll & shlwapi.dll in \\windows\system

Perhaps the problem has something to do with fixing Sumatra first?

Did you modify a Firefox portable or installable version? Do you remember which dlls, exes got changed?

Thanks

I've modified an installed version.

altered dll's in the app folder were : xul.dll, ComDlgEx.dll

And these dll's in the system folder: SHLWAPI.DLL, SHELL32.dll, SETUPAPI.dll

Here ComDlgEx.dll only in the app folders (Firefox / Sumatra) method 4b

I tried to repeat the procedure on this machine two times. I had deleted all walked files in the system folder, the app folder and reinstalled FF 3.6.28, but unfortunately now it crashes in order to print or after printing once. Error in Kernel32.dll

Edited April 19, 2012 by schwups