Re: DLL wedge by Danny
Danny
Fri Jun 01 07:43:03 CDT 2007
No, I do the name change before I run anything. So, in theory (famous
last words...) there should be no problem.
I've also tried rebooting to get things to a known state and just in
case the OS does something "secretly" at boot even though - being only
Windows 98 - I didn't expect it to be as through at protecting system
files as Vista is (at least from what I gather, anyway).
Dan
---
Jeff Richards wrote:
>If the real DLL is getting loaded before you do the name change then it will
>detect a mismatch between the loaded version and the file. Make sure you
>re-start the system after doing the rename.
>--
>Jeff Richards
>MS MVP (Windows - Shell/User)
>"Danny" <x> wrote in message
>news:up6u53tn6ihm2b0n1u9sucferon15a78k9@4ax.com...
>>
>> Ben Voigt wrote:
>>
>>>"Danny" <x> wrote in message
>>>news:laqt53tqql9ud98s42gao2k9nco951ekva@4ax.com...
>>>> Windows 98, C++
>>>>
>>>> I'm trying to wedge into a DLL to log all calls. It's a
>>>> quick-and-dirty thing (and I'm not really proficient in either of the
>>>> above) but the idea is as follows:
>>>>
>>>> TestProgram -> TestFolder/MyDLL -> ../System/RealDLL
>>>>
>>>> MyDLL just logs the call and passes it on to RealDLL as is.
>>>>
>>>> For clarity:
>>>>
>>>> Windows/System/RealDLL: actual DLL
>>>> TestFolder/MyDLL: DLL wedge I have written
>>>> TestFolder/TestProgram: do-nothing program which calls MyDLL
>>>>
>>>> In my test environment described above the code I've written so far
>>>> works just fine, but when I try to wedge in MyDLL for real, things
>>>> break down. Specifically there are two problems related to renaming:
>>>>
>>>> 1. When I rename the original DLL (and adjust references in MyDLL
>>>> accordingly) all of a sudden the calls return an unknown error code.
>>>> Specifically, given the above context, if I:
>>>>
>>>> Rename ../System/RealDLL to, for example, "OriginalDLL".
>>>> Change code in MyDLL to call OriginalDLL (instead of RealDLL).
>>>>
>>>> So I end up with:
>>>>
>>>> TestProgram -> TestFolder/MyDLL -> ../System/OriginalDLL
>>>>
>>>> This results in a bad (unknown) error/status code from the call which
>>>> is strange because nothing has changed internally.
>>>
>>>I don't understand why that would happen, unless the other DLL somehow
>>>checks its own name.
>>
>> That's what confuses me too, but as I say, I don't know much about all
>> this.
>>
>> So, you're saying, the OS (Windows98) does not secretly register
>> (System) DLLs somewhere else (e.g. during boot up) and then checks
>> when they're used. They're simply invoked as needed at run time,
>> right? My initial test program seems to confirm this were it not for
>> the renaming weirdness.
>>
>> If it helps any, the DLL in question is the plain old WNASPI32.DLL.
>> Nothing fancy, I would've thought. I'm trying to log calls to an
>> obsolete SCSI device in order to figure out the command set.
>>
>>>Are you using a linker import library, or
>>>GetProcAddress, to call into the original DLL.
>>
>> My wedge DLL uses LoadLibrary and then GetProcAddress. As far as I
>> understand, all very pedestrian.
>>
>> The weird thing is it works fine if I load the ../System/RealDLL but
>> goes pear shaped if I change the name of this library (both
>> in../System" and then in my code!?
>>
>>>> 2. The second problem is when I rename my wedge DLL to real name of
>>>> the DLL I'm trying to wedge into. Again, given the above context:
>>>>
>>>> Rename TestFolder/MyDLL to TestFolder/RealDLL
>>>> Change code in TestProgram to call this DLL instead of MyDLL resulting
>>>> in:
>>>>
>>>> TestProgram -> TestFolder/RealDLL -> ../System/RealDLL
>>>>
>>>> This blows up with:
>>>>
>>>> "Can't find DLL entry point in 'TestFolder/RealDLL'"
>>>>
>>>> This is very odd because nothing has changed except the name of the
>>>> DLL (which I refer to accordingly).
>>>
>>>This isn't at all surprising. Modules in Windows are identified by the
>>>filename, without path. When your DLL loads and tries to load the other
>>>DLL, it will get a handle to itself... and then won't be able to bind the
>>>import table which is, after all, designed for the other DLL.
>>
>> I can see how that could be a problem when the name is the same
>> although fully qualified references in LoadLibrary seem to work which
>> indicates (implies?) that the OS differentiates between the two.
>>
>> BTW, the above was just a simple case to clearly illustrate this
>> particular problem without confusing the issue with multiple renames.
>>
>> In any case, I've tried all permutations. For example, I tried the
>> following and got the same result:
>>
>> Rename TestFolder/MyDLL to TestFolder/RealDLL
>> Rename ../System/RealDLL to "OriginalDLL".
>> Copy TestFolder/RealDLL to ../System/
>>
>> So I end up with:
>> ../System/OriginalDLL (renamed RealDLL)
>> ../System/RealDLL (renamed MyDLL)
>>
>> So both are in the System directory and no explicit references are
>> needed in LoadLibrary. Still, the same problem occurs.
>>
>> Dan
>