UtyOLESupportApp startUp problems with OLE DLLs

[Joachim Tuchel]

Hi,

I've seen that a few people here seem to still be using Unity OLE Support. I'm trying to migrate an old V6 VAST application to 9.2.2 and have troubles with

UtyOLESupportApp class>>#startUp

or better in the #checkLibraries method, which cannot find on eof the three libraries UTYOLE, OLEAUT32 or OLE32.

The funny thing is that all three are initialized nicely after the image is fully started. I tried by copying the contents of #checkLibrary to a Workspace and executing the three initiializations by hand after the image has come up and reported its 'cannot find UTYOLE20.DLL' error.

YEs, I have added the name mappings to abt.ini, and I also tried forking startUP as a background process that waits for everything else to finish by adding this to UtyOLESupportApp class>>#startUp:

[

        [System imageStarted] whileFalse: [
       
            Transcript cr; show: 'Waiting for ImageStarted'.
        (Delay forSeconds: 1) wait].

...existingCode...

] fork.

The Transcript doesn't show anything, but #halt: ing instead stops...

The funny thing, however, is that I can do all the initializations later in a workspace, so the DLLs can be found and the getAddress: calls in #checkLibraries do retunr actual addresses.

Did anybody encounter and solve this problem already?

Joachim

[Joachim Tuchel]

I should have added that both the old VAST6 and the new VAST 9.2.2 images/vms are 32 bits. So this is not a 32/64 bits problem (we weren't courageous enough to do 2 jumps at the same time, for a reason ;-) )

[Seth Berman]

Hi Joachim,

We have one report on this scenario, but it went unresolved because the reporter stopped responding.

If you are able to share just this portion with us (along with the dlls), then we could debug the loading issue pretty quickly.

I've got a UtyOLESupportApp.st file-out, but no dlls.

Let Instantiations know if you get stuck for too long, or if nobody else has any ideas.

If so, well just need the Uty* apps in question, the dlls, and ideally a simple use case.

Kind Regards,

- Seth

[Robert Long]

Hi Joachim,

We use the Unity DLLs and went from 7.5 to 9.1 two years ago and to 9.2.2 this past summer.  We had an issue at first but resolved it and of the top of my head I can’t remember what. In the morning when I login to work, I will look at it.

P.S.  the DLLs will not work with 64 bit VAST 9.1 or 9.2.  I already tried that however we do not have the in-house resource to do the reverse engineering required to create the 64 bit versions (wrapper) 

Bob Long

Sent from my iPhone 

On 21 Jan 2021, at 17:23, 'Seth Berman' via VA Smalltalk <va-sma...@googlegroups.com> wrote:

Hi Joachim,

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/792ebff8-cd0e-4d37-af16-624af2fa92e4n%40googlegroups.com.

[Robert Long]

Hi Joachim,

I recalled we had to do something to get this to work and we performed the fix in the #checkLibraries method.

However, the code we added makes use of our proprietary code so I don’t know that it will help you however you can look at the pattern we used and it may give you some idea as to how to make it work:

checkLibraries

                "Answer nil if all the libraries required to support OLE are present.  If one or more of the

                libraries are not present, answer a string describing which library was not present."

 

                | lib |

 

                ^[

                                lib := PlatformLibrary logicalName: 'UTYOLE'.

                                lib getAddress: 'Version'.

 

                                lib := PlatformLibrary logicalName: (UtyOLEBaseSupportApp oleLibraryName).

                                lib getAddress: 'OleInitialize'.

 

                                lib := PlatformLibrary logicalName: (UtyOLEBaseSupportApp oleDispatchLibraryName).

                                lib getAddress: 'RegisterActiveObject'.

 

                                nil]

                                                when: ExAll

                                                do: [:ex | | aString aClass |

                                                                aString := 'UTYOLE checkLibraries... Could not find ' , lib physicalName , '.DLL.'.

                                                                ((aClass := Smalltalk classAt: #JdaObjectManager) notNil and: [aClass showTranscript])

                                                                                ifTrue: [

                                                                                                Transcript

                                                                                                                cr;

                                                                                                                nextPutAll: aString.

                                                                                                aClass theViewManager system notNil ifTrue: [self logJdaErrorWith: aString]].

                                                                ex exitWith: nil]

Cheers

Bob long

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/42cc65b5-53b8-4c97-9782-4f2f5678479fn%40googlegroups.com.

[Joachim Tuchel]

HI Bob,

thanks for you code snippet. I really appreciate your taking the time and effort.
I see you added some stuff to the exception handling code, but the three registrations and getAddress: calls are the same as in the original, afaict. So I guess there must be something else you did in addition to this. I would be grateful if you happen to remember what else had to be done.

The strange thing is that the loading of these three DLLs work in a workspace, sometimes not all of them in one pass, but one after the other.... So this is most likely not (only) a configuration or path or file permissions issue

Joachim

[Joachim Tuchel]

Seth,

thanks a lot for your offer to look into this.

I'll have to check with our customer if we can share code and DLLs with you. If I can, I'll contact you through support.

I only found out after my post that the customer is quite sure the application doesn't use the OLE Automation parts any more, they just never removed the Smalltalk code that actually uses the parts.

Joachim

[Mariano Martinez Peck]

Hi Joachim, 

I wrote a blog post with lots of ideas about how to troubleshoot DLL loading. Maybe that could be of help?

https://dev.to/martinezpeck/dll-hell-tips-tricks-to-avoid-it-in-vast-27gm

BTW, quick questions... when the DLLs are correctly loaded when run explicitly from a workspace after image started:

1) Which is the exact path those DLLs were found (see my post for that)

2) Which is the working directory of VAST at this point?

Cheers, 

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/01d8ace0-ad6a-4bc6-b5e3-5f009b8c2b2dn%40googlegroups.com.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: mp...@instantiations.com

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

[Marcus Wagner]

Dear all,

I found also another subtle dependency causing a DLL to fail to load - the corresponding language runtime system used to compile the DLL (in addition to the bitness).

I had an example where a C++ DLL was compiled with Visual Studio 2010 which did not load in VAST, though all being 32 bit.

Having compiled it with Visual Studio 6 (!) did it (a rare case being able to recompile the DLL).

I did not invest into further clarifying details why the main routine of the DLL failed, it very likely referenced incompatible runtime support of C++.

Marcus

[Mariano Martinez Peck]

Hi Marcus,

That's interesting. I haven't seen that exact error but a similar one in which you try to load a DLL and it won't load due to missing dependencies like microsoft runtime... 

For that, I wrote another blog post: 

https://dev.to/martinezpeck/troubleshooting-applications-running-on-windows-107m

If you check the blog, you will see I use "dumpbin /dependencies" 

Would that help you in that case? 

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/d29a5061-03cf-4e98-93fd-98053dcc0878n%40googlegroups.com.

[Marcus Wagner]

Hi Mariano,

thank you for your extremely valuable insights offered in your blogs. I studied your links with great interest.

The case I mentioned happened before 2010 as I remember. The case was closed long ago. And I did not delve into details then.

And yes, it was a case of dependency. There was a conflict of VAST using C++ MS  runtime system of a particular kind with an arbitrary DLL using another C++ MS runtime system of another kind. VAST VM is based on C++, isn't it?

It is obvously not a very common case that a C++ Version 6 program explicitely attempts to call a C++ Version 2010 DLL.

But by using VAST and calling another third party Software out of it exactly this situation may arise indirectly.

Initially the system silently failed (the DLL load persistently returned a load error and the calling code simply assumed that the referenced function was not installed at all) - very likely I used PROCMON then to detect that.

Kind regards

Marcus