Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Programming Microsoft

Microsoft Previews 'Rust for Windows' (microsoft.com) 70

From Mike Melanson's "This Week in Programming" column: "The Rustening at Microsoft has begun," tweeted Microsoft distinguished engineer Miguel de Icaza.

What de Icaza is referring to is a newly-offered course by Microsoft on taking the first steps with Rust, which much of the Twitterverse of Rust devotees sees as a sign that the company is further increasing its favor for their crab-themed language of choice. Of course, this isn't the first we've heard of Microsoft looking to Rust to handle the 70% of Microsoft vulnerabilities that it says come from using the memory-unsafe C++ programming language in its software. A few years back now, Microsoft launched Project Verona, a research programming language that takes a bite from Rust in the realm of ownership and is said to be inspired by Rust, among others.

More recently, however, Microsoft announced the preview of Rust for Windows, which "lets you use any Windows API (past, present, and future) directly and seamlessly via the windows crate (crate is Rust's term for a binary or a library, and/or the source code that builds into one)." With Rust for Windows, developers can now not only use Rust on Windows, they can also write apps for Windows using Rust...

According to the project description, the Windows crate "lets you call any Windows API past, present, and future using code generated on the fly directly from the metadata describing the API and right into your Rust package where you can call them as if they were just another Rust module" and that, along with the introduction of a course for learning Rust, is precisely what has all those Rust devotees so excited.

InfoWorld has more information...
This discussion has been archived. No new comments can be posted.

Microsoft Previews 'Rust for Windows'

