View Single Post
  #8  
Old December 8th 17, 04:29 AM posted to alt.windows7.general
Mayayana
external usenet poster
 
Posts: 6,438
Default Windows Explorer Replacements

"J. P. Gilliver (John)" wrote

| So this is one case where 32-bit software _won't_ run under 64, is it? I
| presume because in 64, Explorer is a true 64-bit application, so won't
| "play nice" with extensions?

It's because a shell extension is an in-process DLL.
It runs in the Explorer process, as part of the Explorer
program, so to speak. 32-bit can run on Win64 but
the two can't mix in the same process. I'm not entirely
clear about the technical reasons. I think it's that an
in-process DLL is sharing the same memory space, which
is different size in 32 and 64. And functions use different
size parameters. For instance, as an Explorer Bar my DLL
receives notifications from Explorer. Things like info about
its size and location, and access to the instance of the
ShemllFolderView object representing the folder contents.
That allows me to respond to events like changes in the
selection. Those messages will have 32-bit parameters.
In 64-bit they'd probably be 64-bit parameters. That means
my DLL would mistakenly read the 1st 4 bytes of the first
parameter as the 1st, and the 2nd 4 bytes of the 1st
parameter as the second parameter. Since that's likely to
be a pointer to data stored at a memory address in Explorer's
memory context, my DLL will try to read "illegal" or wrong
memory as a result and crash. At best it would just fail to
work.

For other 32-bit COM DLLs I can just write an ActiveX
EXE for Win64. Same exact thing but out-of-process. And
any kind of stand-alone software can run on Win64. For
shell extensions it won't work that way. It has to be
in-process. And I don't have experience with writing 64-bit
code. So I gave up on adapting my Explorer Bar and now
only use it on 32-bit systems. But I assume other people
have written 64-bit Explorer Bars.


Ads