Windows Implementation Library

Windows Implementation Libraries (WIL)

Build Status

The Windows Implementation Libraries (WIL) is a header-only C++ library created to make life easier for developers on Windows through readable type-safe C++ interfaces for common Windows coding patterns.

Some things that WIL includes to whet your appetite:

  • include/wil/resource.h (documentation): Smart pointers and auto-releasing resource wrappers to let you manage Windows API HANDLEs, HWNDs, and other resources and resource handles with RAII semantics.
  • include/wil/win32_helpers.h (documentation): Wrappers for API functions that save you the work of manually specifying buffer sizes, calling a function twice to get the needed buffer size and then allocate and pass the right-size buffer, casting or converting between types, and so on.
  • include/wil/registry.h: Registry watchers that can call a lambda function or callback you provide whenever a certain tree within the Windows registry changes.
  • include/wil/result.h (documentation): Preprocessor macros to help you check for errors from Windows API functions, in many of the myriad ways those errors are reported, and surface them as error codes or C++ exceptions in your code.
  • include/wil/tracelogging.h: This file contains the convenience macros that enable developers define and log telemetry. These macros use TraceLogging API to log data. This data can be viewed in tools such as Windows Performance Analyzer.

WIL can be used by C++ code that uses C++ exceptions as well as code that uses returned error codes to report errors. All of WIL can be used from user-space Windows code, and some (such as the RAII resource wrappers) can even be used in kernel mode.

Documentation

This project is documented in its GitHub wiki. Feel free to contribute to it!

Consuming WIL

WIL follows the "live at head" philosophy, so you should feel free to consume WIL directly from the GitHub repo however you please: as a GIT submodule, symbolic link, download and copy files, etc. and update to the latest version at your own cadence. Alternatively, WIL is available using a few package managers, mentioned below. These packages will be updated periodically, likely to average around once or twice per month.

Consuming WIL via NuGet

WIL is available on nuget.org under the name Microsoft.Windows.ImplementationLibrary. This package includes the header files under the include directory as well as a .targets file.

Consuming WIL via vcpkg

WIL is also available using vcpkg under the name wil. Instructions for installing packages can be found in the vcpkg GitHub docs. In general, once vcpkg is set up on the system, you can run:

C:\vcpkg> vcpkg install wil:x86-windows
C:\vcpkg> vcpkg install wil:x64-windows

Note that even though WIL is a header-only library, you still need to install the package for all architectures/platforms you wish to use it with. Otherwise, WIL won't be added to the include path for the missing architectures/platforms. Execute vcpkg help triplet for a list of available options.

Building/Testing

To get started testing WIL, first make sure that you have a recent version of Visual Studio and the most recent Windows SDK installed. If you are doing any non-trivial work, also be sure to have a recent version of Clang installed. Once everything is installed, open a VS native command window (e.g. "x64 Native Tools Command Prompt for VS 2019"). If you are familiar with CMake you can get started building normally. Otherwise, or if you prefer to skip all of the boilerplate, you can use one of the scripts in the scripts directory:

C:\wil> scripts\init.cmd -c clang -g ninja -b debug

You can execute init.cmd --help for a summary of available options. The scripts use a common directory pattern of build/$(compiler)$(arch)$(type) for the build output root. E.g. build/clang64debug when using Clang as the compiler, x64 as the architecture, and Debug as the build type. It is this directory where you will want to build from. For example, if you initialized using the command above, you can build the tests like so:

C:\wil\build\clang64debug> ninja

Or, if you want to only build a single test (e.g. for improved compile times):

C:\wil\build\clang64debug> ninja witest.noexcept

If you initialized using MSBuild as the generator, there will be a .sln file in the root of the build directory. You can either open the solution in Visual Studio or invoke MSBuild directly to build.

The output is a number of test executables. If you used the initialization script(s) mentioned above, or if you followed the same directory naming convention of those scripts, you can use the runtests.cmd script, which will execute any test executables that have been built, erroring out - and preserving the exit code - if any test fails. Note that MSBuild will modify the output directory names, so this script is only compatible with using Ninja as the generator. If you are at the tail end of of a change, you can execute the following to get a wide range of coverage:

C:\wil> scripts\init_all.cmd
C:\wil> scripts\build_all.cmd
C:\wil> scripts\runtests.cmd

