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

171–180 of 219 posts

Re: Rust/WinRT Public Preview

#171

Post by kevingadd »

badsectoracula wrote: post #136
hota_mazi wrote: post #17

Earlier quoted context omitted.

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.

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.

The type libraries are a big part of why it's so successful - you can take a typelib and auto-generate bindings, or manually generate your own bindings based on what you see. If you look at the typelibs for a given GUID, you are almost guaranteed that the API will match once you get a pointer back from a QueryInterface call (sometimes people are naughty). This is nice because you can compile all that in so the QueryInterface call is the only dynamic part of it - everything else at runtime is just regular calls through a vtable. The rigid nature of it means you can also reverse-engineer compiled code to figure out the shape of a given interface's vtable even without a typelib (I've done that a couple times).

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.

Re: Rust/WinRT Public Preview

#172

Post by GordonS »

pathartl wrote: post #38
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…

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.

Re: Rust/WinRT Public Preview

#173

Post by fluffything »

pjmlp wrote: post #166
peatmoss wrote: post #151

Earlier quoted context omitted.

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

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…

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

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.

Re: Rust/WinRT Public Preview

#174

Post by Kipters »

dstaley wrote: post #150
Kipters wrote: post #133

Earlier quoted context omitted.

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

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

It's not official, but it was endorsed by MSFT on stage at last build. You're right about RN, I did not realize that.

Re: Rust/WinRT Public Preview

#175

Post by masklinn »

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…

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

Re: Rust/WinRT Public Preview

#176

Post by noch »

peatmoss wrote: post #151
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…

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

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

Re: Rust/WinRT Public Preview

#177

Post by pornel »

ridiculous_fish wrote: post #141
Rusky wrote: post #112

Earlier quoted context omitted.

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

Rust's borrow checker solves the problem of "get a reference to something interior, and the parent is deallocated". It knows (by static analysis) when an inner reference may be in use, and won't let the program compile if the parent could deallocate during that time.

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.

Re: Rust/WinRT Public Preview

#178

Post by DeathArrow »

pathartl wrote: post #38
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…

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.

Re: Rust/WinRT Public Preview

#179

Post by DeathArrow »

jacobush wrote: post #154
wongarsu wrote: post #144

Earlier quoted context omitted.

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…

That subsystem was just so they could tick off the “POSIX” box for Department of Defence.

People forgot that Microsoft was one of the biggest UNIX vendors with Xenix and for a long time, Microsoft had the highest-volume AT&T Unix license.

Re: Rust/WinRT Public Preview

#180

Post by DeathArrow »

jacobush wrote: post #170
pjmlp wrote: post #167

Earlier quoted context omitted.

That was one of many, then came SFU, followed by SUA. 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.

Yeah, that may be true, but on the other hand, had they made it useable, portabilith with other Unix would have been a simpler option. Simpler than Win32 + Unix portability in any case. Or in some cases, software would have been ported to Win32 at all.

>Yeah, that may be true, but on the other hand, had they made it useable, portabilith with other Unix would have been a simpler option.

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.

Post reply on HN