[3RD PARTY] Windows Kernel-Mode Drivers written in Rust

[forart]

Project page: https://github.com/pravic/winapi-kmd-rs

This library is just a proof-of-concept of the windows kernel-mode drivers, which can be written in Rust programming language.

It contains the types, constants and bindings for the Windows Driver Kit with target OS starting from Windows XP (x86/x64).

Dunno if can help ROS in any way, BTW its dev should be informed/involved IMHO: https://github.com/pravic

[erkinalp]

It can help ReactOS. Rust is 100% C ABI compatible. However, there is only one Rust compiler vendor versus 3 supported C++ vendors among many of them.

[Z98]

Unlikely to help us. We require any code that is considered for inclusion in ReactOS to be C or C++ and compilable by msvc and gcc/g++. Any driver written by rust is by definition disqualified. And I question whether kernel developers working in the industry would have any incentive to adopt rust.

[lumix]

Common Intermediate Language bsd implementation: https://en.m.wikipedia.org/wiki/Cosmos_ ... ng_system)

[erkinalp]

We require any code that is considered for inclusion in ReactOS to be C or C++ and compilable by msvc and gcc/g++. Any driver written by rust is by definition disqualified.

Until GRust and Visual Rust is out.

[PurpleGurl]

Unless there is a good Rust to C converter that would produce fully-compliant C code (and carry the comments over in the right places). Then in that case, if the code is fully compliant and has the right open source licensing, then one could use the converter one time and then maintain it as C. Just some musings out loud.

[Z98]

We require any code that is considered for inclusion in ReactOS to be C or C++ and compilable by msvc and gcc/g++. Any driver written by rust is by definition disqualified.

Until GRust and Visual Rust is out.

Uh, no, we're still going to require code written in C or C++ only.

[erkinalp]

That's why? We will need no extra machinery in our build system.

[PurpleGurl]

That's why? We will need no extra machinery in our build system.

Yes, but this could limit those who can help on the project. If you include too many languages and you have developers using languages that only one dev knows, then what would happen if they left? And while Rust is similar to C and C++, it doesn't seem that many are adopting it. So you don't want to fragment your developer base.

What if Gigaherz had done all the work in Rust? He got a bit burnt out towards the end of the explorer work. That didn't affect us much since he did the heavy lifting, and it was done in C++ and C so others like Giannis could pick it up.

So what if you have only 1 developer coding in Rust and they reach a point of burnout or a fundamental, irreconcilable difference with the project? Or they have a protracted illness or even pass? So you don't want key parts coded in things that only a developer or 2 knows.

I've looked for Rust to C converters and cross-compilers, but I've found none. And according to some online, the converted code might not necessarily be "safe" code. That's no real problem for a good developer, as they can spot the potentials for memory leaks, overflows, data overruns, etc. (And there is Coverity and other conformance tools.)

[EmuandCo]

Best example we have right now: NTVDM. No sound yet... well, yes we have the needed code, but it's written in some BASIC language. So someone has to port it over to get things work for everyone. Nope, we will NOT add support for RUST to RosBE. At least not as long as I have some right to argue in that matter, too.

[erkinalp]

I've looked for Rust to C converters and cross-compilers, but I've found none. And according to some online, the converted code might not necessarily be "safe" code. That's no real problem for a good developer, as they can spot the potentials for memory leaks, overflows, data overruns, etc. (And there is Coverity and other conformance tools.)

You will find the converters for the other way. Rust's safety comes from affine typing and statically checking all uses. All Rust to Rust interactions are safe according to typing discipline. Rust to C interaction may be safe yet is controlled by typing again(you cannot interact with non-Rust code without typing

Code: Select all

unsafe { /* your code */ } 

)however you will only need to mark Rust to C wrappers unsafe, and will not need to modify it frequently while editing Rust or C code because of ABI compatibility with C. Converted code may look unsafe because Rust's compiler is highly optimising.

[Z98]

The chances of us ever accepting 'generated' or 'auto-converted' code is effectively nil. Such code is extremely difficult to debug and look through because of how messy the resulting code is. And once you find a bug, the question becomes whether the bug was in the original code or due to the generator or so on. It adds a significant amount of complexity for no extra gain on the part of the project. If someone submits a patch that looks like complete gibberish, it will get rejected. Our code has to be maintainable. Auto-generated code tends to be anything but.

[PurpleGurl]

That was why I mentioned about carrying over of comments, etc. What I meant was for a developer who was proficient in C or C++ to convert the code and then format it, make it safe, clean up any variable size dilemmas, etc. But if it's more work than if they were to write from scratch, then no, I wouldn't want to use it. You might have to take the generated code, generate a flow chart from it, and then code from the chart back. And if the code is complex, then that idea is out.

I agree that if patches start looking like gibberish, I wouldn't want them submitted. It's bad enough being a volunteer supervisor on a well-known Q&A site. I contend with trolling and gibberish on occasion. For instance, take a question asking about the symptoms of cancer. The answer: "The symptoms of cancer are cancer, death, and dying. However, if you rub unicorn [semen] on the lesions, they will go away." It turns out that the answer came from an automated bot, and it sometimes even used profanity. To make things more disturbing, the Q&A site's technical team coded the bot that was giving poor quality answers that supervisors like myself would block actual contributors over. Since it had a supervisor badge, we couldn't block it. (Community Assistants could, but since they created it, any sanctions would be unlikely.) So it was frustrating. They disbanded the bot after complaints, but then it seems they reintroduced the bot as "anonymous" posters. I asked a question about how you can stop bots from answering your questions with pat answers and received, "The way to stop bots from answering your questions with pat answers is to block their IP address." I laughed at the irony. A bot obviously answered that. That's their format, to rephrase the question and then give a pat answer. The bot's advice doesn't work. End users cannot block IP addresses, and supers who randomly block IP addresses of contributors will get demoted. There are a few random IP users we are allowed to just block right out for very long periods of times, including diet pill spammers, car quote spammers, paedophiles (like the so-called "nipple vandal"), and one prolific nonsense poster. Anyway, the nonsense spammers are annoying, so I can understand not wanting gibberish source code. It's bad enough dealing with Indian ESL posters, since their English is not the best. At least chat speakers tend to be a little easier to clean up after, unless every word is in chat/text speak. Of course, most vandals don't speak in gibberish. They just use profanity, so I just delete those answers and warn the contributors.

Sorry about the OT posting, but I was just saying I understand the frustration of receiving nonsense code.