Rust/WinRT Public Preview

https://blogs.windows.com/windowsdeveloper/2020/04/30/rust-winrt-public-preview/

by steveklabnik • 6 years ago

628 206 6 years ago

blogs.windows.com

dstaley2• 6 years ago

I'm super excited for this! I do wish that they'd ressurect their JavaScript projection for the runtime though. Especially with their focus on React Native, it'd be awesome not to need a "native" module to call Windows APIs. That being said, I also hope Rust/WinRT becomes a valid native module format for React Native (though I suspect it won't since that would likely require React Native developers to have the Rust toolchain setup to compile the module).

pjmlp13• 6 years ago

PWAs on Edge were able to do it, when signed.

Hopefully they will do the same with the new version.

Kipters5• 6 years ago

Something like this already exists: https://github.com/NodeRT/NodeRT

dstaley2• 6 years ago

This is neither an official language projection nor for React Native.

weiming2• 6 years ago

Now I'd like some native Rust bindings for Cocoa/UIKit, perhaps as an "official"/higher-level alternative to https://crates.io/crates/objc. There are some crates already attempting to replicate all of Apple frameworks, but they are community-supported/require a bit of `unsafe`.

Klonoar• 6 years ago

You won't get around the unsafe.

I've been hacking away at these for a few months now: https://github.com/ryanmcgrath/cacao

Goal is to get a good-enough version to build apps with. I'm dogfooding it for my next product so there's some incentive to keep pushing.

roblabla• 6 years ago

The state of Rust MacOS bindings is pretty bad. Last I checked, a lot of crates are built on top of the `core-foundation` crate which is full of unsound abstractions. And a lot of them seem to be hard to fix, as the Core Foundation types are all equivalent to `Arc<Data>` with no synchronization of the inner data. This makes mutable collections very complicated to model, for instance.

oaiey3• 6 years ago

I start to understand the Windows team desire for this WinRT. You can flow through time with these language bindings without being locked into a programming language. .NET, JS, C++ and now Rust. That is seriously cool.

hota_mazi3• 6 years ago

It's been a reality on Windows for over 20 years, though. COM has made it possible to write applications on Windows and integrate with pretty much anything in it in any language with COM bindings.

Glad to see Rust is now one more such language.

Kipters5• 6 years ago

WinRT is actually built on COM, Rust/WinRT uses it under the hood

badsectoracula4• 6 years ago

Yeah though... pretty much any natively compiled language and many interpreted/VM-based languages can use the C ABI in any modern plaform anyway, so what COM provides isn't so much the ability to use the same API from many languages but a dynamic object oriented approach for doing so.

After all it isn't like you can't use the Win32 API directly from Rust - or any other language, e.g. Python.

oaiey3• 6 years ago

Well, just before it was selected stuff. Now it is the xml parser element node. That is a bit more than before. And the tooling changed like hell.

DeathArrow5• 6 years ago

That's true. But developing apps for Windows seems like a small niche now.

And if you don't use C#, you are in a world of pain with MFC and Win32.

C++ developers asked for a nice GUI framework for ages.

lostmsu• 6 years ago

To be fair, you could do this with plain C, then with COM, etc.

xrd• 6 years ago

I stopped reading at "The Windows Runtime is based on Component Object Model (COM) APIs..."

Is that a bad choice on my part?

I see COM and think of OLE, CORBA and I remember that I'm old and going to die pretty soon (within the next 40-50 years almost assuredly).

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

sleepinseattle2• 6 years ago

It’s not that different from things like Protocol Buffers, and for application code it’s mostly a hidden implementation detail. The API you’re calling (like the Composition API’s in the Minesweeper example) might be calling into a separate process but you don’t have to care.

Disclosure: I work on the Windows team

blinkingled3• 6 years ago

Trouble is you can't really the solve the problem Microsoft had without using something like COM. Good news is you don't have to care - you can use C# or Rust and not worry about COM.

pjmlp13• 6 years ago

Somehow I think .NET would have been much better had it started as something like .NET Native, but yeah cannot turn back in time.

oaiey3• 6 years ago

Windows UI and Framework beyond Win32 is solidly based on COM. Win 10 works for many years now with a deployment close to a billion. I would say: works.

