examples crash without a helpful error message when setup.bat isn't loaded

[codebot]

this might be a Windows-specific issue, but if you try to run talker.exe or examples_rclcpp_minimal_publisher_lambda.exe or basically anything (it seems?) without first calling local_setup.bat, Windows 10 pops up the generic "this program has stopped working" box. I'm not sure what the answer is, but it would be nicer to have a friendly error message instead.

[wjwwood]

That's Windows failing to find the .dll files it needs. So this is happening at dynamic linking time. I do not think we can do anything before this. The only thing you could do is wrap all of these in a .bat which makes sure the env is reasonable before running. I don't think this is a very nice thing to do though, because it is awkward to call a .bat file in order to run an exe and because it's not clear to me what the script would check to consider the environment to be reasonably set up.

[codebot]

I see, thanks for explaining. I suppose we could load the DLLs ourselves (rather than asking Windows to do it) because we could then catch the "I couldn't find the .dll" error ourselves and try to have a helpful error message. But that sounds like an awful lot of work.

[wjwwood]

Yeah, that doesn't sound very feasible to me, since we would also have to do that for Linux or have two completely different mechanisms for dealing with shared libraries on Windows and Linux.

Also, it's not just our libraries, it's libraries like boost (via fast rtps) which would need to be loaded manually.

[wjwwood]

You might be able to do Static linking by default on the Windows packaging job (which would required getting static linking working first, but that would be nice anyways). And then you'd still want to have something in our executables which checked the env, because that just works around the missing dll's, but not other things that might break because of the missing source of setup.bat.

[codebot]

Naive question: how do "typical" Windows applications handle this? If you're using MS Word or Firefox or whatever else is popular, and a DLL is moved or not on the loader's path, do they try to catch it, or does Windows just pop up that generic "OH NOES" box for them as well?

[wjwwood]

They put all of the dll's (for their code as well as dependencies not provided on the PATH) in the same folder as the executable. If they use someone else's libraries which are in a different folder which is not on the PATH by default, then they update the default PATH to include that folder with the installer program (.msi or w/e).

[wjwwood]

Or they do static linking.

[codebot]

I see, thanks. And if a DLL goes missing, is it an error box provided by the OS, or do they do a custom error box somehow? (just curious, not worth investigating, only if you know off the top of your head)

On Mon, Dec 19, 2016 at 12:15 PM, William Woodall notifications@github.com wrote:

Or they do static linking.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ros2/examples/issues/161#issuecomment-268066500, or mute the thread https://github.com/notifications/unsubscribe-auth/AFBR2oI-yH7bZQSce-AfX_WAjNIwt0L7ks5rJuXhgaJpZM4LRIPg .

[wjwwood]

The OS provides the error box. There might be a way to customize it, but I'm not aware of one. You could also wrap your executable in a shell script or another program which checks before trying to run it.

[gavanderhoorn]

I think this is actually program-specific. Just tested this - as I was curious as well - with 7z, and when I remove the 7z.dll from the program's installation directory (C:\Program Files\7-Zip) and then try to use 7z, I get:

That seems like what @codebot is looking for.

[codebot]

Ah, thanks @gavanderhoorn I guess my curiosity would be if it was possible to (easily) modify the error box the OS generates, so that we could give a friendly reminder to users about a likely next-step to take as they are troubleshooting. Maybe 7-Zip is loading their DLL "manually" rather than letting the OS load it for them, so they can capture any problems and generate their own error box.

[wjwwood]

I think that's auto generated by the OS. 7-Zip is the executable name (either the file name 7-Zip.exe or maybe there is a way to indicate to Windows what the executable's name is just like you can do so with the icon).

[gavanderhoorn]

It looks like they have a custom DLL/plugin loader mechanism that allows them to catch these kind of things: 7z/CPP/7zip/UI/GUI/GUI.cpp, lines 147-152 (that is not an official repo, but close enough).

[wjwwood]

You're right @gavanderhoorn, that's crazy. It might be worth doing for high visibility programs, but I wonder what the impact would be on our examples. Maybe it could be baked into them somehow so that it wouldn't be added complexity for simple programs.

[codebot]

Maybe we could make something like the roswtf program that tried to dlopen something standard, or just a dummy DLL that we make in that package just for this purpose.

On Mon, Dec 19, 2016 at 12:40 PM, William Woodall notifications@github.com wrote:

You're right @gavanderhoorn https://github.com/gavanderhoorn, that's crazy. It might be worth doing for high visibility programs, but I wonder what the impact would be on our examples. Maybe it could be baked into them somehow so that it wouldn't be added complexity for simple programs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ros2/examples/issues/161#issuecomment-268072296, or mute the thread https://github.com/notifications/unsubscribe-auth/AFBR2oujLXQNQUzcDzG1jF5NAjvsIyNDks5rJuvPgaJpZM4LRIPg .

[gavanderhoorn]

From a quick google, perhaps delayed loading with DLLs could be (ab)used to get something like a generic / customisable error dialogue. A Windows dev would probably quickly point out why that is not a sane approach though (for one thing it could mean 'unpredictable' performance hits as loading of code is done JIT).