microsoft / xlang

What is xlang?

The xlang project is the hub for the constellation of tools that enable development of Windows applications across a variety of programming languages. This includes tooling to process metadata, and tooling to access APIs from various programming languages including C#, C++, Rust, and Python.

Code in this repository provides infrastructure and tooling related to basic metadata handling & app usage. Tooling for each language is (mostly) maintained in separate repositories. Issue and work tracking for each tool or language is tracked in the corresponding repository as well. Issues that span languages or relate to basic metadata issues are tracked here.

Metadata & Infrastructure

• Undocked RegFree WinRT - Provides access to user-defined WinRT types for versions of Windows prior to Windows 10 May 2019 update.

• WinRT test component - Provides a compact but thorough test suite for validating projection support for consuming and implementing Windows Runtime-style APIs.

• Win32 & COM Metadata - Tooling that analyzes Windows C/C++ headers, and provides metadata describing the Win32 & COM API surface of Windows. This metadata is used to provide access to Win32 from other programming languages such as C# & Rust.

C++

• C++/WinRT - A tool that provides C++ support for calling Windows Runtime APIs that has a modern C++ feel.

• C++ winmd parser - A C++ parser library for efficiently parsing WinRT metadata.

• WinRT ABI (C with classes) Header Generation Tool - Tool that generates the C++ representation of the raw "COM-style" interfaces that make WinRT work.

• C++/Win32 - Tooling that leverages the Win32 metadata to provide a modern C++ development experience for Windows APIs.

• Windows Implementation Libraries - A set of helper libraries that provide RAII and other helpful abstractions for many existing SDK headers & types.

C#

• C#/WinRT - Interop support for WinRT APIs and .NET 5.

• C#/Win32 - A metadata-based projection of Win32 and COM APIs.

Rust

• Rust for Windows - Tooling that creates WinRT, Win32 and COM APIs for the Rust programming language.

Python

• Python/WinRT - Support for calling most (non-XAML) APIs from the Python programming language.

Cross-platform WinRT

When this repository first created, we used this space to explore what it would take to bring Windows Runtime APIs to other platforms. While that investment has been put on hold for the time being, some of the project code and samples in this repo remain but may be in disrepair.

Related projects

• Project Reunion

• .NET 5

License

Code licensed under the MIT License.

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.

xlang's Issues

C++/WinRT coroutine locals may return/complete before locals are destroyed

James McNellis recently discovered that the traditional way of implementing a coroutine type may allow locals within the coroutine to be destroyed after the coroutine returns/completes (rather than prior to final suspension). Gor Nishanov clarified that the resumption of any waiter should be deferred until final suspension to avoid this problem (among other benefits).

Investigate need for "associated objects" for xlang objects

It may be beneficial for an xlang object to have some understanding and cooperation with projection(s). One example that comes to mind is how weak references and event listeners might interact with garbage collected languages like Java. Simple pseudo java code like the below should work:

 someProjectedXLangObject.someEvent().subscribe((sender, args)->
{
    someProjectedXLangObject.doSomethingElse();
});

The reference cycle becomes: someProjectedXLangObject -> nativeXLangObject -> eventHandler -> someProjectedXLangObject

In GC languages this is typically not an issue because Reachability analysis will know that the cycle only goes through un reachable objects if someProjectedXLangObject is no longer referenced elsewhere. This however implies that nativeXLangObject can take a reference on the event handler in a way that the GC can see through.

Additionally for caching and quick retrieval of projection objects it is likely beneficial to know what any existing projections are.

It is possible that each "projections infrastrucure" could manage this and be totally extrinsic to the xlangobject itself. I am wondering if it instead makes sense to add some "expando mechanism" that would allow the xlangobject itself to carry this information.

implement convert_string in PAL for non-windows platforms

The two convert_string PAL functions (UTF-8 -> UTF16 and UTF16 -> UTF8) are only implemented for windows. The version in common_string_convert.cpp simply throw today.

Rename design notes to remove the L prefix

Either change them to just DN or use X as the new L (i.e. XDN00 instead of LDN00)

Parity: Restore support for response files in C++/WinRT

xlang's cmd::reader needs to support response files for compatibility with cppwinrt.exe

Create Design Note detailing Comments, Annotations, and Metadata Authoring Tooling

