We have a native DLL called WN99.DLL, which has a number of programs named WN99???. Our application is mostly native but we are starting to add managed functions to it. When we start up our application, we load WN99.DLL in our native driver program with:
SET PROC-POINTER TO ENTRY "WN99.DLL"
All of our object, both native and managed, is output to the same directory. I was able to call a native WN99 program from a managed project without doing any further handling. When another programmer ran the same managed code, he got an error 173 on the call to the WN99 program. We fixed this in one of two ways, either by adding a reference in the managed project to WN99.DLL or by doing the above SET PROC-POINTER statement in the first managed program that got run (we have a little managed program which is run when we start our application and its purpose is to do any necessary preloads of DLL'S).
Is it true that native DLL's that are called from both native and managed have to be preloaded from both native and managed code ? It's odd that I didn't have to preload WN99.DLL from managed code whereas the other programmer did. I only had to preload it in the native driver program.
#VisualCOBOL> Is it true that native DLL's that are called from both native and managed have to be preloaded from both native and managed code ?
Yes because the native runtime does not know anything about the managed runtime, so they do not
have the ability to share the knowledge about what is loaded in their respective runtime.
On a side note, I would recommend that you remove the ".dll" if you want your code to be 100% portable.
re: documentation.microfocus.com/.../index.jsp
We have a native DLL called WN99.DLL, which has a number of programs named WN99???. Our application is mostly native but we are starting to add managed functions to it. When we start up our application, we load WN99.DLL in our native driver program with:
SET PROC-POINTER TO ENTRY "WN99.DLL"
All of our object, both native and managed, is output to the same directory. I was able to call a native WN99 program from a managed project without doing any further handling. When another programmer ran the same managed code, he got an error 173 on the call to the WN99 program. We fixed this in one of two ways, either by adding a reference in the managed project to WN99.DLL or by doing the above SET PROC-POINTER statement in the first managed program that got run (we have a little managed program which is run when we start our application and its purpose is to do any necessary preloads of DLL'S).
Is it true that native DLL's that are called from both native and managed have to be preloaded from both native and managed code ? It's odd that I didn't have to preload WN99.DLL from managed code whereas the other programmer did. I only had to preload it in the native driver program.
#VisualCOBOLI removed ".DLL" as you suggested.
When I perform SET PROC-POINTER TO ENTRY "WN99" from managed code, while in the debugger, PROC-POINTER is "null" before the SET statement and also "null" after the SET statement, but this still works and my native programs in WN99.DLL can be found.
We have a native DLL called WN99.DLL, which has a number of programs named WN99???. Our application is mostly native but we are starting to add managed functions to it. When we start up our application, we load WN99.DLL in our native driver program with:
SET PROC-POINTER TO ENTRY "WN99.DLL"
All of our object, both native and managed, is output to the same directory. I was able to call a native WN99 program from a managed project without doing any further handling. When another programmer ran the same managed code, he got an error 173 on the call to the WN99 program. We fixed this in one of two ways, either by adding a reference in the managed project to WN99.DLL or by doing the above SET PROC-POINTER statement in the first managed program that got run (we have a little managed program which is run when we start our application and its purpose is to do any necessary preloads of DLL'S).
Is it true that native DLL's that are called from both native and managed have to be preloaded from both native and managed code ? It's odd that I didn't have to preload WN99.DLL from managed code whereas the other programmer did. I only had to preload it in the native driver program.
#VisualCOBOLIf the DLL WN99 does not contain an exported symbol called WN99 it will return null (unlike native which
will return ordinal #0), if you did a second "SET PROC-POINTER TO ENTRY "xx"" where XX is found
in WN99 and exported it will ensure you get a portable behaviour if you want to ensure WN99 is actually
loaded.
You can check the exports by using "dumpbin /exports WN99.DLL" or look at the .def file.
We have a native DLL called WN99.DLL, which has a number of programs named WN99???. Our application is mostly native but we are starting to add managed functions to it. When we start up our application, we load WN99.DLL in our native driver program with:
SET PROC-POINTER TO ENTRY "WN99.DLL"
All of our object, both native and managed, is output to the same directory. I was able to call a native WN99 program from a managed project without doing any further handling. When another programmer ran the same managed code, he got an error 173 on the call to the WN99 program. We fixed this in one of two ways, either by adding a reference in the managed project to WN99.DLL or by doing the above SET PROC-POINTER statement in the first managed program that got run (we have a little managed program which is run when we start our application and its purpose is to do any necessary preloads of DLL'S).
Is it true that native DLL's that are called from both native and managed have to be preloaded from both native and managed code ? It's odd that I didn't have to preload WN99.DLL from managed code whereas the other programmer did. I only had to preload it in the native driver program.
#VisualCOBOLI did dumpbin/exports on WN99.DLL and it gave me a list of program names such as WN99FCV. "WN99" is not an exported symbol. My managed code now looks like this:
SET PROC-POINTER TO ENTRY "WN99"
SET PROC-POINTER TO ENTRY "WN99FCV"
The first statement returns null for the pointer.
The second statement returns "..." as seen in the debugger, which is low values ?
If I skip the first statement and only do the second statement I also get "..." for the pointer.
I must not be understanding your last post. I just want to make sure I get portable behavior.
We have a native DLL called WN99.DLL, which has a number of programs named WN99???. Our application is mostly native but we are starting to add managed functions to it. When we start up our application, we load WN99.DLL in our native driver program with:
SET PROC-POINTER TO ENTRY "WN99.DLL"
All of our object, both native and managed, is output to the same directory. I was able to call a native WN99 program from a managed project without doing any further handling. When another programmer ran the same managed code, he got an error 173 on the call to the WN99 program. We fixed this in one of two ways, either by adding a reference in the managed project to WN99.DLL or by doing the above SET PROC-POINTER statement in the first managed program that got run (we have a little managed program which is run when we start our application and its purpose is to do any necessary preloads of DLL'S).
Is it true that native DLL's that are called from both native and managed have to be preloaded from both native and managed code ? It's odd that I didn't have to preload WN99.DLL from managed code whereas the other programmer did. I only had to preload it in the native driver program.
#VisualCOBOLPROC-POINTER will only be set to null if the name specified in the TO ENTRY phrase is not actually the name of an entry point in the .dll.
So if you actually had a program called "WIN99" in the "WIN99.DLL" it would load the .dll and set PROC-POINTER to a non-null value.
Since the entry point name that you wish to call is different than the name of the .dll then in order to test if it loaded successfully you would have to do:
SET PROC-POINTER TO ENTRY "WN99"
if proc-pointer = null
SET PROC-POINTER TO ENTRY "WN99FCV"
if proc-pointer = null
display "not loaded"
else
display "loaded"
call "WIN99FCV" ...
end-if
else
display "loaded"
call "WIN99FCV" ...
end-if.
Another option is to add a dummy COBOL program that had the same name as the .dll to the .dll.
identification division.
program-id. WIN99.
procedure division.
goback.
Then when the statement:
SET PROC-POINTER TO ENTRY "WN99"
is executed it will call the dummy program and PROC-POINTER will be set to non-null so it will pass the not null test.
Your questions:
The second statement returns "..." as seen in the debugger, which is low values ?
No this is not low-values, it is a pointer value that will pass the not null test.
If I skip the first statement and only do the second statement I also get "..." for the pointer.
My tests show the value as "null" in the debugger when the .dll is not loaded.
