Loosing XP style on execustion

[TBass]

Hello,

We just upgraded from VS2003 to VS2008 Pro. One thing I noticed is
that, while editing forms in Visual Studio, they have a nice Windows
XP style (rounded buttons and frames, etc). However, once I run the
program (either inside or outside the debugger), that style is lost
and I get the typical Windows 2000 look (except for the window
border).

I'm assuming that there is a style configuration I'm supposed be
turning on or off in a config file, but I haven't seen one. Can anyone
tell me what I'm supposed to do to maintain the style?

Thanks!
Tom

 

[Kyle Alons]

Hello,

We just upgraded from VS2003 to VS2008 Pro. One thing I noticed is
that, while editing forms in Visual Studio, they have a nice Windows
XP style (rounded buttons and frames, etc). However, once I run the
program (either inside or outside the debugger), that style is lost
and I get the typical Windows 2000 look (except for the window
border).

I'm assuming that there is a style configuration I'm supposed be
turning on or off in a config file, but I haven't seen one. Can anyone
tell me what I'm supposed to do to maintain the style?

We found it necessary to turn off VS2008's default of generating and
embedding a manifest file. The manifest it generates doesn't have a section
to declare that your program should use the v6 common controls (which
enables XP themes). Oddly, while all our (VC++) projects already had a
manifest, and some failed to build due to a duplicate resource, others
compiled and linked but ran without themes. To correct both problems, in
project properties, under Configuration Properties -> Manifest Tool -> Input
and Output, we changed Embed Manifest to No and Output Manifest File to
$(IntDir)\$(ProjectName).manifest. Also note that although you can select
multiple projects + all configurations and seemingly change all at once, we
found that most of the time this did not stick with multiple projects
selected.

Another annoyance we found was that every build (even with no changes)
results in yet another .manifest file getting regenerated, which we also
disabled at Configuration Properties -> Manifest File -> Generate Manifest.

More about our upgrade experience is here:
http://www.kinook.com/blog/?p=49

 

[TBass]

Thanks for the tip, Kyle. Much appreciated.

T

 

[Ben Voigt [C++ MVP]]

We found it necessary to turn off VS2008's default of generating and
embedding a manifest file. The manifest it generates doesn't have a
section to declare that your program should use the v6 common
controls (which enables XP themes). Oddly, while all our (VC++)
projects already had a manifest, and some failed to build due to a
duplicate resource, others compiled and linked but ran without
themes. To correct both problems, in project properties, under
Configuration Properties -> Manifest Tool -> Input and Output, we
changed Embed Manifest to No and Output Manifest File to
$(IntDir)\$(ProjectName).manifest. Also note that although you can
select multiple projects + all configurations and seemingly change
all at once, we found that most of the time this did not stick with
multiple projects selected.
Another annoyance we found was that every build (even with no changes)
results in yet another .manifest file getting regenerated, which we
also disabled at Configuration Properties -> Manifest File ->
Generate Manifest.

In reality, you should embed a manifest (the CRT may not even load correctly
without it) but I agree the default generated manifest isn't always
sufficient. You can specify additional "manifest fragment files" under the
"Manifest Tool->Input and Output" section of project properties.

 

[Kyle Alons]

In reality, you should embed a manifest (the CRT may not even load

correctly without it) but I agree the default generated manifest isn't
always sufficient.

As I said, we do. And we link statically with the CRT.

 

[Ben Voigt [C++ MVP]]

As I said, we do. And we link statically with the CRT.

The way I understood your message was that you were suggesting turning
manifests off entirely.

And if you're using the CRT in any significant way (which is certainly true
when using MFC as this thread is concerning) you should use the DLL form of
the CRT.

 

[David Wilkinson]

The way I understood your message was that you were suggesting turning
manifests off entirely.

And if you're using the CRT in any significant way (which is certainly true
when using MFC as this thread is concerning) you should use the DLL form of
the CRT.

