Visual C++ Team Blog

Can we control which runtime the automatically created manifest will reference? I would like my old VC++ 2008 projects to keep using the crt and mfc dlls of the RTM version and only use the new runtimes when I have new projects which use the new functionality.

--

SvenC

I would like to deploy dynamically linked apps using Installshield.  I will need merge modules for the new library files.

Are they available?

This is great news Kudos to the team. Now what I'd really like to see is a couple of MSDN Magazine articles that cover the new MFC additions (TR1 stuff I can find from 'Standards' sources).

Great! Thanks!

Is it planned to release a Feature Pack for WinForms? It would be great to add a Ribbon to a WinForm application as well.

Any plans for Win32 API versions of those controls (which don't already have Win32 API versions, of course)? Not everyone uses/likes MFC, and MFC can use native controls, so it seems a shame that they are made for MFC rather than native Win32 API (with an optional thin MFC wrapper for those who want it).

TR1 does look useful, so thanks for that. It's great to see things being added to the C++ support quickly now.

Does anyone know exactly what has changed since the pre-released Feature Pack?

Some components from BCG are missing, /*always Microsoft forget some thing of interting in the lib*/. What about the Grid, the Calender and other intertings things, i can't use this feautre pack unless it's complete (and i guess that others do the same).

Using the feature pack, developers can still develop application with the older look & feel of MFC.

Thanks,

Ayman Shoukry

Hi, unfortunately installation fails on an English language system which have different regional settings. I've English Vista x64  and an English language VS2008 Team Developer Edition. My user account's regional settings are set to German. Setup fails with an error message after extracting file, but before showing the setup GUI. It works after switching Vista's regional settings to en-us.

[Mathias]

> Is it possible to just use the new STL (tr1) stuff and keep the standard vs2008 MFC ?

Yes - there is no interaction between TR1 and MFC.  Using TR1 doesn't force you to use the updated MFC (or MFC, period).

No - you can't patch TR1 without also patching MFC.

[TomC]

> I would like to deploy dynamically linked apps using Installshield.  I will need merge modules for the new library files.

> Are they available?

They are indeed part of the Feature Pack.

[Dave Johansen]

> I think that this is an exciting release, but it should be made available

> to Express edition users as well. Maybe the MFC components can't be

> released to the Express edition, but the TR1 stuff definitely should be.

TR1 is integrated into VC9 SP1 and VC10.

[Jared]

> Does anyone know exactly what has changed since the pre-released Feature Pack?

Lots and lots of bugfixes. For example, in the Beta, linking together two source files that each included <tuple> would fail with "multiply defined symbols". We fixed that thanks to Beta feedback.

Stephan T. Lavavej

Visual C++ Libraries Developer

not worth to get happy. those such libraries make improve GUI only, not the inside quality.

bad job of MS.

"The Feature Pack is available free of charge to any Visual Studio 2008 Standard or above customer."

Is not.  Read the page:  'Support for systems with non-English versions of Visual Studio 2008 installed will be available in Visual Studio 2008 Service Pack 1.'  Now will that come out this year?

Where can I download the documentation for this feature pack, I don't want to always use the online help when I am need help for this new stuff.

Installation doesn't work here (VS2008 Pro English, Vista x64 German), but I could send an error report. Fails with unknown error even after a fresh reboot.

Answering couple of the questions:

1) The feature pack is focused on x86 & x64

2) We are investigating the installation issues, some folks tried changing the locale to English and the installation then worked (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3130795&SiteID=1 might help).

Thanks,

Ayman Shoukry

What about the offline documentation for this feature pack? Any plans or release dates for this? It would be very helpful! Thanks...

I am still interested in my initial question: can we control what kind of manifest will be generated, so that our executables can either have manifests for the RTM version of the crt, mfc or the new runtimes of the feature pack.

I found no documentation if after installing the feature pack we can still build executables which run with the rtm version of crt and mfc.

Thanks,

SvenC

http://blogs.msdn.com/vcblog/archive/2008/04/07/visual-c-2008-feature-pack-released.aspx Finally we get

> MFC will continue to wrap any new Windows controls, so if Windows includes controls that have

> similar functionality to the MFC controls, there will be wrappers available so you can choose

