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

141–150 of 219 posts

Re: Rust/WinRT Public Preview

#141

Post by ridiculous_fish »

Rusky wrote: post #112
ridiculous_fish wrote: post #57

How 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, s…

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

Re: Rust/WinRT Public Preview

#142

Post by roblabla »

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

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` with no synchronization of the inner data. This makes mutable collections very complicated to model, for instance.

Re: Rust/WinRT Public Preview

#143

Post by oaiey »

hota_mazi wrote: post #17
oaiey wrote: post #5

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.

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.

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.

Re: Rust/WinRT Public Preview

#144

Post by wongarsu »

VWWHFSfQ wrote: post #138
pathartl wrote: post #38

Earlier quoted context omitted.

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…

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.

Windows NT used to have a POSIX subsystem [1] that applications could use instead of the Win32 subsystem. So the Windows NT kernel is designed with the option of POSIX compatibility. Arguably the Subsystem for Linux is the current successor of the POSIX subsystem, providing POSIX compatible access to the kernel along with a POSIX compatible shell and UNIX commands.

Obviously the Win32 subsystem isn't POSIX compatible, but I'm not sure why we would want that.

1: https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

Re: Rust/WinRT Public Preview

#145

Post by jupp0r »

pianoben wrote: post #84
pathartl wrote: post #38

Earlier quoted context omitted.

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…

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?

Windows itself has never been the problem, but the Software that’s running on it.

Re: Rust/WinRT Public Preview

#146

Post by zrm »

loeg wrote: post #94
pianoben wrote: post #84

Earlier quoted context omitted.

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?

Windows NT in 2000? I guess ARM was not a going concern at the time, but Windows was remarkably portable in 2000 before the dark decade of more or less exclusively Wintel.

https://archive.org/details/Microsoft_Windows_NT_Server_Vers...

"Disc contains code to run on Windows NT-compatible x86, Pentium, MIPS, R4x00, Alpha, PowerPC and Pentium Pro systems"

Re: Rust/WinRT Public Preview

#147

Post by magicalhippo »

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.

> To this day, I still don't really understand what COM is

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

Re: Rust/WinRT Public Preview

#148

Post by mycall »

Ididntdothis wrote: post #34
recursive wrote: post #24

Earlier quoted context omitted.

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

Is these problems fixed with AOT C# (CoreRT)?

Re: Rust/WinRT Public Preview

#149

Post by pie_flavor »

snuxoll wrote: post #14
jimbob45 wrote: post #10

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.

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.

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

Re: Rust/WinRT Public Preview

#150

Post by dstaley »

Kipters wrote: post #133
dstaley wrote: post #2

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

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

This is neither an official language projection nor for React Native.
Post reply on HN