SKP 2017 Launching external .exe making https calls

:laughing: okay, I was writing up an example of doing just that.
Glad you found how to do it.

SketchUp started shipping the stdlib with SU2014 - when we upgraded to Ruby 2.

Sorry, late in for this thread. Are you having issues with OpenSSL from your own application when it’s been launched from SketchUp?

Hi all :slight_smile:

Now i am using wsscript to launch my external .exe like this:
(this script is generated in Ruby and then launched via system(…) function)

Set WshShell = CreateObject("WScript.Shell")
WshShell.Run """C:\Program Files\TestApp\V1\App.exe"" fr Sketchup 2017 csv basic checkversion", 1, false

And this shows this error:

Edit : Translation of the error should be something like this:

Ordinal 4684 not found in dynamic link library C:.…ssleay32.dll

I have also received a good news : on 4 other computers Sketchup 2017 can launch my .exe
So there is something wrong on my computer and on 2 others on wich i have tested.

My .exe is a QT application and there seem to be some issues with OpenSSL. But i have only read about it, i never experienced issues myself. I have just seen that some issues have been adressed in the latest (5.9.x dated 29 May 2017) version of the framework. I try it immediately.

I have rebuild my .exe with the latest QT framework and the problem remains the same.

When using the wsscript described above:

  • from within SKP 2017 i have an error (as described in above post).
  • from the explorer (simply running the .vbs file) is OK.
  • from within SKP 2015 is OK.
  • from within SKP 2016 is OK.
  • used from a Ruby script (in RubyMine) is OK.

The same as for my previous launching methods (directly via system(…), via extern C code).
I have reinstalled OpenSSL but this changed nothing (i didn’t remember that i had installed OpenSSL before…so i don’t know where my first installation come from)

Could launching from another app be causing different DLLs to be loaded for your app?

I’m afraid that I have few other ideas to what this could be.

(You are exclusively using OpenSSL form your own app, not via Ruby in SU at all?)

What is the error you are seeing? (Sorry you already posted this and I missed it.)

Are you using OpenSSL as a system lib, or a local lib to your application?

We’ve seen issues in SU where some user have had DLLs installed to their system folder causing issues.

>>>Could launching from another app be causing different DLLs to be loaded for your app?
I am using QTWebEngineView in a QT application.
Without looking at the source code of the QT framework i cannot be sure what is exactly used by the app i build :frowning: To remove all complexity form my .exe i have made a very simple application only calling a web service (see my first posts above).

>>>You are exclusively using OpenSSL form your own app, not via Ruby in SU at all?
I made no network calls in ruby. All is done in the external .exe.

>>>Are you using OpenSSL as a system lib, or a local lib to your application?
I dont use explicitly OpenSLL. Maybe QT does use it somewhere but it’s hidden at my level of usage.
There are no OpenSSL libs in my application folder.

To be sure about OpenSSL i just uninstalled OpenSSL from my computer and retested my .exe from all my plugins:

  • SKP 2015 & 2016 OK
  • SKP 2017 NOT OK
  • Revit 2015, 2016, 2017, 2018 OK
  • Archicad 18, 19, 20 OK
  • 3DSMax (via MaxScript) 2016, 2017 OK
  • From RubyMine (in a Ruby 2.4.1 script) OK
  • Direct launch of .exe OK
    This means my .exe doesn’t use OpenSSL i suppose.

That could be some rogue dll in the system folder that isn’t compatible with your app. Some apps blindly install into the system folder instead of keeping local copies for themselves.

Your QT app might not actually use OpenSSL, but maybe QT will attempt to load the DLL anyway - as part of the framework. Maybe part of QT use it to generate random numbers.

Still, its strange that this would happen under SU2017 but not previous versions…

I’m not familiar with how things work when launching process from another, some times they inherit from the parent process. Maybe the OpenSSL version in SU2017 conflicts - but its strange that the error message then points to the system32 folder…

Do you have a ssleay32.dll inyour system32 path?

I looked through some old emails on the topic of OpenSSL. Some customer had problems using Trimble Connect because it threw errors when trying to load openssl.so.

In one particular case it turned out that there were versions of libeay32.dll and ssleay32.dll in Windows/System32 and Windows/SysWOW64. When the customer removed/renamed these then Trimble Connect started working again.

A alternative to touching the system32 files was to copy these two DLLs:

  • C:\Program Files\SketchUp\SketchUp 2015\Tools\RubyStdLib\platform_specific\libeay32.dll
  • C:\Program Files\SketchUp\SketchUp 2015\Tools\RubyStdLib\platform_specific\ssleay32.dll

into:

C:\Program Files\SketchUp\SketchUp 2015

You could try the same, just replace 2015 with 2017. See if that works.

Yes i have this dll in the system32 folder.
It is version 1.0.2.4.
The version in C:\Program Files\SketchUp\SketchUp 2017\Tools\RubyStdLib\platform_specific\ is 1.0.1.12

When i copy the DLLs as you said, nothing changed.
(from C:\Program Files\SketchUp\SketchUp 2017\Tools\RubyStdLib\platform_specific\ to C:\Program Files\SketchUp\SketchUp 2017)

When i remove (rename) the libeay32.dll & ssleay32.dll from my system32 folder then my .exe starts from SKP 2017.

Edit :
When i remove these dlls from the system32 folder then my QT app has following warnings (when running in IDE):
qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_client_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_client_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_server_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_server_method
qt.network.ssl: QSslSocket: cannot resolve SSL_select_next_proto
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb
qt.network.ssl: QSslSocket: cannot resolve SSL_get0_next_proto_negotiated
qt.network.ssl: QSslSocket: cannot resolve SSL_set_alpn_protos
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_alpn_select_cb
qt.network.ssl: QSslSocket: cannot resolve SSL_get0_alpn_selected
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get0_next_proto_negotiated

@bugra any idea what could be causing what georges describe his is previous post here?

I guess I would first figure out where the app expects the find these OpenSSL DLLs normally. Probably (and hopefully) not from System32, some rogue app must have installed them there. I would just run the app normally (double-click) and find out which libeay32.sll and ssleay32.dll got loaded (using a tool such as Process Explorer).

When you spawn your app as a child process, it will inherit the environment variables including PATH. SketchUp adds its RubyStdLib folder to its path. But PATH is dead last in the DLL search path so this is unlikely to cause an issue.

But current working directory might be a factor since it’s still considered in the DLL search path. I would try setting it to your exe directory before launching your app.

1 Like

Has the Trimble SU team looked at using a manifest for dll resolution?

Thanks for the answers.

I’ll see if my QT app really needs these DLL’s. If so i’ll put them in the app folder (of course :wink: )
But at the latest news my app doesn’t need them (it work perfectly on computers who don’t have these DLL’s installed).

But when these DLL’s are allready in the system folder (i don’t know for what reason), Sketchup 2017 could give problems with plugins (?) Or even have problems with his own network accesses (?)

In OpenSSL terms, you have 1.0.2d (2015-Jul-09) in system32, and 1.0.1l (2015-Jan-15) in the SU folder. Additional issues may arise from different compiler versions being used when they were created…

You mentioned the other apps it works with. Your QT app seems to be a MinGW app, and Ruby in SU is also MinGW. If the other apps you mention are not MinGW, they wouldn’t have similar OpenSSL dll’s to load or set a path to. Or, simply put, no conflicts.

For a test, on a non working system, you could copy your dll’s into the SU Tools\RubyStdLib\platform_specific folder, saving the originals. If SU will start (it may not), then try your app. If it works, you know your app is probably loading the SU dlls, and you need to fix the dll resolution issue. Obviously, when finished, delete your dlls and replace with the original SU versions. Just a “don’t try this at home” idea.

MinGW apps can be messy, For instance, both the GitHub windows client and Git for Windows are MinGW apps, and they install dlls with similar names in different folders. Hence, if you’re writing a MinGW app, dll resolution is critical. There could be copies everywhere, and you can’t test against all the MinGW apps a user might have loaded when they run your app.

Hi Greg :slight_smile:
No, it is builded with the MSVC 2015 64 Bit compiler.

Interesting. Any idea what compiler generates the OpenSSL files it uses? I assumed it was MinGW since it had OpenSSL files. I believe the SU OpenSSL dll’s are generated by a MinGW gcc compiler.

BTW, last message was a little unclear. Using @Bugra’s phrase, only rogue apps will cause issues. But you can’t assume that a user hasn’t installed one.

My app works fine from all other plugins i have (SKP2015&2016, all my Revits, all my Archicads, 3DSMax and several others). For this reason I prefer not do any changes to my build or installers to eventually “arrange” things for Sketchup 2017. This is too risky for me right now. :wink:

I’ll eventually spend again some time a bit later.
For the moment i’ll keep the problem clearly documented in a “Sketchup 2017 note” and i hope not too many end users will have the same problem as i had.

Many many thanks to all for your time. :slight_smile:

Perhaps “Entry point 4684 not found in dynamic link library …”

@georges_reif, an idea:

Dir::chdir(my_app_path) {
  # launch my app here
  sleep(5) # give app time to load
}
# Ruby resets working directory to previous path