Ben:

Have to disagree with this statement. If you can design your application so that
it uses static linking, it is so much less trouble.

 

[Ben Voigt [C++ MVP]]

Ben:

Have to disagree with this statement. If you can design your
application so that it uses static linking, it is so much less
trouble.

Up to the point someone finds a security hole in the library or a
floating-point bug in the CPU that needs a library workaround, then suddenly
having a DLL is much better.

 

[David Wilkinson]

Up to the point someone finds a security hole in the library or a
floating-point bug in the CPU that needs a library workaround, then suddenly
having a DLL is much better.

Ben:

I have to say that I am very suspicious of this argument. Firstly it is very
different from the original argument for DLL's, which was to save disk space.
With the massive bloat in the OS itself, MS is wise to abandon this one.
Secondly, how often does this miraculous healing of MFC/CRT DLL's actually
occur? Extremely rarely I would imagine.

But the main problem I have with this is that these updates may be buggy and
destroy a previously working app. After all, applications are supposed to be
tested, and they are of necessity tested with the DLL's that they ship with (if
any). Even if my app should actually depend on a bug in some DLL, although I
would like to know about it, I would prefer to find out from an update in the
compiler, or a new version of the compiler, not from a bunch of users
complaining that my app no longer works after the latest Windows Update.

 

[David Lowndes]

Secondly, how often does this miraculous healing of MFC/CRT DLL's actually

occur? Extremely rarely I would imagine.

I'm not aware of it being done since VC6 time.

But the main problem I have with this is that these updates may be buggy and
destroy a previously working app.

Indeed that's what happened - when MS released updated versions around
VC6 time that fixed a problem they then had more problems with
applications that broke - 2 wrongs were making incorrect things work
and MS's (albeit correct) fix, broke them.

I also prefer static linking the CRT wherever possible, it's just so
much more convenient.

Dave

 

[Ben Voigt [C++ MVP]]

I'm not aware of it being done since VC6 time.

..NET Framework service packs push new versions of the Visual C++ Runtime
Libraries, I believe.

You can also certainly download newer versions of the Visual C++
Redistributable Runtime from the Microsoft site.

Indeed that's what happened - when MS released updated versions around
VC6 time that fixed a problem they then had more problems with
applications that broke - 2 wrongs were making incorrect things work
and MS's (albeit correct) fix, broke them.

They were broken even with the original library.

From a user's perspective, I would rather:

(1) Have an application not run at all than expose a exploitable security
hole
and
(2) Have the applications using the library correctly not have the
exploitable hole

I can always rollback the library by placing the original version in the app
directory, if I determine that the vulnerability is not a problem (blocked
via firewall, for example, or I have total control over input files, or
whatever reason).

I also prefer static linking the CRT wherever possible, it's just so
much more convenient.

I mostly avoid the CRT, and I totally avoid MFC. Calling Win32 APIs has
less footprint and they do get patched on a regular basis.

And yes, then for the few pieces of CRT needed, I statically link. But
that's pretty much just the entry point and wcerr.

 

[David Lowndes]

I'm not aware of it being done since VC6 time.

.NET Framework service packs push new versions of the Visual C++ Runtime
Libraries, I believe.

New maybe, but do they effectively replace existing ones and run the
risk of breaking applications? Based on MS's prior experience I think
they're highly reluctant to do that unless it could be deemed a severe
security risk that they're patching - and in the case of the CRT that
wouldn't be easy to determine as it depends on the application using
it.

They were broken even with the original library.

No, they worked with the original DLLs. They were probably wrong to
have done so, but they still worked correctly.

From a user's perspective, I would rather:
(1) Have an application not run at all than expose a exploitable security
hole and

How can MS ascertain whether a fix in the CRT constitutes a security
hole? It depends on the application using the CRT and MS have no
knowledge of that.

I really don't think the argument for security fixes holds any water
w.r.t. the CRT DLL usage.

Dave