Microsoft has been shipping a C++ compiler for decades, and for the most part it is the preferred language for Windows development even today.
Moreover, there have been PLENTY of libraries designed to make it easier, like MFC, ATL, etc.
Why didn’t this already exist?!
Like I realize some of it is modern C++ and maybe Microsoft was not focusing on desktop when C++ had these innovations. But why not smart pointers for handles, error handling macros, etc. Crazy.
Lateness aside, I still occasionally do write win32 stuff, usually to extend/compliment/hack upon existing win32 stuff. So this is probably going to become a goto library now, if its as good as it sounds.
> Like I realize some of it is modern C++ and maybe Microsoft was not focusing on desktop when C++ had these innovations
This is basically it, I think; COM and HANDLEs predate working standardised C++ compilers. MFC provides higher-level abstractions. Then everyone got distracted by managed runtimes. Finally C++ has a mostly-sane framework for universal usage of smart pointers, so this is bringing them back to the old Win32 era.
Unfortunately we can't get rid of wstring, but we can provide yet another layer of wrappers for it.
This is a bit strange to me. It has been possible to write refcounted pointers in C++ since ages. And everybody has them in their own private library. Of Course, this introduces compatibility issues because everyone's smart pointer is different, so it is really nice that it eventually ended up in the standard library. However, it seems really hard to argue that it only now is possible to use smart points.
As the other response mentions, a lot of the win32 stuff predates C++11/0x. Also, a lot of the win32 stuff are C API's by design, not C++.
If your question was "why wasn't a C++ wrapper released sooner?" I think the answer is ".NET". If your question was "why didn't the API's have C++ semantics?" I think the answer is "because a lot of it is C, not C++."
Well, this has existed, but it's been internal to Microsoft (perhaps only internal to the windows team? That's the only place I've seen it). It's just taken a while to slowly open source more and more internal tools
And remarkably we didn’t have this in the Windows team until relatively recently (a few years ago). Before WIL, each team developed their own C++ wrappers and error handling conventions, and it was difficult to trace errors as they flowed across different teams’ components.
It was a big improvement when we standardized on this library across all the teams. I can’t recommend this enough.
> Windows Template Library (WTL) is a free software, object-oriented C++ template library for Win32 development. WTL was created by Microsoft employee Nenad Stefanovic for internal use and later released as an unsupported add-on to Visual Studio and the Win32 Framework SDK. It was developed primarily as a light-weight alternative to the Microsoft Foundation Classes and builds upon Microsoft's ATL, another lightweight API widely used to create COM and ActiveX libraries.
It did, at least internally. WIL originally stood for Windows Internal Library. They ripped out a few private concepts and relabeled it for general public.
Moreover, there have been PLENTY of libraries designed to make it easier, like MFC, ATL, etc.
My experience with Win32 apps using those (mostly from the perspective of modifying existing code, not starting from scratch) is that they made it easy to create something quickly to meet the initial requirements, but then the increased abstraction later gets in the way of debugging and extending. I suspect this effect is general to all libraries and frameworks that attempt to be a layer over an existing one.
Personally, I've found pure C and Win32 to be easy enough, but then again, it's something I've been doing for decades.
I always ended up making my own abstractions and even smart pointers at times. I wouldn't say it's 'easier' than pure C, but it was absolutely more productive, anyway.
WinRT + coroutines makes modern Windows programming _amazing_ to write and read, and efficient to run. This plus the xlang (compiler? toolset?) system, all open-sourced, shows how Microsoft has hedged against whichever platform will win the next round. Kenny Kerr deserves much credit for pushing all of C++ forward with these concepts.
Oh wow, this is exactly what I've always wanted in my many many years of developing Windows software in C++.
Despite a million fancy new API layers in newer versions of Windows, Win32 is very much not dead, but it's still a C interface with a lot of clunky and inconsistent nonsense. This looks like the ideal modern C++ wrapper for all that.
It looks pretty usable indeed, I just wish they had insludes std::error_code implementations for everything. Last time I checked, getting proper error_codes (i.e. which can be compared against standard categories and which have good error description strings) for everything in the API was still some manual work.
This is quite nice! I like the error handler monitor thing. Also quite amazing that they placed whole platform-independent (sort of) thread local storage implementation there.
Clang and CMake are becoming first class citizens now in the Windows ecosystem. New Windows open source projects are being shipped with CMake build as default and Clang compatibility.
Microsoft has been shipping a C++ compiler for decades, and for the most part it is the preferred language for Windows development even today.
Moreover, there have been PLENTY of libraries designed to make it easier, like MFC, ATL, etc.
Why didn’t this already exist?!
Like I realize some of it is modern C++ and maybe Microsoft was not focusing on desktop when C++ had these innovations. But why not smart pointers for handles, error handling macros, etc. Crazy.
Lateness aside, I still occasionally do write win32 stuff, usually to extend/compliment/hack upon existing win32 stuff. So this is probably going to become a goto library now, if its as good as it sounds.