Are there any update plan for this?

[lynnux]

I can't compile the project with latest nightly toolchain. And I'm newbie to rust, have no idea how to get this to work.
error like:
E:\prj\rust\kmd-env-rs\km\examples\01.minimal>cargo build --release
Compiling core v0.0.0 (file:///E:/prj/rust/kmd-env-rs/libcore)
error[E0557]: feature has been removed
--> E:\prj\rust\kmd-env-rs\libcore\lib.rs:77:12
|
77 | #![feature(reflect)]
| ^^^^^^^

[pravic]

Yeah, it is broken for a while. Need to sync.

[pravic]

Tried to update.

1. Float-free libcore (Float-free libcore (for embedded systems and kernel drivers, among other things) rust-lang/rfcs#1364). While someone claims about +soft-float, it doesn't work for me, so I had to use the libcore_nofp patch still.

2. A lot of standard library changes like allocator api, i128 type and so on.

3. Target specification was changed a bit.

[Trolldemorted]

Is the current master supposed to build right now?

I can't get it to work, followed the setting up instructions quite literally:

C:\Users\Benni\repositories>git clone https://github.com/pravic/kmd-env-rs
Cloning into 'kmd-env-rs'...
remote: Counting objects: 351, done.
remote: Total 351 (delta 0), reused 0 (delta 0), pack-reused 351
Receiving objects: 100% (351/351), 1.36 MiB | 1.29 MiB/s, done.
Resolving deltas: 100% (176/176), done.

C:\Users\Benni\repositories>cd kmd-env-rs

C:\Users\Benni\repositories\kmd-env-rs>git submodule init
Submodule 'km' (https://github.com/pravic/winapi-km-rs.git) registered for path 'km'

C:\Users\Benni\repositories\kmd-env-rs>git submodule update --recursive
Cloning into 'C:/Users/Benni/repositories/kmd-env-rs/km'...
Submodule path 'km': checked out '8512c30508c8bcd17b7667020c6716faae5cfccf'

C:\Users\Benni\repositories\kmd-env-rs>rustup override add nightly-i686-msvc
info: using existing install for 'nightly-i686-pc-windows-msvc'
info: override toolchain for 'C:\Users\Benni\repositories\kmd-env-rs' set to 'nightly-i686-pc-windows-msvc'

  nightly-i686-pc-windows-msvc unchanged - rustc 1.22.0-nightly (eba374fb2 2017-09-11)


C:\Users\Benni\repositories\kmd-env-rs>cd km\examples\01.minimal

C:\Users\Benni\repositories\kmd-env-rs\km\examples\01.minimal>cargo build --release
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --cfg disable_float -C soft-float --target i686-sys-windows-msvc --crate-type bin --crate-type dylib --crate-type rlib` (exit code: 101)
--- stderr
error: Error loading target specification: Could not find specification for target "i686-sys-windows-msvc"
  |
  = help: Use `--print target-list` for a list of built-in targets



C:\Users\Benni\repositories\kmd-env-rs\km\examples\01.minimal>

I have to say that my msvc is the one from VS 2017 and not 2015, but the errormessage does not sound like that is the issue here. I am not a total rust beginner, but i have never touched custom targets, and thus have no clue where the target should be specified and why this is apparently not properly done on my installation.

If i explicitely set the rustpath, i get a different error:

C:\Users\Benni\repositories\kmd-env-rs\km\examples\01.minimal>set RUST_TARGET_PATH=C:\Users\Benni\repositories\kmd-env-rs\.cargo

C:\Users\Benni\repositories\kmd-env-rs\km\examples\01.minimal>cargo build --release
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --cfg disable_float -C soft-float --target i686-sys-windows-msvc --crate-type bin --crate-type dylib --crate-type rlib` (exit code: 101)
--- stderr
error: Error loading target specification: Field linker-flavor in target specification is required
  |
  = help: Use `--print target-list` for a list of built-in targets

[pravic]

Is the current master supposed to build right now?

Nah, due to Rust changes it is broken at the moment. I 've managed to update the new libcore, but it needs to implement the new allocator API also.

[Trolldemorted]

I have had a look at the new allocator api and have successfully built a library, but i can't test it because windows refuses to load it.

The target system is running W10 Pro N x64, and I attempt to use https://github.com/maldevel/ServiceInstaller to load the driver. I enabled test signing mode (bcdedit -set TESTSIGNING ON) and I have successfully booted into test mode, but it won't work:

With an unsigned driver, StartService fails with error 577 (ERROR_INVALID_IMAGE_HASH), and a fancy popup appears saying that it did not install the driver.

With a self-signed driver (using SignTool), StartService fails with error 2 (ERROR_FILE_NOT_FOUND), which is odd. The path to the sys file is correct, and a quick look at the documentation reveals that StartService should yield ERROR_PATH_NOT_FOUND (and not file not found) if the path to the service binary is incorrect.

Apart from the small hint

Others[error codes] can be set by the registry functions that are called by the service control manager

I have no clue what went wrong. Was it a dependency that could not be found? These are the lib's imports according to IDA:

How did deploy your driver examples?

[pravic]

Of course you are not allowed to use any of usermode DLLs in kernel mode, that's why service loader complains about it.

I'd like to have a look on your code to figure out what's wrong with it. At least try to avoid any references or crates, use only libcore and external NT Kernel API functions.

P.S. As for deployment - the easiest way is to setup a VM with Windows XP, actually. Windows 8 and higher is for experienced driver developers :)

[kgv]

@pravic Are you still have plans to upgrade this project to working condition?

[pravic]

No idea, to be honest. Technically I can..

Need to check whether we can skip the "libcore_nofp.patch" part.

As for the further development - I doubt that. It was more of (an exciting) proof of concept rather than a real project: porting the whole Windows Driver Kit isn't a good idea, as for the simple clib-style bindings - it would be possible, but worthless perhaps.