UtyOLESupportApp startUp problems with OLE DLLs

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

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 ;-) )

Joachim Tuchel schrieb am Donnerstag, 21. Januar 2021 um 09:47:50 UTC+1:

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

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

On 21 Jan 2021, at 03:47, Joachim Tuchel <[hidden email]> wrote:

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

--
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 [hidden email].

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

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

On Thursday, January 21, 2021 at 3:52:03 AM UTC-5 [hidden email] wrote:

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 ;-) )

Joachim Tuchel schrieb am Donnerstag, 21. Januar 2021 um 09:47:50 UTC+1:

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

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

Seth Berman schrieb am Donnerstag, 21. Januar 2021 um 23:23:23 UTC+1:

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

On Thursday, January 21, 2021 at 3:52:03 AM UTC-5 [hidden email] wrote:

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 ;-) )

Joachim Tuchel schrieb am Donnerstag, 21. Januar 2021 um 09:47:50 UTC+1:

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/01d8ace0-ad6a-4bc6-b5e3-5f009b8c2b2dn%40googlegroups.com.

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, 

On Sat, Jan 23, 2021 at 9:10 AM Joachim Tuchel <[hidden email]> wrote:

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

Seth Berman schrieb am Donnerstag, 21. Januar 2021 um 23:23:23 UTC+1:

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

On Thursday, January 21, 2021 at 3:52:03 AM UTC-5 [hidden email] wrote:

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 ;-) )

Joachim Tuchel schrieb am Donnerstag, 21. Januar 2021 um 09:47:50 UTC+1:

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

--
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 [hidden email].

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: [hidden email]

Twitter: https://twitter.com/MartinezPeck

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

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

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

[hidden email] schrieb am Montag, 25. Januar 2021 um 13:52:09 UTC+1:

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, 

On Sat, Jan 23, 2021 at 9:10 AM Joachim Tuchel <[hidden email]> wrote:

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

Seth Berman schrieb am Donnerstag, 21. Januar 2021 um 23:23:23 UTC+1:

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

On Thursday, January 21, 2021 at 3:52:03 AM UTC-5 [hidden email] wrote:

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 ;-) )

Joachim Tuchel schrieb am Donnerstag, 21. Januar 2021 um 09:47:50 UTC+1:

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

--
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 [hidden email].

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: [hidden email]

Twitter: https://twitter.com/MartinezPeck

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

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/d29a5061-03cf-4e98-93fd-98053dcc0878n%40googlegroups.com.

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? 

On Mon, Jan 25, 2021 at 10:16 AM Marcus Wagner <[hidden email]> wrote:

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

[hidden email] schrieb am Montag, 25. Januar 2021 um 13:52:09 UTC+1:

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, 

On Sat, Jan 23, 2021 at 9:10 AM Joachim Tuchel <[hidden email]> wrote:

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

Seth Berman schrieb am Donnerstag, 21. Januar 2021 um 23:23:23 UTC+1:

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

On Thursday, January 21, 2021 at 3:52:03 AM UTC-5 [hidden email] wrote:

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 ;-) )

Joachim Tuchel schrieb am Donnerstag, 21. Januar 2021 um 09:47:50 UTC+1:

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

--
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 [hidden email].

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: [hidden email]

Twitter: https://twitter.com/MartinezPeck

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

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

--
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 [hidden email].

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

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

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

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