Jump to content

Printing with KernelEx 4.5.1


diamant

Recommended Posts


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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

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

Edited by tomasz86
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by schwups
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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