> between using the Windows control and the MFC control.

I was asking for the opposite. :) I don't want to be forced to use MFC to get these new controls. I find that MFC makes very easy projects slightly easier (and I use it for throwing together very simple GUI apps), but for anything complex MFC actually gets in the way and makes things more difficult, not less.

If the Visual C++ team are going to invest in GUI controls it would be nice if they were available to all Visual C++ developers, not just those using MFC. Of course, it's easy to turn a Win32 control into an MFC object so you can please both groups of people by writing/buying Win32 controls and wrapping them in MFC. With an MFC-only control, however, it's not easy to convert it into a non-MFC control.

Of course, anything is better than nothing; I'm just saying that controls like these would be useful to many more people if they were not tied to MFC. I also understand that the controls were bought from a 3rd party and maybe there simply were no non-MFC alternatives.

I wish to update my current MFC 8.0 project and replace some 3rd-party code with Feature Pack CMFC* classes.

But there's one question, Can it be deployed to Win 2000 after my upgrade? a more general question is: what OSes are supported by applications developed with MFC9.0+Power Pack?

Thanks.

[S. Colcord]

> If I install the feature pack, will I have to agree to the Fluent UI licensing terms?

You only have to agree to the Fluent UI licensing terms if you are creating an application that uses the Fluent UI components (aka the ribbon UI) in MFC.

Installation package is a peace of crap. After 10 minutes and progress bar frozen somewhere at 75% it returned with "fatal error"

From the log file:

MSI (c) (C8:F8) [22:25:12:187]: MainEngineThread is returning 1603

-------------------------------------------

VS Team: you have no rights to release such a junk even if junk is just an installation routine but not the content.

Get this error in 32-bit compiles with the TR1 update installed:

1>c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\intrin.h(204) : error C2373: '_InterlockedCompareExchange' : redefinition; different type modifiers

1>        c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\memory(994) : see declaration of '_InterlockedCompareExchange'

Ouch!  The newer Windows SDK caused some problems like this with VC++ 2005, but 2008 fixed them.  Now it happens again, but within VC++ itself!

Cory Nelson:

Thanks for reporting this. I've added your repro to our internal bug "<memory> should include <intrin.h>".

Stephan T. Lavavej

Visual C++ Libraries Developer

Hi Mr.MFC,

I just tried the sample myself and it seems to compile with no errors. Have you tried installing after uninstalling the beta?

Let me know if the sample still doesn't compile with you.

Thanks,

Ayman Shoukry

thank you! I've been using BCG for years and years, love it. This is nice for those apps that don't need *all* the bcg features. A step in the right direction for sure. Much appreciated!

[Pat Brenner]

> No, there is no separation via namespace.  Basically, if you are not using any of the CMFCRibbon* classes, you are probably not using the fluent UI.

Thanks, Pat.  FWIW, I think that without such a separation, a lot of developers will use those classes without realizing the legal implications.  The above guideline is helpful, but I think that company lawyers are going to want something more definite.

To clarify why this is a concern, Microsoft is saying "If you use the Fluent UI, you need a license", but I haven't found an clear definition of what constitutes "Using the Fluent UI".  Without a clear definition, the license requirements create a lot of FUD, since a developer can't tell whether they need a license or not.

> Note that the license is a no-cost, royalty-free licence which is obtained via a simple click-through agreement on the Office UI site.

The issue isn't the cost; it's that the license incorporates the Fluent UI design guidelines as legal requirements.  Depending on the application, the costs of making it conform to those requirements could be prohibitive.

If you have been using the Boost libraries then you will probably not see anything major that's not already

I'm very happy to see the new BCG controls.  But I'm trying to test out the random number generation that is part of TR1, and no dice.

If I create a new MFC project from scratch, accept the default settings, then use

#include <random>

anywhere, I get 117 errors and 6 warnings, (listed at the end).  Since I'm doing all this from scratch with the default settings, I think this is a bug.

errors/warning beginning with:

1>c:\program files\microsoft visual studio 9.0\vc\include\xdebug(32) : warning C4229: anachronism used : modifiers on data are ignored