Note that this will only test for the architecture that corresponds to the command window you opened. You will want to repeat this process for the other architecture (e.g. by using the "x86 Native Tools Command Prompt for VS 2019")

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Owner
Microsoft
Open source projects and samples from Microsoft
Microsoft
Comments
  • Changing linker order will cause tests to fail

    Changing linker order will cause tests to fail

    Change cpplatest source listing to:

    target_sources(witest.cpplatest PUBLIC
        ${CMAKE_CURRENT_SOURCE_DIR}/../CommonTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../ComTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../FileSystemTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../main.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../ResourceTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../ResultTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../SafeCastTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../WistdTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../wiTest.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../CppWinRTTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../StlTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../TokenHelpersTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../UniqueWinRTEventTokenTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../WatcherTests.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/../WinRTTests.cpp
        )
    

    compile and run tests. It will fail.

  • Error C2440 in result_macros.h

    Error C2440 in result_macros.h

    Hi, I am fairly new to desktop apps so this might be a stupid question. But I follow all the steps of the Sample App and yet get the following error

    webview2samples-master\gettingstartedguides\win32_gettingstarted\packages\microsoft.windows.implementationlibrary.1.0.200902.2\include\wil\result_macros.h(1225): error C2440: 'return': cannot convert from 'initializer list' to 'wil::details::ResultStatus'

    Not sure what I missed. I am using vs2015 (v140), Target platform Version: 10.0.17763.0, Target platform: Windows 10

  • `lock_winrt_module()` to prevent C++/WinRT host module from unloading

    `lock_winrt_module()` to prevent C++/WinRT host module from unloading

    Active coroutines normally prevent the C++/WinRT host module from unloading because they employ one or more of these techniques:

    • They are part of an IAsyncAction or IAsyncOperation, which retains a reference to the host module until they are destructed.
    • They explicitly take a reference to their parent object via get_strong().

    The missing case is a fire_and_forget coroutine that is not an instance member function. (Either a free function or a static member function.) These things are not attached to COM objects and therefore cannot prevent the host DLL from unloading.

    The new wil::lock_winrt_module() method acquires a reference count on the C++/WinRT host object's module lock (winrt::get_module_lock()) and returns an RAII type that releases the reference upon destruction.

    Example usage

    winrt::fire_and_forget DoSomethingInBackground()
    {
        // take a strong reference to the host module
        // to prevent premature unload.
        auto module_strong = wil::lock_winrt_module();
    
        co_await DoStuffThatUpdatesGlobals();
    
        // module_strong destructor release the reference,
        // allowing the module to be unloaded.
    }
    
  • secure_string is not secure

    secure_string is not secure

    Due to SSO optimizations, simply making an allocator is not good enough for std::basic_string as far as I understand. If a string grows too large, it can leave plain data in the small buffer that is never cleared by the given allocator. If it isn't initially large or doesn't grow large enough, the buffer is never cleared at all.

    I think secure_vector is fine.

    A test case: https://godbolt.org/z/q3hsxe

  • Add error handling for windows RPC APIs (that use SEH)

    Add error handling for windows RPC APIs (that use SEH)

    A feature request from internal windows teams.

    RETURN_IF_RPC_FAILED/THROW_IF_RPC_FAILED/FAIL_FAST_IF_RPC_FAILED macros that would use a lambda to create a function scope that enables the use of the __try/__catch/__finally language extensions needed to consume RPC based APIs.

    #define RETURN_IF_RPC_FAILED(hr)
    do
    {
    HRESULT __hrRet = & -> HRESULT
    {
    RpcTryExcept
    {
    HRESULT __hrRet = wil::verify_hresult(hr);
    if (FAILED(__hrRet))
    {
    __RETURN_HR_FAIL(__hrRet, #hr);
    }
    }
    RpcExcept(I_RpcExceptionFilter(RpcExceptionCode()))
    {
    __RETURN_WIN32_FAIL(RpcExceptionCode(), #hr);
    }
    RpcEndExcept
    return S_OK;
    }();
    }
    while (0, 0)

  • [Request for comments] wil::unique_string

    [Request for comments] wil::unique_string

    While trying to add support for conversion to std::string_view to unique_any_t when used to hold strings, I faced multiple issues that prevented me from correctly implementing it without creating a dependency on <string_view> or causing a static assertion/ugly basic_string_view error when trying to convert non character types to string_view. To fix this issue (and add more functionality), I have the idea of creating a unique_string type, which would look somehow like this:

    template<...>
    class unique_string : public unique_any_array_ptr<...>
    {
        static_assert(/* that ValueType is a wchar_t or char */);
    
        // avoid code duplication, reuse constructors from inherited class
        using unique_any_array_ptr<...>::unique_any_array_ptr;
    
        // somehow enabled conditionally
        operator std::basic_string_view<value_type>() const { return { this->get(), this->size() }; }
    
        const_pointer c_str() const { return this->get(); }
        size_type length() const { return this->size(); }
    
        // maybe more string manipulation functions?
    }
    

    All the existing type aliases and string helpers would be updated to use this type instead. This would allow for things like correctly embedding null characters, bounds checked string access, and being able to pass the string RAII wrappers to functions accepting string views.

    I believe that after updating everything, this shouldn't break normal usage cases, because unique_string will end up exposing the same API surface than unique_any via public inheritance of unique_array_ptr.

    As a bonus some Natvis visualizers for unique_string could be made so that it shows up nicely in a debugger.

    I'm submitting this as request for comments since this would be a pretty major change, so I want to get comments or check if this would even be accepted before getting to work implementing it.

  • wil::resume_foreground addresses many issues with winrt::resume_foreground

    wil::resume_foreground addresses many issues with winrt::resume_foreground

    The C++/WinRT built-in resume_foreground() support is problematic.

    co_await resume_foreground(CoreDispatcher) has no return value. If the resumption of the coroutine could not be enqueued, the coroutine simply hangs, resulting in a memory leak (from accumulated suspended coroutines that never complete), while giving the developer no indication that the work they wanted to do will never be done.

    co_await resume_foreground(DispatcherQueue) returns false if the resumption of the coroutine could not be enqueued and the thread switch therefore failed. In practice, nobody checks the return value, meaning that the code after the co_await is running on the wrong thread. (This flaw was copy/paste'd into Microsoft.UI.Dispatching.co_await.h.)

    Furthermore, just because the coroutine continuation was enqueued doesn't mean that it will actually run. The work item may end up simply abandoned, for example if the dispatcher thread exits abruptly.

    To fix all this, we provide alternate versions wil::resume_foreground() which have these properties:

    • If the thread-switch is successful, the co_await completes normally.
    • If the thread-switch is unsuccessful, the co_await completes with an exception on an unspecified thread.

    Another problem with C++/WinRT's winrt::resume_foreground() is simply that it's in C++/WinRT. It really belongs in an outside library, since C++/WinRT should be focused on the projection. Putting them in C++/WinRT forces dispatcher implementors to have to modify C++/WinRT whenever they want to change something.

    Implementation details

    The implementation is tricky because wil/cppwinrt.h is included before any other C++/WinRT headers, yet it wants to access types from headers that may be included after it. It cannot #include those headers directly, because they may not exist.

    The solution is to forward-declare the types, and then use them as dependent types in template expansions, so that the members aren't resolved until the second phase of template name lookup, at which point the full definitions should have been provided by the calling app.

    We declare a traits type dispatcher_traits and specialize it for each of the dispatchers we support. This also serves as a convenient hook for the unit test: We can just invent our own custom dispatcher, and as long as it has a dispatcher_traits, we can use it with wil::resume_foreground.

    In order to be able to call RunAsync or TryEnqueue before the methods have been declared, we make them dependent names in dispatcher_RunAsync and dispatcher_TryEnqueue, so that the name lookup happens at invoke time rather than definition time.

    To detect abandoned work, we use a custom delegate which detects that it has been destructed without ever having been invoked, in which case it resumes the coroutine so it can raise an exception with error code ERROR_NO_TASK_QUEUE. (We ignore the return value from Scheduler::Schedule because a successful return value does not guarantee that the work item will run.)

    The abandonment could take place on any thread, because it might occur after the work was successfully queued, and then before it can run, the destination thread exits. The work item is now stuck in limbo: The destination thread no longer exists, and the source thread may not exist either. It has no choice but to resume on some other thread.

    The state of the suspended coroutine is kept in a dispatched_handler_state. Our m_state pointer is non-null if we are the "active" dispatcher_handler. The pointer is moved when the move-only dispatcher_handler is moved, so only the instance that lives inside the delegate has a non-null pointer, and even that instance nulls out its pointer before resuming the coroutine, so that we never have a pointer to a destructed state.

    The handle is non-null if the coroutine is still suspended. orphaned is set to true if the handler discovers that it was never invoked. Upon resumption, we raise an exception if we realize we were orphaned.

    There is a subtlety in the await_suspend: We need to keep an explicit reference to the work item, so that it doesn't destruct prematurely. In the case where the Queue function throws an exception, we null out the coroutine handle in the state so that the handler's destructor won't try to report the failure: The exception in the Queue function puts the the coroutine into an error state, making it no longer resumable.

    A bonus side effect of the replacement wil::resume_foreground is that its await_suspend returns void rather than bool, thereby avoiding a heap corruption coroutine code generation bug in older versions of Visual Studio.

    One of the problematic pieces is figuring out whether coroutine handles live in the std or std::experimental namespace (or neither, if coroutines aren't supported at all). This is particularly tricky because different versions of C++/WinRT leave different traces behind. Ultimately, I opted not to rely on C++/WinRT at all and instead use the compiler symbols.

    • _RESUMABLE_FUNCTIONS_SUPPORTED: /await mode (pre-standard)
    • __cpp_lib_coroutine: C++20 standard mode
  • Best practices for using com_ptr to create factory objects?

    Best practices for using com_ptr to create factory objects?

    Hi, I'm sorry for asking such a basic question, but I'm back to using COM APIs after a decade-long break and trying to adjust to modern best practices.

    I'm working on some code that uses Direct2D and I'm looking at WIL to help me with that.

    What are the recommended best practices for using com_ptr when calling functions like D2D1CreateFactory or DWriteCreateFactory? The former uses void** as the type of the output parameter, the latter IUnknown**. I've been following the examples in the docs for Direct2D and DirectWrite and using reinterpret_cast -- that seems to work well after upgrading to com_ptr, and looking at the source code there's nothing indicating that there's a better alternative for:

    wil::com_ptr<IDWriteFactory2> pDWriteFactory2;
    DWriteCreateFactory(
        DWRITE_FACTORY_TYPE_SHARED, 
        __uuidof(IDWriteFactory2), 
        reinterpret_cast<IUnknown**>(&pDWriteFactory2));
    

    but I might be missing something... I think earlier incarnations of smart COM pointers had methods like put_void for getting the underlying pointer cast to void** for purposes like this. Just wanted to make sure there's no better way of doing things that I had somehow missed...

    My other question is: how to use wil::CoCreateInstance to obtain a WIC factory object that implements IWICImagingFactory2? The first template argument expects a class, from which it can extract the CLSID using __uuidof, but in this case I only have the GUID CLSID_WICImagingFactory2. Is it a supported scenario, or should I not even bother and stick to the old way of doing things?

  • Update fail fast handling (FAIL_FAST, FAIL_FAST_IF, etc.) to use RoFailFastWithErrorContext to improve diagnosis of failures and Watson bucketing

    Update fail fast handling (FAIL_FAST, FAIL_FAST_IF, etc.) to use RoFailFastWithErrorContext to improve diagnosis of failures and Watson bucketing

    There has been feedback that WIL FailFast should use stowed exceptions to get better blaming. This indeed could be useful as part of FAIL_FAST_IF_FAILED calls.

    In addition, the POF logic could also be useful as in the FAIL_FAIL_FAST_IF_FAILED calls that did RoOriginate, you can end up with a crash dump from the point where it actually failed.

    We should rationalize what the best way to achieve this is (i.e. this could be just calling RoFailFastWithErrorContext as part of wil/result_originate.h if there is a stowed exception).

  • Fix noreturn compile error for clang

    Fix noreturn compile error for clang

    Many of the functions called from the RETURN_IF_FAILED macro used noreturn annotation since in the failfast and exception case it isn't expected for them to return. In the case that a failfast or exception wasn't expected the functions would still retrun and had SAL annotation to express this. Clang doesn't pick up on the SAL resulting in a warning being generated. This change provides template overloads based on the return type so that in all cases the functions are properly annotated as noreturn or not. Additionally, the suppress action flag was factored into a template parameter for ReportFailure as that overrides no return behavior and setting it at runtime for a failfast or exception return would result in UB. Tested on VS 2017 and Clang 9.0.0

  • Documentation says unique_variant is a unique_any but it's a unique_struct.

    Documentation says unique_variant is a unique_any but it's a unique_struct.

    The wiki says that unique_variant is derived from unique_any, but it's actually derived from unique_struct. Among other things, this means that to get a raw VARIANT the correct thing to do is a static_cast, because get() is not implemented. (And there is no shared_variant, for obvious reasons.)

    I would make the change to the wiki myself, but I'm not sure that there aren't other similar issues with other types, and I'm not sure how unique_variant (and any other wrappers with the same issue) should be mentioned relative to the current documentation for unique_struct.

  • Enable use of RtlDisownModuleHeapAllocation when available

    Enable use of RtlDisownModuleHeapAllocation when available

    https://github.com/microsoft/wil/blob/fd91a817faeec8dee12558b40a6ee54a863d24a7/include/wil/result_macros.h#L1301-L1310

    This API is now publicly documented - https://docs.microsoft.com/en-us/windows/win32/DevNotes/rtlsupportapi/nf-rtlsupportapi-rtldisownmoduleheapallocation

    Move the setting of the function pointer to the global init path when available so apps using appverifier and wil no longer get a "leak" warning.

  • VS2015 result_macros.h problems

    VS2015 result_macros.h problems

    Dear WIL team,

    My VS2015 IDE is: Microsoft Visual Studio Professional 2015 Version 14.0.25431.01 Update 3 Microsoft .NET Framework Version 4.8.04084

    My CL.exe is the default that comes with the above IDE (not sure about the version of C++ it supports), however I know that VS2015 does not seem to offer you the /std option to choose a version of C++, like the VS2017 upwards do.

    I am trying to use WIL in my project with: #include <wil/com.h>

    And trying to compile, I get the following all related to result_macros.h:

    1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(1227): error C2440: 'return': cannot convert from 'initializer list' to 'wil::details::ResultStatus' 1> \packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(1227): note: No constructor could take the source type, or constructor overload resolution was ambiguous 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(1231): error C2440: 'return': cannot convert from 'initializer list' to 'wil::details::ResultStatus' 1> \packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(1231): note: No constructor could take the source type, or constructor overload resolution was ambiguous 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(1235): error C2440: 'return': cannot convert from 'initializer list' to 'wil::details::ResultStatus' 1> \packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(1235): note: No constructor could take the source type, or constructor overload resolution was ambiguous 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(2035): error C2144: syntax error: 'HRESULT' should be preceded by ';' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(2035): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(2041): error C2144: syntax error: 'HRESULT' should be preceded by ';' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(2041): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(2041): error C2086: 'int wil::details::Translates_last_error_to_HRESULT': redefinition 1> \packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(2035): note: see declaration of 'wil::details::Translates_last_error_to_HRESULT' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3906): error C2988: unrecognizable template declaration/definition 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3906): error C2059: syntax error: '(' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3918): error C2143: syntax error: missing ';' before '{' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3918): error C2447: '{': missing function header (old-style formal list?) 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3926): error C2988: unrecognizable template declaration/definition 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3926): error C2059: syntax error: '(' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3936): error C2143: syntax error: missing ';' before '{' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3936): error C2447: '{': missing function header (old-style formal list?) 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3944): error C2988: unrecognizable template declaration/definition 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3944): error C2143: syntax error: missing ';' before '<' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3944): error C2495: 'ReportFailure_GetLastError': '__declspec(noinline)' can only be applied to function declarations or definitions 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3944): error C3829: standard attribute 'noreturn' may only be applied to functions 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3944): error C2433: 'ReportFailure_GetLastError': 'inline' not permitted on data declarations 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3944): error C2495: 'wil::details::ReportFailure_GetLastError': '__declspec(noinline)' can only be applied to function declarations or definitions 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3944): error C2059: syntax error: '<' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3954): error C2143: syntax error: missing ';' before '{' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3954): error C2447: '{': missing function header (old-style formal list?) 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3964): error C2144: syntax error: 'HRESULT' should be preceded by ';' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3974): error C2144: syntax error: 'HRESULT' should be preceded by ';' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3974): error C2988: unrecognizable template declaration/definition 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3974): error C2143: syntax error: missing ';' before '<' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3985): error C2143: syntax error: missing ';' before '{' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3985): error C2447: '{': missing function header (old-style formal list?) 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3993): error C2988: unrecognizable template declaration/definition 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(3993): error C2059: syntax error: '(' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4005): error C2143: syntax error: missing ';' before '{' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4005): error C2447: '{': missing function header (old-style formal list?) 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4013): error C2988: unrecognizable template declaration/definition 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4013): error C2059: syntax error: '(' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4023): error C2143: syntax error: missing ';' before '{' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4023): error C2447: '{': missing function header (old-style formal list?) 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4065): error C2988: unrecognizable template declaration/definition 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4065): error C2059: syntax error: '(' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4077): error C2143: syntax error: missing ';' before '{' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4077): error C2447: '{': missing function header (old-style formal list?) 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4085): error C2988: unrecognizable template declaration/definition 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4085): error C2059: syntax error: '(' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4095): error C2143: syntax error: missing ';' before '{' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4095): error C2447: '{': missing function header (old-style formal list?) 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4103): error C2988: unrecognizable template declaration/definition 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4103): error C2143: syntax error: missing ';' before '<' 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4103): error C2495: 'ReportFailure_GetLastErrorMsg': '__declspec(noinline)' can only be applied to function declarations or definitions 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4103): error C3829: standard attribute 'noreturn' may only be applied to functions 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4103): error C2433: 'ReportFailure_GetLastErrorMsg': 'inline' not permitted on data declarations 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4103): error C2495: 'wil::details::ReportFailure_GetLastErrorMsg': '__declspec(noinline)' can only be applied to function declarations or definitions 1>\packages\microsoft.windows.implementationlibrary.1.0.220201.1\include\wil\result_macros.h(4103): fatal error C1903: unable to recover from previous error(s); stopping compilation 1> INTERNAL COMPILER ERROR in 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe' 1> Please choose the Technical Support command on the Visual C++ 1> Help menu, or open the Technical Support help file for more information ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

    Could this be due to a wrong C++ version the compiler supports? My project is somehow old and uses MBCS, I would expect for there to be an issue with WIL using Unicode chars, however none of the above seem to be pointing to anything like that.

    Any ideas?

    You are my last resort, I haven't been able to find a solution on any of the forums out there.

    Thank you very much.

  • WIL error output from OS binaries occasionally swamps debug console

    WIL error output from OS binaries occasionally swamps debug console

    See also https://task.ms/39969151 for a proposal, replicated here:

    The output-to-debug-console logic at https://github.com/microsoft/wil/blob/18c1ebd9019c1b48591e7e5e27c34b227697fa6c/include/wil/result_macros.h#L3630 dumps useful information from the OS to the debugger, but in certain cases ends up swamping other information.

    Proposal:

    • Update to WIL's existing IsDebuggerPresent check to look for system-wide configuration enabling WIL output to debug stream
    • New method EnableProcessDebugOutputReport that overrides the check above to force output anyway
    • Binaries built with DEBUG retain current behavior IsDebuggerPresent
  • Revert result macros to be noexcept again

    Revert result macros to be noexcept again

    A number of result macros aren't declared as noexcept which causes C26447 warnings if they're used within a noexcept context. This can make them uncomfortable to use in the Terminal project which has this warning enabled.

    It appears as if the noexcept attribute was removed in/around OS PR !2943876, when C++17 was enabled for a project. This resulted in a conflict with the __forceinline attribute and caused the FailFast_IfWin32Error function to be exported from the .lib erroneously. DevDiv-748887 seems to be the related bug report for MSVC and was resolved in VS 16.1.

    This PR was tested by building (chk, dev) the .lib mentioned in !2943876 and comparing the dumpbin /SYMBOLS output before and after the change. Apart from a size reduction of 16 bytes, nothing changed.

  • Apply PR feedback for duck-typing of to_vector

    Apply PR feedback for duck-typing of to_vector

    @oldnewthing had a great suggestion to duck-type the to_vector helper from #240 but I was too hasty.

    Along the way, discovered that the test crash was due to an interaction between the malloc spy and leaking an apartment init, so added explicit init/shutdown that uses it.

    And suddenly, LLVM is complaining that cppwinrt's base.h uses _InterlockedCompareExchange128 which needs their -mcx16 option, but which wasn't included in our common build flags.

