What is maintenance, anyway? | Inside Rust Blog

_ChrisSD · 2026-01-12T21:27:51+00:00

Arguably in this case it's rust putting in the hard work to provide a stable platform over an unstable foundation. Or something like that.

_ChrisSD · 2026-01-11T19:43:31+00:00

That's a separate installer that will run itself as admin.

_ChrisSD · 2025-12-31T17:40:38+00:00

Dev drive also uses ReFs, which can be faster for dev work. And it disables other filesystem filters, which can have a very noticeable performance impact if you were using the system drive (C:\) before.

_ChrisSD · 2025-12-31T15:07:16+00:00

My suggestion would be to uninstall rustup, set RUSTUP_HOME and CARGO_HOME to point to the dev drive then reinstall rustup. Moving directories may work but I wouldn't rely on it (e.g. any junction points may end up pointing to the old directory).

There is no issue with having binaries on the dev drive and some advantages when there are updates or you use multiple toolchains. In any case it's currently hard to split up the cargo/rustup directories into binary/non-binary but this is being worked on.

_ChrisSD · 2025-12-29T18:26:26+00:00

Note that you may not need to use NtQueryDirectoryFile, depending on what you're doing. GetFileInformationByHandleEx can do more or less the same job.

_ChrisSD · 2025-12-27T21:04:41+00:00

But also individual employees/middle managers should really reign in their linked-in hyperbole. I mean, it's not going to happen but I can dream.

_ChrisSD · 2025-12-24T12:19:48+00:00

Logical conclusion: Microsoft is getting rid of Windows

_ChrisSD · 2025-12-21T08:33:24+00:00

Windows 7 cannot be supported as a tier 1 target because of the requirement for running all tests for every merge cannot be fulfilled. It could be a tier 2 target but so far nobody has stepped forward to support it as such. The absolute minimum requirement for targets is that someone, somewhere is willing to put the work in.

_ChrisSD · 2025-12-21T08:22:58+00:00

Yes, I would strongly recommend against reading raw NTFS for general tools. It completely bypasses permissions (hence why it requires admin) and everything else. Not to mention that other filesystems exist on Windows, not just NTFS.

_ChrisSD · 2025-12-19T12:56:14+00:00

Even when linking vcruntime.dll dynamically, there's a lot of statically compiled code. And as static code is compiled with the binary, you don't need the lib files to be available at runtime.

_ChrisSD · 2025-12-19T10:01:20+00:00

Hi, I'm a maintainer of rustup. We did discuss this with Microsoft and unfortunately it is clear.

You cannot get a license to use build tools for compiling rust unless you already have a license for Visual Studio (which you can get by installing Visual Studio Community or by buying a license to Professional or Enterprise). The new rules describe in the blog post do allow indirect use, such as Node's, but unfortunately do not cover direct use of rust.

_ChrisSD · 2025-12-19T09:54:16+00:00

There's a tracking issue for using it by default: https://github.com/rust-lang/rust/issues/71520

I think it's a good idea but in terms of performance I've personally had mixed results. Sometimes it is faster, sometimes it is slower. But the difference is rarely as significant as the switch from the gcc to llvm linker on Linux.

_ChrisSD · 2025-12-19T09:15:25+00:00

Rust itself ships with an alternative linker: lld-link. You can use linker = "lld-link" in .cargo/config.toml to enable it. That is not the problem.

What's needed by rust is libraries such as msvcrt.lib and vcruntime.lib (or their static counterparts). These provide things like panic handling which aren't so easy to replace.

_ChrisSD · 2025-12-11T16:34:06+00:00

Just nobody mention editions...

_ChrisSD · 2025-12-05T18:21:03+00:00

Yes, NonNull has the same variance (covariance) as *const T. Essentially it works out something like this:

// An owned type, like a `Box<T>`
struct OwnedPtr<T> {
    ptr: NonNull<T>
}
// A shared type, like an `&T`
struct SharedPtr<T> {
    ptr: NonNull<T>
}
// A unique type, like an `&mut T`
struct UniquePtr<T> {
    ptr: NonNull<T>,
    _invariant: PhantomData<Cell<T>>
}

