UtyOLESupportApp startUp problems with OLE DLLs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

UtyOLESupportApp startUp problems with OLE DLLs

jtuchel
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.
Reply | Threaded
Open this post in threaded view
|

Re: UtyOLESupportApp startUp problems with OLE DLLs

jtuchel
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/111556ca-ba2f-40af-8f8f-d2747ea6550en%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: UtyOLESupportApp startUp problems with OLE DLLs

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

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/792ebff8-cd0e-4d37-af16-624af2fa92e4n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: UtyOLESupportApp startUp problems with OLE DLLs

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

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/792ebff8-cd0e-4d37-af16-624af2fa92e4n%40googlegroups.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/F5B5646C-FD9E-44EB-BDAC-1C6080F7C11F%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: UtyOLESupportApp startUp problems with OLE DLLs

Bob Long
In reply to this post by jtuchel
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.

--
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/8409B6B1-8457-432E-A681-9F5D53F17AE6%40gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: UtyOLESupportApp startUp problems with OLE DLLs

jtuchel
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


Bob Long schrieb am Freitag, 22. Januar 2021 um 15:07:11 UTC+1:
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].

--
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/066ee359-92e1-477b-a479-dabc5d94d638n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: UtyOLESupportApp startUp problems with OLE DLLs

jtuchel
In reply to this post by Seth Berman
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.
Reply | Threaded
Open this post in threaded view
|

Re: UtyOLESupportApp startUp problems with OLE DLLs

Mariano Martinez Peck-2
Hi Joachim, 

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

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.

--
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/CAOUkibEkxpzES1CGO2a3jeCe5Y5u%2BftuNJzkts_i6iYC09YbxA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: UtyOLESupportApp startUp problems with OLE DLLs

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

[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?

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].


--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.

--
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.
Reply | Threaded
Open this post in threaded view
|

Re: UtyOLESupportApp startUp problems with OLE DLLs

Mariano Martinez Peck-2
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: 


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?

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].


--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.

--
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.

--
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/CAOUkibEFzwYRPFNTZpJ%2Bz_Xx--J%2Bfh_9ifXqOeV_Ed3dH1V%3Dnw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: UtyOLESupportApp startUp problems with OLE DLLs

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

[hidden email] schrieb am Montag, 25. Januar 2021 um 14:20:23 UTC+1:
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: 


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?

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].


--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.

--
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].


--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.

--
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/07f56083-ef9d-4293-8173-62f727ea4fa5n%40googlegroups.com.