1>c:\program files\microsoft visual studio 9.0\vc\include\xdebug(32) : error C2365: 'operator new' : redefinition; previous definition was 'function'

1>c:\program files\microsoft visual studio 9.0\vc\include\xdebug(32) : error C2491: 'new' : definition of dllimport data not allowed

1>c:\program files\microsoft visual studio 9.0\vc\include\xdebug(32) : error C2078: too many initializers

1>c:\program files\microsoft visual studio 9.0\vc\include\xdebug(32) : error C2440: 'initializing' : cannot convert from 'int' to 'void *'

1>        Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast

1>c:\program files\microsoft visual studio 9.0\vc\include\xdebug(32) : error C2143: syntax error : missing ';' before '('

1>c:\program files\microsoft visual studio 9.0\vc\include\xdebug(32) : error C2226: syntax error : unexpected type 'size_t'

1>c:\program files\microsoft visual studio 9.0\vc\include\xdebug(33) : error C2059: syntax error : ')'

Hi Big E,

Could you let us know what kind of changes you made so that we can reproduce the issue on our side.

Feel free to send me the project straight ahead at aymans at microsoft dot com

Thanks,

Ayman Shoukry

> Could you let us know what kind of changes you made so that we can reproduce the issue on our side.

I'm actually not touching anything when this happens. As I stated originally, I'm just running through the MFC app wizard.

I'm choosing almost all the default values, with the exception of the first page of the wizard. There, I choose the following:

Application type: Single document

Document / View architecture: enabled

Resource language: English

Use unicode libs: enabled

Project sytle: Office

Visual style and colors: Office 2007 (Blue theme)

Enable visual style switching: enabled

Use of MFC: Use MFC in a static lib

On every subsequent page of the wizard, I just go with the default values. Once complete, I build the application (rebuild all) and hit F5.

This results in an assertion firing on line 3891 of afxribbonbar.cpp, which is this line:

ENSURE(str1.LoadString(AFX_IDS_ONEPAGE));

The ENSURE macro then throws an unhandled exception that terminates the app.

I haven't yet tried any other project types.

Hope that helps.

Thanks, Stephan - I appreciate the info.  Works now.

[Norman Diamond]

> (1) A workaround is to delete the line

> "#define new DEBUG_NEW".

Yes, insofar as that stops stomping on the Standard/TR1 headers. I'm not sure how that affects the MFC side of things. (The danger here is presumably using the MFC leak tracking in some translation units and not in others, leading to heap corruption when they pass pointers to each other. It does appear that the MFC leak tracking is optional, according to MSDN - the new project wizard is simply enabling it by default. So, if you really get rid of all occurrences of this macro, you should be fine.)

> (2) This is a bug in the wizard which might be a

> fix or might be a won't fix for VS2008 SP1.

According to my understanding, the wizard has always done this, and it's always opened up the 17.4.3.1.1/2 can of worms - TR1 just happens to trigger actual breakage.