C++ STL in the Windows Kernel with C++ Exception Support

C++ STL in Windows Drivers This project uses MSVC C++ STL in a Windows Kernel Driver. In this solution jxystl.lib is implemented as a kernel-tuned, po

Aug 12, 2022
A standard conforming C++20 implementation of std::optional.

A standard conforming C++20 implementation of std::optional.

Feb 11, 2022
42 Cursus - Libft: My implementation of some useful C functions and some additional ones to use it in future projects of 42.

42 Cursus - libft Info My implementation of some useful C functions and some additional ones to use it in future projects of 42. Status: still updatin

Jul 21, 2022
A size-optimized STL implementation.

uSTL This library is obsolete. Please use the official gcc C++ standard library. uSTL is a partial implementation of the C++ standard library that foc

Jul 9, 2022
Libft is an individual project at 42 that requires us to re-create some standard C library functions including some additional ones that can be used later to build a library of useful functions for the rest of the program.

?? Index What is Libft? List of Functions Technologies ✨ What is Libft? Libft is an individual project at 42 that requires us to re-create some standa

Jan 17, 2022
Library that simplify to find header for class from STL library.

Library that simplify to find header for class from STL library. Instead of searching header for some class you can just include header with the class name.

Jun 7, 2022
Thrust is a C++ parallel programming library which resembles the C++ Standard Library.

