3 ms·

There is an official Rust Windows API: https://github.com/microsoft/windows-rs https://github.com/microsoft/windows-rs

pjmlp 4y ago
An official work in progress Windows binding, still far behind of what C# existing bindings are capable of, or legacy toolkits like MFC. Also given how the team has managed C++/CX transition to C++/WinRT with lesser tooling stuck on C++17, dropped Modern C++ bindings [0][1], before going into other shinny thing, I wonder how long they will keep at it. [0] - https://blogs.windows.com/windowsdeveloper/2021/01/21/making-win32-apis-more-accessible-to-more-languages https://blogs.windows.com/windowsdeveloper/2021/01/21/making... [1] - https://github.com/microsoft/cppwin32 https://github.com/microsoft/cppwin32
- flohofwoe 4y ago
  It doesn't matter if the project is driven by Microsoft or not, the cat (of automatically generated language bindings) is out of the bag. E.g. Zig is using the same approach without being an official MS project: https://github.com/marlersoft/zigwin32 https://github.com/marlersoft/zigwin32, and Apple has an automatically generated C++ API for Metal (https://developer.apple.com/metal/cpp/ https://developer.apple.com/metal/cpp/). In the future, the question won't be "what language do I need to learn to code on this platform", but instead "where are the language bindings for my favourite language".
  - pjmlp 4y ago
    Depends if one is on yak shaving or delivering code into production. Being a Borland and ETHZ fanboy has taught me some hard lessons in development effort, when languages don't have tier 1 support from platform owners. So until Rust is on Visual Studio and Windows SDK out of the box, I rather keep using .NET languages alongside C++ for Windows development.
- whizzter 4y ago
  I think it's just a balancing of where work is needed. C++/Cx (and it's predecessors) was bad in requiring special compiler support whilst WinRT had already seen real adoption and cppwin32 didn't really give any benefits apart from another backend so they seem to have concluded that C++ devs would easier be supported by something more mature (that needed support anyhow) and then just focus the win32metadata project (That's still alive) on "new" languages.
  - pjmlp 4y ago
    Adoption by WinDev, nobody else cares after they screwed their customers. They should all have been fired if it was up to me, we don't pay VS licenses for killing our workflows like that. WinRT is Windows only technology, who cares about extensions. Plenty of people don't have any issues with GCC and clang extensions, or macOS specific ones like Objective-C++, or TI, or ARM SDK, or whatever fancies their party, only MS ones are bad.

An official work in progress Windows binding, still far behind of what C# existing bindings are capable of, or legacy toolkits like MFC. Also given how the team has managed C++/CX transition to C++/WinRT with lesser tooling stuck on C++17, dropped Modern C++ bindings [0][1], before going into other shinny thing, I wonder how long they will keep at it. [0] - https://blogs.windows.com/windowsdeveloper/2021/01/21/making-win32-apis-more-accessible-to-more-languages https://blogs.windows.com/windowsdeveloper/2021/01/21/making... [1] - https://github.com/microsoft/cppwin32 https://github.com/microsoft/cppwin32

flohofwoe 4y ago
It doesn't matter if the project is driven by Microsoft or not, the cat (of automatically generated language bindings) is out of the bag. E.g. Zig is using the same approach without being an official MS project: https://github.com/marlersoft/zigwin32 https://github.com/marlersoft/zigwin32, and Apple has an automatically generated C++ API for Metal (https://developer.apple.com/metal/cpp/ https://developer.apple.com/metal/cpp/). In the future, the question won't be "what language do I need to learn to code on this platform", but instead "where are the language bindings for my favourite language".
- pjmlp 4y ago
  Depends if one is on yak shaving or delivering code into production. Being a Borland and ETHZ fanboy has taught me some hard lessons in development effort, when languages don't have tier 1 support from platform owners. So until Rust is on Visual Studio and Windows SDK out of the box, I rather keep using .NET languages alongside C++ for Windows development.
whizzter 4y ago
I think it's just a balancing of where work is needed. C++/Cx (and it's predecessors) was bad in requiring special compiler support whilst WinRT had already seen real adoption and cppwin32 didn't really give any benefits apart from another backend so they seem to have concluded that C++ devs would easier be supported by something more mature (that needed support anyhow) and then just focus the win32metadata project (That's still alive) on "new" languages.
- pjmlp 4y ago
  Adoption by WinDev, nobody else cares after they screwed their customers. They should all have been fired if it was up to me, we don't pay VS licenses for killing our workflows like that. WinRT is Windows only technology, who cares about extensions. Plenty of people don't have any issues with GCC and clang extensions, or macOS specific ones like Objective-C++, or TI, or ARM SDK, or whatever fancies their party, only MS ones are bad.