DLLs and manifests
Christian Kaiser
a) Out tool DLL depends on other DLLs ("utility" functions, controls and
language resource DLLs)
Which DLL(s) need a manifest file? The DLL, the main application, the
"utility" DLLs, the language resource DLL?
If I set a manifest file in the DLLs resources, only ownerdrawn,
non-editable combo boxes have the XP dropdown button, all others have an
old-styled gray button. The dropdown list boxes as well as combo boxes have
XP scrollbars. Edit controls all have a black border.
Does anybody know the answer?
b) if we want to add commctrl 6 functionality, we need to include strange
functions like the appended ones (extracted from the new commctrl.h file)...
Yet some of the strange named functions have no declaration etc. Where do
they come from? Is there another way?
Christian
ISOLATION_AWARE_INLINE BOOL WINAPI
IsolationAwarePageSetupDlgW(LPPAGESETUPDLGW unnamed1)
{
BOOL fResult = FALSE;
typedef BOOL (WINAPI* PFN)(LPPAGESETUPDLGW unnamed1);
static PFN s_pfn;
ULONG_PTR ulpCookie = 0;
const BOOL fActivateActCtxSuccess = IsolationAwarePrivateG_FqbjaLEiEL ||
IsolationAwarePrivatenCgIiAgEzlnCgpgk(&ulpCookie);
if (!fActivateActCtxSuccess)
return fResult;
__try
{
if (s_pfn == NULL)
{
s_pfn =
(PFN)CommdlgIsolationAwarePrivatetEgCebCnDDeEff_pbMDLGDC_DLL("PageSetupDlgW"
);
if (s_pfn == NULL)
__leave;
}
fResult = s_pfn(unnamed1);
}
__finally
{
if (!IsolationAwarePrivateG_FqbjaLEiEL)
{
const BOOL fPreserveLastError = (fResult == FALSE);
const DWORD dwLastError = fPreserveLastError ? GetLastError() :
NO_ERROR;
(void)IsolationAwareDeactivateActCtx(0, ulpCookie);
if (fPreserveLastError)
SetLastError(dwLastError);
}
}
return fResult;
}
Dave
IsolationAware* functions allow both the V5 and V6 COMCTL32 to be used in
the same process.
Christian Kaiser
listbox and editbox. As first step, this SHOULD be easy, but it is not.
As it is, only some comboboxes have XP appearance, others the old one, all
listboxes are in XP style and edit controls have the old (black frame)
appearance. Catastrophe.
ISOLATION_AWARE_... is a problem for my compiler, as they use __try __except
which WC 11.0 does not yet support. Ok, I can work around that, but what
about the strange functions that I don't know where they need to be imported
from....
Christian
<Dave> schrieb im Newsbeitrag news:uuz4kRicBHA.1540@tkmsftngp03...
Jon Wiswall [MS]
> language resource DLLs)
>
> Which DLL(s) need a manifest file? The DLL, the main application, the
> "utility" DLLs, the language resource DLL?
Depends on what you're building. It sounds like you're building a DLL that
your app will load and use at some point during its lifetime, and which DLL
might load other DLLs. If you're building a component for some larger app,
may I suggest that you look into "private side-by-side assemblies"? A
private assembly is a collection of files (DLLs, images, etc.) that
logically go together, and can have a version number, a language type, etc.
Sounds exactly like what you're looking for -
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/sideb
yside_1y5v.asp tells about the guidelines for creating the assemblies, and
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/sideb
yside_1qur.asp details how private assemblies can be used in an application.
The question of "which dlls need a manifest" depends a lot on how your
application are structured. If you have one DLL that exports your public
APIs (toolldll.dll) that knows how to delegate calls to tool_part1.dll and
tool_part2.dll, then you might consider doing your own activation context
management - see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/sideb
yside_1qur.asp - around your entrypoints in tooldll.dll, so "your"
activation context is active only when your code is running. If, however,
you've got a host of little DLLs that your application knows how to load and
talk to directly, or they're statically linked into your main application
(ie: no need to loadlibrary/getprocaddress), then you should consider using
ISOLATION_AWARE_ENABLED on each DLL, each DLL having its own manifest at
resource ID 2 (type RT_MANIFEST), so only the calls that need it will get
isolated.
--
Jon Wiswall - Microsoft
This posting is provided AS IS with no warranties, and confers no rights.
"Christian Kaiser" <bc...@gmx.de> wrote in message
news:#tfbf$dcBHA.568@tkmsftngp02...
> We are creator of tool DLLs and very confused now...
>
Christian Kaiser
I read the sections in the MSDN right now. This is somehow enlightening, but
not sufficient to get all of the idea behind it (or bugs in XP make me think
I don't get it...) For example, why are comboboxes in a DLL themed if the
DLL is not and the APP has a manifest, but is ISOLATIONAWARE? (see my last
mail). And why are edit controls NOT and listboxes only partially (they have
the NULL pointer bug, but the black frame instead of the themed one)?
Next question: if we make a program using ISOLATION_AWARE_ENABLED, why does
the app still work on NT4 although all these new IsolationAwareXxxx and
ActCtxXxx API functions are used? I did not create the app, so it's a bit
hard for me to tell all these switches of MSVC, but I don't see "delayload"
to be in effect. I'm missing something obvious here, but I don't see it :)))
BTW: Where can I download XP SP1 as the automatic update does not work?
(possibly due to the proxy/firewall).
Thanks,
Christian
"Jon Wiswall [MS]" <jon...@online.microsoft.com> schrieb im Newsbeitrag
news:uqLCF1UeBHA.2680@tkmsftngp07...
David Lowndes
Don't feel alone in this respect - have a good moan about it :)
I've raised the same issue (inadequate documentation on theming to
know why something isn't working as you'd expect) as well.
I've also recently had confirmation from MS that it's not possible to
get an MFC shell extension to theme - currently (I'm still waiting for
more information).
Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
My address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow-up email copies.
Jon Wiswall [MS]
aware." Isolation-aware means "I know how to manage activation contexts so
that I get the DLLs, WndProcs, and COM objects that I need, no matter what
my consumer does." Typically when one talks about both of them, they say
"my dll is themed with a manifest" - this is only partially correct. Your
DLL is themed because you had a manifest that mentioned the v6 common
controls, and that manifest was turned into an activation context and
activated before calling InitCommonControls or CreateWindow("combobox",
...).
The reason your DLL gets themed comboboxes when your consumer doesn't know
about theming (imagine an old pre-build app loading your DLL, and requesting
your DLL for some UI) is that you compiled with ISOLATION_AWARE_ENABLED and
had a manifest in your resources at ID #2. Let's take a look at what
happens when you compile with I_A_E set and are consumed by FooApp.
0. FooApp calls the v5 InitCommonControls b/c it doesn't know how to get v6
1. FooApp loads YourDll.dll
2. FooApp calls YourDll!DisplaySomeUserInterface
3. YourDll!DisplaySomeUserInterface calls CreateWindow for a control (let's
say it's combobox)
4.1 CreateWindow was compiled as YourDll!IsolationAware{CreateWindow}
because of the stuff in winbase.h
4.2 YourDll!IsolationAware{CreateWindow} determines that you have a manifest
at ID 2, and creates an activation context for it
4.3 YourDll!IsolationAware{CreateWindow} activates said activation context,
and calls through to user32!CreateWindow
4.4 user32!CreateWindow knows how to use the active context to find the v6
window class and wndproc for combobox (let's say comctl6!WndProcComboBox,
which is theme-aware)
4.5 user32!CreateWindow returns, and YourDll!IsolationAware{CreateWindow}
deactivates the previous activation context
5. FooApp uses the HWND that you returned it to display the UI you created.
6. When FooApp calls user32!ShowWindow, the wndproc messages for that
combobox are routed to comctl6!WndProcComboBox rather than the
comctl5!WndProcComboBox, because the HWND stores the wndproc that the
messages are destined for.
See how that works? Your caller didn't (doesn't) know anything about /your/
isolation capability, and it doesn't need to - it just needs to know about
HWNDs. The HWND that you created with CreateWindow for the combobox is the
one that contains the target windowproc for it, and the window-message
infrastructure simply routes messages to the wndproc, which (because
yourdll.dll was isolation-aware) came out of comctl6.
> Next question: if we make a program using ISOLATION_AWARE_ENABLED, why
does
> the app still work on NT4 although all these new IsolationAwareXxxx and
> ActCtxXxx API functions are used? I did not create the app, so it's a bit
> hard for me to tell all these switches of MSVC, but I don't see
"delayload"
> to be in effect. I'm missing something obvious here, but I don't see it
:)))
So the nice thing about I_A_E is that it works "downlevel" - the wrappers
(IsolationAware*) are aware of whether or not they're on a side-by-side
capable OS by looking at Kernel32 for ActivateActCtx. It's "delayload" in
the sense of "delaying lookup of function entry points until necessary." In
a downlevel world (ie: no ActivateActCtx, CreateActCtxW, DeactivateActCtxW,
etc. in kernel32.dll) the wrappers act as pass-throughs to the original
function without doing any context management. Uplevel (XP, etc.), they'll
do the Right Thing with regards to activating the proper context as needed.
This isn't obvious for a reason - the obfuscated IsolationAware* functions
are not meant to be consumed directly, rather only through inclusion of
winbase.h.
> BTW: Where can I download XP SP1 as the automatic update does not work?
> (possibly due to the proxy/firewall).
www.windowsupdate.microsoft.com has the latest updates available.
Roger Pfister
> Remember that there's a difference between "themeing" and being "isolation
> ....
Great stuff [deleted]
Thanks greatly - my only comment is
Please can we have all this "side view and strutural approach"
that your posting is, go into the knowledge base.
IMO idealy it would have been there by the time of the XP consumer launch :)
but anyway - thanks again, for the insights.
--
Roger
David Lowndes
>aware."
>...
>4.1 CreateWindow was compiled as YourDll!IsolationAware{CreateWindow}
>because of the stuff in winbase.h
>4.2 YourDll!IsolationAware{CreateWindow} determines that you have a manifest
>at ID 2, and creates an activation context for it
Jon,
Your mention of the term "activation context" in conjunction with
themes is the first I've ever seen, and now I have, I see there's
quite a bit of information on the subject on MSDN (though not
necessarily in conjunction with adding theme support). However, it's a
bit heavy going.
I don't think MS has done a very good job of explaining to developers
quite how theming working. Consequently, if the overly simplistic
step-by-step instruction on how to enable theming in your application
don't work, then I (and presumably others) are rather stumped as to
why.
A few pictures in the Platform SDK explaining what happens wouldn't go
amiss!
Are you aware of the difficulties some of us are having in this area,
and if so, what's being done about it?
>.. more steps snipped..
>6. When FooApp calls user32!ShowWindow, the wndproc messages for that
>combobox are routed to comctl6!WndProcComboBox rather than the
>comctl5!WndProcComboBox, because the HWND stores the wndproc that the
>messages are destined for.
>
>See how that works?
Quite honestly - no :(
Are there any pictures in the SDK docs to help visualise this?
Jon Wiswall [MS]
> bit heavy going.
>
> I don't think MS has done a very good job of explaining to developers
> why.
>
> A few pictures in the Platform SDK explaining what happens wouldn't go
> amiss!
Thanks for your comment on the docs - you're right, the term "activation
context" is a little impenetrable, and hard to see where it comes in with
theming. Now that you've read up on activation contexts and side-by-side
isolation, you can probably see the benefit of having multiple shared
versions of the same component on a system, right? Unfortunately, it's a
hard road to convince developers that they should switch their
already-working-and-shipping components to be side-by-side aware on Windows
XP, since there's no support for it downlevel, for which (unfortunately) the
majority of their components are designed. (However, there should be
downlevel "dump everything in system32 or the app directory" support if you
install your component downlevel via MSI.)
My area of work is in the side-by-side component sharing plumbing, not in
the theming area, so my take comes completely from "gee, side-by-side (sxs)
sharing is really neat!" rather than "apps that look like they belong on XP
are neat!" The theory behind having developers use activation contexts to
get to the "new visualization" should be thought not of as "theming my app"
but rather "using activation contexts to get to the version 6
common-controls assembly." If you can make that leap, and you can cozy up
to the MSDN docs on side-by-side sharing for a little while, it'll all make
a lot more sense. As for the themeing API docs, that's something else
entirely.
I'll see what I can do about getting some updates into the PSDK docs that
better describe exactly how an app gets ahold of the v6 common controls
(aside from the "just put a manifest in the exe" or "recompile with I_A_E
enabled" versions), and what side-by-side sharing exactly allows you to do.
Could I ask what part of the step-by-step instructions didn't work for you?
I'll see if I can reproduce it and get updates to the docs.
> Are you aware of the difficulties some of us are having in this area,
> and if so, what's being done about it?
Most of us are so close to the source, it's hard to see the forest for the
trees. We understood that there would be something of a large learning
curve to get on-track with sxs components, for which we had prepared our
stuff in the PSDK. Unfortunately, there's no "ThemeMyAppMagically()" or
link-switch "-appisthemed" - like any other API, it's hard to get used to
using it at first. This is an "entirely new world" enabling better shared
code. We'd hoped that ISOLATION_AWARE_ENABLED and the "app.exe.manifest"
solutions would cover 90% of the cases. What specific problems are you
having (besides the ones you've already pointed out) that we can address?
> Quite honestly - no :(
>
> Are there any pictures in the SDK docs to help visualise this?
There aren't at the moment... it's all thought experiments and explanations,
but no easily-grokkable diagrams. Could I ask which of the topics were
most/least helpful for understanding sxs-sharing? Also, I'll see what I can
do about getting some better walkthroughs of how all this works
conceptually. However, be warned that these updates will be for "side by
side assemblies" in general, and may or may not have much to do with
themeing specifically.
David Lowndes
>isolation, you can probably see the benefit of having multiple shared
>versions of the same component on a system, right?
I wouldn't say that I've read up on it. It's something I've not needed
to worry about so far. I like to take as much of the OS for granted
for as long as I can :)
>I'll see what I can do about getting some updates into the PSDK docs that
>better describe exactly how an app gets ahold of the v6 common controls
>(aside from the "just put a manifest in the exe" or "recompile with I_A_E
>enabled" versions)
Great, that's the area that I think needs quite a bit more detail.
Those instructions aren't any use when they don't work - or are
incorrect (or just out of date) as they were in early releases of the
SDK documentation.
>Could I ask what part of the step-by-step instructions didn't work for you?
I've already raised some specific points through another channel so
you may already have heard my comments, but basically those
instructions are insufficient. For instance:
"Include the common controls header file".
Which source file should you include it in - and why? Do you need to
explicitly include it if it's already getting included from some other
part of your build process? The answer is no - you don't necessarily
need to include it if it's already getting pulled in from elsewhere. I
established this from an SDK project that themed correctly despite my
not having included commctrl.h in any of my source or header files.
VC7 traced its inclusion down to stdlib.h:
Note: including file: H:\Microsoft Visual Studio
.NET\Vc7\include\stdlib.h
...
Note: including file: H:\Microsoft Visual Studio
.NET\Vc7\PlatformSDK\include\commctrl.h
"Compile your application with the -DISOLATION_AWARE_ENABLED flag"
Again, why - and which modules need it. What's getting changed as a
result of this definition?
The whole set of instructions just beg the question - why do we need
to do it? What happens just below the surface?
>What specific problems are you
>having (besides the ones you've already pointed out) that we can address?
The problem I've come across is an inability to theme an MFC based
shell extension DLL.
I've done non-MFC shell extensions, and an MFC application without a
problem, but the MFC shell extension dialogs just wouldn't display
themed - although I could use the new marque style progress control in
a modeless dialog that displayed the theme correctly (this dialog was
a non-MFC dialog). Someone at MS has subsequently reproduced the
problem and confirmed there is an issue that needs solving.
The problem I had with the documentation was that it gave me no
knowledge of how theming was supposed to work, so I couldn't decide
whether I was doing something wrong or not. Thankfully it appears I
wasn't.
>> Are there any pictures in the SDK docs to help visualise this?
>
>There aren't at the moment... it's all thought experiments and explanations,
>but no easily-grokkable diagrams. Could I ask which of the topics were
>most/least helpful for understanding sxs-sharing?
I'm afraid I've only given them a casual skimp through, so I can't
offer you any suggestions at this time. Should I need to, rest assured
that I will pass on my comments.
>Also, I'll see what I can
>do about getting some better walkthroughs of how all this works
>conceptually.
Thanks.
Christian Kaiser
okay, I know you sigh, it's me again, but there are some issues you might be
able to answer.
If I create a small program in delphi 4, make sure I call
InitCommonControls() and add a manifest resource, everything works like a
theming charm. All frames the correct color, dropdown button themed, common
dialogs themed, etc.
How does Delphi 4 (!) do that without knowing anything about Activation
Contexts? This is behaviour mere mortals like me, unaware and (yet) not in
the need of isolation, want. Minimal work for full theming awareness.
This is what my DLL does right now (relies on the main app that needs a
manifest and InitCommonControl(), and that's all), except that these editbox
frames are black etc - I eagerly hope you find an answer to that
irregularity.
Thanks,
Christian
David Lowndes
>shell extension DLL.
This is a good one! The latest feedback I've had notes this...
If I invoke the shell extension normally from a file of folder
selected in Explorer, theming doesn't work (at least there's no
visible difference in the displayed dialog).
However, if I invoke it by right clicking a shortcut item in the Quick
Launch, the very same dialog displays themed.
Jon Wiswall [MS]
be
> able to answer.
Actually, it's nice to know that someone's using what I worked on for the
past year and a half or so. =)
> If I create a small program in delphi 4, make sure I call
>[..]
> the need of isolation, want. Minimal work for full theming awareness.
So here's what's happening in that case (behind the scenes, mostly:)
1. Your exe (delphi-test.exe, for naming purposes) got created via
CreateProcess, and during that time manifest (RT_MANIFEST) was found in
resources at ID #1. (That's important, and I'll mention it later)
2. Because that manifest was found in a "default" place, it got created with
a call to CreateActCtx, and the resulting activation context was set as the
"process default."
3. Delphi's runtime (or the straight code) called LoadLibrary at some point
to get "comctl32.dll"
3.1 The loader called SearchPath (rather, the guts of searchpath) to find
"comctl32.dll".
3.2 SearchPath looked for a current activation context, and it found that
there was a "default" for the process (which was set in step #2)
3.3 That activation context listed "comctl32.dll" as belonging to the
assembly "x86 Microsoft.Windows.Common-Controls v6.0.0.0", and searchpath
knew how to find out that the common-controls assembly lived in
"%windir%\winsxs\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.
0.0_x-ww_1382d70a" - it found a comctl32.dll there, so it returned that path
to the loader
3.4 The loader opened the dll that SearchPath found
(%windir%\winsxs\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.
0.0_x-ww_1382d70a\comctl32.dll) and returned that module handle.
4. Delphi called GetProcAddress on the DLL that LoadLibrary returned, and
found InitCommonControls.
5. The delphi framework (or you directly, doesn't matter) called
CreateWindow(listbox, ...)
5.1 User32 looked at the current activation context for the window class
"listbox", and found that one was available in "x86
Microsoft.Windows.Common-Controls v6.0.0.0" from "comctl32.dll"
5.2 User32 associated the "listbox" window class that the version 6 comctl32
had registered as being the one you wanted, rather than any others.
6 All windows get created with the version 6 common controls, and as such,
are themed.
This is based on the fact that your manifest was listed as a "process
default" - it was found at ID 1 in the exe image resource tables, or it was
found on the filesystem as "dephi-test.exe.manifest" - both of these
instruct the loader to create an activation context for that manifest, and
use it for all loadlibary, searchpath, CoCreateInstance, CreateWindow,
RegisterWndClass, etc. calls. If you look at the common-controls v6
manifest
(%windir%\winsxs\Manifests\x86_Microsoft.Windows.Common-Controls_6595b64144c
cf1df_6.0.0.0_x-ww_1382d70a.Manifest), you'll see what I'm talking about -
there are <windowClass> entries under the file for comctl32.dll, which mean
that whenever someone requests one of those window classes, it should come
out of the dll under which the windowClass tag is listed.
The short version is, "you had a manifest in a default place, so the loader
picked it up and used it anytime you needed an activation context and hadn't
activated one of your own." The common-controls are all
forwards-compatible, so you were able to simply drop a manifest in a default
place and get all the theming goodness you needed. This wouldn't work if
the common-controls weren't forwards compatible, and it probably won't work
with other assemblies (Microsoft XML, GDI+, etc.).
> This is what my DLL does right now (relies on the main app that needs a
> manifest and InitCommonControl(), and that's all), except that these
editbox
> frames are black etc - I eagerly hope you find an answer to that
> irregularity.
I'm still confused as to the "black border" problem - I have yet to see this
effect, but of course, all my work is in C and C++. The rule of thumb,
however, is that unless a DLL can only ever be called into by a single
application, it should have its own activation context (potentially shared
with the main exe by some global, however) and activate it as necessary.
ISOLATION_AWARE_ENABLED with a manifest in resources at ID #2 in the DLL
should fix that.
I'll try and find Delphi somewhere to investigate what you're seeing.
Christian Kaiser
nope, the black frames are in a C++ DLL. The DLL does neither have a
manifest nor ActCtx calls, but is used by an MFC app that has both. If that
DLL has edit or list controls in a dialog, their borders are black. And if
that DLL creates a window on the fly (i.e. a combo box), this is not themed
at all - so I guess dialogs created by CreateDialog[Indirect] are
automatcially themed (caused by the app's manifest), but CreateWindow() is
not... Why is that?
(Attention: these are not standard dialogs of "#32xxx" class but have an own
class - I don'T know whether that's important)
If it would help, I can send you an application which shows the effect, or I
even easier can tell you where to download a demo of our tool DLL to see it.
I just wondered why a Delphi application that knew nothing of ISOLATION
worked with the scheming. Thanks you very much for your very explicit
explanation, I hope it cleared up some muddy waters in my mind. Need to
sleep over all that :)
Christian
"Jon Wiswall [MS]" <jon...@online.microsoft.com> wrote in message
news:up#Kl85fBHA.2472@tkmsftngp03...
Jon Wiswall [MS]
news:VA.0000007...@rpsd.net...
> black box/border example
>
> [Great Stuff deleted]
>
> Jon Wiswall wrote
>
> > I'm still confused as to the "black border" problem - I have yet to see
this
> > effect, but of course, all my work is in C and C++.
>
>
> ThemeTab.zip
I'll look at this first-thing monday.
> If you want to see "black box" in live code. Put a defualt mainifest
> on VB6 and run the main APP wizard. the choice of MDI SSI EXP shows
> as three black boxes
You mean put a manifest on the vb6 IDE? That's certainly not supported -
dropping a manifest on an existing EXE like this has a pretty good chance of
working the way you want it to, but it also has a pretty good chance of
completely not working at all. I don't advise simply putting a manifest in
resources at ID 1 or making foo.exe.manifest - it -may- work, but then
again, as we see with the vb6 ide, it probably won't. =)
--
Jon Wiswall - Microsoft
This posting is provided AS IS with no warranties, and confers no rights.
>
> Thanks for all your postings.
>
> --
> Roger
>
>
Roger Pfister
> > If you want to see "black box" in live code. Put a defualt mainifest
> > on VB6 and run the main APP wizard. the choice of MDI SSI EXP shows
> > as three black boxes
>
> You mean put a manifest on the vb6 IDE? That's certainly not supported -
> dropping a manifest on an existing EXE like this has a pretty good chance of
> working the way you want it to, but it also has a pretty good chance of
> completely not working at all. I don't advise simply putting a manifest in
> resources at ID 1 or making foo.exe.manifest - it -may- work, but then
> again, as we see with the vb6 ide, it probably won't. =)
Of course I would not advise this as "user policy". This was just
part of "developer exploration".
--
Roger