alxmdev• 6 years ago

"Under the hood" makes it sound like you wouldn't deal with any COM stuff yourself, it's just how the different languages' APIs were implemented to interface with the OS runtime.

hota_mazi3• 6 years ago

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.

recursive• 6 years ago

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.

dralley• 6 years ago

GObject is somewhat similar but it's nowhere close to first-class (being a Gtk specific tech)

tonyedgecombe• 6 years ago

Nothing like that remotely exists on Linux or macOS.

https://developer.apple.com/library/archive/documentation/Co...

winter_blue2• 6 years ago

COM brings back a lot of fantastic old memories.

When I was a kid, I used to make VB6 applications, and I'd be able to get custom widgets from the Internet, and import them into my VB6 project seamlessly. It was truly amazing, and mind-expanding.

The JS/React/etc web ecosystem doesn't come anywhere close, in terms of the ease-of-use that VB6 had.

pjmlp13• 6 years ago

Yes it is.

After the whole political disaster that was Longhorn, the Windows team decided to rebuilt Longhorn ideas, originally based on .NET, and redo them with COM.

So while many outside Windows have considered COM dead, actually since Vista all major Windows APIs have been provided as COM interfaces, the large majority of Win32 surface has been frozen since Windows XP.

With WinRT/UA/UAP/UWP they have gone back to the roots, while pursuing this idea one level up.

Basically they replaced COM type libraries with .NET Metadata, added support for generics, structured data types and implementation inheritance, bringing it to what .NET would have been like if they did not decided to copy Java.

So while the implementation of this reboot has been somewhat clusmy, COM is not going anywhere on Windows.

Also, this isn't a Windows only thing, Linux has gathered around DCOP, Android has AIDL, Fuchsia FIDL, macOS/iOS has XPC, then there is gRPC and plenty of other variants.

codys• 6 years ago