(IIRC, other Standard Library headers attempt to defend themselves against "new" being macro-ized - but if you ask me, we should actually detect and #error when any keywords are macros, rather than defending against it. We do defend against "min" and "max" being macros, but that's because <windows.h> defines them.)

"#define new DEBUG_NEW" is operating by design, and the wizard is enabling it by design. The design just happens to be extremely unfriendly to the Standard headers. (As co-maintainer of the headers being stomped on, this is not my favorite macro.)

> By the way, is there a target yet for which year

> most language versions of VS2008 SP1 might be

> released?

I'm not sure what you're asking. VC9 SP1 (any language) has not yet been released, and I don't think we've talked about release dates yet (although we certainly have them in mind).

I can say that it is not yet too late to get fixes for Horrible TR1 (and MFC) Bugs into VC9 SP1, *if* they are reported promptly enough (and the bugs are horrible enough, and the fixes safe enough, etc.).

Thanks,

Stephan T. Lavavej, Visual C++ Libraries Developer

Hi Norman,

I don't believe there were any dates published yet regarding VS2008 SP1. I will make sure to post those dates as soon as I have them.

Thanks,

Ayman Shoukry

I've tried running the Boost regression tests against the release feature pack, and while a lot of the problems from the Beta have

been fixed, there are still a few left:

-Random:

One of the Random tests is failing (http://tinyurl.com/5lt4u7) because of a missing "seed(integer-type s)" member function in xor_combine.

When i mentioned this on the Boost list, it was thought that this was a 'bug' in TR1 due to Table 16 saying that all random number

engines should have that member, but the description of xor_combine not mentioning it.

However, the TR1 spec is also missing this seed member from discard_block, and i see that the feature pack implementation contains it

anyway. So, is the missing function from xor_combine an oversight?

-Regex:

One of the Regex tests is failing (http://tinyurl.com/6ktl8c) due to a problem with a char_class_type typedef.

When i asked about this on the Boost list, the response was that it looks like a feature pack bug:

http://article.gmane.org/gmane.comp.lib.boost.devel/173685

-Bind:

There are some Bind failures (http://tinyurl.com/5edo35) due to a missing member result_type definition.

Anyone got any thoughts?

I can raise bugs on Connect if they are considered bugs on the feature pack side.

Thanks,

Richard Webb

[Richard Webb]

> I've tried running the Boost regression tests

> against the release feature pack

Awesome! Your bug reports from running the tests against the Feature Pack Beta were really helpful.

> So, is the missing function from xor_combine an

> oversight?

That appears to be the case. (It doesn't help when the TR1 spec contains thinkos.)

We're trying to conform to TR1 + obvious thinko fixes + selected C++0x backports, and this appears to fall under "obvious thinko fix".  Please file a Connect bug for this.

> One of the Regex tests is failing

> (http://tinyurl.com/6ktl8c) due to a problem with a

> char_class_type typedef.

Our std::tr1::regex_traits<T>::char_class_type is a typedef for int. TR1 7.2/4 requires that char_class_type be a bitmask type, and [lib.bitmask.types] C++03 17.3.2.1.2/1 explains that "Each bitmask type can be implemented as an enumerated type that overloads certain operators, as an integer type, or as a bitset".

Can you explain what the conformance problem is here? I don't understand what the Boost test is complaining about.

> There are some Bind failures

> (http://tinyurl.com/5edo35) due to a missing member

> result_type definition.

This is a known bug, but it was discovered too late (Feb 7) to be fixed in the Feature Pack. The internal bug number is Dev10.391723.

Feel free to E-mail me directly (stl@microsoft.com) if you encounter any other issues.

Thanks!

Stephan T. Lavavej

Visual C++ Libraries Developer

Using the Feature Pack in Visual Studio 2008  (<regex> library) I am getting the following linker error:

error LNK2019: unresolved external symbol "void __cdecl std::tr1::_Destroy(class std::tr1::_Node_base *,enum std::tr1::_Node_type)" (?_Destroy@tr1@std@@YAXPAV_Node_base@12@W4_Node_type@12@@Z) referenced in function "public: virtual __thiscall std::tr1::_Node_assert::~_Node_assert(void)" (??1_Node_assert@tr1@std@@UAE@XZ)

When I was using the beta distribution of the Feature Pack I was getting no linker errors.

[John Shroe]

> error LNK2019: unresolved external symbol "void __cdecl std::tr1::_Destroy(

Somehow, you're using the Feature Pack Beta headers with the Feature Pack RTW (Release To Web, i.e. final) binaries.  std::tr1::_Destroy() in Beta was renamed to std::tr1::_Destroy_node() in RTW, in order to fix a memory leak.

Installing the Feature Pack RTW over the Feature Pack Beta isn't supported. You have to uninstall the Feature Pack Beta (which I am told is robust) before installing the Feature Pack RTW.

Thanks,

Stephan T. Lavavej, Visual C++ Libraries Developer

once I compiled the program use vc2008 mfc, it will use .net framework 3.5 and will installed about more 50MB .net framework library. It's very bad and anoyed.

I test it in vista platform, it also need install .net framework 3.5!

Microsoft should deploy .net framework 3.5 themselves or don't need .net framework 3.5 if I compiled use vc2008 mfc.

How can I remove the .net framework 3.5 depend library, I hate to install more 50MB files.

Today we are pleased to announce that Microsoft Visual Studio 2008 Service Pack 1 (SP1) is now available