Q: will whidbey provide for better debugger support for STL containers? Also, any chance of nice STL compile error messages?
A: Yes. David assures me that our support is "awesome."
Q: Will Whidbey support OpenMP (or whatever the clustering buzzword is), as well as 64-bit code, equally on all languages?
A: We will support OpenMP in C++ ... including 64 bit. For managed code, we are working on some new ideas in conjunction with the Windows HPC team; we will share more details over the next few months
Q: Are all the remote tools from eMbedded Visual C++ integrated in VS 2005? Are there new tools?
A: Yes. All of the tools for CE and Smartphone are now fully integrated into VS2005. There have been major improvements to the debugger (emulator and remote). MFC/ATL for devices is much more compatible with the desktop versions too. You can leverage the latest advantages available on the desktop when doing device development.
Q: Will support Visual basic 2005 COM interoperativity ?
A: Yes, VB 2005 will continue to support COM interop
Q: will any new security controls, mitigations or checks in addition to PREfix and /GS be built into Whidbey?
A: In addition to PREfix and /GS, we have also made significant advances in the libraries space. In Whidbey we are shipping the SafeCRTs, that eliminate most of the security related issues in the C runtime libraries. MFC & ATL have also been updated to leverage this. These improvements have been submitted to the C & C++ standards working groups
Q: Are all the remote tools from eMbedded Visual C++ integrated in VS 2005? Are there new tools?
A: We are only doing 6, there were 10 in eVC, 4 will not ship in B2. Call Profiler, Kerner Tracker, System Info and Heap Walker will NOT be in B2
Q: what is the role of native/COM C++ development going forward? Is this something that Microsoft will actively encourage and support?
A: YES! Both native C++ and COM development will be fully supported for the far distant future. Also, with the new VC++ 2005 product, interop between the native/COM and managed worlds is practically seamless. For the C++ developer, .NET provides superior support for paradigms where COM has historically been used, and for newer interop technologies like WebServices
Q: Scott Guthrie, will VS05 fully support document generation from the C# code comments?
A: The C# compiler produces .xml files that enable such tools. There are several such tools available on the market, e.g.,
http://ndoc.sourceforge.net. VS itself does not automatically produce such documentation. VB and C++ also add xml-doc functionality in VS 2005.
Q: The "seamless interop" between C++/CLI and unmanaged C++ sounds very promising. Is it seamless in the sense that it's transparent to the programmer, or is it seamless in the sense that it runs almost as fast as using only native code?
A: It is seamless in that you can 1) use native and .NET interchangeably in a C++ application, 2) you can now use C++ paradigms on .NET types (scope based resource management {destructors that work} & features like templates, and 3) you can tune usage of native vs. .NET based on business need, value proposition, performance, etc., on a function by function basis.
