Windows Implementation Libraries: type-safe C++ interfaces for Windows patterns | Hacker News Reader

Windows Implementation Libraries: type-safe C++ interfaces for Windows patterns

github.com

148 pointsingve25 comments

Here’s what I don’t get.

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.

Microsoft provides the 'CComPtr' class template, a ref-counting smart-pointer for COM. It's been around since very roughly the year 2000 [0] [1].

Boost's smart pointers have apparently [2] been around for about as long.

If people have been rolling their own smart pointers since that time, isn't that their own fault?

[0] https://docs.microsoft.com/en-us/cpp/atl/reference/ccomptr-c...

[1] https://en.wikipedia.org/wiki/Active_Template_Library#Histor...

[2] https://www.boost.org/doc/libs/1_31_0/libs/smart_ptr/smart_p...

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++."

std::unique_ptr was made possible first in C++11 thanks to move semantics. Same goes for the similar smart pointers in wil.

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.

https://en.wikipedia.org/wiki/Windows_Template_Library

Not the same thing

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.

Doesn't WTL do almost the same thing?

It's existed for a while but was never very popular.

Also check out C++/WinRT - a _pure_ C++17 library facade over WinRT/UWP API's. https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a...

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.

It's not too hard. Just write a simple wrapper around FormatMessage:

  DWORD errorCode = GetLastError();

  DWORD dwFlg = FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM |    FORMAT_MESSAGE_IGNORE_INSERTS;
  LPTSTR lpMsgBuf = NULL;
  FormatMessageA(dwFlg, 0, errorCode, 0, (LPTSTR)&lpMsgBuf, 0, NULL);

  // Error message is in lpMsgBuf so make sure to free afterwards.
  LocalFree(lpMsgBuf);

It's even easier since the MSVC STL std::error_code (std::system_category) already does that.

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.

> If you are doing any non-trivial work, also be sure to have a recent version of Clang installed.

Nice to see Clang being put to good use on Windows.

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.

But why do you need two compilers?

Microsoft tried to lock developers in with MSVC, but it didn't work. Now we have to wait for it to die, so that we can use Clang instead.

Reply on news.ycombinator.com