Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust/WinRT Public Preview

blogs.windows.com

Post reply on HN
Print view View original

31–40 of 219 posts

Re: Rust/WinRT Public Preview

#31

Post by weiming »

cs702 wrote: post #15

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 adopti…

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

Re: Rust/WinRT Public Preview

#32

Post by Klonoar »

weiming wrote: post #4

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

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.

Re: Rust/WinRT Public Preview

#33

Post by contextfree »

alkonaut wrote: post #18

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)?

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.

Re: Rust/WinRT Public Preview

#34

Post by Ididntdothis »

recursive wrote: post #24
hota_mazi wrote: post #20

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

there is a big difference between out of process COM (like Office Automation) and in process COM (like WinRT and UWP or DirectX). Out of process was always a little tricky and not implemented well. DCOM was even worse. In process COM works really well.

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.

Re: Rust/WinRT Public Preview

#35

Post by captainmuon »

contextfree wrote: post #33
alkonaut wrote: post #18

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)?

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 "monol…

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.

Re: Rust/WinRT Public Preview

#36

Post by codys »

pjmlp wrote: post #25
xrd wrote: post #6

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

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…

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

Re: Rust/WinRT Public Preview

#37

Post by contextfree »

captainmuon wrote: post #35
contextfree wrote: post #33

Earlier quoted context omitted.

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 "monol…

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.

My understanding is the WinUI 3 Win32 model is still going to be basically doing what you can already do with XAML Islands, just packaged more nicely with wrapper classes and Visual Studio templates and so on, so by itself it doesn't change the underlying HWND vs. CoreWindow situation (just wraps it). There are already Win32 apps, like Windows Terminal, that implement a "UWP" UI by doing their entire UI in one big XAML Island.

Re: Rust/WinRT Public Preview

#38

Post by pathartl »

blinkingled wrote: post #7

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_cas…

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.

Re: Rust/WinRT Public Preview

#39

Post by 29athrowaway »

cs702 wrote: post #15

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 adopti…

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.

Now take a look at LLVM, that's a better example of collaboration.

Re: Rust/WinRT Public Preview

#40

Post by alkonaut »

contextfree wrote: post #33
alkonaut wrote: post #18

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)?

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 "monol…

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

Post reply on HN