It's an external plugin on all my systems - Mac & linux - so you shouldn't see it in the listBuiltinModules list. If I start a fresh image, the SSL plugin is not loaded. If I run the SqueakSSLTest tests in the TestRunner, they all pass and the plugin is in the listLoadedModules list.

Thanks, Tim, this description makes sense and it looks the same in my fresh image! So the problem is that my problematic image does not automatically load the SSL plugin when invoking the primitive?

Christoph, where does your SqueakSSL.dll live? Is it the right architecture (32/64-bit)?

It's both 64-bit.

I have just made two more observations:

  1. I patched primitiveSSLCreate and added an error: ec argument to the primitive pragma. When the primitive fails, ec is set to #'not found'.
  2. I used another VM (202003021730 instead of 202010232046) to open my image and it shows two interesting observations: First, just during the start-up phase during ThisOSProcess is started up, and second, when evaluating SqueakSSL new, a number of access violation errors pop out in the debug console of the VM:
    LoadLibrary(Win32OSProcessPlugin) (998: Unzuläÿssiger Zugriff auf einen Speicherbereich.
    LoadLibrary(Win32OSProcessPlugin.dll) (998: Unzuläÿssiger Zugriff auf einen Speicherbereich.
    # about 12 repetitions of the above ...
    LoadLibrary(SqueakSSL) (998: Unzuläÿssiger Zugriff auf einen Speicherbereich.
    LoadLibrary(SqueakSSL.dll) (998: Unzuläÿssiger Zugriff auf einen Speicherbereich.
    "Unzuläÿssiger Zugriff auf einen Speicherbereich" is German for "Invalid access to memory location" (by the way, the encoding is wrong, äÿ should be only ä).

There has already been a similar issue reported on the mailing-list, but apparently, it has not yet been solved:

You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.