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

181–190 of 219 posts

Re: Rust/WinRT Public Preview

#181

Post by pjmlp »

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.

What UNIX portability?

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.

Re: Rust/WinRT Public Preview

#182

Post by DeathArrow »

dmitriid wrote: post #169
VWWHFSfQ wrote: post #138

Earlier quoted context omitted.

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.

In reality, there are very very few people who care about POSIX compatibility. Because there are no POSIX-compatible systems in the wild. 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…

I am beginning to think that while POSIX, Unix and X11 might have been innovative and very useful in the '70s and ' 80s, now they are really old and most of the computing landscape changed.

We need better operating systems metaphors.

Re: Rust/WinRT Public Preview

#183

Post by DeathArrow »

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.

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.

Re: Rust/WinRT Public Preview

#184

Post by badsectoracula »

kevingadd wrote: post #171
badsectoracula wrote: post #136

Earlier quoted context omitted.

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

I wouldn't call it successful, COM is mainly used by Microsoft and pretty much nobody else uses it unless they want to interface with Microsoft's products (Office, etc).

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.

Re: Rust/WinRT Public Preview

#185

Post by lukeh »

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…

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

Re: Rust/WinRT Public Preview

#186

Post by lukeh »

tonyedgecombe wrote: post #52
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.

Nothing like that remotely exists on Linux or macOS. https://developer.apple.com/library/archive/documentation/Co...

The COM support in CoreFoundation (such as it is) is... unusual. I have actually used it but it doesn't give you much from memory, beyond a way to locate plugins by UUID and the IUnknown ABI layout.

Re: Rust/WinRT Public Preview

#187

Post by steveklabnik »

masklinn wrote: post #175
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...

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

Re: Rust/WinRT Public Preview

#188

Post by masklinn »

steveklabnik wrote: post #187
masklinn wrote: post #175

Earlier quoted context omitted.

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

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

Seems sensible though, the build.rs solution would require every project using rust/winrt to have a build.rs and code to load & codegen the modules (probably copy/pasted), so it'd be a lot more work for users of rust/winrt, though I guess it'd be less magic.

Re: Rust/WinRT Public Preview

#189

Post by mister_hn »

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…

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

Re: Rust/WinRT Public Preview

#190

Post by steveklabnik »

masklinn wrote: post #188
steveklabnik wrote: post #187

Earlier quoted context omitted.

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

Seems sensible though, the build.rs solution would require every project using rust/winrt to have a build.rs and code to load & codegen the modules (probably copy/pasted), so it'd be a lot more work for users of rust/winrt, though I guess it'd be less magic.

Oh yeah, I agree. I’m really interested to see if this approach would work better than build.rs for some other projects too.
Post reply on HN