Comments Filter:
  • by Ostracus ( 1354233 ) on Saturday April 24, 2021 @01:46PM (#61309282) Journal

    Of course, this isn't the first we've heard of Microsoft looking to Rust to handle the 70% of Microsoft vulnerabilities that it says come from using the memory-unsafe C++ programming language in its software.

    All these decades and memory management seems to be the most difficult thing to handle.

    • Re: (Score:3, Insightful)

      It's actually rather simple; just use a garbage collector and don't use unsafe pointers. That makes it impossible for you to make a memory management error outside of retaining things for too long.
      • by DrXym ( 126579 ) on Saturday April 24, 2021 @02:39PM (#61309458)
        Garbage collection comes with a cost. For example in Go (which has garbage collection), the GC can freeze the world while it frees stuff up. In a high level application that's no big deal, but it is the lower into the system you go or for timing sensitive stuff. In addition it can affect how you write code, e.g. creating lots of temporary objects is bad in a garbage collected language. Garbage collection also has a tendency to make memory consumption go up and down like a yo-yo which isn't much good for embedded systems.

        So instead Rust doesn't use GC but does what C and C++ do. Objects either reside in the stack or in the heap. The compiler tracks lifetimes during compilation and knows where to put the allocations and the frees if they're needed. It also has constructs sort of analogous to smart pointers in C++ called a Box (scoped pointer) and a Rc / Arc (shared pointer) that will free up when their lifetime ends.

        • by K. S. Kyosuke ( 729550 ) on Saturday April 24, 2021 @02:54PM (#61309494)

          For example in Go (which has garbage collection), the GC can freeze the world while it frees stuff up.

          Go is hardly the pinnacle of automated memory management. There have been way better implementations of it, such as C4. Having said that, even Go apparently got fairly good in the recent versions (or so they say).

          The compiler tracks lifetimes during compilation and knows where to put the allocations and the frees if they're needed.

          Yes, at the expense of twisting your program from the beginning to have a particular shape, for example the inability to construct general object graphs. So certain kinds of useful programs such as object databases are impossible to write this way.

          It also has constructs sort of analogous to smart pointers in C++ called a Box (scoped pointer) and a Rc / Arc (shared pointer) that will free up when their lifetime ends.

          And that comes at the expense of having to do frequent atomic operations in a multi-threaded environment, otherwise the refcount bookeeping wouldn't work at all (plus the memory overhead of those references).

          • And that comes at the expense of having to do frequent atomic operations in a multi-threaded environment, otherwise the refcount bookeeping wouldn't work at all (plus the memory overhead of those references).

            Honestly that's way overstating it, atomic ref counting really isn't that big of a deal. If you really hate it that much, there are probably some tricks you can do using unsafe to get around it, but the performance you'll gain from it is almost certainly not worth it. Rust is flexible enough that there are plenty of ways of skinning any given cat. Though it's really telling that you advocate the use of a garbage collector yet at the same time you're complaining about the expensive of atomic ref counting.

            • Rust makes atomic refcounting performant by almost not using it, rather relying on stricter dependencies between objects and enforcing ownership most of the time. Likewise GC'd languages make GC fast by almost not doing it as well, relying on the generational behavior. There's no silver bullet and everyone in the class is cheating to pass the test. ;)
              • Rust makes atomic refcounting performant by almost not using it, rather relying on stricter dependencies between objects and enforcing ownership most of the time. Likewise GC'd languages make GC fast by almost not doing it as well, relying on the generational behavior. There's no silver bullet and everyone in the class is cheating to pass the test. ;)

                So relying on memory to be defined for it beforehand by another language that's "supposed" to be so bad at it? Another general question is this how well does this solution scale up with undefined upper limits, without a language like C/C++ doing the heavy work in the kernel?

            • by DrXym ( 126579 )
              Rust gives an Rc for refcounting within a thread and Arc for across threads. If you try to transfer data across threads with the wrong type, the compiler will kick your ass. So providing something only resides in a single thread, use Rc and save a little cost for atomic operations. In that regard it's more efficient than C++ since a std::shared_ptr is atomic ref counted to be thread safe even when it doesn't need to be.
          • by DrXym ( 126579 )
            And that comes at the expense of having to do frequent atomic operations in a multi-threaded environment, otherwise the refcount bookeeping wouldn't work at all (plus the memory overhead of those references). No, because Box isn't atomic and Rc isn't atomic. In fact, Arc is the atomic ref counted memory allocation and if you don't need for in your graph example, don't use it.
            • ...what did you think I was talking about? If you don't have memory sharing you might as well go for the Erlang heap model and be done with it.
              • by DrXym ( 126579 )
                I really don't know since you are not required to do "frequent atomic operations". I am pointing out the language allows non-atomic reference counting if that is desirable.
        • BTW I've just checked on Go and apparently in 1.15 or so they got rid of STW marking, if I understand it correctly. Now marking should be concurrent only with two shorter STW phases at the beginning and at the end. So it's not quite accurate to say that "the GC can freeze the world while it frees stuff up". Some mutator goroutines may run into write barriers but in general the mutators should be progressing "while stuff is being freed up" in the latest version of Go. This is of course still a far cry from C
          • by DrXym ( 126579 )
            That's good to know although I hope you understand that no matter how they do it is always going to be suboptimal to the code itself knowing when objects are no longer used.
            • It's not even always possible to know "when objects are no longer used". It would be equally suboptimal to remove a row from a database table just because you think nobody needs it anymore. So for example a system with persistent objects can't use Rust's approach.
              • by DrXym ( 126579 )
                No it's not always possible. But most of the time it is. And in the other cases for shared objects then you wait for the reference count to hit zero and deallocate right there. In the GC world there would be some kind of mark and sweep algorithm or similar which tries to figure which objects are no longer used and it would be way more expensive overall.
        • Comment removed based on user account deletion
          • by DrXym ( 126579 )
            Rust doesn't have "automatic garbage collection". It just tracks and enforces the lifetime of objects at compile time and inserts free calls (if need be) in the generated code. It would be the same as correct C code calling free() if it needs to. It would also compile to nothing if there is no need to free, e.g. if the instance wholly resided on the stack or the data was move assigned somewhere else. It basically uses stack and heap just like C/C++ would and has analogous types. e.g. Wrapping a struct in Rc
      • It's actually rather simple; just use a garbage collector and don't use unsafe pointers. That makes it impossible for you to make a memory management error outside of retaining things for too long.

        No. You can have an object that is referenced but unused, which happened a lot in the earlier Spring framework. Here's a simplified way [pastebin.com] of how that happens.

        The static reference indicates that so long as the given class is loaded, the ArrayList list will exist, even if you never need it again. It will only be gone once you explicitly unload the class from the JVM or the application closes. And early on many objects in Spring had static lifetimes but programmers would call them into existence as if they w

        • No. You can have an object that is referenced but unused

          I guess you completely ignored the part where I wrote:

          outside of retaining things for too long.

          rendering the rest of your text redundant. Also, the need for weak references have nothing to do with cycles. Proper garbage collectors are not confused by cycles even with strong references. If a cycle is not reachable from roots, it gets thrown away. Likewise Java language design deficiencies are avoidable and don't have to be repeated in other languages.

          • I guess you completely ignored the part where I wrote:

            No I caught that, that still doesn't mean that GC is a magic bullet. So when you say

            It's actually rather simple

            Actually it isn't and you still need to have competency to avoid memory leaks. You just magically carving out some exception doesn't make it so. Which is where you miss my point of:

            A GC ensures that you do not leak memory for most cases, but it is an insane proposition to assume that it will prevent ALL leaks.

            rendering the rest of your text redundant

            No because it ignores the point that I made with try-with-resouces, which the GC isn't watching for by default hence the syntax.

            Proper garbage collectors are not confused by cycles even with strong references

            *sigh* I mean are you going to stay in one lane or you just going to be all over the place? Because you either are

            • No I caught that, that still doesn't mean that GC is a magic bullet.

              I never said that it was a silver bullet. Every solution has some drawbacks. It's just that for GC, lack of memory safety isn't one of them.

              Actually it isn't and you still need to have competency to avoid memory leaks.

              But not memory safety, which is what the comment I was responding to [slashdot.org] was about.

              No because it ignores the point that I made with try-with-resouces, which the GC isn't watching for by default hence the syntax.

              ANOTHER point that doesn't have anything to do with memory safety? How many of them will be there?

              *sigh* I mean are you going to stay in one lane or you just going to be all over the place? Because you either are going to say, "yeah that's true in a single threaded environment"

              Proper garbage collectors are not confused by cycles even with strong references even in multi-threaded environment.

              is some serious attempt to bend reality to match up with what you're trying to prove.

              Are you claiming that the cycle won't be collected? You should file a bug repor

              • My position is that GC solves the memory safety problem that MS struggles with.

                No, it doesn't. When you need to do systems programming, or when you need to write highly performant code, garbage collection simply isn't an option. Rust gives you both highly performant code comparable to C, AND it gives you memory safety. No other language does, save for a few experimental ones.

                • It does that, at the cost of some pretty severe limitations. Expressive, safe, fast -- today, pick two. I wonder what the status quo would be today had Azul Vega-like features been present in mainstream CPUs for much longer time rather than for the last few years or so. At the very least you'd definitely have a greater range of options today.
                  • It does that, at the cost of some pretty severe limitations

                    Those are only limitation if you do not understand the syntax and underlying point of Rust.

                    Expressive, safe, fast -- today, pick two

                    In systems programming there is only a pick one (out of the options you've given) and it is "safe" everytime. If that is not the case, then whoever does not need to be in systems programming. And that is ultimately the biggest problem MS has with their WINAPI. The nice thing about Rust is that it allows you to indicate particular contracts that you must obey by or the compiler will require you to wrap it in unsafe

                  • Expressive, safe, fast -- today, pick two.

                    Rust gives you all three. Really. The only "limitation" of Rust would be that it's not as old as the mainstream systems languages, so there aren't as many libraries available for it, but that is very rapidly changing.

                    • Two and half. It's somewhat expressive but lacking in some places. If people have to ask "how do I represent a generic graph" and the answer is "you can't" [stackoverflow.com], then clearly there's some deficiencies to be addressed. Or, one perhaps could treat Rust as a lower-level language, if it doesn't pass the muster for high-level language in the "language X is high-level if you don't have to think about details irrelevant to your level of abstraction" sense. That is NOT necessarily a negative thing; the world has needed
        • An object that can both own and construct another object that can do likewise with the other can lead to cycle references that a GC just simply can never dispose of.
          that is nonsense.
          If there is no reference (or chain of references) from the stack or static class members, those are cleaned up just fine.

          A circle is a group of objects that reference each other, and can not be reached from "the main function" or any location on the stack. And that is the reason why reference counting is not garbage collection.

      • by jythie ( 914043 )
        Even simpler : use the stack.
        • by ebvwfbw ( 864834 )

          Even simpler : use the stack.

          Just allocate a new process onto the stack. Yea... Try it. See how that works out.

    • by gweihir ( 88907 )

      Of course, this isn't the first we've heard of Microsoft looking to Rust to handle the 70% of Microsoft vulnerabilities that it says come from using the memory-unsafe C++ programming language in its software.

      All these decades and memory management seems to be the most difficult thing to handle.

      Not really. But I think there are too many people that underestimate memory management or do not want to be bothered by it. These people then screw up. But there are plenty of software packages written in memory-safe languages that have security problem after security problem. That is why the move to Rust is bogus. It fixes the wrong problem.

  • by doragasu ( 2717547 ) on Saturday April 24, 2021 @01:52PM (#61309302)

    Rust applications can be easily built for Linux, Windows and Mac as long as the crates they use are available for these OSs. Use this Windows crate and you break your app for Linux and Mac.

    • by gtall ( 79522 ) on Saturday April 24, 2021 @01:56PM (#61309316)

      So it is working as intended then.

      • by DrXym ( 126579 )
        Don't use a crated intended to provide Win32 bindings if you don't have a reason to call Win32. This should be obvious. Microsoft wrote a crate because the existing Rust bindings were hand edited and they have produced an alternative that used machine descriptions of Win32 APIs.
      • If the intent is to break compatibility with anything, then it won't work very well. The only reason you'd need to use this crate is if you are trying to do something specific with the win32 api that you can't realistically do any other way. Whenever you use this in cross platform code, precede those bits with this:

        #[cfg(target_os = "windows")]

        Then when you compile for linux, that part won't be compiled in. Likewise, if you're doing something specific for Linux, you use this:

        #[cfg(target_os = "linux")]

        Then

    • by ArmoredDragon ( 3450605 ) on Saturday April 24, 2021 @03:50PM (#61309646)

      Use this Windows crate and you break your app for Linux and Mac.

      No you don't; Rust has macros that allow you to specify where your code does one thing in one OS, and another thing in a different OS.

      You can basically think of this crate as being a more feature complete version of the winapi crate, which tons of other crates that are cross platform already rely upon. Here's one that I use all the time:

      https://github.com/hwchen/keyr... [github.com]

      • by tepples ( 727027 )

        Rust has macros that allow you to specify where your code does one thing in one OS, and another thing in a different OS.

        For example, you could have an application that works in Windows and displays "GUI missing; pull requests welcome!" on other operating systems.

  • Its Rusting (Score:4, Funny)

    by nicolaiplum ( 169077 ) on Saturday April 24, 2021 @02:08PM (#61309366)

    Accretion of rust on something is called rusting.

    Microsoft is rusting.

  • Ironic (Score:4, Interesting)

    by Elledan ( 582730 ) on Saturday April 24, 2021 @02:13PM (#61309386) Homepage
    The irony here is that MSFT never bothered to offer C++ APIs, only the most horrible C APIs, between Win32 and MFC.

    They probably reckoned that C# (.NET) would win out over C++, so when it didn't they're now trying to save face by jumping on a bandwagon.

    What about that D or Ada API, Microsoft? :)
    • Re:Ironic (Score:5, Interesting)

      by Dwedit ( 232252 ) on Saturday April 24, 2021 @03:18PM (#61309552) Homepage

      Microsoft offered many COM APIs, which were designed around their VTable format. Despite being callable from C, they are basically C++ APIs.

      • by DrXym ( 126579 )
        Microsoft had ATL which was COM but also served as a lightweight wrapper around Win32 functions for windows / dialogs. They also had MFC which was a lot more heavy weight but did pretty much everything a desktop app at the time needed.

        I think if I were intent on writing a GUI application on Windows these days I'd be using something like QT or wxWidgets. Not only is it fairly convenient, but also it makes cross-platform development viable too.

        Getting back on topic, I think that GUI development is definit

  • ... an implementation of Java that seemed to be so incompatible as to raise questions whether Microsoft was intentionally trying to hinder or destroy Java's acceptance? Will Rust suffer a similar fate at the hands of Microsoft?
    • No, this doesn't modify rust in any way, nor is it Microsoft's own implementation of rust. It's basically a shim that makes it easier to call win32 functions in a way that feels more native to rust rather than building your own FFI interfaces manually. For most things you do with rust, you won't need this, but if you're calling any win32 functions, it's really handy.

    • by DrXym ( 126579 )
      They developed a crate for Rust which has better bindings for calling Win32 than an existing crate. They are not subverting the language here.
    • Yes the MS version may be incompatible but, no, that may not be an issue. Java was intended by Sun to be cross-platform and standardized; the Java licensing specifically stated this. Microsoft intentionally introducing incompatibility went against the licensing and was clearly out to harm Java. With Rust, there is no current standardization of the API and the licenses (Apache and MIT) do not forbid MS creating their own incompatible version. Also due to the nature of the purpose, incompatibilities between v

  • We are talking about Windows here, right?
  • Don't they have to come up with a standard Microsoft name for it? Or will it just be Rust Sharp?
  • So... (Score:2, Insightful)

    by Anonymous Coward
    If 70% of Microsoft's vulnerabilities come from unsafe memory handling errors in C++ land you'd think they could run a simple static analsysis to find and fix them, right? Or is it only attackers that arr smart enough use static analysis to find and exploit them?
    • by Jeremi ( 14640 )

      If 70% of Microsoft's vulnerabilities come from unsafe memory handling errors in C++ land you'd think they could run a simple static analsysis to find and fix them, right?

      Static analysis tools aren't able to detect all (or even most) memory-handling errors. It would be awesome if they could, but as usual the Halting Problem comes in to ruin the fun.

      • The halting problem only shows that there's an infinite number of programs can't be statically checked, it doesn't prove that the "measure" of this set of uncheckable programs inside the set of programs written by humans is significant. I really think that people over stress its meaning.

        Also, from a pure theoretical point of view, since our machines are finite, you can say that they are not turing machines but finite state machines, which renders the halting problem meaningless. I feel like people like to u

        • The halting problem only shows that there's an infinite number of programs can't be statically checked, it doesn't prove that the "measure" of this set of uncheckable programs inside the set of programs written by humans is significant. I really think that people over stress its meaning.

          Rust's type checker is a static analysis. It's pretty much state-of-the-art.

          Also, from a pure theoretical point of view, since our machines are finite, you can say that they are not turing machines but finite state machines, which renders the halting problem meaningless.

          Well not meaningless but the situation is indeed more complicated than computable or not computable. Any static analysis needs to complete in the amount of time you're prepared to wait for it, or it's not very practical. Indeed, Rust's type checker is often criticised for being slow.

          I feel like people like to use the halting problem simply as an excuse to not improve static checking and/or theorem proving for programs.

          Have you improved static checking and/or theorem proving? If not, what's your excuse?

          • I've done most of my programming either in OCaml or C++, with the C++ code always using unique/shared pointers and as much useful static asserts as I can think of. As for why I'm not doing theorem proving, the answer is quite simple, because it would slow down my coding and my employer prefers me to crank out code faster even if it is less secure. That's market conditions for you.

    • by DrXym ( 126579 )
      I'm sure Microsoft have tried that and come to the same conclusion that everyone else has who has tried static analysis - they find some issues but not all of them. And the tools are usually slow, memory hungry, janky AF and spew out a lot of false positives.

      That said I doubt they would have any reason to rewrite that code in Rust. If it works and is stable, it makes sense to leave it the way it is. But for new code it makes a lot of sense to consider Rust because it stops bugs from happening in the first

    • If static analysis could find all unsafe memory handling in C++, then that would be built into a good C++ compiler. As far as I know, the design of C++ does not allow complete analysis of that kind. There are holes. A tool like Valgrind can detect memory errors, but only by running code on a virtual machine. This is a species of testing, rather than static analysis. I am pretty sure it is possible to write code that looks OK under Valgrind, but contains memory unsafe operations that were missed in testing.

  • They're actually playing nice, building a crate rather than a whole reimplementation of the language.

He who has but four and spends five has no need for a wallet.

Working...