[HN Gopher] Rust/WinRT Public Preview
___________________________________________________________________
Rust/WinRT Public Preview
Author : steveklabnik
Score : 366 points
Date : 2020-04-30 17:27 UTC (5 hours ago)
(HTM) web link (blogs.windows.com)
(TXT) w3m dump (blogs.windows.com)
| adzm wrote:
| With Windows 7 on its way out slowly, WinRT is becoming more
| palatable.
| loeg wrote:
| Slowly?! Hasn't Win7 been dead for years?
|
| > 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.
| jimbob45 wrote:
| 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.
| steveklabnik wrote:
| The article has a very prominent
| https://github.com/microsoft/winrt-rs in it, where you will
| find that this is MIT licensed.
| snuxoll wrote:
| 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.
| contextfree wrote:
| In fact there were third-party bindings already which I
| worked on: https://github.com/contextfree/winrt-rust
|
| 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. :)
| pcwalton wrote:
| The source is open, as already mentioned. But as for spending
| developer resources, I think having Microsoft work on things
| like this helps Rust and Windows alike. It helps Rust by
| lending a sense of official platform support to the language.
| And it helps Windows by encouraging Rust users to develop for
| the platform.
| mwcampbell wrote:
| Looks like async/await support isn't ready yet. I wonder how
| challenging it will be to integrate WinRT's async model with
| Rust's futures and tasks.
| znpy wrote:
| I want to reply to many other comments but I want to make this
| more visible: Microsoft does not do Embrace-Extend-Extinguish
| anymore today (or at least, it does a lot lot less).
|
| You know who does Embrace-Extend-Extinguish? Google.
| ridiculous_fish wrote:
| How does this projection work with the borrow checker? UI
| frameworks typically allow you to have multiple mutable reference
| to the same element.
| Rusky wrote:
| 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, 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.
| jhoechtl wrote:
| Would this be possible for Go too?
| favorited wrote:
| It is possible for any language, really. They already have 3
| language projections for C++ (C++/WinRT being the newest, by
| the same person running this Rust projection), C#, VB, and
| JavaScript.
|
| 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.
| camccar wrote:
| C interop is slow in golang so I don't think it would be the
| best language for it. People do it with SDL though
| brian_herman__ wrote:
| This is so cool. I should brush up on my rust maybe I should make
| a python extension or something...
| boromi wrote:
| Sorry for the naive question, but how does this fit into WinUI
| 3.0?
| camccar wrote:
| Yes
| xrd wrote:
| 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
| hota_mazi wrote:
| 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.
| recursive wrote:
| 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.
| Ididntdothis wrote:
| 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.
| jfkebwjsbx wrote:
| What is the point of "In process COM"? Is the same as any
| other library?
|
| I thought COM was meant to communicate between processes?
|
| Any enlightenment is appreciated...
| Ididntdothis wrote:
| COM is Common Object Model. What you mean is OLE. In
| process COM calls are basically direct DLL calls and
| therefore very fast.
| snuxoll wrote:
| COM is primarily used in-process, it exposes an ABI that
| allows multiple languages to operate on a common object
| model within the same process. That's why you can import
| COM controls into a .Net application by referencing the
| DLL in your project and work with them as if they were
| native CLR objects - or Python, Ruby, Perl, etc. for that
| matter.
| winter_blue wrote:
| COM brings back a lot of fantastic old memories.
|
| 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.
| tonyedgecombe wrote:
| _Nothing like that remotely exists on Linux or macOS._
|
| https://developer.apple.com/library/archive/documentation/Co.
| ..
| hota_mazi wrote:
| There have been plenty of _attempts_ to emulate what COM
| does.
|
| 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.
| winter_blue wrote:
| Yea, this is so true. It would be amazing if some
| standard similar to COM could unify the Linux community.
| snuxoll wrote:
| GObject gets us some of the way, but the ABI and bindings
| for other languages make it a royal pain in the ass to
| _export_ types from anything but C rather than just
| consuming them.
|
| 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.
| dralley wrote:
| GObject is somewhat similar but it's nowhere close to first-
| class (being a Gtk specific tech)
| oaiey wrote:
| Windows UI and Framework beyond Win32 is solidly based on COM.
| Win 10 works for many years now with a deployment close to a
| billion. I would say: works.
| alxmdev wrote:
| "Under the hood" makes it sound like you wouldn't deal with any
| COM stuff yourself, it's just how the different languages' APIs
| were implemented to interface with the OS runtime.
| pjmlp wrote:
| 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 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.
| amaranth wrote:
| I think the most similar thing to WinRT on Linux would be
| GObject Introspection since the main point appears to be a
| way to somewhat automatically surface the platform API in
| multiple languages using language-specific idioms. D-Bus is
| instead for RPC and events, which I guess COM also gets used
| for?
| KeBugCheckEx wrote:
| Historical note: first versions of .NET were called "COM+
| 3.0".
| codys wrote:
| For linux I believe you mean D-Bus instead of DCOP. (that
| said, it's largely similar in concept)
| pjmlp wrote:
| You are right, that was the old protocol.
| Koshkin wrote:
| That's what they called "going native" (vs. using .NET).
| discreteevent wrote:
| I don't think the basic architecture is going to go away. Even
| some of the newest operating systems have something quite
| similar:
|
| https://fuchsia.googlesource.com/docs/+/ea2fce2874556205204d...
| sleepinseattle wrote:
| It's not that different from things like Protocol Buffers, and
| for application code it's mostly a hidden implementation
| detail. The API you're calling (like the Composition API's in
| the Minesweeper example) might be calling into a separate
| process but you don't have to care.
|
| Disclosure: I work on the Windows team
| blinkingled wrote:
| Trouble is you can't really the solve the problem Microsoft had
| without using something like COM. Good news is you don't have
| to care - you can use C# or Rust and not worry about COM.
| pjmlp wrote:
| Somehow I think .NET would have been much better had it
| started as something like .NET Native, but yeah cannot turn
| back in time.
| barrkel wrote:
| It would have been no good for web application servers,
| which is where the competition was going.
|
| Native would have chased the declining native GUI market.
| pjmlp wrote:
| Sure it would, after all that is where backend
| development is going to, back to AOT compilation
| toolchains.
|
| 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.
| m-hilgendorf wrote:
| While we've been hacking on the vst3-sys crate [0], we wound up
| forking the mentioned com-rs crate to support COM APIs on non-
| win32 targets (notably, there's some stuff with endianness of the
| IIDs, the calling convention of the generated vtables) as well as
| usability (the com-rs crate only supports up to 5 interfaces
| implemented at once). We're still chasing down some issues with
| order mattering when implementing the interfaces. Even without
| those small changes, it's an impressive piece of macro
| programming that is very close to being usable for general
| purpose, ABI-stable rust crates.
|
| As a little dose of irony, clippy doesn't like the com-rs crate
| too much.
|
| [0] https://github.com/RustAudio/vst3-sys.git
| blinkingled wrote:
| 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_case on module and method names and the ? operator for
| error propagation.
|
| Developing on and now for Windows just keeps getting better.
| Koshkin wrote:
| > _brilliantly avoided mixing up C++ /COM_
|
| I remember VB6 was also exceptionally good at this.
| KeBugCheckEx wrote:
| Actually a lot in COM was made to work on vb. COM string type
| is BSTR which stands for Basic STRing.
| pathartl wrote:
| 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.
| pianoben wrote:
| 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?
| loeg wrote:
| 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.
| weiming wrote:
| 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`.
| Klonoar wrote:
| 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.
| cs702 wrote:
| 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 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.)
| ape4 wrote:
| F# is Microsoft's invented here version of Java
| munchbunny wrote:
| I thought C# was Microsoft's NIH version of Java?
| kerng wrote:
| To be fair Microsoft wanted to adopt Java, and with J++
| they added Windows specific base libraries and make it work
| with COM. One could still compile ordinary Java back then
| also with J++.
|
| 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.
| loeg wrote:
| You mean C#? F# is an ML family language on the CLR.
|
| > 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)
| nemothekid wrote:
| It's in their blood - its the 'Embrace' in EEE.
| acdha wrote:
| You know that's from 3 decades and 2 CEOs ago, right? They're
| a large company so there's sure to be plenty to dislike but I
| don't think it's contributing much without some analysis of
| their actions in this century.
| m463 wrote:
| I wrote this below, but I'll mention it here
|
| 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.
| 29athrowaway wrote:
| Let me introduce you to Steve Ballmer, the CEO before the
| current one, Satya Nadella:
|
| 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.
| fortran77 wrote:
| They _lost_?
|
| 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."
| Koshkin wrote:
| > _dual-monitor, dual NVidia GPU_
|
| Not exactly thanks to Microsoft.
| fortran77 wrote:
| You can't do it on a Mac (unless you want to run two non-
| supported graphics cards sharing 4 lanes on a
| Thunderbold/USB-C connector instead of each having their
| own x16 PCIe connection)
| noisem4ker wrote:
| To their credit, stability of such a setup might be
| facilitated by Windows' fine display driver model (WDDM).
| AQuantized wrote:
| Saying they "lost" in this context means they got to a
| point where it was clear capitulation to open source was
| the obvious play.
| loeg wrote:
| EEE did not end 3 decades ago and Balmer was only 1 CEO
| ago, so... no?
| yarrel wrote:
| Sure let's do that. This century they have bought up
| LinkedIn, GitHub, npm, and a stake in Facebook. They have
| replaced Atom with a fauxpen source editor. They've pointed
| them all at their locked down me-too cloud platform. And
| don't forget to develop your code on their locked down me-
| too tablet.
|
| 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 ca change...
| pedrocx486 wrote:
| >They have replaced Atom with a fauxpen source editor.
|
| 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.
| acdha wrote:
| > This century they have bought up LinkedIn, GitHub, npm,
| and a stake in Facebook. They have replaced Atom with a
| fauxpen source editor.
|
| 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.
| blub wrote:
| Concentration of power is (or at least I thought it was)
| obviously bad. This is why there's laws protecting
| against that but either they're not enforced or they
| weren't updated to the internet age.
| acdha wrote:
| It is a concern but being popular is not the same as
| having high power: GitHub has lock-in to the extent that
| it's a great service but it's not exactly like they're
| changing Git to prevent you from using your own self-
| hosted service, Gitlab, BitBucket, etc. Similarly, VSCode
| is open-source with tons of competitors: where's the
| angle where they have much ability to dictate anything to
| users?
| contextfree wrote:
| my view is that embrace/extend has really always been a
| general platform business thing and not specifically a
| Microsoft thing. it became infamously associated with
| Microsoft in '90s-00s because of the monopoly position they
| had.
|
| 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.
| derefr wrote:
| I don't see Microsoft doing much EEE on their modern non-
| cost-centre platform (Azure), though. Amazon is a much
| clearer example these days, with AWS having "embraced and
| extended" Postgres into Aurora, Redis into ElastiCache,
| and many other examples. (I don't know if AWS has ever
| gone all the way and "extinguished" any of the cores
| they've built upon, though?)
| contextfree wrote:
| at its most benign embrace/extend can just mean that your
| product supports the standards people expect and need,
| and there's also some differentiating aspect in which
| it's better than the other options (otherwise why does it
| exist?)
|
| 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
| derefr wrote:
| > But actually AFAICT Microsoft rarely (never?) actually
| succeeded in extinguishing any of the open standards they
| were infamous for attacking
|
| 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.
| forty wrote:
| MemoryStore is GCP, AWS' redis is named Elasticache.
| drej wrote:
| As much as I appreciate what Microsoft is doing here, your NIH
| praise is not entirely well targeted - look at this research
| project from Microsoft, which aims to build a slightly
| different Rust. https://github.com/microsoft/verona
| dtech wrote:
| How is a research proof of NIH? I guess C++ or Java should
| never have existed because how dare another programming
| language use that "OOP" concept Smalltalk popularized
| drej wrote:
| That's not at all a point I'm making. OP praised Microsoft
| for embracing Rust and making it work well on Windows and
| thanked them for not doing their own thing and instead
| supporting an existing project. So I'm just pointing out to
| a very recent endeavour that goes against all of that. I
| just enjoyed the irony of it all, that's it.
|
| Not saying anything about anything else.
| steveklabnik wrote:
| I think you're confusing Microsoft Research with
| Microsoft more broadly. A language research division (MSR
| does more than this, but they do this) is going to
| produce languages, that's their job. They often aren't
| trying to make a language that folks will use, but are
| instead exploring possibilities that end up improving
| other languages. Verona (and it is _far_ too early to
| tell, IMHO) may end up in fact improving Rust. At the
| same time, Microsoft can and does support Rust, both as
| an organization on their own and indirectly via GitHub.
| These two things aren 't in conflict, especially when
| you're talking about an organization as big as Microsoft
| is.
| tambourine_man wrote:
| It's always easy to be an open source proponent when you are
| the underdog.
|
| 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.
| cheez wrote:
| The Microsoft you remember is at a time when dev tools were
| "the future". They are now the past. Microsoft's ruthlessness
| is no doubt focused elsewhere now. For example, do they go
| out of their way to make your code portable b/w Azure and
| Google? Probably not.
| munchbunny wrote:
| From firsthand experience... Microsoft has quite a bit of NIH
| syndrome. Still does. They've just gotten better about it in
| recent years.
| akiselev wrote:
| Also from firsthand experience: for many (not most) of MS's
| projects, that's the right decision. A lot of their software
| is at a unique intersection between consumer and enterprise
| support which at their scale often has unique requirements.
|
| But then MS's bureaucracy can grind down even the most well
| thought out projects (Also getting better, though).
| Nullabillity wrote:
| > It may be the only large software company that doesn't seem
| susceptible to not-invented-here syndrome.
|
| .NET?
| [deleted]
| weiming wrote:
| TIL Rust is also sponsored by Amazon.
| (https://aws.amazon.com/blogs/opensource/aws-sponsorship-
| of-t...)
| 29athrowaway wrote:
| 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.
| disgruntledphd2 wrote:
| Microsoft R is kinda annoying, OTOH it only happened because
| Microsoft bought Revolution Analytics, who developed this
| tool.
|
| AFAIUI, it's mostly just R with better parallelisation of
| matrix libraries (which is cool).
|
| It's not quite compatible, but I've used both through Conda a
| bunch, and haven't hit any edge cases that caused a problem.
|
| So yeah, you're right that it's embrace/extend, but the
| extend was done by a startup which they bought.
| 29athrowaway wrote:
| So it's embrace and extend, thank you.
| skylanh wrote:
| > Added their own packages version of every package.
|
| > Added their own package repository (MRAN), replacing CRAN.
|
| How is any of this different than the many incompatible Linux
| packaging solutions?
|
| How would you address insecurity and trust relations if you
| weren't a first-class contributor of CRAN? (consider the
| recent Python package exploit; although amateur, it's still
| an indication of such issues; I'm sure I remember this was an
| issue with the Perl packages as well; wasn't there an exploit
| pushed to the Linux kernel tree at some point years ago?)
|
| The narrative changes from "MS is EEE'ing CRAN" to "MS
| allowed a package with exploits to be deployed from CRAN".
|
| I am not familiar with any of the issues within the R
| ecospace, but I am very familiar with corporate culture,
| security, and liability awareness.
| m463 wrote:
| > I am very familiar with corporate culture, security, and
| liability awareness
|
| I thought the same thing many years ago. I was speaking
| with a friend ( _many_ years ago) who used to work for
| microsoft.
|
| I said, "so they broke something and didn't support this,
| they're just developers and how do they know all the
| issues?" Basically, I was saying the coders were human, and
| sometimes getting something out is hard.
|
| My friend said, "No, don't be naive. they had meetings.
| They sat around and said, "how can we own this?""
|
| It might be interesting to revisit the (ancient) halloween
| documents:
|
| https://catb.org/esr/halloween/halloween1.html
|
| This also works in a benign fashion. Emergent behavior.
| People/roups 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.
| oaiey wrote:
| 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.
| hota_mazi wrote:
| 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.
| lostmsu wrote:
| To be fair, you could do this with plain C, then with COM, etc.
| alkonaut wrote:
| 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)?
| pjmlp wrote:
| The future of Win32 is also bound to sandboxing, although we
| are not yet there.
|
| "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.
| Rusky wrote:
| A lot of WinRT APIs are usable from "normal" desktop win32
| apps, but some are restricted to the sandboxed/appx/etc model.
|
| 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
| sleepinseattle wrote:
| The minesweeper example from the article is a regular Win32
| app. Desktop Win32 apps can call WinRT API's.
|
| https://github.com/robmikh/minesweeper-rs/blob/master/src/ma...
| contextfree wrote:
| 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.
| captainmuon wrote:
| 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.
| contextfree wrote:
| 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.
| edko wrote:
| Rust/WinRT has really triggered my interest. For someone
| who hasn't been following Windows development for more
| than almost two decades, what's a good read to understand
| the different models of app creation and distribution?
| contextfree wrote:
| Unfortunately it's a bit of a mess right now for reasons
| alkonaut mentioned in his post upthread. The official
| Microsoft doc page -> https://docs.microsoft.com/en-
| us/windows/apps/desktop/ is maybe an ok starting point
| for someone with a vague memory of Windows desktop
| development who's curious about what's new, but I could
| see someone getting lost in a maze of acronyms and links,
| especially if you're trying to use it with a newly semi-
| supported language like Rust
| temac wrote:
| > on the other hand, only UWP CoreWindows can make use of UWP
| shell integration features like fullscreen and picture-in-
| picture
|
| What are the practical advantages of fullscreening / PIP'ing
| thanks to UWP as compared to what you can achieve without?
| WorldMaker wrote:
| The Shell managed PIP is entirely unique to UWP. In Win32
| you can fake it with an always-on-top window, but you don't
| get the PIP window management gestures out of the box and
| some other things. From what I recall, where this
| particularly matters is touch gestures and HoloLens and
| Windows MR support where Win32 always-on-top is very
| different from Shell-managed PIP in three dimensions.
| (Also, Xbox doesn't support Win32 always-on-top.)
|
| 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".
| alkonaut wrote:
| 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).
| contextfree wrote:
| Yeah, it's definitely confusing for anyone who hasn't been
| following all the twists and turns (i.e., the vast majority
| of developers)
| dstaley wrote:
| 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 toolchain setup to
| compile the module).
| pjmlp wrote:
| PWAs on Edge were able to do it, when signed.
|
| Hopefully they will do the same with the new version.
___________________________________________________________________
(page generated 2020-04-30 23:00 UTC)