Sorry for the naive question, but how does this fit into WinUI 3.0?
Yes
Rust/WinRT Public Preview
111–120 of 219 posts
Re: Rust/WinRT Public Preview
#112How does this projection work with the borrow checker? UI frameworks typically allow you to have multiple mutable reference to the same element.
It works fine- Rust only forbids multiple `&mut T`s to the same object, but `&mut T` doesn't exist outside of Rust, so code in other languages doesn't have to care about that rule at all.
These bindings can just expose non-Rust pointers as (wrapped) raw pointers, leaving all the actual dereferencing and mutation to the other language. WinRT objects don't expose anything but virtual methods on opaque objects anyway, so this isn't even Rust-specific.
Outside of WinRT this sort of thing requires a bit more thought, but you can still use the usual tools- `Rc` and `Cell` or their variants, or raw pointers and `unsafe`.
You can think of `&T` and `&mut T`, and their associated "no shared mutability" rule, as a compiler-checked version of C's `restrict`. Stop using `restrict` and the rules go away.
Re: Rust/WinRT Public Preview
#113Earlier quoted context omitted.
You know that’s from 3 decades and 2 CEOs ago, right? They’re a large company so there’s sure to be plenty to dislike but I don’t think it’s contributing much without some analysis of their actions in this century.
Sure let's do that. This century they have bought up LinkedIn, GitHub, npm, and a stake in Facebook. They have replaced Atom with a fauxpen source editor. They've pointed them all at their locked down me-too cloud platform. And don't forget to develop your code on their locked down me-too tablet. What has changed is that MSDN is no longer delivered on CDs. That's because "Open Source" is a much cheaper deliver mechan…
>They have replaced Atom with a fauxpen source editor.
I'm gonna counter this with the fact that VSCode was way better maintained and optimized than Atom.
The GitHub before Microsoft seemed to me as an company that would half-ass everything they could, and Atom was one of those things.
When VSCode came, at least to me, it absolutely destroyed Atom with versatility and stability.
Re: Rust/WinRT Public Preview
#114Earlier quoted context omitted.
COM is a fantastic invention and implementation. Granted, it was pretty painful in C and somewhat in C++, but all the other languages (VB and C# mostly, but plenty of others) really unlock the power of COM. Nothing like that remotely exists on Linux or macOS.
My only experience with COM (that I know of) was trying to do MS Office automation from C# >10 years ago. I recall that it was very awkward, and somehow prone to memory leaks, and unclosed resources. To this day, I still don't really understand what COM is, or is supposed to be. But I still have a negative visceral reaction.
The bit about memory leaks is probably a comment on the effectiveness of the .net GC more than anything else. COM objects are reference counted. When the .net runtime GCs a wrapped COM object it bumps the count down. My experience from years ago is that can take a long time or not happen at all. There is a manual call that releases the object, after which it is no longer usable from .net.
Re: Rust/WinRT Public Preview
#115Coding in C++/WinRT (similaly, C++/CX) is in my experience a major mistake when targeting WinRT/UWP using C++. The primary use case for WinRT/UWP is making apps for the Microsoft Store, where most of the time you're going to be sharing code also targeting Google Play and the Apple Store given those markets are vastly larger (and have viable ad-platforms; Microsoft is shutting theirs down on June 1st).
The C++/WinRT and C++/CX language projections are incompatible with compilers that target Android and IOS due to WinRT reference specific syntax and keywords such as the '^' reference indicator.
As an alternative, it is possible to access all of the same WinRT/UWP platform functionality in pure C++ without the C++/WinRT syntactic sugar extensions, allowing you to cleanly abstract the WinRT/UWP platform APIs relative to Android and IOS. This is not well documented but by far a superior option for folks familiar with COM and Windows internals.
Furthermore, avoiding things like '^' reference operator syntax gives you tighter control over object lifetime as C++/WinRT and C++/CX hide to some degree the mechanics of COM object lifetime and gives a pseudo-environment much more like C# on .Net.
Microsoft does provide the WRL pure C++ template library, which is in many ways a spiritual successor to the ATL COM template library. WRL is in my experience the best way to interact with COM objects surrounding WinRT and UWP.
(Source: developer of several top 10 apps (at times) on Microsoft Store).
Glossary of Microsoft terms:
WinRT/UWP (WinRT (Windows Runtime) the old name used in Windows 8/8.1 for what later was renamed to UWP (Universal Windows Platform) in Windows 10). WinRT/UWP was originally intended to be an object-oriented replacement API for Win32 but hasn't lived up to its charter due to only being useful for Microsoft Store apps and being significantly less capable than Win32.
COM - Component Object Model; an object-oriented API style used by some Win32 APIs, this style was used near-exclusively as the basis for the WinRT APIs. COM can be unweildy to deal with so there are several C++ template libraries like WRL and ATL to make it easier.
C++/WinRT (and C++/CX) are Microsoft specific C++ extensions that require MSVC and hide the complexity of dealing with COM relative to WinRT/UWP APIs.
Re: Rust/WinRT Public Preview
#116Earlier quoted context omitted.
It’s always easy to be an open source proponent when you are the underdog. And Microsoft, as crazy as it sounds to me, kinda is when it comes to cool dev stuff. We'll have to see if they have really changed or just waiting to regain ground and going back to the extinguish part. But what I can confidently say is that, of all the BigCorps, Microsoft is the only one actively trying to make developer's life easier. Apple…
The Microsoft you remember is at a time when dev tools were "the future". They are now the past. Microsoft's ruthlessness is no doubt focused elsewhere now. For example, do they go out of their way to make your code portable b/w Azure and Google? Probably not.
Off the top of my head here are three different offerings from Microsoft that enable cross cloud applications:
- https://azure.microsoft.com/en-us/services/azure-arc/
- https://dapr.io/
- https://keda.sh/
Re: Rust/WinRT Public Preview
#117Earlier quoted context omitted.
It's in their blood - its the 'Embrace' in EEE.
You know that’s from 3 decades and 2 CEOs ago, right? They’re a large company so there’s sure to be plenty to dislike but I don’t think it’s contributing much without some analysis of their actions in this century.
Whether or not you like/dislike EEE, the fact remains that MS openness to Embrace helps them today to quickly implement different technologies into Microsoft's own stack.
They may have stopped the "Extend & Extinguish" part, but they haven't forgotten how to Embrace.
Re: Rust/WinRT Public Preview
#118Earlier quoted context omitted.
Microsoft R Open is embrace/extend: - Incompatible with R. - Added their own packages version of every package. - Added their own package repository (MRAN), replacing CRAN. It's open source, and supports Linux, but if they found ways to optimize R perhaps it would be a better idea to just contribute that to the upstream project. Downvote all you want, but if you are rational, reply here and explain how I am wrong. No…
Microsoft R is kinda annoying, OTOH it only happened because Microsoft bought Revolution Analytics, who developed this tool. AFAIUI, it's mostly just R with better parallelisation of matrix libraries (which is cool). It's not quite compatible, but I've used both through Conda a bunch, and haven't hit any edge cases that caused a problem. So yeah, you're right that it's embrace/extend, but the extend was done by a sta…
Yeah this seems like a good take. Otherwise it's like saying anyone building alternative or similar runtimes for existing languages is evil. This is common. People don't always contribute to existing languages or runtimes because it's fraught a lot of politics and it can just be easier to fork and do what you need, rather than trying to get what you need into a project that might not want it.
Re: Rust/WinRT Public Preview
#119Coding in C++/WinRT (similaly, C++/CX) is in my experience a major mistake when targeting WinRT/UWP using C++. The primary use case for WinRT/UWP is making apps for the Microsoft Store, where most of the time you're going to be sharing code also targeting Google Play and the Apple Store given those markets are vastly larger (and have viable ad-platforms; Microsoft is shutting theirs down on June 1st). The C++/WinRT a…
C++/WinRT and C++/CX are not the same; they are different enough that Microsoft Docs has a whole page explaining how to move from C++/CX to C++/WinRT:
https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a...
In particular only the older C++/CX has ^ pointers or other Microsoft-specific C++ language extensions. C++/WinRT is standard C++.
Writing your code using WRL (Windows Runtime C++ template Library) is good if you want to learn enough about how the Windows Runtime extensions to COM work in order to debug effectively. However, its close relationship to the underlying COM and Windows Runtime APIs also makes it far too verbose to quickly write good API-consuming and -producing code, in my opinion.
Re: Rust/WinRT Public Preview
#120With Windows 7 on its way out slowly, WinRT is becoming more palatable.
Slowly?! Hasn't Win7 been dead for years? > Latest release Service Pack 1 (6.1.7601) / February 22, 2011; 9 years ago > Mainstream support for Windows 7 ended on January 13, 2015. There is: > Extended support for Windows 7 ended on January 14, 2020. But that is referring to very specific business contracts, not casual users pretending EOL never happened.
Casual users still received updates for Windows 7 until January 14th, 2020.
Businesses can get "Windows 7 Extended Security Updates (ESU)" for a maximum of 3 years after January 14th, 2020. https://support.microsoft.com/en-us/help/4527878/faq-about-e...