--- In [email protected], "excesspapers" <excesspap...@...> wrote:
>
> I compiled on my XP 64-bit machine but still no difference. From what I can
> tell the dll is not getting built correct as a shell extension and that is
> causing the dll to not even be loaded. This seems to be validated since
> listdlls.exe does not show pproctx.dll being loaded at all. On the 32-bit
> system listdlls shows the dll as loaded under explorer.exe
My concern here is that explorer gets partly through loading, but then finds a
problem, and so unloads. That would also explain the listdlls situation.
Short answer: if you have logging called from dllmain and dllgetclassobject,
and you see nothing, I think it is a registry issue. See Sheri's note. My
superficial understanding is that the Windows WOW64 system can transparently
make it look like keys created from 32 bit apps (pproconf.exe in this case) are
in the 64 bit registry, when in fact they are not. But I am not sure under
what circumstances that transparent redirection happens and whether it affects
how you are viewing the registry. Recreating the keys from regsvr64 or 64 bit
regedit may help.
If you do see calls to dllmain and dllgetclassobject, it is an issue in the dll.
>
> I tried adding logging statements to functions in shellext.cpp but still did
> not get any debug file created. I see that shexinit.cpp already has the line:
>
> PProLog(TEXT(">>>Call initialize"), TEXT(""),0,0);
>
> Assuming that the init should be first and write the file seems
Actually, this call would be very late in the game.
A shell extension is just a dll which exports the getclassobject function.
Then when getclassobject is called, the dll must return a pointer to something
that behaves as a com object that, in turn, responds properly to
queryinterface calls. The dll must eventually state that is supports the com
interfaces associated with shell extensions and context menus when asked
through queryinteface. These interfaces have predefined guids which are passed
to queryinterface. The interfaces in binary are nothing more that vectors of
pointers to functions: if dll is implemented in c++, then the member function
pointers in the compiled object reference serve the role. So the static dll is
nothing special, rather it is how dllgetclassobject and the pointers it returns
respond to subsequent calls.
I think the order of calls would be something like (going my memory)
dllmain to load dll
getclassobject to get a com interface for object factory
queryinterface on object returned above to confirm it supports interface for
generic com factory
- call through that returned interface to COM object factory to get pointer to
new object
- call to query interface on that new object to see if it supports shell
extension init interface
- call in resulting pointer to shell extentsion init interface to function in
shexinit.cpp I(which is one of the member functions of context menu); this is
the function you note above
call on object to make sure it support context menu interface
calls on the resulting interface to build the menu and then invoke any
seleected command
--------------------------
I understand of course that you only have limited time to work on this. So
whenever it is convenient to you.
As I said above, if dllmain is not being called, I would still guess it is a
registry issue. But if some calls are logged, then let me know which.
