Rust/WinRT Public Preview
blogs.windows.com
blogs.windows.com
> 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.
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.
"Disc contains code to run on Windows NT-compatible x86, Pentium, MIPS, R4x00, Alpha, PowerPC and Pentium Pro systems"
Obviously the Win32 subsystem isn't POSIX compatible, but I'm not sure why we would want that.
GNU/Linux users should be happy that old Microsoft didn't bother to do that much with POSIX subsystem.
Had they actually invested into keeping it up to date, and many of us on PC land would never bothered with FOSS UNIX clones.
Simpler than Win32 + Unix portability in any case. Or in some cases, software would have been ported to Win32 at all.
That's not necessarily the case. See macOS which is using different GUI libraries, Metal instead of Vulkan etc.
So you can't recompile macOS apps to use them on Linux.
Back when I was in the university, and Linux kernel was still at 1.0, I had the pleasure to write C and C++ code across Xenix, DG/UX, Aix, HP-UX, Solaris, BSD and naturally Linux also.
There is POSIX, there is what each OS actually do for the implementation defined behaviours, then the whole set of APIs that made each UNIX variant unique and were the selling point of the UNIX clone to start with.
Autoconf and friends did not start out of masochism.
POSIX-certified systems conform to different POSIX standards. And most of them are of no use to the average developer such as AIX, HP-UX, Solaris.
The rest are largely compatible which means they are not compatible. And yes, that includes every single one of Linux distributions and FreeBSD.
We need better operating systems metaphors.
Seeing what was coming with cloud and making .NET cross-platform was very well timed.
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.
I remember VB6 was also exceptionally good at this.
.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.
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?
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.
Do you know many people that used to do this with macOS and are now using Windows ?
Like, oh boy, I tried, but after 4 months I ended up back with macOS.
So I've seen Mac users who work in these areas get sick of the issues and limitations and switch to Win 10 + sometimes WSL.
The people remaining with Macs are executive suite (who go for iPad pros) and account execs who do sales where it looks cool to go pull out a Mac. However even there people are increasingly looking dumb when they want to present something and go on 5 min dongle troubleshooting hunt because Mac killed HDMI and VGA ports and start their presentation appearing incompetent. Sometimes over web screen shares, only the desktop shows and not the applications.
By refusing to focus on hardware/software quality and power users, Apple has lost the game on high end.
This is what I do and works perfectly. My dev machines are 82 cores xeon platinums with Terabytes of RAM or nodes with 8 V100 GPUs attached, etc.
I don't know of any workstation, much less laptop, that could be a replacement for any of that.
For the stuff I do on the laptop itself (Word/Powerpoint/Outlook, web browsing, using an editor to edit files remotely, etc.), more power wouldn't hurt, but my macbook is a macbook air 2013... so I can't imagine that a 2020 macbook would be underpowered.
For example, take high DPI. You have two primary competing toolkits between GTK/QT. It took a while but QT/KDE finally added HiDPI. Great, so I could get Hi-DPI setup on KDE! Then I open Firefox and it all falls apart because GTK. Extrapolate to any other number of issues. Unfortunately, Windows 10 isn't much better wrt to HiDPI (at least a couple years back when I last used it). I think there are more different UI toolkits on Windows than Linux has. Counterpoint: MacOS has one global toolkit with message passing based objects, it was almost trivial for Apple to add HiDPI and then dark modes. GNUStep/ObjectiveC would've provided similar basis on Linux, but it never took off. Now macOS is slowly loosing cohesion, instead of ObjectiveC 3.0, they made Swift which from my perspective appears to only be good at adding bugs to the terminal app while trying to avoiding message passing (no more user hot-loadable, un-sactioned third party plugins for any program on macOS :/ ).
At this point, I vaguely dream that HaikuOS will take off or someone makes a WebOS DE for Linux that has a complete suite of tools... but like peatmoss, I'd settle for a Rust/winRT on Linux.
One thing I’ve also thought is that if Linux had managed a first-class GNUStep environment with a compelling alternative to macOS in terms of dev tooling, it could have been great leverage in terms of keeping Apple focused on the core developer experience in macOS.
Rather, individual distributions of Linux are Operating Systems. As are the other Unices, e.g. the BSDs, Solaris/Illumos, all the old ones like IRIX, etc. And all of those, at first, built their own Desktop Environment from the ground up, just like Windows and macOS did.
As it happens, through the power of FOSS, many of these Desktop Environment projects were gradually merged, or the various distributions dropped their own DE in favor of someone else's.
But the historical path-dependence is still there, and the political lines are still mostly clear.
Don't think of KDE as "a Linux Desktop Environment." It's both not just for Linux (you can run it on FreeBSD, too!) and also isn't available for every Linux distro. KDE is still fundamentally, in some sense, "SUSE's Desktop Environment."
Same with GNOME: it might have been created by GNU, but it was mostly funded by RedHat and IBM for many years, even if Debian et al eventually picked it up as well.
Same with CDE: that's HP's desktop environment.
If you think of each of these companies as providing their own Operating System with a GUI composed solely of the graphical applications written for their own DE, the continued non-merging of these DEs makes a lot more sense. There's no more reason for them to merge with each-other than for them to merge with e.g. Android. (These OSes all happen to be based on Linux, but that doesn't really mean anything. macOS is based on BSD; should the macOS DE therefore merge with some DE that runs on BSD?)
† Defining "Operating System" here as "a software ecosystem that tries to deliver a cohesive user experience to the people who deploy it."
---
The thing that makes POSIX DEs different from the ones on Windows and macOS, is that you can install multiple DEs' libraries, and then run applications from one DE "under" another DE.
Except for special one-off internal provisions for their own legacy DEs (Carbon; WoW) you can't run software written for another DE "directly" on Windows or macOS. You can only virtualize such software using e.g. Wine, or an X11 server that runs as a window under your DE.
But the fact that Linux can do this, doesn't mean that the software was designed with this in mind. There's no "Linux integrated GUI experience" that all these applications are trying to target (FreeDesktop is forum for "meet in the middle" consensus solutions to be generated when required, not a working group for creating an encompassing standard for everyone to converge toward.) There's just the individual Operating Systems' GUI experiences (plural), where a given GUI app will fit in with the OS it was written for—and maybe with any other OS that happens to share its DE as the primary DE that the system is cohered around.
tl;dr: there is no "Linux." There's just RedHat, Debian, Canonical, openSUSE, Slackware, etc. all with their own goals. And also FreeBSD, NetBSD, Illumos, and whatever wacky proprietary Unices are still in play, who all also run and support these same DEs on very different substrates, with their own even-more-different goals. Each corporate player delivers you their own experience. There's no intent, between these companies, to try to commodify that experience into the same experience. Where would these companies/projects be, if they did?
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.
Indeed. https://media.ccc.de/v/ASG2018-174-2018_desktop_linux_platfo...
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...
So, neither cargo nor the compiler really know of the paths, and cannot accordingly rebuild the sources when they change.
Perhaps they can only change when a corresponding version cargo does know about changes, anyhow, bypassing the build/module system with a proc macro is probably not something to be done lightly.
I was totally forgetting rerun-if-changed! This is indeed a barrier in the general case. I think that it doesn't affect this crate, but I am not 100% sure. Regardless, thank you!
Glad to see Rust is now one more such language.
After all it isn't like you can't use the Win32 API directly from Rust - or any other language, e.g. Python.
This is why you were able to manipulate COM objects from VBScript and JScript even though they were dynamic languages, and in fact VBScript could define new COM objects on the fly and then expose new methods and properties through a COM interface called IDispatch. It's all just vtables once you do your initial setup.
IIRC there was a Windows version of Python for a while that had built-in support for COM interop in both directions - you could define IDispatch-based COM objects in Python and implement interfaces while consuming COM libraries using their typelibs.
In any case, yes, this is what i meant with the dynamic part. But the comment i replied to wrote that it made "possible to write applications on Windows and integrate with pretty much anything in it in any language with COM bindings", which - as i wrote - doesn't need COM.
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.
As a little dose of irony, clippy doesn't like the com-rs crate too much.
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.
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)?
"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.
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
https://github.com/robmikh/minesweeper-rs/blob/master/src/ma...
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.
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).
What are the practical advantages of fullscreening / PIP'ing thanks to UWP as compared to what you can achieve without?
I think fullscreening also has some gestures the Shell manages, but I'm not as familiar with them. Similar too that the Shell does very different things in 3D.
There's also the Dual Screen support in CoreWindow that Microsoft has been talking up for Windows "10X".
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
You know who does Embrace-Extend-Extinguish? Google.
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.
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.
The whole point of C++/WinRT is to be 100% standards-compliant C++. The guy who created it didn't even work at Microsoft at the time.
https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a...
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.
Hopefully they will do the same with the new version.
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.)
https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_...
He was CEO of Microsoft until 2014, that is, 6 years ago.
Microsoft changed strategies because they tried everything they possible could to counter open source and Linux and lost. Now they are forced to play nice.
Being forced to be nice is not the same as being nice out of altruism.
If at any moment becoming jerks gives them more shareholder value they will become jerks again.
They have a 1.36 trillion USD Market cap (today). That's more than Apple's 1.29 trillion USD Market cap. It's hilarious how people on hacker news live in this bubble where Microsoft has faded away into irrelevance.
And they're also very good. I'm running Windows 10 right now on a dual-monitor, dual NVidia GPU, dual Xeon system and everything "just works."
Not exactly thanks to Microsoft.
You can use Nvidia GPUs in SLI mode in Linux and BSD too. I am using an Nvidia GPU right now and I am not using Windows, and "everything just works" too, no terminals involved. Are you implying that it's not possible to do this outside Windows?
How much of that market capitalization comes from running a de-facto monopoly of office suites for decades? As a consumer, it's hard to see how corporations like Microsoft push governments around the world to buy licenses in bulk because there are no alternatives.
What has changed is that MSDN is no longer delivered on CDs.
That's because "Open Source" is a much cheaper deliver mechanism if you control the platforms that make its freedoms meaningless.
Plus ça change...
You left out the part where you explained why any of those acquisitions are a problem: LinkedIn is no worse than it was before, GitHub and npm are both popular services people choose to use without coercion, and whether or not you like it a lot of developers are switching to VSCode because it's a better tool which makes them more productive.
I don't what you believe to be true about their Azure integration but I know many people who use GitHub, npm, VSC, etc. and none of them use Azure so clearly there's some key step missing in that process.
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.
since Microsoft is still a platform business, it's reasonable to be wary of the negative potential of embrace/extend in connection with them, for the same reason it is in connection with Google and others.
It can be a bit fuzzy defining precisely where that benign sense stops and the negative sense where the "differentiation" brings harmful lockin begins. Then if you have a monopoly position the "extinguish" bit can come in. But actually AFAICT Microsoft rarely (never?) actually succeeded in extinguishing any of the open standards they were infamous for attacking - their successes happened earlier against proprietary competitors like Lotus 1/2/3 and Novell Netware
SMB pretty well extinguished the use of NFS; and Active Directory pretty well extinguished the use of LDAP.
Neither of these were really Microsoft-driven, though. It was almost the reverse: the ecosystem cloned Microsoft's approach into FOSS, and then liked it better, and replaced their own stuff with it without Microsoft's participation. Sort of like how BitKeeper's approach was cloned as git, which then extinguished most other SCMs.
this stuff also happens in a benign fashion. Emergent behavior. People/groups and their interests bubble up the self-serving outcomes without being a conspiracy.
We have 4 features to support in this release. feature 1 is p0 it is basic functionality. feature 2 is p0 because 3 customers are asking for it. feature 3 is p0 because our team needs it to work with our other product. feature 4 is compatibility and we'll get to that as p1.
That's why products get telemetry and linkedin integration, but not compatibility with other software.
They may have stopped the "Extend & Extinguish" part, but they haven't forgotten how to Embrace.
Amazon is the king of EEE these days. Microsoft is desperately trying to remain relevant.
Not saying anything about anything else.
But then MS's bureaucracy can grind down even the most well thought out projects (Also getting better, though).
Although they weren't allowed to do that if I remember right, so they basically had to create C# - and C# turned out to be fantastic in my opinion.
> 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)
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.
.NET?
https://en.wikipedia.org/wiki/Visual_J%2B%2B#Sun's_litigatio...
Making tools/functionality free such that existing devs don't want to jump, and new devs consider azure is a reasonable business strategy.
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?
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)
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.
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.
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!)
This works well even with externally refcounted objects. You can give reference to an inner object without increasing its refcount, and rely on the borrow checker not to allow the parent to decrease the refcount. Or you bump the refcount of the inner object and give it out as an independently owned object.
Those `ComPtr`s are then wrapped in convenience types that handle method dispatch, via code generated here: https://github.com/microsoft/winrt-rs/blob/master/crates/win...
There is no integration with Rust Arc, but that's just because in COM/WinRT each object is in charge of its own allocation and ref-counting- AddRef and Release are just methods of IUnknown, the root of the interface hierarchy.
That particular trap doesn't really come up in COM/WinRT- COM objects only expose methods that pass around references to full objects. This is because a given object might exist in another process or even on another machine, in which case you are only holding a proxy created by the runtime.
So any references held by your event handler, to the button or its label, are ref-counted (though they may be weak references), and replacing an object is fine because it just decrements its refcount.
In the general case (e.g. implementing an interface yourself, or some other non-COM-based scenario), pornel's sibling comment is correct- just like with Rust's own Rc/Arc types, you can borrow from some particular ref-counted pointer and the compiler will ensure that it outlives those borrows, keeping the object alive.
Application::Current.OnActivated = move |args| stuff();
fn stuff() { Application::Current.OnActivated = None; }
Instead you need to convert the lambda (from whatever language) into the type of that property- in this case some kind of Delegate, at which point it is ref-counted like any other COM object.
So in this case, installing the handler increments the refcount, reading the handler back out to invoke it increments it again, the handler itself decrements it, and finally whoever invoked it drops their reference and the Delegate gets freed.
> 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.
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...
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.
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).
Disclosure: I work on the Windows team
Native would have chased the declining native GUI market.
If Delphi never managed much on the server side, it has more to do with the downfall from Borland than anything else.
So ASP + COM would be ASP.NET with COM+ Runtime instead.
It needed to be an open source cross-platform compiler to be truly viable in the Linux ecosystem, and Linux would be needed to compete with Windows and its licensing fees. Anything other than C# is always a step or two behind on .NET, and .NET was the best route to web apps on Windows.
The only reason AOT is coming back for web apps is FaaS, IMO. FaaS works best with minimal boot-up latency, and FaaS delivers operationally as a way to scale out stateless compute on demand, which optimally means acquiring those compute resources just for the duration of a request or job, and no longer.
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.
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.
Edit: I should add that C# isn’t the best language for COM because it doesn’t release objects when they go out of scope so you either have to release everything manually or wait for the GC to kick in which can cause memory problems. VB and C++ and even PHP are better that way.
I thought COM was meant to communicate between processes?
Any enlightenment is appreciated...
Maybe some excerpts from the documentation[1]:
"COM specifies an object model and programming requirements that enable COM objects (also called COM components, or sometimes simply objects) to interact with other objects. These objects can be within a single process, in other processes, and can even be on remote computers. They can be written in different languages, and they may be structurally quite dissimilar, which is why COM is referred to as a binary standard; a standard that applies after a program has been translated to binary machine code."
"The only language requirement for COM is that code is generated in a language that can create structures of pointers and, either explicitly or implicitly, call functions through pointers."
"Besides specifying the basic binary object standard, COM defines certain basic interfaces that provide functions common to all COM-based technologies, and it provides a small number of functions that all components require."
[1]: https://docs.microsoft.com/en-us/windows/win32/com/the-compo...
https://developer.apple.com/library/archive/documentation/Co...
All operating systems have some sort of object model and sharing API's, but neither macOS nor Linux have anywhere near the thriving ecosystem and actual cooperation model between applications that Windows has.
Rather unfortunate, because with GIR you could easily have a program written in a mix of Rust, C, Go, C++, Vala, etc. all playing nicely if they were all able to expose to the common object model.
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.
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.
As for COM, yes there are multiple models, in-process, external process and across the network (with DCOM).
GObject and KParts would be the in-process variant, with D-BUS for the other execution models.
https://fuchsia.googlesource.com/docs/+/ea2fce2874556205204d...
All of the work MS has done on these bindings is MIT licensed as well.
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. :)