[HN Gopher] Rust for Windows
___________________________________________________________________
Rust for Windows
Author : dsr12
Score : 517 points
Date : 2021-01-21 18:37 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| phkahler wrote:
| Rust needed a GUI and Microsoft provided one. They seem to be
| very focused on giving developers what they need, but only to a
| point. I've been doing some system glue stuff and while it's nice
| that powershell has ssh an scp they are missing some options I
| want. I was going to use curses with python (batteries
| included!), only to find out it's not supported on windows.
|
| It almost feels like a strategy - be standard enough to bring
| people in, but idiosyncratic enough to lock them in.
|
| I'll be using gtk-rs thank you very much.
| freeone3000 wrote:
| You'll need to install windows-curses, since cmd.exe didn't
| support vt100 escape sequences until relatively recently, and
| still requires a special WinRT call in order to enable them.
|
| But it's a bit telling that the first hurdle you hit in running
| python on windows was the operating systems choosing different
| forty-year-old terminal emulator escape sequences. :)
| pjmlp wrote:
| Windows Terminal is the actual solution.
| chiph wrote:
| > They seem to be very focused on giving developers what they
| need, but only to a point.
|
| This may be a consequence of the consent decree they signed in
| the early 2000's, where it was alleged that they used their
| control of Windows APIs to further Internet Explorer market
| share at the expense of other browsers. Since then they have
| had to be careful not to act like a monopoly.
|
| https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor...
| .
| dgellow wrote:
| WSL2 has almost everything you need if Windows isn't enough
| boogies wrote:
| Yep, WSL2 is standard enough to draw some in. Its DirectX
| support is a[n early baby] step in the direction of making it
| idiosyncratic enough to keep them locked in (we should
| probably expect more in the future. Right now it otherwise
| seems to be just a VM, without a lot of non-standard stuff to
| give it an advantage over running the more stable OS on the
| bare metal and keeping the BSODing one contained with
| virtualization).
| alexfromapex wrote:
| That's exactly what this is, a way to sink their proprietary
| claws into Rust and try to influence the market the way they
| have done with most of their software for decades.
| jvanderbot wrote:
| Microsoft has reinvented themselves, but the old hatred won't
| die easy.
|
| I'm excited for Intel to do the same, and look forward to the
| lingering suspicion even then.
| simias wrote:
| Microsoft are a gigantic corporation, they're not the good
| guys or the bad guys, they're collectively amoral and
| profit oriented. That will never change.
|
| Being suspicious of their actions and their intentions is a
| very reasonable stance.
| LAJdgday wrote:
| No they have not reinvented themselves. They are ruthlessly
| taking over OSS software projects by buying the type of
| developers who play politics and love to command others
| around.
|
| I take it that Rust is next after Python, whose development
| has stagnated and where the mailing lists are now censored.
| rockdoe wrote:
| The old hatred flares up every time Windows 10 asks me if
| I'm really really sure I don't want to default Edge as my
| browser, or "accidentally" changes it.
|
| Nothing has changed.
| alexfromapex wrote:
| I disagree that they've reinvented themselves:
| https://www.computerworld.com/article/3568009/slack-files-
| eu...
| dimitrios1 wrote:
| The solution for this is rather simple, and until Windows
| does it, I will always be skeptical of their renaissance
| as some benevolent contributor to open source: open
| source windows.
| ChrisSD wrote:
| Sure! Presumably you're volunteering to track down the
| current rights holders for all code derived from third
| parties and will negotiate the relicensing of their
| contributions?
| sgift wrote:
| That the monetized IRC clone is unhappy doesn't convince
| me that Microsoft has done something wrong. But we'll see
| what the EU commission decides.
| oaiey wrote:
| Well they bring in the language and its runtime to windows
| development via WinRT. They don't bring WinRT to Rust. This is
| the windows team writing adapters for their COM API surface.
| They do the same for C++, C#, JS and now Rust.
| kyriakos wrote:
| JS? can you point me to that?
| ptx wrote:
| Didn't they remove the JavaScript WinRT projection?
|
| The docs[1] describing how to call a WinRT component from JS
| say: _Universal Windows Platform (UWP) projects are not
| supported in Visual Studio 2019. See JavaScript and
| TypeScript in Visual Studio 2019. To follow along with this
| section, we recommend that you use Visual Studio 2017. See
| JavaScript in Visual Studio 2017._
|
| [1] https://docs.microsoft.com/en-us/windows/uwp/winrt-
| component...
| Spivak wrote:
| For people who have not lived in the Windows world this would
| be like GNOME writing Rust Glib bindings.
| Already__Taken wrote:
| curses specifically is majorly antithetical to how powershell
| and by extension Windows/server has decided to evolve. infact
| text-based UI is the reason CMD.exe cannot and will not ever be
| improved.
|
| munging anything around with text very much not the Windows
| way. For better or worse.
| mwcampbell wrote:
| > I'll be using gtk-rs thank you very much.
|
| Please be aware that if you do this, your application won't be
| accessible with screen readers or other assistive technologies
| on Windows and Mac. At least not now. Maybe I'll have time to
| implement GTK accessibility backends for those platforms
| someday.
| Blikkentrekker wrote:
| Screen readers rely on some kind of toolkit a.p.i.?
|
| I would assume they would simply read the screen. Are they
| thus not capable of, for instance, reading a picture?
|
| They should not be called "screen readers" but "text to
| speech" if they not actually read the screen on a bitmap
| level.
| riquito wrote:
| Screen readers, despite the name, don't do OCR, they access
| informations provided by the GUI toolkit (which is one of
| the vastly improved area in GTK 4 Afaik).
| Blikkentrekker wrote:
| Then why don't actual screen readers exist when a.i.'s at
| this point can practically solve captcha's by enhancing
| the reflexion in the eyes of a highly compressed jpeg and
| reading the text in there?
|
| Certainly there would be significant demand for a
| sightless man to be able to read the dankest memes from
| pictures?
| danShumway wrote:
| > Then why don't actual screen readers exist when a.i.'s
| at this point can practically solve captcha's
|
| Training a computer to solve a captcha is a lot easier
| than training a computer to understand interface
| conventions.
|
| There isn't an AI that can look at a jpeg screenshot of
| an interface and say, "there's two input elements, and it
| looks like they're grouped together and control the list
| to the left of them, and one of them is selected, which I
| can tell because it has some kind of subtle glow effect
| on it, but not the glow effect you would get if you
| moused over it."
|
| There's nothing that can realistically do that today, and
| it wouldn't be fast enough or performant enough for low-
| powered cell phones and laptops even if it did exist.
|
| If you're just looking at describing pictures
| themselves... sure, Facebook does auto-generate alt tags
| for images if you forget to put one in. And Youtube auto-
| generates captions. Those are valuable services, but they
| have a lot of glitches and mistakes. If you're a blind
| reader, you'd prefer not to have that experience when
| you're using a piece of software, you'd prefer something
| that just works reliably.
|
| It's the same reason you probably used a keyboard to type
| this comment instead of speech to text. Speech to text is
| useful in some cases, but not good enough or accurate
| enough that you would want to use it as your main input
| method.
| mwcampbell wrote:
| Some screen readers can do OCR on a specific part of the
| screen (e.g. an unlabeled image) on request. But while
| OCR is useful for getting text out of an image, most
| implementations can't discern the structure of a UI, e.g.
| which part is a button, which part is an edit box, etc.
| Also, OCR is typically done just once on-demand, not
| continuously as the screen changes.
|
| However, VoiceOver for iOS has a new feature called
| screen recognition, which is exciting because it
| overcomes these limitations and provides some level of
| access to applications that are otherwise inaccessible.
| Hopefully other platforms will catch up.
|
| Even then, true screen reading will be much more CPU-
| intensive than what screen readers currently do. And
| anyway, it's not here yet, except on iOS. So I will
| continue to warn developers away from toolkits that are
| inaccessible, in hopes that some blind person somewhere
| will be spared the pain of being blocked from doing a
| task because of an inaccessible application.
| danShumway wrote:
| Converting bitmaps to text isn't enough to make an
| interface usable. You need to be able to quickly convey the
| structure of the interface and what controls are available,
| and to do that well you need some kind of semantic insight
| into the interface.
|
| Screenreaders don't just read text, they control the
| interface itself using standardized keyboard shortcuts and
| input components within whatever graphical framework you're
| using, and they communicate what that interface is using a
| set of standardized terminology.
| Blikkentrekker wrote:
| I indeed am imparted that the term "screen reader" is a
| misnomer and not what I expected it to be.
|
| This seems to be more so an "accessibility suite" of
| which text-to-speech is a component rather than what I
| would call a "screen reader".
| danShumway wrote:
| Sorry, I guess? It's been an industry standard phrase for
| a pretty long time. Screenreaders probably have a
| historical reason why they're named the way they are, but
| the short version is that's just what everyone started
| using. A lot of software terminology is like that, it's
| weird to people who are unfamiliar with it because
| there's no central committee somewhere that decides what
| everything should be named.
|
| If you're trying to do a search online for the kind of
| tool you're looking for, probably the phrase you would
| want to search for is "OCR software", short for Optical
| Character Recognition, or if you're trying to tag images
| just straight-up "image recognition."
| [deleted]
| simias wrote:
| What you describe might be more robust in some situations
| but vastly less for software designed to be accessible.
| Take "alt" attributes in HTML img tags for instance, or
| various metadata attached to buttons that use an icon
| instead of text (like a play button, or a X close button
| and similar things).
|
| You can see an example next to this very comment actually:
| the up and downvote buttons won't be accessible with OCR,
| but they have "title" attributes describing what they are.
| And consider that there's more to understanding a given
| user interface that raw text: radio buttons are tied to
| certain labels, there's hierarchy, all sorts of layout cues
| that would be opaque to a screen reader.
|
| I suppose that ideally you'd want both: use native
| accessibility data if available, fallback to OCR when
| there's no alternative.
| phkahler wrote:
| Yet another reason for them to do this. Not just a GUI for
| Rust, but the only accessible one. It really is a solid
| strategic offering to bring Rust developers to their Windows
| platform. But IMHO developers who do are trading tomorrow for
| today.
| mwcampbell wrote:
| Actually, Qt is also accessible (more or less) on all the
| desktop platforms, so that's another option.
| Shared404 wrote:
| Is there a good way to use Qt from Rust?
|
| I looked the other day, but couldn't figure it out.
| varajelle wrote:
| https://github.com/woboq/qmetaobject-rs
| ddevault wrote:
| This only matters if you care about propiretary platforms
| like Windows and Mac. And you should not care!
| mwcampbell wrote:
| I still do, because people are stuck with these platforms,
| for reasons beyond our control, and I care more about
| people's access to applications that they need than about
| being a purist.
| rodgerd wrote:
| "Fuck people who need assistive technologies" does not make
| you a good person.
| kiawe_fire wrote:
| More like "fuck people who use Mac OS or Windows".
|
| I saw no malice there directed at users of assistive
| technology, but rather of users of non-open platforms.
| kevingadd wrote:
| If the assistive technology they need to use isn't
| available on Linux or they don't have the ability to run
| Linux it's not that meaningful of a difference.
| mumblemumble wrote:
| I do think it is a strategy, but I think it's a rather simpler
| one than that: basic work triage and scope management.
|
| ssh and scp make sense to put into powershell, because they're
| everyday sysops things. curses is pretty posix-specific, and
| apps that use it are likely to need other posix stuff, so
| handle that with WSL rather than unnecessarily re-inventing a
| wheel.
| koheripbal wrote:
| Never attribute to malice what can be adequately explained by
| incompetance, laziness, or limited resources.
| nitrogen wrote:
| It's hard to forget that Microsoft's official, documented
| policy for a very long time was Embrace, Extend, and
| Extinguish.
|
| It all feels _very_ vaguely analogous to the West 's
| relations with China and Russia -- both China and Russia
| appeared very open for a time, and then closed back down
| after gaining enough leverage.
| heavyset_go wrote:
| > _I 'll be using gtk-rs thank you very much._
|
| How well does gtk-rs work as a cross-platform GUI library? I
| know it works well on Linux, but I haven't tried it on macOS or
| Windows.
|
| If anyone has experience using it for cross-platform
| development, I'd love to hear about it.
| Macha wrote:
| It works. The windows theme is a little dated, but Windows
| users are used to a random mishmash of inconsistent styles,
| so likely won't cause complaints. On Mac, well actually I
| haven't personally tried it on Mac, just Windows/Linux, but I
| hear a lot of vocal complaints about GTK not fitting in from
| mac users. I'm not sure this means it's worse than on
| Windows, I think Mac users just expect more.
| skybrian wrote:
| Does this automatically generate safe API's as expected for Rust?
| If so, I wonder how they manage it? Did their metadata format
| have to be extended to describe the constraints on Rust callers
| and callbacks?
| ChrisSD wrote:
| It does not generate safe bindings. Currently the metdata is
| scrapped from Windows headers which don't have all the
| necessary information to go that far. In the future the
| metadata could be improved. The metdata format is the same as
| used by .NET and WinRT.
| nn3 wrote:
| Wish there was something like this for Linux too. Rust system
| programing on Linux consist of dealing with a dumpster fire of
| badly implemented and incomplete wrapper crates for the kernel
| interfaces.
| bluejekyll wrote:
| I assume you're talking about more than just libc. Many of the
| Linux specific facilities are captured in higher-level cross
| platform implementations, like mio abstracts over kqueue on BSD
| and epoll on Linux.
|
| What are the APIs you're interested in that are missing or of
| poor quality?
| brundolf wrote:
| Very cool to see the start of official support. Unfortunately it
| looks like it requires unsafe { } for now, though maybe it's
| intended as a low-level foundation on which a higher-level, safer
| API can be built
| coldtea wrote:
| > _Unfortunately it looks like it requires unsafe { } for now_
|
| Forever, and not "unfortunately" but rather as expected and
| necessary. Windows API is unsafe (C/C++) itself, and this is a
| wrapper for it.
| wtetzner wrote:
| Sure, but safe wrappers can be written around unsafe APIs.
| _zamorano_ wrote:
| Well, the Windows API is "unsafe" by design, is C-based, you
| pass pointers around, datatype sizes, etc... How can you avoid
| "unsafe" in this scenario? You're asking for a new framework or
| an API rewrite
| Blikkentrekker wrote:
| Unix libc is also unsafe, but the _Nix_ crate mostly built a
| safe, _Rust_ -esque interface around this and abstracted most
| of the types so that they are safe.
| brundolf wrote:
| The domain itself isn't fundamentally unsafe, only the way
| the C API has been designed. You're right that meaningfully
| different abstractions (instead of a one-to-one translation)
| may be required to make a safe API, which is why I suggested
| that could be a possibility.
| dialamac wrote:
| > The domain itself isn't fundamentally unsafe
|
| This makes no sense to me, what you're saying here. You
| pass raw pointers to the Windows API for one, for which it
| makes no safety guarantees. Short of rewriting Windows from
| scratch I don't see how this isn't a fundamentally unsafe
| domain. Sure you could put more and more wrappers up on top
| (it's not an even an issue of one-to-one translation, but
| how resources such as memory are wrapped), but whatever
| binding there is pretty much must be unsafe.
|
| That it's possible to write a safe wrapper is kind of
| obvious.
| Spivak wrote:
| But that wouldn't eliminate the need for unsafe code at the
| border. All ffi calls are inherently unsafe to Rust. You
| can design the cleanest nicest safest C api in the world
| but it's still unsafe as far as Rust is concerned.
| brundolf wrote:
| Yes, but in Rust there are two independent axes here:
|
| - Whether or not a library calls unsafe code internally
|
| - Whether or not a library declares its public API to be
| unsafe (https://doc.rust-lang.org/book/ch19-01-unsafe-
| rust.html#call...)
|
| It's very much possible (essential, even) to be able to
| present a safe API to external callers of your code,
| despite using unsafe code under the hood. In this case
| you're making a human-checked assertion of safety, which
| is not guaranteed to be without bugs, but the important
| thing is that you're minimizing the surface area of un-
| safety and declaring a contract with your users. You're
| "stopping the buck" of unsafety rather than passing it
| on. The parts that really have to be unsafe can enjoy
| extra scrutiny, and everything else (including the
| caller's code) can be checked by the compiler. This is
| not uncommon in the standard library and other low-level
| libraries.
|
| More information here: https://doc.rust-
| lang.org/book/ch19-01-unsafe-rust.html#crea...
| josephg wrote:
| Sure. So this library exposes all of Microsoft's DLL
| surface area in an API-native way. That's important.
|
| Now that it's released, library authors can wrap this
| with another library, which abstracts over win32,
| reexposing it in safe rust. Wrapper libraries like that
| almost certainly won't cover 100% of the api surface area
| - there are _so many_ functions in the windows APIs.
|
| Anyway, give it time. People will wrap this with safe
| rust.
| brundolf wrote:
| Which is exactly what I suggested in my original comment
| :)
| MereInterest wrote:
| Yes, but those unsafe blocks can be wrapped into the
| library. "Unsafe" doesn't inherently mean "bad", it just
| means that the programmer is explicitly taking the burden
| of making sure that the normal invariants still hold. So
| long as the library authors ensure that, then the
| "unsafe" blocks remain within the library and don't need
| to be worried about by the users of the library. On the
| other hand, if a library pushes that additional
| responsibility to me, it makes me more worried.
| amluto wrote:
| This ought to be doable automatically, at least a lot
| better than the current code: let event =
| CreateEventW( std::ptr::null_mut(),
| true.into(), false.into(),
| std::ptr::null(), );
|
| The .into() is silly but tolerable. But the first parameter
| is a pointer to a struct, and it's clear enough from the
| signature that a reference would work. It could be mut to
| be on the safe side. (Yes, this involves someone making
| sure that the API doesn't retain the pointer.). The last
| argument is, per the prototype, is a string. Admittedly,
| the Windows API has a truly horrible idea of what a string
| is, but surely they could do better than using a pointer.
| steveklabnik wrote:
| Both of these parameters can be null, and references
| cannot be null, so it is not possible to use references
| directly without losing some functionality.
|
| (They could remove the intos if they wanted to, I agree
| it feels kind of weird but I'm not actually sure if doing
| it is better or worse, I am conflicted.)
| Cu3PO42 wrote:
| It could very well be Option<&mut T>, though. Personally
| I think having a 1:1 mapping to the C API is reasonable
| enough as a first target. It should make porting code
| easy and referencing the official documentation is
| probably easiest this way.
|
| No matter how many heuristics they apply to make a
| somewhat more idiomatic mapping, it'll never feel right
| until it's manually designed to fit with Rust
| conventions. So I'm okay with it as it is now and can
| hope for a much thicker abstraction in the future.
| orra wrote:
| Option<T> would sensibly solve the nullability?
| steveklabnik wrote:
| There are a few different possibilities, and some of them
| involve Option, yes. But doing this would still possibly
| create an annotation burden that the parent is
| complaining about.
|
| My comment was trying to be pretty narrowly scoped to
| "why not use a reference here." You and your sibling are
| both right in ways!
| orra wrote:
| Fair enough, and gotcha. Thanks.
| johnsoft wrote:
| A pointer->reference transformation is not always
| correct, because in C, arrays are also passed as
| pointers. Example: https://docs.microsoft.com/en-
| us/windows/win32/api/winuser/n...
| mmastrac wrote:
| Lower-level APIs like this are usually unsafe, with second-
| level libraries providing the safe abstractions over them.
| [deleted]
| MaxBarraclough wrote:
| Someone replied and then deleted their comment, but I'll
| reply to it anyway. They wrote:
|
| > This is the safe abstraction! I mean it's a pretty
| mechanical translation but it's nonetheless as safe as Rust
| will ever consider it.
|
| No, it's not safe. Assuming I understand Rust correctly: if
| your bindings allow Rust programmers to trigger undefined
| behaviour even when they restrict themselves to the safe
| subset of Rust, that means that either your bindings have a
| defect, or the underlying (wrapped) library has a defect.
| mmastrac wrote:
| Yes, exactly. It'll be pretty unlikely that raw API
| bindings can be made safe (even for APIs that just take raw
| integer handles - you could double-close one and cause
| corruption/etc).
| simias wrote:
| I've seen some discussions on HN in the past where some
| rustaceans have argued that it's fine to expose raw C APIs
| in Rust using safe interfaces even if they're fundamentally
| unsound. I fail completely to understand the reasoning
| behind that (and I've really tried) but apparently it's
| still an open debate to some extent.
| MaxBarraclough wrote:
| How disappointing.
| mamcx wrote:
| Look this way: All C/C++ programs, all of them, forever, are
| unsafe by default.
|
| Even if a sanitizer, linker, review by the absolute most
| skilled developer on earth check every line.
|
| Because C/C++ is designed without safety. So, Rust can't
| "believe" the external world is safe because the external world
| is made unsafe.
| brundolf wrote:
| https://doc.rust-lang.org/book/ch19-01-unsafe-
| rust.html#crea...
| Maledictus wrote:
| I'd say this marks the beginning of the `extend` phase.
| Maledictus wrote:
| For those who don't remember:
| https://en.wikipedia.org/wiki/J/Direct
| diego_moita wrote:
| For Mac fans, the closest you'll have to this in OS-X is core-
| foundation-rs[1], by the servo team.
|
| [1] https://github.com/servo/core-foundation-rs
| edko wrote:
| Thanks for the link. Do you know of any examples that use this
| crate that would be easy enough for a beginner to start
| learning how to use it?
| Keyframe wrote:
| Any pointers / way for cross-compiling on linux for windows?
|
| Now Apple for MacOS and iOS, Android and maybe game consoles and
| Rust is a 1st class citizen!
| cletus wrote:
| The lesson from Microsoft I think is that the fish really does
| rot from the head. Put another way: who the CEO is really does
| matter. We have night and day here with Ballmer compared to
| Nadella.
|
| Credit where credit is due: Microsoft has really been doing a lot
| to try and rebuild their credibility when it comes to the
| developer community. Off the top of my head I can think of
| TypeScript, open sourcing .Net, WSL and now this.
|
| Oh and they haven't done an Oracle or a Cisco (or, let's face it,
| a Google at this point) with their acquisition of Github by
| letting it die on the vine or with hostile forced integrations.
|
| Kudos.
| codeflo wrote:
| As someone who writes Windows software now and then, I'm
| genuinely excited. I tried using this early, when it was limited
| to WinRT bindings. It looked promising, but compile times were
| prohibitive. It seems like they now include a build.rs and have
| clear recommendations around caching -- I hope this solves the
| problem. Has anyone tried a recent version?
| hehehaha wrote:
| Wow! Almost want to make Windows App now just for fun.
| AndrewGaspar wrote:
| Since Windows ships a stable ABI, why does this project need to
| generate the bindings at build time? Couldn't all of the bindings
| be pre-generated, eliminating the build-dependencies?
| steveklabnik wrote:
| https://www.reddit.com/r/rust/comments/l23fr7/rust_for_windo...
| Thaxll wrote:
| For someone not familliar with Windows API, why does creating a
| Windows needs unsafe and other low level things? I guess it's the
| same for the C++/C# version?
|
| https://github.com/kennykerr/samples-rs/blob/master/create_w...
| metalliqaz wrote:
| It's a call out to Windows libraries that long predate Rust,
| and they are implemented in (mostly) C++. They don't provide
| any of the safety features on any data structure you pass to
| it. I don't see how it could be anything other than unsafe.
| Blikkentrekker wrote:
| Yet the _xcb_ bindings in that crate are mostly safe:
| https://rtbo.github.io/rust-
| xcb/xcb/xproto/fn.create_window....
|
| They have provided nontrivial wrappers, wrapping _xcb_
| datatypes so to make them safe and uphold the invariants.
|
| I don't know much of any _Windows_ interfaces, but I doubt
| this would be impossible there too; they simply did not do
| so.
| tadfisher wrote:
| Does it actually wrap libxcb, or does it generate bindings
| from the XCB protocol descriptions (XML)? I would think the
| latter would be less work and higher quality.
| Blikkentrekker wrote:
| I don't know how it's achieved, but as I look at the
| bindings for this _Windows_ a.p.i they return all sorts
| of raw pointers and other things, whereas in _XCB_
| bindings for _Rust_ wrap the types in a _Rust_ -friendly
| way so almost all of them are safe.
|
| This _Windows_ a.p.i. in _Rust_ seems of a frankly
| atrocious design and most of the functions seem simple
| `extern "C"` declarations rather than actual attempts at
| proper wrapping.
| infogulch wrote:
| I don't think that's a fair characterization. Most safe
| rust wrapper libraries are built in two layers: 1. Map
| the api's raw interface into raw rust types, usually with
| a simplistic code generator; this enables the bindings to
| closely track upstream api changes. 2. Use that raw
| interface to build a wrapper library that translates the
| api to use rustlike idioms and expose safe constructs.
|
| This seems to be #1 only for now, which is fair because
| winapi is enormous. Also there may be many ways to expose
| a safe rust interface all with different tradeoffs, by
| leaving #2 open they don't lock in a single strategy
| prematurely. That said I am looking forward to a safe
| wrapper as well.
| metalliqaz wrote:
| The Windows API is a sprawling mess.
| Blikkentrekker wrote:
| I really doubt that would have anything to do with
| whether or not the binding wrote safe, _Rust_ -esque
| wrappers or not.
| [deleted]
| steveklabnik wrote:
| Anything not defined in Rust needs to be marked as unsafe,
| because Rust cannot understand non-Rust code. FFI bindings are
| inherently unsafe.
| ywei3410 wrote:
| On a side-note; do you know of any good resources where
| someone tries to wrap a non-trivial C wrapper where they go
| over common C idioms and ways to provide a (safer) API inside
| Rust without too much overhead?
|
| I've always found it to be incredibly difficult because of
| the number of gotchas which can leak into causing a segfault
| in Rust; it's immensely frustrating.
| roblabla wrote:
| I was curious how this worked: The previous iteration of this
| only worked for WinRT API, and this new crate seemed to also work
| by generating code from WinMD files. But WinMD files only
| contained definitions for WinRT/COM APIs, so how could this
| possibly work?
|
| Well turns out, microsoft started a project to also generate
| Win32 API information in WinMD file, to generate APIs from them
| automatically for all native languages! See win32metadata[0].
| This could make interfacing with win32 APIs a lot more
| convenient!
|
| https://github.com/microsoft/win32metadata
| ROARosen wrote:
| Does that meant it's compatible with any other language?
| roblabla wrote:
| Any language that can call C ABI and support the necessary
| datastructures, yes. That's the point of win32metadata.
| Arnavion wrote:
| So does this generator need access to the .winmd files at build
| time to be able to generate the bindings? Are they available
| for non-Windows builders?
| roblabla wrote:
| The WinMD files are shipped with windows-rs. You can find
| them here[0]. For cross-compilation use-cases, the main
| blocker is [1].
|
| [0] https://github.com/microsoft/windows-
| rs/tree/master/crates/w...
|
| [1] https://github.com/microsoft/windows-rs/issues/142
| g051051 wrote:
| Welcome back, J/Direct!
|
| https://en.wikipedia.org/wiki/J/Direct
| pjmlp wrote:
| P/Invoke, it never went away.
| jdlyga wrote:
| Wow, I thought by the name this would be an awkward Windows
| distribution of Rust packaged in an MSI. I'm pleasantly
| surprised. Microsoft has become one of the best big tech
| companies for open source in the past few years.
| Animats wrote:
| Will this work when cross-compiling from Linux? That's supported
| by Rust.
| monocasa wrote:
| I don't see why not, the winapi crate is.
| roblabla wrote:
| The winapi does a lot of work to support that use-case.
| Importantly, it ships (mingw) import libraries to allow
| linking against windows libs from linux trivially[0].
|
| EDIT: windows-rs doesn't yet support cross compilation as
| easily as winapi. Here's the issue tracking it:
| https://github.com/microsoft/windows-rs/issues/142
|
| [0]: https://github.com/retep998/winapi-
| rs/tree/0.3/x86_64/def
| Arnavion wrote:
| The question is valid. The winapi crate binds the functions
| in the Windows headers explicitly. You can call
| `winapi::...::CreateEventW` because winapi has a `pub extern
| unsafe fn CreateEventW(...)` in its code.
|
| This new crate is a generator. If this new generator requires
| access to the .winmd files or .h files from the SDK or
| whatever, where is the non-Windows builder going to get those
| from? And will this generator look for them there?
|
| For example, I used to maintain a generator that took COM
| typelibs and generated Rust bindings for them, but it
| required calling into the Windows API for working with
| typelibs and thus obviously required a Windows builder. The
| functionality of this crate is split between the windows_gen
| and windows_macros crates, and from a cursory glance I could
| not tell how it works wrt win32 bindings.
|
| Edit: Answered by
| https://news.ycombinator.com/item?id=25863581 - the win32 API
| is now also described by .winmd files.
|
| So the question is, can a non-Windows builder get these
| files, and then convince this crate to look for them wherever
| it placed them?
| orra wrote:
| > So the question is, can a non-Windows builder get these
| files, and then convince this crate to look for them
| wherever it placed them?
|
| Yes, there's actually a prebuilt Windows.Win32.winmd file
| in the repo, underneath .windows/.
| dguaraglia wrote:
| > This new crate is a generator. If this new generator
| requires access to the .winmd files or .h files from the
| SDK or whatever, where is the non-Windows builder going to
| get those from? And will this generator look for them
| there?
|
| From memory (I haven't done Windows development in
| forever): there's a few projects that try to provide an
| open source version of the Windows API headers. The MingW
| project, for example, has a full set of drop-in replacement
| headers (meaning you can take code that compiled with
| Visual C++ and compile it directly with MingW's GCC and it
| should 'just work'). The LCC-Win64 project has a similar
| set of headers.
|
| Does that answer your question?
| Arnavion wrote:
| Headers are irrelevant. We're talking about .winmd files.
| est31 wrote:
| https://github.com/microsoft/windows-rs/issues/143#issuecomm...
|
| > we could support this in future, but it is not an immediate
| goal. If this is something that folks would like to do, feel
| free to chime in on this issue and let us know.
|
| Note that most of Microsoft regards Linux mainly as a server
| OS. You are not supposed to use it on the desktop, instead you
| should use Windows there.
| reader_mode wrote:
| Even if that's true you really don't want to run a Windows
| box as a build server - licensing and security and all that.
| phkahler wrote:
| >> Note that most of Microsoft regards Linux mainly as a
| server OS. You are not supposed to use it on the desktop,
| instead you should use Windows there.
|
| Then what's the point of WSL? To allow server software
| development on a Windows desktop? OK. But then what's the
| point of trying to bring DX graphics to linux?
| paavohtl wrote:
| To run Tensorflow and other ML libraries in WSL.
| Erlangen wrote:
| I kind of expect it to be called "Windows for Rust".
| joshuaissac wrote:
| Or maybe "Windows API for Rust".
| levesque wrote:
| Rusty Windows?
| medium_burrito wrote:
| Tetanus
| [deleted]
| kaoD wrote:
| I thought your comment was a tongue-in-cheek reference to
| Windows Subsystem for Linux and then I clicked the link.
| [deleted]
| SloopJon wrote:
| I had the exact same thought. I almost didn't bother following
| the link, because Rust for Windows is already a thing, but this
| is essentially a Rust equivalent to C++/WinRT.
| steveklabnik wrote:
| To be clear, it's a bit broader than that. WinRT is a
| specific subset of windows APIs, and the Rust bindings for
| that have existed for a while. This is for _all_ Windows
| APIs.
| edko wrote:
| I wonder if this would allow using a WebView2 from Rust? I've
| searched the repository, but was not able to find it.
| zRedShift wrote:
| Search everything here: https://microsoft.github.io/windows-
| docs-rs/doc/bindings/win...
| mwcampbell wrote:
| Kenny Kerr's blog post on this may also be of interest. In
| particular, it answers the question I was going to ask about how
| they're handling Win32 and WinRT in a unified way.
|
| https://kennykerr.ca/2021/01/21/rust-for-windows/
| jug wrote:
| I wonder if Rust is becoming Microsoft's way forward for
| development rather than C++ (i.e. Rust for Windows rather than
| C++ for Win32), leaving .NET for higher level development? The
| bold introduction in the blog post surprises me, coming from
| Microsoft themselves who're right now hard at work on these
| individual and ununified technologies.
| mhh__ wrote:
| D has fairly extensive windows API support, and the usual PE
| gubbins. Worth taking a look at
| gabereiser wrote:
| Yes but the topic of discussion is rust here. D is awesome, but
| we are talking about the windows bindings for rust being "just
| good enough".
| vlang1dot0 wrote:
| Rust has had that for a long time as well. This is first-party
| support from Microsoft for Rust in contrast to community
| supported options like in D.
| MaxBarraclough wrote:
| Link: https://wiki.dlang.org/D_for_Win32
|
| Ada has something similar: https://github.com/AdaCore/win32ada
| bluejekyll wrote:
| Are these D bindings relevant to Rust developers? Or asked
| another way, is there some reason that the D bindings would be
| better to use than these native ones in Rust?
| mhh__ wrote:
| When I am writing or choosing (or bindings to) an API I
| always go and look at other languages (especially what the
| functional people do) to avoid repeating non-obvious mistakes
| and seeing where the impedance mismatches are.
|
| Most recently, I've been playing with eBPF on Linux: The
| system call API is terse and pretty impenetrable, whereas the
| high-level APIs either mean writing gadgets in C with a
| nearly-blind debugging experience or relying on a library to
| retain the power of the featureset the kernel exposes.
| komuher wrote:
| This is the same stuff like julia community is doing. Spam
| language in every Python/R related topic (D guys target
| Nim/Rust)
| mhh__ wrote:
| It's hackernews not rustnews, though.
| mmastrac wrote:
| Sorry, I had to look up "gubbins":
|
| British : fish parings or refuse broadly : any bits and pieces;
| gadgets, gadgetry the gubbins for changing a tire all the
| navigational gubbins
| GordonS wrote:
| I wasn't aware of the dictionary definition :)
|
| As the GP used it, it means "and what not", "and such like"
| etc.
| type0 wrote:
| Can we expect to get a better compilation time with this?
| seertaak wrote:
| This is really cool. Kudos to Microsoft for really getting open
| source lately. I wrote an app (which failed miserably) called
| zenaud.io . When I started writing the app, Apple was hands-down
| a better developer experience. Now, it's the exact opposite --
| MacOS is increasingly painful, throwing up more and more
| roadblocks and constricting their platform ever more. And Visual
| Studio is better than Xcode IMO.
|
| Also, as a C++/Python dev - it's increasingly hard not to notice
| the awesome momentum Rust has garnered.
| blub wrote:
| Apple are throwing more roadblocks at least partly because
| developers are becoming more and more deplorable, trying to
| claw every penny they can by collecting and selling every bit
| of metadata (or even data) they can get their claws on.
| Microsoft aren't throwing similar roadblocks at least partly
| because they're one of the deplorables people need protection
| from.
|
| All big software corporations use open source strategically:
| keep the core money-makers closed, release tooling and other
| trinkets for developers so that they do some free advertising
| for the company. They also release expensive-to-develop
| software for free to destroy competitors and expand their
| influence.
| girvo wrote:
| I am an Apple/Linux diehard, but Visual Studio has always been
| superior to Xcode imho.
| bezout wrote:
| OT: I must agree about your comparison of macOS and Windows.
| IMO Microsoft is doing a lot to improve the developer
| experience. WSL2 is so freaking good. It has its quirks and it
| has issues with some workflows, but I'm thinking about moving
| out of macOS after having tried it.
|
| Apple may have the fastest processor, but Microsoft has the
| most comfortable tools. Both companies are not perfect, but if
| we must choose the lesser evil...
| jhoechtl wrote:
| Unleash all your handcuffs and move directly to Linux. It
| will be really refreshing!
| cpeth wrote:
| "Apple may have the fastest processor, but Microsoft has the
| most comfortable tools. Both companies are not perfect, but
| if we must choose the lesser evil..."
|
| It's very fast for a low power, laptop-focused processor and
| even then only truly excels at single-threaded workloads.
| It's out classed by AMD mobile offerings (4900HS and 4800U)
| in multi-threaded workloads on most tests[0]. If you step up
| to desktop processors, the top end processors like the AMD
| 5950X are in a different class of multi-threaded performance.
|
| Don't get me wrong, it's an exceptional processor and
| incredibly fast for its sub-25W TDP.
|
| [0] - https://www.anandtech.com/show/16252/mac-mini-
| apple-m1-teste...
| caycep wrote:
| This is simply a matter of adding more cores...I mean, I
| would hope the 5950x with its 16 full strength cores would
| be better than an M1 with it's big/little design...
| chx wrote:
| > WSL2 is so freaking good.
|
| I am on WSL1 two things hold me back from upgrading
|
| 1. How's networking? I go on and off VPNs quite a bit.
|
| 2. How's cross system access to files especially performance
| wise? I edit with phpstorm for windows, I share the files
| with Slack also windows, I access the same files with WSL
| git, LAMP stack and more.
| kyriakos wrote:
| 1. Just works. Only issue I found is that Wsl2 will not
| update its dns resolver IPs when connecting to the vpn.
| There's a workaround script. So it's either exit the
| terminal and re enter it or run the script to update them.
|
| 2. This is my current pain. Windows file system is slow
| already and accessing it from wsl adds an overhead. Ideally
| I keep projects in Wsl2 storage and IDEs in Windows. I
| searched a lot for a solution but haven't found one. On the
| other hand, Wsl2 Linux storage speed runs circles around
| wsl1.
| peschkaj wrote:
| I use X410 and run tools from inside of WSL2 by exporting
| the display. Works well for Emacs, JetBrains Rider, and
| every other GUI application I've tried so far.
| girvo wrote:
| That sounds excellent: I'll have to give it a shot.
| VSCode under WSL2 with its Docker support is neat, but
| can be slow due to the storage system overhead. This
| might solve that for my team!
| naikrovek wrote:
| Concur. X410 is great and survives where xming and vcxsrv
| both crash for me. It's not free but the "not crashing"
| feature makes it well worth the $10 I paid for it.
| TheOperator wrote:
| Buying Microsoft for it's OS and Apple for it's hardware?
| What is this opposite day?
| hctaw wrote:
| > Apple may have the fastest processor, but Microsoft has the
| most comfortable tools.
|
| It doesn't matter how fast the M1 is if XCode can't keep up
| with modern development tools. I don't understand how Apple
| developers produce any software with it, the experience is
| truly awful compared to nearly every alternative. It's slow,
| buggy and inscrutable. How long does it take to onboard a
| fresh grad at Apple, I wonder?
| kenjackson wrote:
| I have an existing app in Swift and Interface Builder. I
| hate xCode. Simple things like deploying the app to a
| device is hit or miss (usually miss). Is there a
| development environment that I could use for my app which
| is better? Happy to use any platform (MacOS, Linux,
| Windows).
| hctaw wrote:
| App Code is probably the only thing worth checking out.
| Swift isn't a useful language outside of the Apple
| ecosystem and interface builders come and go, usually go
| (design in Figma/Adobe products, implement in Code rather
| than UI wysiwyg)
| seertaak wrote:
| Indeed, WSL2 is pretty cool. Also, Windows Terminal is
| actually pretty sweet, and I even gave PowerShell a spin the
| other day. The crazy thing is you can basically use it as a
| bash shell, and it gets the job done. My developer experience
| right now consists of PowerShell, where I do all my regular
| directory jumping, editing (vim), etc., and a Developer Shell
| with god awful classic "terminal" which I only use to call
| conan/cmake/clang-windows.
|
| I have to add the following: MSVC supports clang on windows.
| And CMake - all within Visual Studio. And it works perfectly,
| with perfect support for C++17. Badass.
| jhoechtl wrote:
| What is windows terminal? cmd?
| jolux wrote:
| Visual Studio has supported Developer PowerShell for a
| while now, and it's possible to load it into Windows
| Terminal. It's just a set of arguments. This blog post
| explains them:
| https://devblogs.microsoft.com/visualstudio/say-hello-to-
| the...
| atonse wrote:
| MS has always been solid with developer tools,
| documentation, and dev relations.
|
| Even though I prefer administering Linux servers any day
| over Windows servers, I find myself often missing
| PowerShell when I use bash. It has some quirks but some of
| the design decisions are exactly what you'd hope someone
| would make if they redesigned a command-line shell 40 years
| later.
|
| I still find it comical that we proudly paste around
| commands that just wrangle text no differently from what
| perl programmers did in the 90s, using sed, print, cut,
| etc, when things like PowerShell moved to piping objects
| between commands. It just removes a whole class of
| ambiguity.
| blibble wrote:
| > MS has always been solid with developer tools,
| documentation, and dev relations.
|
| in my 25 years of using their tooling and reading their
| documentation, they've never been more than what just
| qualifies as borderline acceptable
|
| I booted up VS2019 today for the first time in a while
| (after waiting 90 minutes for it to install) and it still
| feels like using a Jetbrains IDE from 15 years ago, and
| it's still worse than what Borland produced in the 90s
|
| ... and it's even slower than IntelliJ IDEA, which just
| seems amazing as IDEA is written in Java
| 908B64B197 wrote:
| > 90s
|
| The paradigm of sending text in and out of pipes is ~20
| years older than that.
| unnouinceput wrote:
| Wait until you find out CygWin is a thing for decades and
| you could've used Linux style under Windows all this time
| nitrogen wrote:
| There was even a period of time when Cygwin's X server
| supported GLX and I managed to get some OpenGL software I
| wrote for Linux to run in Cygwin, but for some reason it
| was removed or stopped working.
| naikrovek wrote:
| Not at all the same. Not at all.
| girvo wrote:
| I mean sure it's not, but back in the late 2000s I did
| everything under it and it made for a great experience.
| It's little package manager was handy, everything I
| needed was there, it worked surprisingly well.
| entropy1111 wrote:
| >This is really cool. Kudos to Microsoft for really getting
| open source lately
|
| If they get open source so much it means not open sourcing what
| really matters is intentional. And quite frankly getting rid of
| patents, their litigiousness and data collection. But I'm
| asking too much and I would settle for them to just stop
| suffocating competitors, innovation and stop with vendor lock
| in. Same deal for their competitors.
|
| Anything that really matters is just like the same old MS you
| know. DirectX, Office, Xbox, everything SaaS, IDE, compilers,
| debuggers, language servers, file formats, UI frameworks, UI
| patents, GitHub, Windows, Server, you'll find examples in every
| area. Practices like buying or killing competitors like Vulkan
| related acquisitions. I get it they are a company and need to
| maximize profits, so it's cool.
|
| Microsoft has so many quality projects and good people working
| for them, it's just so frustrating that it's still like this.
| This will only get worse as the exploitative behavior and
| business models of their competitors like Google force their
| hand to do the same.
| DennisP wrote:
| "By joining the Open Invention Network, Microsoft is offering
| its entire patent portfolio to all of the open-source patent
| consortium's members."
|
| https://www.zdnet.com/article/microsoft-open-sources-its-
| ent...
|
| Apple had "1,996 total patents granted between July 1, 2019
| and June 1, 2020, more than any other company in Silicon
| Valley."
|
| https://www.bizjournals.com/sanjose/news/2020/07/27/top-
| of-t...
| entropy1111 wrote:
| My recollection from previous OIN threads was that it came
| with a lot of caveats. I can't comment any further from
| lack of knowledge about patents and its subtleties. Would
| love to see an analysis of what really happened in practice
| since they did that.
| galgalesh wrote:
| Microsoft joined the open invention network; a defensive
| patent pool protecting Linux (kernel and distributions). This
| directly cut into their patent revenue and removed some of
| their leverage towards Android OEM's. This matters a lot to
| the android and wider Linux ecosystem.
|
| Moreover, every single Microsoft patent will now be used to
| fight against any patent claim concerning Linux, related open
| source software, and a limited set of codecs. [0]
|
| Given the recent inclusion of an exFAT driver in Linux, this
| hurt MS's business even more.
|
| [0] https://openinventionnetwork.com/linux-system/
| nitrogen wrote:
| _Moreover, every single Microsoft patent will now be used
| to fight against any patent claim concerning Linux, related
| open source software, and a limited set of codecs._
|
| Did Microsoft contribute _all_ of their patents to the OIN?
| I seem to recall IBM only contributed a specific subset
| back in the day.
| me551ah wrote:
| I agree with you.
|
| 1. I run Arch Linux on windows vis WSL which provides pacman as
| a package manager. Pacman is way better than homebrew.
|
| 2. Docker runs much faster on windows compared to Mac.
|
| 3. My Mac will freeze up at times, while ctrl+alt+del always
| works on windows.
|
| 4. I am no longer limited to the crappy gpu options on Mac and
| can actually do gaming on my laptop.
| kyriakos wrote:
| +1 for docker under Wsl2 is way better than macos
| seertaak wrote:
| Agreed. BTW if you're looking for a apt/brew like experience
| on Windows proper, try chocolatey: https://chocolatey.org/
|
| (Obviously there's also the Windows store, which is not bad
| for GUI programs, but for more developer-type stuff - e.g.
| installing python - chocolatey is great.)
| me551ah wrote:
| I love chocolatey and use it quite a bit. But I like Arch
| Linux's AUR more because it contains way more packages.
| Though Microsoft also seems to be on their way to make
| their own
|
| https://devblogs.microsoft.com/commandline/windows-
| package-m...
| reader_mode wrote:
| It's a different use case - use Chocolatey to manage
| native windows installers - it's more like brew casks.
| iimblack wrote:
| Scoop is a good option too IMO.
| thewrinklyninja wrote:
| I prefer scoop myself. Everything is isolated to the users
| profile. Check it out.
|
| https://scoop.sh/
| paulryanrogers wrote:
| Hasn't WinGet superceded Choco of late?
| _Microft wrote:
| You might enjoy the backstory to the Windows task manager:
|
| https://news.ycombinator.com/item?id=23304536
| X6S1x6Okd1st wrote:
| If you find yourself in a Mac again I'd really recommend nix
| over homebrew
| girvo wrote:
| For what it's worth, the GPU thing can be solved using an
| eGPU on Intel macs -- but the thermal throttling and CPU perf
| basically killed that dead in the water for me; I was running
| an RX 590 which worked brilliantly, but gaming itself was
| lacking sadly.
|
| Gave up and built a mini ITX box next to my laptop. Swap
| DisplayPort, swap one USB-C, done!
| nomel wrote:
| > throwing up more and more roadblocks and constricting their
| platform ever more
|
| Do you have any specific examples? From my perspective as an
| app user, rather than developer, the restrictions they've put
| in place seem to be beneficial to me. I like sandboxed apps,
| absolutely love that I can tell an app to bugger off when it
| tries to access some folder that it has no business reading.
| boogies wrote:
| What about GNU? It seems like most Windows-[?]using devs use
| WSL2's Linux VM. What advantages does that have over keeping
| the MS OS's forced updates, BSODs, etc. in a VM, while keeping
| a free OS stably settled on bare metal?
|
| I can imagine drivers, but if you stick to only Dell Developer
| Edition, Lenovo Linux-certified, Purism Librem, System76, or
| similar (still significantly wider selection than Apple sheep
| fans seem satisfied with) hardware, things should work more
| smoothly than with Windows (drivers are built into the kernel
| and update with the OS).
| tonyedgecombe wrote:
| _It seems like most Windows users use WSL2's Linux VM._
|
| Most Windows users haven't got a clue what Linux is let alone
| WSL2.
| boogies wrote:
| Or that Rust isn't iron oxide. I've edited that line to be
| clearer, and I'll link definitions for all the other words
| ~~if someone will show me a pastebin that will hold the
| 583732 byte file I've just created for shell (xargs & dict)
| practice for free~~ Edit: https://ghostbin.com/paste/kgwWc.
___________________________________________________________________
(page generated 2021-01-21 23:00 UTC)