[dencorso]

snuz2, on 05 April 2012 - 10:03 PM, said:

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

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

Thanks for the swift feedback. You rock!

[dencorso]

dencorso, on 05 April 2012 - 07:20 PM, said:

jumper, on 04 April 2012 - 05:54 PM, said:

According to this link:

Quote

	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)

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

[loblo]

dencorso, on 07 April 2012 - 12:54 PM, said:

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

It returns 0xBFF60000, OK.

[LoneCrusader]

dencorso, on 07 April 2012 - 12:54 PM, said:

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

Quote

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.

This post has been edited by LoneCrusader: 07 April 2012 - 08:05 PM

[dencorso]

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

[tomasz86]

dencorso, on 07 April 2012 - 12:54 PM, said:

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

Quote

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]

dencorso, on 08 April 2012 - 10:01 AM, said:

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!

This post has been edited by jumper: 09 April 2012 - 10:44 PM

[rloew]

jumper, on 09 April 2012 - 05:50 PM, said:

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]

jumper, on 09 April 2012 - 05:50 PM, said:

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.

rloew, on 09 April 2012 - 08:21 PM, said:

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]

dencorso, on 10 April 2012 - 02:42 AM, said:

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.

This post has been edited by tomasz86: 15 April 2012 - 04:14 AM

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

vilyathegreat, on 18 April 2012 - 08:01 AM, said:

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.

This post has been edited by schwups: 18 April 2012 - 02:08 PM

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

vilyathegreat, on 18 April 2012 - 08:01 AM, said:

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]

vilyathegreat, on 18 April 2012 - 03:35 PM, said:

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

This post has been edited by schwups: 19 April 2012 - 07:21 AM