This issue came out of feedback from XDN03 (specifically #120 (comment)). We need a design note describing the authoring experience/tooling and what communication channels beyond the API signature itself will be available to xlang component authors.

An example of this is comments. Many languages have structured styles for comments (javadoc, etc) that help guide consumers to use APIs appropriately. Ideally, Xlang's projection process has a facility such that these comments are auto generated and appropriately reference any converted types / names. This suggests some fairly deep integration with the code generation tooling itself.

Another example is annotations. Several languages have annotation affordances that allow API authors to perform varying levels of compile time (and even runtime for languages like Java) inspection and processing of API use. Things like https://developer.android.com/reference/android/support/annotation/IntRange#annotations seem like they could be highly valuable to component authors. Xlang should take a stance (either part of or not part of the charter) on a system to describe "standard" annotations that get projected.

stop disabling Wreturn-type-c-linkage in pal.h

operator|= and operator&=give a return-type-c-linkage warning when compiling with clang on Ubuntu. these operators are already in a #ifdef __cplusplus block, so I think the warning is spurious. If there a way to modify these functions to avoid the clang warning? I'm OK leaving the #pragma that disables the warning in place (though the TODO comment needs to be updated)

commit dd695e61ef2025cd0d2fafc2049f44d0460dc77a does not build on clang/bionic.

• dd695e6 does not build with clang++6 on bionic.
• Previous commit c9a4a50 did build.

Steps to reproduce:

$ clang --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ git checkout c9a4a50feeec0b6332ebc908344bfac40d709f9f
$ rm -r _build && bash ./src/scripts/ubuntu/build.sh
<successful build>
$ git checkout dd695e61ef2025cd0d2fafc2049f44d0460dc77a
$ rm -r _build && bash ./src/scripts/ubuntu/build.sh
[19/26] Building CXX object tool/cpp/CMakeFiles/cpp.dir/main.cpp.o
FAILED: tool/cpp/CMakeFiles/cpp.dir/main.cpp.o 
/usr/bin/clang   -I/home/marco/tmp/xlang/src/library -Itool/cpp -I/home/marco/tmp/xlang/src/tool/cpp -g -D_DEBUG   -stdlib=libc++ -std=gnu++1z -MD -MT tool/cpp/CMakeFiles/cpp.dir/main.cpp.o -MF tool/cpp/CMakeFiles/cpp.dir/main.cpp.o.d -o tool/cpp/CMakeFiles/cpp.dir/main.cpp.o -c /home/marco/tmp/xlang/src/tool/cpp/main.cpp
In file included from /home/marco/tmp/xlang/src/tool/cpp/main.cpp:5:
/home/marco/tmp/xlang/src/tool/cpp/type_writers.h:437:13: error: call to 'visit' is ambiguous
            visit(type,
            ^~~~~
/usr/include/c++/v1/variant:1513:26: note: candidate function [with _Visitor = const std::__1::variant<xlang::meta::reader::ElementType, xlang::meta::reader::coded_index<xlang::meta::reader::TypeDefOrRef>, xlang::meta::reader::GenericTypeIndex, xlang::meta::reader::GenericTypeInstSig> &, _Vs = <(lambda at /home/marco/tmp/xlang/src/tool/cpp/type_writers.h:438:17), (lambda at /home/marco/tmp/xlang/src/tool/cpp/type_writers.h:483:17), (lambda at /home/marco/tmp/xlang/src/tool/cpp/type_writers.h:487:17)>]
constexpr decltype(auto) visit(_Visitor&& __visitor, _Vs&&... __vs) {
                         ^
/home/marco/tmp/xlang/src/library/impl/base.h:75:10: note: candidate function [with V = const std::__1::variant<xlang::meta::reader::ElementType, xlang::meta::reader::coded_index<xlang::meta::reader::TypeDefOrRef>, xlang::meta::reader::GenericTypeIndex, xlang::meta::reader::GenericTypeInstSig> &, C = <(lambda at /home/marco/tmp/xlang/src/tool/cpp/type_writers.h:438:17), (lambda at /home/marco/tmp/xlang/src/tool/cpp/type_writers.h:483:17), (lambda at /home/marco/tmp/xlang/src/tool/cpp/type_writers.h:487:17)>]
    void visit(V&& variant, C&&...call)
         ^
In file included from /home/marco/tmp/xlang/src/tool/cpp/main.cpp:6:
/home/marco/tmp/xlang/src/tool/cpp/helpers.h:195:9: error: call to 'visit' is ambiguous
        visit(method_signature.return_signature().Type().Type(),
        ^~~~~
/usr/include/c++/v1/variant:1513:26: note: candidate function [with _Visitor = const std::__1::variant<xlang::meta::reader::ElementType, xlang::meta::reader::coded_index<xlang::meta::reader::TypeDefOrRef>, xlang::meta::reader::GenericTypeIndex, xlang::meta::reader::GenericTypeInstSig> &, _Vs = <(lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:196:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:211:13)>]
constexpr decltype(auto) visit(_Visitor&& __visitor, _Vs&&... __vs) {
                         ^
/home/marco/tmp/xlang/src/library/impl/base.h:75:10: note: candidate function [with V = const std::__1::variant<xlang::meta::reader::ElementType, xlang::meta::reader::coded_index<xlang::meta::reader::TypeDefOrRef>, xlang::meta::reader::GenericTypeIndex, xlang::meta::reader::GenericTypeInstSig> &, C = <(lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:196:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:211:13)>]
    void visit(V&& variant, C&&...call)
         ^
In file included from /home/marco/tmp/xlang/src/tool/cpp/main.cpp:6:
/home/marco/tmp/xlang/src/tool/cpp/helpers.h:462:9: error: call to 'visit' is ambiguous
        visit(signature.Type(),
        ^~~~~
/usr/include/c++/v1/variant:1513:26: note: candidate function [with _Visitor = const std::__1::variant<xlang::meta::reader::ElementType, xlang::meta::reader::coded_index<xlang::meta::reader::TypeDefOrRef>, xlang::meta::reader::GenericTypeIndex, xlang::meta::reader::GenericTypeInstSig> &, _Vs = <(lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:463:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:467:13)>]
constexpr decltype(auto) visit(_Visitor&& __visitor, _Vs&&... __vs) {
                         ^
/home/marco/tmp/xlang/src/library/impl/base.h:75:10: note: candidate function [with V = const std::__1::variant<xlang::meta::reader::ElementType, xlang::meta::reader::coded_index<xlang::meta::reader::TypeDefOrRef>, xlang::meta::reader::GenericTypeIndex, xlang::meta::reader::GenericTypeInstSig> &, C = <(lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:463:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:467:13)>]
    void visit(V&& variant, C&&...call)
         ^
In file included from /home/marco/tmp/xlang/src/tool/cpp/main.cpp:6:
/home/marco/tmp/xlang/src/tool/cpp/helpers.h:479:9: error: call to 'visit' is ambiguous
        visit(signature.Type(),
        ^~~~~
/usr/include/c++/v1/variant:1513:26: note: candidate function [with _Visitor = const std::__1::variant<xlang::meta::reader::ElementType, xlang::meta::reader::coded_index<xlang::meta::reader::TypeDefOrRef>, xlang::meta::reader::GenericTypeIndex, xlang::meta::reader::GenericTypeInstSig> &, _Vs = <(lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:480:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:487:13)>]
constexpr decltype(auto) visit(_Visitor&& __visitor, _Vs&&... __vs) {
                         ^
/home/marco/tmp/xlang/src/library/impl/base.h:75:10: note: candidate function [with V = const std::__1::variant<xlang::meta::reader::ElementType, xlang::meta::reader::coded_index<xlang::meta::reader::TypeDefOrRef>, xlang::meta::reader::GenericTypeIndex, xlang::meta::reader::GenericTypeInstSig> &, C = <(lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:480:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/helpers.h:487:13)>]
    void visit(V&& variant, C&&...call)
         ^
In file included from /home/marco/tmp/xlang/src/tool/cpp/main.cpp:7:
/home/marco/tmp/xlang/src/tool/cpp/code_writers.h:958:9: error: call to 'visit' is ambiguous
        visit(signature.Type(),
        ^~~~~
/usr/include/c++/v1/variant:1513:26: note: candidate function [with _Visitor = const std::__1::variant<xlang::meta::reader::ElementType, xlang::meta::reader::coded_index<xlang::meta::reader::TypeDefOrRef>, xlang::meta::reader::GenericTypeIndex, xlang::meta::reader::GenericTypeInstSig> &, _Vs = <(lambda at /home/marco/tmp/xlang/src/tool/cpp/code_writers.h:959:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/code_writers.h:970:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/code_writers.h:992:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/code_writers.h:996:13)>]
constexpr decltype(auto) visit(_Visitor&& __visitor, _Vs&&... __vs) {
                         ^
/home/marco/tmp/xlang/src/library/impl/base.h:75:10: note: candidate function [with V = const std::__1::variant<xlang::meta::reader::ElementType, xlang::meta::reader::coded_index<xlang::meta::reader::TypeDefOrRef>, xlang::meta::reader::GenericTypeIndex, xlang::meta::reader::GenericTypeInstSig> &, C = <(lambda at /home/marco/tmp/xlang/src/tool/cpp/code_writers.h:959:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/code_writers.h:970:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/code_writers.h:992:13), (lambda at /home/marco/tmp/xlang/src/tool/cpp/code_writers.h:996:13)>]
    void visit(V&& variant, C&&...call)
         ^
5 errors generated.

Parity: Command line doesn’t support SDK versions

The cppwinrt command line accepts a specific version number as an alternative to winmd folder or file name paths. The xlang replacement doesn't yet support that.

I would expect cmd::reader::files to support this on Windows.

Adopting GSL

XLDN02 lists the C++ Core Guidelines (CCG) as a coding guideline for C++ code. CCG recommends the use of GSL to express the ideas formulated in the guidelines.

Proposal:

• GSL should be made available to the private xlang interface, probably as a submodule.
• The CCG Checks of clang-tidy should be added to the build.

[Suggestion] Default unsealed runtimeclasses

Since this project is not aiming to preserve binary compatibility with Windows Runtime and port Windows APIs, I would like to suggest making all the runtimeclasses unsealed by default.

This makes sence since there are no more Windows.* base classes that are required for WinRT unsealed classes, and this also aligns Xlang runtimeclasses with all the other languages.

This would require some changes to MIDL 3.0 — first of all, introduction of sealed keyword, but I believe it’s a must to get rid of this artificial limitation.

Use clang-tidy for code conformance checks

CMAKE 3.6 and up supports building targets with a clang-tidy step on the target compilation database out of the box. clang-tidy has a growing number of code compliance checks, which should be useful to keep the code clean. It should be easy to integrate into the build system.

Parity: C++/WinRT doesn't provide data helper on Windows::Storage::Streams::Buffer

The C++/WinRT projection adds a data helper to the Buffer class for direct access to the underlying buffer since that is (sadly) not available through the projection. xlang needs to provide the same helper for consistency.

Copy design docs from VSTS repo

use std::filesystem instead of std::experimental::filesystem

Containers like IVector/IObservableVector should support reverse iterators

I was recommending to a colleague that they use an STL algorithm instead of a manual for loop but in their case they were searching backwards so they couldn't use rbegin/rend with std::find_first_of.

Please add rbegin/rend support to all the random access containers in C++/WinRT. Thanks!

src\test\cpp\metadata should have contract metadata not runtime metadata checked in

cpp_test AsyncProgress and Events tests failing when run as part of Azure pipeline

Example: https://dev.azure.com/msft-xlang/public/_build/results?buildId=510&view=ms.vss-test-web.build-test-results-tab

I'm going to disable these tests. We will use this issue to track fixing and re-enabling them

Fix test_platform linker issues on Ubuntu

The fix_ubuntu branch now compiles the PAL clean on Ubuntu (we were missing an include file). However, test_platform fails to link with undefined references:

platform/libpal.so: undefined reference to `xlang::impl::convert_string(char const*, unsigned int, char16_t*, unsigned int)'
platform/libpal.so: undefined reference to `xlang::impl::get_converted_length(char16_t const*, unsigned int)'
platform/libpal.so: undefined reference to `xlang::impl::get_converted_length(char const*, unsigned int)'
platform/libpal.so: undefined reference to `xlang::impl::convert_string(char16_t const*, unsigned int, char*, unsigned int)'

Move build containers to public registry

Currently, we publish docker build containers for Windows and Ubuntu to a private Azure container registry instance. We need to move that to a public registry like hub.docker.com

clean up python projection error handling and ref counting

Need RAII wrappers to ensure correct lifetime management and error checking for Python object pointers

Example https://github.com/zooba/pyptr

stop disabling -Wexceptions for xlang::to_result

xlang::to_result is marked no_except, but it throws and doesn't catch unconditionally. Can we rework this function to eliminate the #pragma to ignore the compiler warning on clang?

String comparisons

Given that the string design can flexibly support both UTF-8 and UTF-16 strings, we should provide string comparison support to ensure this gets done correctly by clients.

Naïve lexographical sorting of UTF-16 data doesn't order the same as UTF-8 or UTF-32, due to UTF-16 representing code points above U+FFFF as surrogate pairs in the range U+D800 through U+DFFF.

See this demo:
http://coliru.stacked-crooked.com/a/0cc8b1595a7828d0

UTF-16 sorts an emoticon (U+1F600) below the replacement character (U+FFFD), whereas UTF-8 and UTF-32 both preserve code point order.

Build instruction using GCC/MingW/Clang

In order for this to be truly crossplatform, one should be able to build it using various compilers. This is just a placeholder to gauge interest and to mark the progress towards that.

If that is already supported, than treat this as a request to update readme and to add travis/circleci builds using those toolchains.

Have a good weekend.

Xlang - Will this bring XAML standard, and Windows UI Library to Linux, Android, iOS, Mac, etc

Looking through the design docs, I get the impression that the scope of this project abstracts the basic base types and other building blocks of building code for an app. Assuming this API would be built on WinRT/UWP - would you imagine Xlang would allow for porting of much of the UWP API surface for use on other platforms - by projection of the compiled binaries, towards native ports of WinRT, or some translation to native framework equivalents?

Would XAML Standard be supported for rendering UI to native platform surfaces, as XAML is rendered to Direct X on Windows 10?

If it is just for Windows, why would there be a need to add yet another abstraction with language projections?

idl compile generates a lot of noise

I'd expect a single line of output when building a .idl file, instead see what is produced below

I recall seeing a "verbose" setting in the .vcxproj generated by the project templates, I recommend removing that and having people that want this specify via midl options.

1>Microsoft(R) Metadata Merge Utility Version 10.0.47.
1>
1>
1>Load input metadata file C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Foundation.FoundationContract\3.0.0.0\Windows.Foundation.FoundationContract.winmd.
1>Load input metadata file C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Foundation.UniversalApiContract\7.0.0.0\Windows.Foundation.UniversalApiContract.winmd.
1>Load input metadata file C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Networking.Connectivity.WwanContract\2.0.0.0\Windows.Networking.Connectivity.WwanContract.winmd.
1>Processing input metadata file C:\Users\Chris\Source\Repos\ChrisGuzakWork\ApiInformationForUdkDemo\x64\Debug\Unmerged\ApiInformation.winmd.
1>Processing input metadata file C:\Users\Chris\Source\Repos\ChrisGuzakWork\ApiInformationForUdkDemo\x64\Debug\Unmerged\SampleApi.winmd.
1>Processing input metadata file C:\Users\Chris\Source\Repos\ChrisGuzakWork\ApiInformationForUdkDemo\x64\Debug\Unmerged\Source.winmd.
1>Processing input metadata file C:\Users\Chris\Source\Repos\ChrisGuzakWork\ApiInformationForUdkDemo\x64\Debug\Unmerged\WindowsUdk.UI.ViewManagement.winmd.
1>Saved output metadata file WindowsUdk.winmd.
1>Saved output metadata file WindowsUdk.Foundation.winmd.
1>Saved output metadata file WindowsUdk.Sample.winmd.
1>Saved output metadata file WindowsUdk.UI.ViewManagement.winmd.
1>Validating metadata file C:\Users\Chris\Source\Repos\ChrisGuzakWork\ApiInformationForUdkDemo\x64\Debug\Merged\WindowsUdk.Foundation.winmd.
1>Validating metadata file C:\Users\Chris\Source\Repos\ChrisGuzakWork\ApiInformationForUdkDemo\x64\Debug\Merged\WindowsUdk.Sample.winmd.
1>Validating metadata file C:\Users\Chris\Source\Repos\ChrisGuzakWork\ApiInformationForUdkDemo\x64\Debug\Merged\WindowsUdk.UI.ViewManagement.winmd.
1>Validating metadata file C:\Users\Chris\Source\Repos\ChrisGuzakWork\ApiInformationForUdkDemo\x64\Debug\Merged\WindowsUdk.winmd.
1>main.cpp
1>ApiInformationForUdkDemo.vcxproj -> C:\Users\Chris\Source\Repos\ChrisGuzakWork\ApiInformationForUdkDemo\x64\Debug\ApiInformationForUdkDemo.exe

Revisit string encoding decision

WinRT uses UTF-16 encoded strings. Since xlang is not attempting to be binary compatible with WinRT, we can revisit this decision. In particular, we can consider several options

1. sticking with UTF16 encoded strings
2. changing to UTF8 encoded strings
3. Update string type + ABI to support UTF8 and UTF16 with conversion between the encodings

Generate Interface Authoring stubs for C++

When using the -component flag, cppwinrt will generate authoring stubs for all runtime classes in all of the -input metadata files (modulo any -include/-exclude filter flags). cppwinrt should also generate authoring stubs for all non-exclusive interfaces as well.

Use common try/catch wrapper in Python projection

@Scottj1s suggested unfolding try/catch blocks at compile time rather than projection time in a PR comment. More research on size/speed trade off needed, so creating a new issue to track.

Originally posted by @Scottj1s in #127

Building with VS 2019 Preview 2 introduces a lot more cmake noise

1> CMake generation started.
1> Command line: C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\PREVIEW\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe -G "Ninja" -DCMAKE_INSTALL_PREFIX:PATH="C:\git\xlang_build\Windows\x86\Debug\Install" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Preview/VC/Tools/MSVC/14.20.27305/bin/HostX86/x86/cl.exe" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Preview/VC/Tools/MSVC/14.20.27305/bin/HostX86/x86/cl.exe" -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\PREVIEW\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "C:\git\xlang\src"
1> Working directory: C:\git\xlang_build\Windows\x86\Debug
1> [CMake] -- The C compiler identification is MSVC 19.20.27305.0
1> [CMake] -- The CXX compiler identification is MSVC 19.20.27305.0
1> [CMake] -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Preview/VC/Tools/MSVC/14.20.27305/bin/HostX86/x86/cl.exe
1> [CMake] -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Preview/VC/Tools/MSVC/14.20.27305/bin/HostX86/x86/cl.exe -- works
1> [CMake] -- Detecting C compiler ABI info
1> [CMake] -- Detecting C compiler ABI info - done
1> [CMake] -- Detecting C compile features
1> [CMake] -- Detecting C compile features - done
1> [CMake] -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Preview/VC/Tools/MSVC/14.20.27305/bin/HostX86/x86/cl.exe
1> [CMake] -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Preview/VC/Tools/MSVC/14.20.27305/bin/HostX86/x86/cl.exe -- works
1> [CMake] -- Detecting CXX compiler ABI info
1> [CMake] -- Detecting CXX compiler ABI info - done
1> [CMake] -- Detecting CXX compile features
1> [CMake] -- Detecting CXX compile features - done
1> [CMake] CMake Warning (dev) at tool/abi/CMakeLists.txt:10 (target_sources):
1> [CMake] Policy CMP0076 is not set: target_sources() command converts relative paths
1> [CMake] to absolute. Run "cmake --help-policy CMP0076" for policy details. Use
1> [CMake] the cmake_policy command to set the policy and suppress this warning.
1> [CMake]
1> [CMake] An interface source of target "abi" has a relative path.
1> [CMake] This warning is for project developers. Use -Wno-dev to suppress it.
1> [CMake]
1> [CMake] CMake Warning (dev) at tool/cpp/cppwinrt/CMakeLists.txt:6 (target_sources):
1> [CMake] Policy CMP0076 is not set: target_sources() command converts relative paths
1> [CMake] to absolute. Run "cmake --help-policy CMP0076" for policy details. Use
1> [CMake] the cmake_policy command to set the policy and suppress this warning.
1> [CMake]
1> [CMake] An interface source of target "cppwinrt" has a relative path.
1> [CMake] This warning is for project developers. Use -Wno-dev to suppress it.
1> [CMake]
1> [CMake] CMake Warning (dev) at tool/idl/CMakeLists.txt:6 (target_sources):
1> [CMake] Policy CMP0076 is not set: target_sources() command converts relative paths
1> [CMake] to absolute. Run "cmake --help-policy CMP0076" for policy details. Use
1> [CMake] the cmake_policy command to set the policy and suppress this warning.
1> [CMake]
1> [CMake] An interface source of target "idl" has a relative path.
1> [CMake] This warning is for project developers. Use -Wno-dev to suppress it.
1> [CMake]
1> [CMake] CMake Warning (dev) at tool/python/CMakeLists.txt:6 (target_sources):
1> [CMake] Policy CMP0076 is not set: target_sources() command converts relative paths
1> [CMake] to absolute. Run "cmake --help-policy CMP0076" for policy details. Use
1> [CMake] the cmake_policy command to set the policy and suppress this warning.
1> [CMake]
1> [CMake] An interface source of target "pywinrt" has a relative path.
1> [CMake] This warning is for project developers. Use -Wno-dev to suppress it.
1> [CMake]
1> [CMake] CMake Warning (dev) at test/platform/CMakeLists.txt:6 (target_sources):
1> [CMake] Policy CMP0076 is not set: target_sources() command converts relative paths
1> [CMake] to absolute. Run "cmake --help-policy CMP0076" for policy details. Use
1> [CMake] the cmake_policy command to set the policy and suppress this warning.
1> [CMake]
1> [CMake] An interface source of target "test_platform" has a relative path.
1> [CMake] This warning is for project developers. Use -Wno-dev to suppress it.
1> [CMake]
1> [CMake] CMake Warning (dev) at test/platform/CMakeLists.txt:22 (target_sources):
1> [CMake] Policy CMP0076 is not set: target_sources() command converts relative paths
1> [CMake] to absolute. Run "cmake --help-policy CMP0076" for policy details. Use
1> [CMake] the cmake_policy command to set the policy and suppress this warning.
1> [CMake]
1> [CMake] An interface source of target "test_platform" has a relative path.
1> [CMake] This warning is for project developers. Use -Wno-dev to suppress it.
1> [CMake]
1> [CMake] CMake Warning (dev) at test/cpp/CMakeLists.txt:5 (target_sources):
1> [CMake] Policy CMP0076 is not set: target_sources() command converts relative paths
1> [CMake] to absolute. Run "cmake --help-policy CMP0076" for policy details. Use
1> [CMake] the cmake_policy command to set the policy and suppress this warning.
1> [CMake]
1> [CMake] An interface source of target "cpp_test" has a relative path.
1> [CMake] This warning is for project developers. Use -Wno-dev to suppress it.
1> [CMake]
1> [CMake] CMake Warning (dev) at test/cpp/CMakeLists.txt:55 (target_sources):
1> [CMake] Policy CMP0076 is not set: target_sources() command converts relative paths
1> [CMake] to absolute. Run "cmake --help-policy CMP0076" for policy details. Use
1> [CMake] the cmake_policy command to set the policy and suppress this warning.
1> [CMake]
1> [CMake] An interface source of target "cpp_test" has a relative path.
1> [CMake] This warning is for project developers. Use -Wno-dev to suppress it.
1> [CMake]
1> [CMake] -- Configuring done
1> [CMake] -- Generating done
1> [CMake] -- Build files have been written to: C:/git/xlang/_build/Windows/x86/Debug
1> [CMake]
1> Starting CMake target info extraction ...
1> CMake server connection made.
1> Extracted includes paths.
1> Extracted CMake variables.
1> Extracted source files and headers.
1> Extracted global settings.
1> Extracted code model.
1> Extracted CTest info.
1> Collating data ...
1> Target info extraction done.
1> CMake generation finished.

clarify namespace traversal in XDN03

According to XDN03, xlang_get_activation_factory first looks for an activation in a shared library that exactly matches the full type name. I.e. if searching for MyComponent.Feature.Widget, the function will first look for a library MyComponent.Feature.Widget.[dll/so/dylib]. But the implentation in #41 starts by looking for a shared library that matches just the namespace of the type (I.e. MyComponent.Feature.[dll/so/dylib]).

I'm pretty sure XDN03 is wrong here. Certainly, WinRT not considers only the type namespace when resolving metadata at runtime (a different but still relatated scenario)

xlang cmake builds are unreliable

C:\git\xlang\src\tool\python\code_writers.h(1989): warning C4189: 'category': local variable is initialized but not referenced

C:\git\LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification

Parity: Restore option to build C++/WinRT as a C++ module

The xlang/cpp tool doesn't generate the winrt.ixx file.

[Suggestion] Introduce Int8 MIDL type

Since this project is not aiming to preserve binary compatibility with Windows Runtime, I would like to suggest introducing signed 8-byte Int8 primitive type into Xlang type system.

Current MIDL 3.0 doesn’t support Int8 type, and only has unsigned 8-bit integer type. But introducing the signed one would make a lot of sence if you expect to support UTF-8 strings in Xlang ABI.

This would require changes to MIDL 3.0 definition language of course.

Azure Pipeline builds aren't being kicked off automaticaly

ABI executable needs to exclude override interfaces

Although exclusiveto, overridable interfaces are not "exclusive" exclusive

winrt::capture helper must support projected types as well

The capture helpers currently only support com_ptr types and not projected types. This impacts a number of interop scenarios where COM interfaces are used to create WinRT types. Those callers must manually stitch up the calls, which is rather error prone.

Pythonic Python Experience

Currently, pywinrt (aka the python projection generation tool) emits code that is usable from python, but does not provide a pythonic experience - i.e. it does not feel natural and familiar to a python developer. This issue tracks the work we will do to generate a more pythonic experience by wrapping the generated native types in pure python.

At a minimum, expected to project the following WinRT constructs as the corresponding pythonic constructs:

WinRT Construct	Python Construct
Namespaces	pythonic experience TBD
IStringable	__str__ support
IClosable	with statement support
Collections	sequence protocol and __len__ support
IAsync*	await support
get/put methods	property support
add/remove methods	pythonic experience TBD

Azure Pipelines builds aren't public

The badge in the readme links to https://microsoft.visualstudio.com/Dart/_build/latest?definitionId=31784 which is only accessible inside of MSFT.

winrt::delegate is missing constructors for get_strong and get_weak support

This particular delegate didn't receive the get_strong/get_weak overloads that all of the other delegates received in order to create a delegate holding a strong/weak reference automatically. This is an inconsistency and makes it harder to code these patterns correctly.

Marshaling support?

First, I have to say that I'm excited about this project and am hoping for this to mature into a cross-platform alternative to COM and WinRT.

One of the big strengths of COM is transparent support for out-of-process marshaling, provided that the interfaces are "automation" compatible. This have enabled my team to easily switch between in-process (for performance), and out-of-process deployment (for failure isolation) of the same SW with minimal SW changes.

Are there any similar plans for transparent out-of-process marshaling with "xlang"?

Is compatibility with the Windows Runtime a goal of the project?

I'm mostly asking about the way language projections work. For example if I write a tool that generates Rust code akin to the C++/Python ones, will it work with today's Windows Runtime APIs?

Any plan for Node.JS?

Developing and distributing a native extension for Node.js is a disaster, as every Node dev know.

Relationships between xlang and grpc

How does xlang relate to the grpc project?
https://github.com/grpc/grpc
From what I see grpc targets protocol buffers (and still make use of IDL) while xlang is meant to solve in-process bindings.
Anyway, I believe there is an opportunity to bridge the two.
Comments?

Consider removing MAX_PATH specialization in windows version of try_get_activation_func

@kennykerr comment from #41 PR: I'm not sure that optimizing for short paths is worthwhile. Seems like something we can add once we've profiled and determined that this is in fact a bottleneck.

@Scottj1s comment from #41 PR: or just use _malloca if you want a variable buffer that can be allocated from stack or heap as appropriate

CI build Broken

PR #61 broke the CI build (purposefully - that PR changes the build scripts). @Scottj1s to fix the CI system to point to the new build script

Needs to build on MacOS

This does not seem to be designed to work on Unix.

ABI support for Object Equality

@bbowman suggested that the xlang ABI should have a mechanism for equality comparison. Many OO languages provide a mechanism for types to customize equality comparisons:

• dotnet Object.Equals methon
• Python __eq__ magic method
• Java Object.equals method
• Objective-C NSObject isEqual

Need to decide if this should be added as a method to IXlangObject, somehow shoe-horned into IXlangObject::GetInfo, or be a seperate interface accessed via QI

[Question] Support xlang in .NET Core

Hi everybody,

First of all thank you for this project, I think I have been waiting for something like that since the very announcement of Windows Runtime :)

I think this suggestion belongs to the actual .NET Core repo, but I just wanted to clarify some of the goals of this project.

Is support for Xlang by .NET Core on the roadmap of both projects? .NET Core badly lacks C++/CLI, and this project can easily and once and for all solve this problem, basically becoming the future of interop for .NET.

Is it being communicated between you guys and .NET Core team(s)?

Thank you!

Update PAL doc with new function names

After the documentation was committed, the implementation for memory allocation and strings adopted the snake_case naming convention. The PAL doc needs to be updated to be consistent.