For linux I believe you mean D-Bus instead of DCOP. (that said, it's largely similar in concept)

KeBugCheckEx2• 6 years ago

Historical note: first versions of .NET were called "COM+ 3.0".

amaranth• 6 years ago

I think the most similar thing to WinRT on Linux would be GObject Introspection since the main point appears to be a way to somewhat automatically surface the platform API in multiple languages using language-specific idioms. D-Bus is instead for RPC and events, which I guess COM also gets used for?

lukeh2• 6 years ago

Well, even before XPC there was Distributed Objects. In the mid-90s NeXT had a bridge between COM and DO called D'OLE, which remoted COM before Microsoft did. Of course, that didn't really take off, but it was a great example of how flexible a dynamic runtime can be. (They also had a lot of very smart developers.)

Koshkin3• 6 years ago

That's what they called "going native" (vs. using .NET).

discreteevent• 6 years ago

I don't think the basic architecture is going to go away. Even some of the newest operating systems have something quite similar:

https://fuchsia.googlesource.com/docs/+/ea2fce2874556205204d...

blinkingled3• 6 years ago

https://github.com/robmikh/minesweeper-rs - I just love how they brilliantly avoided mixing up C++/COM things into this. Tough one to pull when you're dealing with bindings for a foreign language. The code looks fairly standard Rust (except maybe for the winrt::import that looks like Go?).

If you are familiar with Rust, you will notice this looks far more like Rust than it looks like C++ or C#. Notice the snake_case on module and method names and the ? operator for error propagation.

Developing on and now for Windows just keeps getting better.

pathartl• 6 years ago

It seems like they're doing all they can to get developers on their platform. Not to establish Windows developers like they have in the past, but to have others see Windows as just another platform.

We're reaching a revolution from moving from x86 to ARM and I think the more Microsoft positions themselves like this, the less likely they are to be left in some weird compatibility limbo.

As weird as this sounds, I feel more confident with Microsoft being able to do a successful transition to ARM than Apple at this point.

pianoben• 6 years ago

In fact, the _have_ transitioned to ARM, way back around the time of the first Surface tablet. Windows and Office have been running on ARM since at least, what, 2012?

VWWHFSfQ• 6 years ago

It will be very difficult until Windows is POSIX-compatible. Whatever that means, I don't know. But it can't just be the Windows Subsystem for Linux. The whole OS needs to have POSIX compatibilities.

GordonS• 6 years ago

Windows is my daily driver, and I spend most of my time at work these days building dotnet core applications for Linux on both x64 and ARM. It's a great dev experience

Seeing what was coming with cloud and making .NET cross-platform was very well timed.

DeathArrow5• 6 years ago

Microsoft tried countless times to move to Arm.

The most recent efforts are with their Surface Pro X, their SQ1 CPU and pushing Qualcomm to release Snapdragon 8cx CPU for ARM laptops.

But most software development companies didn't care enough to recompile their software for Arm and running X86 software in emulation is not exactly a good experience.

Koshkin3• 6 years ago

brilliantly avoided mixing up C++/COM

I remember VB6 was also exceptionally good at this.

KeBugCheckEx2• 6 years ago

Actually a lot in COM was made to work on vb. COM string type is BSTR which stands for Basic STRing.

pjmlp13• 6 years ago

COM is both an evolution of VBX and a subset of OLE 2.0.

.NET was going to be what UWP is now, an evolution of COM, but then Java happened, and they went with something similar instead.

There are some references to how this all happened in the story of F# evolution, given that Don Syme was part of the team since the early days.

peatmoss2• 6 years ago

How can we bring this to Linux/BSD? Specifically the GUI layer? I’ve lamented that Linux desktop world has been fragmented and alien as compared to other major environments. I used to think that things would have been better if we had chased GNUStep and source compatibility with macOS.

I feel like the non-GUI userland in Linux is best in class and is effectively a given for any server deployment. But all the developers I know cobble together a mediocre Linux-like environment on macOS so they can have a first-class desktop environment and an okay development environment.

On the other hand I read about people using Windows as development environment by using WSL.

I feel like Linux will never organically gain critical mass for a desktop environment—substantial source compatibility with some major platform seems like the way to go. How are the Windows APIs vs the Cocoa APIs these days? Assuming source compatibility could help boost desktop Linux’s fortunes, is Windows or Cocoa a better target? Does consideration of iOS change the calculus?

pjmlp13• 6 years ago

It is already available, it is called GObject, KParts, D-Bus.

If the community has embraced a proper desktop eco-system around them, like the component vendors on other platforms, they aren't going to start now.

I surely don't see job offers for Linux/BSD GUI toolkits as I see for Apple, Microsoft and Google ones.

WSL is only for those that use Windows to target GNU/Linux, the demography that used to buy macOS to do the same.

For traditional Windows developers it doesn't really matter. PowerShell + Windows Terminal is where the action is.

badsectoracula4• 6 years ago

IMO the main issue with Linux desktop is that it keeps getting broken. Outside of X11, which itself doesn't provide much in terms of features so you need to implement a ton of things, there is no stable API. Both Gtk and Qt intentionally break backwards compatibility every few years and unintentionally in-between (mainly Gtk though), which means that projects that rely on those waste time on keeping up with the changes instead of adding features and fixing bugs.

And it isn't just Gtk and Qt, outside of a very very small set of libraries (e.g. libcurl and Cairo), most other libraries do the same thing and most developers do not even seem to see that as a problem - except if you sit down and consider how much time is wasted in total by the users of those libraries (ie. the people who would actually make the desktops and the desktop applications) it should be obvious how much of an issue is (and even then, because many programmers prefer theoretically "clean" code and believe that the only way to do that is to rid existing working code and replace it with new -and unknownly broken- code, they have a very strong bias against even trying to accept this).

A very big reason Windows is dominant is because when something lands on the OS itself, chances are you'll be able to use it decades later. macOS much less so, but they have an army of engineers to keep up and even then as time moves on you see many people disliking how macOS breaks things (see the latest 32bit disaster).

Outside of a few influential outliers, like Linus himself or Keith Packard (who works on Xorg and Cairo) there aren't many that care about not breaking things. And IMO it is a bit disconcerting that it seems to be mainly the "old guard" of Linux developers that seem to care about this. I hope this is only because they've been around enough to realize that unnecessarily breaking things isn't a good idea, otherwise we can only expect things to become more broken over time (and Linus had this stance for decades, so it might not have anything to do with wising over the years).

Honestly, the move fast and break things culture that the web has fostered doesn't work for anything that has to do with other stuff people rely on.

But this is most likely also why you do not see that issue as much in the non-GUI world: most of the non-GUI stuff on Linux are either very long running projects (e.g. Bash, Perl, etc) that just do not break or very young projects that are mainly used for web work that will be thrown away in a couple of years or so, so any breakage wont be felt as much (and people working on those are used to broken things anyway). Any exception to that has ramifications that are felt for a long time - see Python2 vs Python3 as an example (...of what not to do - and note how many will even consider such breakage as natural and unavoidable, as if it was some sort of force of nature).

Unless this mentality and culture of breakage changes so that we can build stuff on solid foundations, things wont change.

noch• 6 years ago

I feel like Linux will never organically gain critical mass for a desktop environment [...]

Indeed. https://media.ccc.de/v/ASG2018-174-2018_desktop_linux_platfo...

mister_hn• 6 years ago

Just use Qt binding for Rust and you can have it on Linux.

masklinn2• 6 years ago

except maybe for the winrt::import that looks like Go?

It looks to be a pretty extensive codegen hook, generating bindings to the referenced runtime components on the fly based on the module metadata it finds on the system.

Apparently the C++ version uses IDL and an explicit codegen step instead: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a...

steveklabnik8• 6 years ago

It's a really intriguing approach; most use "build.rs" to do codegen.

jimbob45• 6 years ago

Wish they'd open the source and let the Rust community do this kind of stuff instead. No need to waste Windows development time on niche stuff.

steveklabnik8• 6 years ago

The article has a very prominent https://github.com/microsoft/winrt-rs in it, where you will find that this is MIT licensed.

snuxoll3• 6 years ago

Open what source? Everyone has access to the winmd files necessary, the COM ABI is documented - there’s been nothing stopping anyone from doing this.

All of the work MS has done on these bindings is MIT licensed as well.

contextfree7• 6 years ago

In fact there were third-party bindings already which I worked on: https://github.com/contextfree/winrt-rust

the new first-party ones look to be more complete and polished but this is mainly due to time and skill limitations on my part. :)

