Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

rab36

rab36 rab36

Niner since 2010

  • VC++ Bytes 2-1: Create Declaration/Definition with Oleg Kharitonov

    Excellent stuff, please keep up the great work. This feature together with the renaming you already implemented covers about 90% of my daily refactoring tasks (currently using Visual Assist).

    Other useful features would be "move to namespace" and creating XML comment templates from a function declaration like in C#.

    Bernd

  • OzCode

    This looks very useful. Is this for managed code only? Or can I use some of the features for native C++ code, too?

    Thanks, Bernd

  • GoingNative 9: LINQ for C/C++, Native Rx, Meet Aaron Lahman

    Did Microsoft change cmd so that it works like bash now?

    It think it's power shell.

    LINQ in C++ looks a lot like boost::range on steroids. This is very promising and I can't wait to try it. I am tired of wrting code with the STL algorithms which do not compose as nicely as LINQ and it is one of the things that I miss most when programming in C++ and not in C#.

    What I do not get though, is why using C for Rx. Is it because the library that was wrapped was in C or is this a general decision? I doubt that people programming in C are really interested in Rx and using Rx in C seems to be very complicated. Why not doing all this in C++?

    An Rx interface to the async stuff in WinRT might be an interesting showcase.

    Bernd

  • GoingNative 4: Jim Springfield on ATL, GoingNative Conference - Register Today!

    , Charles wrote

    @Raanen: I did not miss your post...

    Windows XP is nearing end of life (in terms of MS support). There's nothing that can be done about this. We can't support XP forever (and we won't). What else do you want to know?

    C

    Windows XP extended support lasts until April 9th, 2014. VS 11 is supposed to be released in 2012, right? So why not supporting to create C++ programs for XP in VS 11 with the latest C++ toolset?

    .NET 4.5 will very probably support Windows XP because it is an inplace upgrade from 4.0: http://reddevnews.com/blogs/rdn-express/2011/11/back-to-app-migrations-with-ms-net-vnext.aspx

    So why not offer C++ programmers the same possibilities?

    What is the motivation? What are the technical reasons, if there are any?

    I just want to elaborate a bit more about our motivation to support XP at least until 2014, maybe even longer with our software:

    We are a manufacturer of measurement systems that are sold with an industrial PC (with Windows XP or Windows 7) and a sophisticated C++ application for acquiring, storing, analyzing the data.

    Only recently we managed to offer Windows 7 64-Bit with all our systems because of driver issues of 3rd party data acquisition boards that are in the IPC.

    We have an OEM license agreement with Microsoft for embedded systems that still allows us to purchase Windows XP.

    We are selling maintenance agreements with our software and we have lots of systems on maintenance worldwide that are running Windows XP. Some of them are used in test lab or production environments that are not even connected to a network, so even the end of extended support of Windows XP in April 2014 will not force customers to migrate to Win 7. Upgrades to Windows 7 are difficult and expensive because hardware (because of the driver incompatibilities) with costs of several thousand of dollars (up to $15.000) has to be exchanged. The measurement hardware of the system is used typically for longer than 10 years, the IPCs are exchanged every 5-7 years.

    On the other hand, I am very interested in using the latest Visual Studio and toolset for our software. In the past, we managed to migrate to the latest Visual Studio release typically within one year after the release of Visual Studio. We have a demanding application that makes heavy use of multitasking and multithreading. New features are developed with the latest language features and libraries. We are using lambdas, auto, PPL and ConCRT and agents library right now with VS 2010 SP1 in our product.

    Not being able to use the latest toolset lets say in 2013 (because of Windows XP) would heavily impact this strategy. I expect that we have to support XP until at least 2015. So having no XP support in VS 11 comes way to early for us.

    Bernd

  • GoingNative 4: Jim Springfield on ATL, GoingNative Conference - Register Today!

    @Raanen:

    If this is not an appropriate thread for this question, what is? Where should I ask this question? Support for Windows XP is a make-it or break-it for us.

    http://connect.microsoft.com/VisualStudio/feedback/details/690617

    http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/e2f43b8e-a620-4c52-878c-8b546252af45

    http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2287078-allow-mfc-11-to-run-in-xp-sp3

    http://channel9.msdn.com/Forums/Coffeehouse/Development-tool-life-cycle-is-different-from-the-OS#c072f2b56878a4f6686ad9fa301264729

    @Charles:

    Now that the quest for $112 is over, I just want to support Raanen with his (off-topic) request for an explanation of why the CRT Windows XP support was dropped. When there is a compelling technical reason OK. When not, well, this impacts a lot of C++ developpers, so maybe you reconsider...

    Bernd

  • GoingNative 4: Jim Springfield on ATL, GoingNative Conference - Register Today!

    , tgoodhew wrote

    @rab36: The Visual Studio 11 Developer Preview supports targeting Windows XP via native C++ multi-targeting. You need to have either Visual Studio 2010 or the Windows SDK 7.1 installed. You can then select the approprite toolset for you project. This post describes it for Visual Studio 2010 but it's basically the same for Visual Studio 11:

    http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx

    Tony Goodhew - Microsoft Corp.

    Tony, thanks for the reply. I am aware of the fact, that I can use the VS 2010 toolset to create programs for Windows XP with VS 11. But as Dennis already mentioned I am loosing the VS 11 C++ 11 compiler (and C++ AMP by the way) when doing this.

    Could you confirm that the VS 11 toolset will definitely not support Windows XP? Or are you still considering changing this for the final product?

    I think this is a big topic for all C++ developers and clarifying this would help us planning.

    Thanks,
    Bernd

  • GoingNative 4: Jim Springfield on ATL, GoingNative Conference - Register Today!

    @Charles:

    Thanks for putting so much focus an C++, I really appreciate it. Having a C++ conference is a very good idea, I whish my company would let me go there (coming from Germany it would be quite expensive). Hoping for Channel 9 coverage of the conference.

    There seems to be evidence that VS 11 won't support creating C++ programs for Windows XP SP3 any more: https://connect.microsoft.com/VisualStudio/feedback/details/690617.

    If this is really the case, it would be very important to know this as early as possible. Can you comment on this or investigate what is planned?

    Thanks,
    Bernd

  • GoingNative 2: C++ at BUILD, Windows Runtime Library(WRL), Meet Tarek and Sridhar

    @felix9:

    You are right, C++/CLI is an option for this specific scenario. Nevertheless, a pure native possibility to publish (and consume) components with a stable ABI would be great. This is missing from C++ for a long time now and WinRT components with C++/CX could be a solution for it. It would enable component based architecture for applications with free choice of the programming languages.

    With C++/CLI you are forced to create mixed moded assemblies and to pull in the .NET framework and GC even when you consume the components from native code. Moreover it is not as easy to use e.g. PPL and ConCRT in C++/CLI (you have to to do a lot of indirection using pImpl all over) as in the the WinRT components. Think about all the pin_ptrs, gcroot<> etc. you have to write. I think C++/CX feels more natural, because it is native.

    But to have C++/CX availabe for metro style apps on Windows 8 only, is a big limitation. I must say, that I am a bit disappointed with the BUILD stuff in total. Metro, WinRT, XAML based UI for C++ and all that is great. And I think that PCs with Windows 8 will have a very good chance to get a huge share from the tablet / touch market beginning next year.

    But I think many of us C++ programmers (very likely the vast majority) will continue to write desktop applications for traditional PCs (because I strongly believe that there will be a large class of applications that cannot be Metro style) and they will have to support Windows XP and Windows 7 for at least 5 years from now.

    For a C++ renaissance on Windows a great UI / general native library (like WinRT for Metro is) to program desktop applications on Win XP and successors is still missing (like the .NET Framework and WPF is for managed applications). And when I have to continue to program against the Win32 library now and know that there is something much bettern than this, but I cannot use it, it is a bit frustrating.

    Bernd

  • GoingNative 2: C++ at BUILD, Windows Runtime Library(WRL), Meet Tarek and Sridhar

    Great episode, congratulations! For me having an ABI and metadata that can be used in managed and native languages is the most exciting news from BUILD. I think one of the most productive ways of writing applications today is mixing C#/.NET code for UI, networking, XML etc. and native C++ components for accessing hardware and doing the really performance critical stuff. One big argument for using C# over C++ are the new async and await keywords that make asynchronous programming so much easier, which is especially important for writing responsive UIs. We were using COM for the interface between these two worlds for years now. But writing COM with C++/ATL and handling all the deployment stuff and datatype conversion is no fun at all. C++/CX, WinRT and .winmd seems to make this a lot easier, also making asynchronous operations across the boundary possible. But for our applications we will have to support Windows XP and 7 for a long time to come. So my question is: is there a chance to use this stuff for non metro desktop applications on older OS? I do not want to use any WinRT stuff, just the ABI infrastructure and C++/CX. Bernd
  • Future directions for C# and Visual Basic

    @bcooly: I think that interoperability between managed and native code just made a big leap forward by introducing WinRT components. I just watched a build session where they demoed how to write a WinRT component in C# consuming it in JavaScript. Herb Sutter showed how to write a WinRT component in C++. It seems to be clean, easy and performant in all languages, managed and native. For me that is the most important aspect of WinRT. Write the 10% really performance critical parts of your app in C++ maybe using the GPU and automatic vectorization, wrap it in a WinRT component and consume it seamlessly in the rest of your application written with best productivity in C# and .NET. No COM, no interop, no Pinvoke. It would be a dream if this would work on Win7 and XP, too (not the WinRT itself, only WinRT components). Bernd

See more comments…