Thrust: Code at the speed of light Thrust is a C++ parallel programming library which resembles the C++ Standard Library. Thrust's high-level interfac

Aug 15, 2022
jkds is a modern header-only C++20 library that complements the standard library.

jkds is a modern header-only C++20 library that complements the standard library. It provides generic atypical data structures, ergonomic functional programming abstractions, and then some.

May 24, 2022
Bionic BSD-3-ClauseBionic - Google's standard library, developed for Android. BSD-3-Clause

bionic bionic is Android's C library, math library, and dynamic linker. Using bionic as an app developer See the user documentation. Working on bionic

Jul 31, 2022
CloudABI's standard C library

NOTE: This project is unmaintained CloudABI is no longer being maintained. It was an awesome experiment, but it never got enough traction to be sustai

Jun 7, 2022
libcu++: The C++ Standard Library for Your Entire System

libcu++, the NVIDIA C++ Standard Library, is the C++ Standard Library for your entire system. It provides a heterogeneous implementation of the C++ Standard Library that can be used in and between CPU and GPU code.

Aug 8, 2022
D++ Extremely Lightweight C++ Discord Library

D++ An incredibly lightweight C++ Discord library This project is in alpha stages of development. Completed so far: Websocket connection with heartbea

Aug 10, 2022
EASTL stands for Electronic Arts Standard C++ Template Library