pie_flavor• 6 years ago

It's so open source, the developer of C++/WinRT didn't even work for Microsoft when he made it.

pcwalton• 6 years ago

The source is open, as already mentioned. But as for spending developer resources, I think having Microsoft work on things like this helps Rust and Windows alike. It helps Rust by lending a sense of official platform support to the language. And it helps Windows by encouraging Rust users to develop for the platform.

cs702• 6 years ago

You have to hand it to Microsoft: It may be the only large software company that doesn't seem susceptible to not-invented-here syndrome.

It's true that Microsoft historically has been an intensely competitive company, often trying to undermine competing technologies, e.g., with "embrace and extend" strategies.

But whenever a competing technology -- whether a language, or a framework, or an application -- gains adoption with developers or users, Microsoft to its credit will follow along, sooner or later, and do the work necessary for making it a first-class citizen on Windows.

(For those who don't know, Rust is originally a Mozilla project.)

nemothekid2• 6 years ago

It's in their blood - its the 'Embrace' in EEE.

acdha3• 6 years ago

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.

rhinoceraptor2• 6 years ago

I don't think they really have the power to extinguish anymore. Sure, Windows is still dominant in the desktop market, but that's not where the novel software is being written.

Amazon is the king of EEE these days. Microsoft is desperately trying to remain relevant.

weiming2• 6 years ago

TIL Rust is also sponsored by Amazon. (https://aws.amazon.com/blogs/opensource/aws-sponsorship-of-t...)

drej2• 6 years ago

As much as I appreciate what Microsoft is doing here, your NIH praise is not entirely well targeted - look at this research project from Microsoft, which aims to build a slightly different Rust. https://github.com/microsoft/verona

dtech• 6 years ago

How is a research proof of NIH? I guess C++ or Java should never have existed because how dare another programming language use that "OOP" concept Smalltalk popularized

munchbunny2• 6 years ago

From firsthand experience... Microsoft has quite a bit of NIH syndrome. Still does. They've just gotten better about it in recent years.

akiselev• 6 years ago

Also from firsthand experience: for many (not most) of MS's projects, that's the right decision. A lot of their software is at a unique intersection between consumer and enterprise support which at their scale often has unique requirements.

But then MS's bureaucracy can grind down even the most well thought out projects (Also getting better, though).

rhinoceraptor2• 6 years ago

One good example is Microsoft adding dtrace to Windows. The Linux community has floundered for years with several competing tracing tools, all of which have major deficiencies in one way or another.

ape4• 6 years ago

F# is Microsoft's invented here version of Java

munchbunny2• 6 years ago

I thought C# was Microsoft's NIH version of Java?

loeg4• 6 years ago

You mean C#? F# is an ML family language on the CLR.

James Gosling, who created the Java programming language in 1994, and Bill Joy, a co-founder of Sun Microsystems, the originator of Java, called C# an "imitation" of Java; Gosling further said that "[C# is] sort of Java with reliability, productivity and security deleted."

(Wikipedia)

tambourine_man• 6 years ago

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 is consumer first, so MacOS is getting harder and harder to hack on, for better and worse.

Chromebook was never a serious competitor. And Linux is Linux, hackable to a fault.

But Windows… which I have always despised, is, for the first time in my life, tantalizing… to some extent.

cheez2• 6 years ago

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.

Nullabillity• 6 years ago

It may be the only large software company that doesn't seem susceptible to not-invented-here syndrome.

.NET?

sidpatil• 6 years ago

.NET, ActiveX, JScript, etc.

whoisthemachine• 6 years ago

Many developers don't know that C# began in essence as a response to a lawsuit from Sun, sound familiar?

https://en.wikipedia.org/wiki/Visual_J%2B%2B#Sun's_litigatio...

_bxg12• 6 years ago

Right now they seem to have an enormous theme of winning over developers, of all kinds, for all platforms. I would say it's to sell them tools, but most of the recently-headlining MS tools have been free. Maybe it's just to garner general goodwill. Maybe it's to draw people to Azure. I can't quite see the strategy, but it's a very clear theme behind many of their recent (publicly-facing) efforts.

lumost• 6 years ago

MS has a huge legacy market, they don't want to end up as the next oracle where every dev relentlessly argues to move to a different platform.

Making tools/functionality free such that existing devs don't want to jump, and new devs consider azure is a reasonable business strategy.

dustinmoris• 6 years ago

that doesn't seem susceptible to not-invented-here syndrome

Really?

Compelte opposite from my experience, Microsoft is re-inventing their own version of literally everything, even the smallest thing which doesn't have any strategic benefits. That shows me that they suffer extremely from not-invented-here syndrome.

For example, why does Microsoft need to invent their own Redis cache alternative (=AppFabric)? Why does Microsoft need to invent "Windows containers" which are incompatible with Docker Linux containers (aka normal Docker)? Why do they need to keep re-inventing Internet Explorer? Why does Microsoft need to re-invent their own search engine which nobody uses (Bing in case you have never seen/heard of it)? Why does Microsoft need to invent their own inferior Slack after already nuking Skype, Skype for Business, Yammer, etc.? Why does Microsoft need to invent their own Azure DevPops inferior alternative to GitHub, especially when they already bought the better tool, why compete with it with a shit product which makes every developers blood boil?

afiori• 6 years ago

those are product offerings, it is like saying why are there new fast-food chains if McDonald's already exists.

specifically the alternative you list are commercial offerings from other companies, that is just wanting a piece of the cake.

and for example, "internet explorer" is now going to be based on chromium, a terrible news for the web, but definitely a invented-elsewhere case.

regarding Rust a not invented here situation would be trying to develop their own rustc/cargo or a new similar language, sort of like apple with swift (not saying this is what motivated apple)

alkonaut2• 6 years ago

Never really understood whether WinRT binds me to store apps, sandboxes, appx and so on.

Can I develop a single windows app with this that runs on Windows 10 desktop as a win32 app does (such as a plugin to another application where I can’t can’t decide the deployment model)?

pjmlp13• 6 years ago

The future of Win32 is also bound to sandboxing, although we are not yet there.

"How Windows 10X runs UWP and Win32 apps"

https://www.youtube.com/watch?v=ztrmrIlgbIc&list=PLWZJrkeLOr...

WinRT is an improvement of COM, it either runs sandboxed in UWP (its home), or you can access it from Win32 via XAML Islands and Win32/UWP interop.

Right now Win32 applications can still choose between legacy mode, or opt into Win32 sandoxing via MSIX packages.

As Windows 10X shows, it might not be for long.

Rusky4• 6 years ago

A lot of WinRT APIs are usable from "normal" desktop win32 apps, but some are restricted to the sandboxed/appx/etc model.

The most prominent of these is probably the XAML GUI stuff, but those are becoming available everywhere in the near future, and being decoupled from the OS itself, to go along with WinUI 3.0

sleepinseattle2• 6 years ago

The minesweeper example from the article is a regular Win32 app. Desktop Win32 apps can call WinRT API’s.

https://github.com/robmikh/minesweeper-rs/blob/master/src/ma...

contextfree7• 6 years ago

WinRT, as in the API/ABI shape, at this point really isn't tied to any aspect of the UWP app model (other than that existing UWP-related APIs tend to be newer and more likely to use it). Third-party WinRT component activation used to depend on app packaging but that dependency was removed last year: https://blogs.windows.com/windowsdeveloper/2019/04/30/enhanc...

In general what used to be various facets of the "monolithic" Win32 vs. UWP divide have been refactored to allow a la carte usage, so not only can you activate your WinRT components without a packaged app, but you can also register your app as "packaged" for runtime purposes without having to install in that format ( https://blogs.windows.com/windowsdeveloper/2019/10/29/identi... ), can install in the packaged format without having to use the sandbox features ( https://docs.microsoft.com/en-us/windows/msix/overview ) can distribute sandboxed apps outside the store ( https://docs.microsoft.com/en-us/windows/msix/app-installer/... ), etc.

The only remaining aspect I'm aware of where there's still a binary decision and coupling is in the windowing model and shell integration; a Win32 process's top-level windows can only be HWNDs and a UWP process's top-level windows can only be CoreWindows. Win32 HWNDs can host both Win32 and UWP UI, but UWP CoreWindows can only host UWP UI; on the other hand, only UWP CoreWindows can make use of UWP shell integration features like fullscreen and picture-in-picture. It would make sense to somehow decouple this facet as well but I'm not aware of any plans to do so.

captainmuon• 6 years ago

WinUI 3 is planned to have support for "Win32 app model" apps. I'm not sure if this is strictly "CoreWindow" or another class with different features, but you'll be able to write "native" UWP-Style apps in C++ and deploy them as an unrestricted .exe. They're going to show a demo at Build 2020, I heard.

alkonaut2• 6 years ago

Thanks this is informative. I think my confusion comes from that many things are introduced as walled-off vertical concepts but later backported at least partially. Also there is no lack of terminology confusion when things can be an API, an app-model or both.

I’m a full time windows desktop dev since 15 years now. And I still find these UI and app model frameworks extremely confusing (which is why I haven’t gone near one after WPF).

temac• 6 years ago

on the other hand, only UWP CoreWindows can make use of UWP shell integration features like fullscreen and picture-in-picture

What are the practical advantages of fullscreening / PIP'ing thanks to UWP as compared to what you can achieve without?

Kipters5• 6 years ago

It's a spectrum. You can already use (some) WinRT features on desktop/console win32 apps, even unsandboxed[0].

You can use UWP XAML in win32 desktop apps with a sandbox, and you'll probably be able to use it without a sandbox when WinUI 3 comes out (currently in early preview, they'll probably have a couple sessions about it at Build)

[0] some APIs require your app to have an identity though, and you need the sandbox for that

boromi• 6 years ago

Sorry for the naive question, but how does this fit into WinUI 3.0?

camccar2• 6 years ago

Yes

m-hilgendorf• 6 years ago

While we've been hacking on the vst3-sys crate [0], we wound up forking the mentioned com-rs crate to support COM APIs on non-win32 targets (notably, there's some stuff with endianness of the IIDs, the calling convention of the generated vtables) as well as usability (the com-rs crate only supports up to 5 interfaces implemented at once). We're still chasing down some issues with order mattering when implementing the interfaces. Even without those small changes, it's an impressive piece of macro programming that is very close to being usable for general purpose, ABI-stable rust crates.

As a little dose of irony, clippy doesn't like the com-rs crate too much.

[0] https://github.com/RustAudio/vst3-sys.git

ridiculous_fish4• 6 years ago

How does this projection work with the borrow checker? UI frameworks typically allow you to have multiple mutable reference to the same element.

Rusky4• 6 years ago

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.

ridiculous_fish4• 6 years ago

Is the projection literally "wrapped raw pointers?" How are the raw pointers wrapped - for example is there interop between COM reference counting and Rust Arc? Or something else?

Here's a classic trap: you get a reference to something interior, and then the parent is deallocated. My event handler gets a ref to this button's label and then replaces the button. Is this possible with Rust/WinRT? (No judgement either way!)

jhoechtl• 6 years ago

Would this be possible for Go too?

favorited2• 6 years ago

It is possible for any language, really. They already have 3 language projections for C++ (C++/WinRT being the newest, by the same person running this Rust projection), C#, VB, and JavaScript.

Under the hood they call out to (and potentially expose) COM interfaces which are C. So if your language has C interop, or if it could be added, something like this could be built.

camccar2• 6 years ago

C interop is slow in golang so I don’t think it would be the best language for it. People do it with SDL though

brian_herman__• 6 years ago

This is so cool. I should brush up on my rust maybe I should make a python extension or something...

znpy• 6 years ago

I want to reply to many other comments but I want to make this more visible: Microsoft does not do Embrace-Extend-Extinguish anymore today (or at least, it does a lot lot less).

You know who does Embrace-Extend-Extinguish? Google.

adzm• 6 years ago

With Windows 7 on its way out slowly, WinRT is becoming more palatable.

loeg4• 6 years ago

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.

ploxiln• 6 years ago

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

badsectoracula4• 6 years ago

Slowly?! Hasn't Win7 been dead for years?

No. Microsoft wants to kill it, but... even just checking Steam's hardware survey (users of which are more likely to upgrade so chances are overall PC usage of Win7 is higher) there is a combined ~7% of users on Win7.

With ~25M concurrent users the last 48 hours, that means there were more than 1.7M users running on Win7 just within the last two days.

FWIW these numbers are a bit lower than 10 times the Linux numbers of all distros combined.

mwcampbell• 6 years ago

Looks like async/await support isn't ready yet. I wonder how challenging it will be to integrate WinRT's async model with Rust's futures and tasks.

ComputerGuru• 6 years ago

IAsyncOperation is pretty flexible. I don’t think it will be technically hard, though perhaps picking the best fit model will be a time consuming process.

optimiz32• 6 years ago

Coding 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.

hyperrail• 6 years ago

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.

optimiz32• 6 years ago

Updated my post - I had forgotten C++/WinRT discarded the ^ syntax as we skipped C++/WinRT for our development as it suffers from many of the same problems of C++/CX.

projektfu• 6 years ago

I think C++/WinRT is more of a "modern C++" projection than C++/CX, and they aren't an also-known-as, although they meet similar goals. For example, with the ^ reference:

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a...

pjmlp13• 6 years ago

Just like Qt depends on moc.

GCC and clang are also full of language extensions.

In fact if it wasn't for the work of Google, to this day Linux would only be compilable with GCC C.

I remember C devs on Apple platforms being happy for their lambdas extensions when they were introduced.

So I never understand why everyone else is allowed to create language extensions, but when Microsoft does it is bad.

wicket• 6 years ago

Well this really confused me as I thought Microsoft had discontinued the Windows RT operating system. It turns out that they also have a platform-agnostic application architecture, ingeniously named WinRT.

Ericson23143• 6 years ago

https://github.com/retep998/winapi-rs they should work with this

steveklabnik8• 6 years ago

These are two different APIs, so it's not clear to me how they would.

Ericson23143• 6 years ago

I thought there was much overlap

zeroc82• 6 years ago

As a former MFC/Winforms/WPF/Qt now turned Angular developer, this is really sparking my interest. I would love to back to writing great desktop applications. Problem is, most of my projects nowadays require a multiplatform GUI. Desktop is not enough, we also need web and mobile.

Rust/WinRT Public Preview

Related Stories