STATUS_ENTRYPOINT_NOT_FOUND

[fu5ha]

Hi, When I try to use nwg in my own project, I am getting STATUS_ENTRYPOINT_NOT_FOUND similar to #142. I'm on MSVC. I am able to run the examples, but when included in my own project, it doesn't work.

In Cargo.toml:

native-windows-gui = { version = "^1.0.12", features = ["tray-notification", "message-window", "menu", "cursor", "combobox", "textbox"] }

in main.rs:

extern crate native_windows_gui as nwg;
...
fn main() {
    nwg::init()?;
    nwg::Font::set_global_family("Segoe UI")?;

    let _built_ui = ui::H3SplitApp::build_ui(ui::H3SplitApp::new(log_buffer.clone()))?;

    nwg::dispatch_thread_events();
}

Latest rust stable MSVC

     Running `target\release\h3split.exe`
error: process didn't exit successfully: `target\release\h3split.exe` (exit code: 0xc0000139, STATUS_ENTRYPOINT_NOT_FOUND)

Can share more code if needed.

[fu5ha]

I've narrowed this down to being caused by some kind of incompatibility with parking_lot. If I use std Mutexes instead of parking_lot ones, then I don't get this error.

[gabdube]

I found this issue that could be similar to yours: https://github.com/microsoft/windows-rs/issues/1294

Can you try to enable the "no-styling" feature to disable the auto visual style and enable COM 6.0 using a manifest file. The embed-resources example does that.

[wellitecho]

I ran into this issue just now, and resolved it by doing what riverar suggested

[cfsamson]

Just for future reference. There seems to be som incompatability between how winapi and windows-sys calls GetWindowSubclass which leads to this error.

A rather simple workaround to avoid this problem is to do a cargo tree -i windows-sys and see what packages depend on windows-sys and force those packages to use an earlier version that depends on winapi instead (if possible).

In my case, adding the following to Cargo.toml got everything working:

schannel = "=0.1.19"
mio = "=0.8.2"

[StevePER]

Can you try to enable the "no-styling" feature to disable the auto visual style and enable COM 6.0 using a manifest file. The embed-resources example does that.

This fixes the problem.

[harryhaaren]

Bumped into this issue too; very simple app integrating NWG into a reqwest and tokio snippet.

1. Tried @cfsamson 's fix https://github.com/gabdube/native-windows-gui/issues/241#issuecomment-1153268639 but didn't work
2. Tried @gabdube 's fix https://github.com/gabdube/native-windows-gui/issues/241#issuecomment-1054632856 didnt work either
3. Fixed by adding Manifest file like here https://github.com/microsoft/windows-rs/issues/1294#issuecomment-963417891, however this is the least desirable fix as it required extra files outside the .exe

It allows me to keep playing with the crate for testing, but hoping to resolve in a neater (re-trying the above other solutions) way then.

[ixidion]

I had in my project these error message in coincidence with those two crates: yahoo_finance_api = "1.3.0" and tokio-test = "0.4.2". Pinning the mio-Version to 0.8.2 fixed it for me as described here: https://github.com/gabdube/native-windows-gui/issues/241#issuecomment-1153268639

[Mazwak]

It seems winapi is stalled, last release is over 1 year ago.

Are there any plans to switch to windows-sys (or windows) crate ?

[cfsamson]

The "proper" workaround for now seems to be to use embed-manifest together with a build.rs file:

cargo.toml

[build-dependencies]
embed-manifest = "1.3.1"

buld.rs

use embed_manifest::{embed_manifest, new_manifest};

fn main() {
    if std::env::var_os("CARGO_CFG_WINDOWS").is_some() {
        embed_manifest(new_manifest("Contoso.Sample")).expect("unable to embed manifest file");
    }
    println!("cargo:rerun-if-changed=build.rs");
}

I believe that you can call the manifest pretty much anything you want.

However, migrating to windows-sys seems like the long term solution as it seems to now be the de-facto standard and is backed by Microsoft.