EASTL stands for Electronic Arts Standard Template Library. It is an extensive and robust implementation that has an emphasis on high performance.

Aug 8, 2022
An open source standard C library that includes useful functions && (Reimplementation of libc functions + own functions).
An open source standard C library that includes useful functions && (Reimplementation of libc functions + own functions).

?? LIBFT-42 : Artistic view of LIBC: ?? HOW DOES IT FEEL HAVING YOUR OWN LIB: SUBJECT : ENGLISH PDF ℹ️ What is LIBFT : This project aims to code a C l

Mar 24, 2022
Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags.
Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags.

Single-header header-only C++11 / C++14 / C++17 library for easily managing set of auto-generated type-safe flags. Quick start #include <bitflags/bitf

Jul 30, 2022
expected lite - Expected objects in C++11 and later in a single-file header-only library

expected lite: expected objects for C++11 and later expected lite is a single-file header-only library for objects that either represent a valid value

Aug 16, 2022
Guidelines Support Library

GSL: Guidelines Support Library The Guidelines Support Library (GSL) contains functions and types that are suggested for use by the C++ Core Guideline

Aug 13, 2022
gsl-lite – A single-file header-only version of ISO C++ Guidelines Support Library (GSL) for C++98, C++11, and later

gsl-lite: Guidelines Support Library for C++98, C++11 up metadata build packages try online gsl-lite is an implementation of the C++ Core Guidelines S

Aug 10, 2022
Your standard library for metaprogramming

Boost.Hana Your standard library for metaprogramming Overview #include <boost/hana.hpp> #include <cassert> #include <string> namespace hana = boost::h

Aug 1, 2022