dencorso

At first sight both solutions should be equivalent, in most relevant cases, that's true. In any case, the most obvious use is to modify the registry unhampered. And, what's more wonderful is that, when fdv started this thread, we had no solution to the problem, and now, thanks to you, we actually have *two*! :

Great find, joakin! Thanks a lot! Yet I do ask myself whether your original solution, although much more complicated, does not, in fact, yield a more complete impersonation of TI... Of course, that can only be answered by time and good testing.

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!

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!

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

Welcome to MSFN!

Welcome to MSFN!

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!

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

You don't use OpenVPN, do you? If you do, it might very well be an unconnected TAP-Win32 Adapter.

OK. Now I see there was a problem, after all. But I think I've solved it: below is a quote of the lines I added to the top of the first post.

The link is the last line of his signature. Why is it confusing?

Yes. With all due respect, how do you intend to fit the 1 MiB EWF config partition in the 63 KiB partition created? By flushing the rest of the data into a parallel universe?

We do have a really high no-tolerance policy against Warez in general and Hiren's in particular. Now that Tony is aware of it and already expressed his stance about it, no further mention of it is needed or warranted. And, considering how uncanny his problem is, let's again focus on it, in the hopes we can progress towards solving it.

Welcome to the fold!

Well... I can agree that both KernelEx and RP are easy to install afterwards, and are projects that remain (hopefully) being developed, and that this is a reason not to include them in the uSP. But Drugwash has just made an important point: the files in Tihiy's Requirements pack surely should be a part of the uSP, regardless of whether the user intends or not to install RP later. As for WIA, provided it can be made to get along with TWAIN, I see no problem with adding it as an optional. And, BTW, for those interested, Maximus-Decim's Cumulative Updates for MDAC and IE6 are real good and cater well for having those particular pieces of software up-to-date if needed/wanted. So I see no need at all for the uSP to navigate those waters.

No. There's a serious misunderstanding here. There's no group-think verdict at all. Some of us hazarded guesses about what might be happening. I didn't hazard any and continue not doing it. For me, there's still too little info to go on. I'll reserve any guessing on my part for a later time, when I think some guess might be warranted. That said, and since none of the others seem familiar with SpinRite, I must add SpinRite 6 rocks! It is able to do some types of repair no other tool I know of can do (in particular it can sometimes "revive" floppies no other software can save, for time enough for a good image to be acquired from them). But SpinRite 6 is only useful for a limited number of conditions, most of them hardware issues. And, of course, it may be used simply to detect and access disks. Are you using SpinRite 6, perchance? All earlier versions of SpinRite are too out-of-date to be useful for disks using Win 95 OSR2 - Win 7 (read this and this). BTW, in what regards disks and disk hardware, I consider Steve Gibson an authority, but for all other matters, especially security and the internet, his opinions are somewhat controversial and should be taken with the proverbial grain of salt.

Hmmm, with this patch Win98Se would not be running in ms-dos compatibility mode ?? Of course *not*. To run in MS-DOS Compatibility Mode no driver is needed.

No. Zipfldr.dll hijacks the association for itself, so disabling it is required.

At RLoew's Site, of course.

+1. In other words: we here work by the Scientific Method. We construct hypotheses (not necessarily always explicitly described) and propose experiments in order to validate or disprove them. Then the OP performs the tests suggested and reports back. Then, more refined hypotheses are thought up (not necessarily by the same person) and so on, until we get to understand what actually is happening, and then we move on to solution. Without experiments we simply cannot help.

I think PROBLEMCHYLD made wise decisions about what not to include. In particular, I think that WIA (because it may break TWAIN) and .NET (because it may break windows search) are problematic packages, which must be handled with due care, and have no place in an update pack, at least until the known issues get sorted out. However, if an "Advanced" optional section ends up being created, it should include both KernelEx and the Revolutions Pack. I'm one of those minimalists Drugwash just mentioned, and yet I do use RP (with themes disabled) because it helps a lot (or effectively solves) with the resource limitation, and adds the possibility of locking the taskbar and Tihiy's improved Task Manager, and I deem those three improvements very important for attaining the best possible 98SE experience.

Check which vwesion of SETUPAPI.DLL you have on the machine. If it turns out to be 5.1.2600.2180, follow the links PROBLEMCHYLD provided some posts above, to solve the issue. If that's not the case, then update NUSB to version 3.5, using the link below to get it.

Mohammed Rafi - Jaan Pehechaan Ho

W2k driver with KernelEx won't work. KernelEx doesn't cater for drivers. Some will work with WDMSTUB.SYS, but not many. Search the forum for WDMSTUB, and you'll find much more about it. BTW, welcome to MSFN!