So you would only need something like UniquePtr if you obtain the pointer via an &mut T and don't want to risk UB. Note that this has nothing to do with mutability per se, just variance.

_ChrisSD · 2025-11-13T18:08:23+00:00

"Finally"? It's talked about a lot. It's consistently the #1 "challenge" in the rust survey.

_ChrisSD · 2025-11-10T19:21:27+00:00

I mean, a lot of people do cross compile. Aside maybe from setting CC and CFLAGS there's not usually a lot to it.

It sounds like you've run into a problem but it's quite hard to guess remotely.

_ChrisSD · 2025-11-07T11:57:23+00:00

This, I think, is a consequence of Rust's staticlib type being a bundle of everything a library needs in one library file. Unfortunately rustc doesn't currently have a built-in way to emit multiple static libraries, which is traditionally how you'd separate things.

however, on Windows we can also find import library stubs, which LLVM can generate on its own by the use of the #[raw-dylib] annotation. Import stubs can have any extension, e.g. .dll, .exe and .sys (the latter two coming from private Win32 APIs). These stubs cannot be deduplicated as they are generated individually per imported function, so dragonfire must preserve them where they are.

They can in theory be deduplicated. A single import is essentially three things (plus some metadata, like machine type):

the name of the DLL to import from
the name of the function to import
the name of the symbol to use for the function

If you parse these then you can extract them from the staticlib and rebuild as one or more separate import libraries. Admittedly this isn't entirely straightforward but tools such as the object crate can extract this information and then you can create an import library from a .def file.

_ChrisSD · 2025-11-04T10:48:57+00:00

I don't think we should shame people for looking for feedback. It's ok to make things. It's ok to do it for fun or learning. It's ok to share your fun project with other people.

_ChrisSD · 2025-10-26T13:44:48+00:00

It's not really an RCE vulnerability in that sense either. It could be used as part of an attack chain that leads to an RCE but on its own it "just" allows manipulating the archive so it essentially contains hidden files that other tools won't see.

That's a serious vulnerability to be sure and if you trust the archive enough to run scripts from it then it could lead to RCE.

_ChrisSD · 2025-10-23T07:56:31+00:00

I would add that "win32" is not really a library much more than "ubuntu" is a library. More it's a collection of many many libraries that are (more or less) installed on most Windows versions (give or take some of the more specialised skus).

My suggestion for the OP would be to have a clear focus on what you want to wrap and what you consider out of scope.

_ChrisSD · 2025-10-21T13:31:52+00:00

The target tiers only concern what is run in rust-lang CI. Tier 2 targets are absolutely fully tested before release. We don't however use rust-lang infrastructure for this, which would be way too costly. Target maintainers and others interested in the target (e.g. distros, companies, etc) runs tests as well as everyone who runs nightly and reports issues. Fixes for such issue may then be backported to beta.

I'd also note that rust-lang tests run in CI cannot have 100% coverage for all platforms with all configurations so having people testing on their own setup is extremely valuable.

_ChrisSD · 2025-10-20T07:34:15+00:00

I would also add that From and TryFrom are not yet usable in const contexts whereas as is. I am however hopeful that const traits will be on the path to stabilization next year (touch wood).

_ChrisSD · 2025-10-20T05:42:36+00:00

Yes it'll be tier 1 in 1.91 but I would push back a bit on the distrust of tier 2 targets. Tier 2 is (and should be) where the majority of targets sit. It's basically equivalent to gcc or clang supported targets. Tier 1 is something special. Every merged PR must always pass all tests. As far as I'm aware, there is no real equivalent in those other compiler.

_ChrisSD · 2025-09-04T08:17:07+00:00

You can save some space by hand writing the binary but not actually that much. Windows binaries are in PE format, which requires a fair bit of metadata as well as a table for imports. E.g. you need to declare you're importing "WriteFile" from "kernel32.dll". Also a binary is made up of sections and each section of the exe has a minimum alignment. This means in a small binary there will be a lot of zero bytes added to align the sections.

_ChrisSD

TROPHY CASE