Highlighted
Absent Member.
Absent Member.
2128 views

SuppressUnmanagedCodeSecurity

Jump to solution

Hello,

could anyone help me ? I need to create a window as a form in Visual COBOL .NET and then create a listview object into this form but from the listview class written in simple native code. So after creation of the form I need to call native code with the handle of the form and here's the problem. First time I use the form handle in the native code as a parameter in calling Windows API functions causes exception and the process is terminated. I was looking for the solution and I've found that perhaps something like SuppressUnmanagedCodeSecurity attribute must be specified in the calling managed code. But I don't know if I'm right and if I'm how to declare it. In the attachment file is dialog-box with the exception thrown by first calling Windows API with the form handle.

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: SuppressUnmanagedCodeSecurity

Jump to solution

managed app compiled with $set noilnative

         declare myhandle as binary-long = self::Handle as binary-long
         declare myret as binary-long
         call "subprog" using myhandle myret

native subprog.

      working-storage section.
      01 pp  procedure-pointer.
      linkage section.
      01 winhandle    pic x(4) comp-5.
      01 retlength    pic x(4) comp-5.
      procedure division using winhandle retlength.
          set pp to entry "User32"
          call winapi "GetWindowTextLengthA"
             using by value winhandle
             returning retlength

View solution in original post

0 Likes
11 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: SuppressUnmanagedCodeSecurity

Jump to solution

I am not really sure what is causing the exception as there really isn't enough detail.

How are you passing the Form's handle to native code and what is the Windows API call where it is being used?

I believe that this should work if you get the handle using:

   declare myhandle as type IntPtr = self::Handle

and pass the IntPtr into native code

but I have never tried this.

Attributes can be assigned in managed code at the class level or at the method level, etc.

      class-id winformhandle.Form1 is partial

      inherits type System.Windows.Forms.Form

      attribute System.Security.SuppressUnmanagedCodeSecurity.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: SuppressUnmanagedCodeSecurity

Jump to solution

Thanks for your reply.

I wrote it exactly the same way you told me to do:

(1) I obtain the handle the same way that you mentioned. I'm only not sure how to pass the handle correctly to the native code, so in managed code I added these lines in addition

01  l-Int32                     type System.Int32.

set l-Int32 to l-hwnd::ToInt32

and in the native code I declared this parameter in linkage section as 01  ln-hwnd pic x(4) comp-5. Maybe it's not neccesary, I don't know.

(2) I added the attribute to my class the same way that you mentioned. I didn't noticed that method could have attribute - maybe this way ?

method-id CreateListview final private

                                              attribute System.Security.SuppressUnmanagedCodeSecurity.

(3) And finally the Windows API, where it's being used... at first I just wanted to create a "NetExpress object" by calling

invoke Window "fromHandle" using ln-hwnd

                                               returning aWindow

where Window is just class "window" declared in class-control and aWindow an item declared as object reference. And then I just wrote some "test" invoke

invoke aWindow "GetTitle" returning aTitle

to check the handle parameter was passed ok. But just this invoke caused the exception and looking inside the NetExpress library into the code processed by this invoke I found out that this exception appears by calling

   call WAPI GetWindowTextLength using by value ln-hwnd

                                                         returning lsSize

After that I tested one more API call

   call WAPI GetWindowRect using by value ln-hwnd

                                                               by reference lsRect

                                             returning lsBool

to be sure that the result is the same and that the exception is caused generally by Windows API calling. So this is my experience. Maybe the mistake is some bad type of compilation or so, maybe the code is wrong. I don't know.

Thank you.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: SuppressUnmanagedCodeSecurity

Jump to solution

I can get this to work correctly but it seems like the run-time is forcing parameters being passed directly as integers to be passed by value even when by value isn't specified.

If I do not use by value in the procedure division header of the native subprogram than I get the same exception error as you.

I am still researching this but could you give this a try?

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: SuppressUnmanagedCodeSecurity

Jump to solution

Actually if you compile the managed code application using the directive ILNONATIVE the pass by reference will work correctly.

Thanks.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: SuppressUnmanagedCodeSecurity

Jump to solution

managed app compiled with $set noilnative

         declare myhandle as binary-long = self::Handle as binary-long
         declare myret as binary-long
         call "subprog" using myhandle myret

native subprog.

      working-storage section.
      01 pp  procedure-pointer.
      linkage section.
      01 winhandle    pic x(4) comp-5.
      01 retlength    pic x(4) comp-5.
      procedure division using winhandle retlength.
          set pp to entry "User32"
          call winapi "GetWindowTextLengthA"
             using by value winhandle
             returning retlength

View solution in original post

0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

RE: SuppressUnmanagedCodeSecurity

Jump to solution

Chris,

Pardon, but I believe it is spelled like this:  NOILNATIVE

Thanks

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: SuppressUnmanagedCodeSecurity

Jump to solution

Yes, you are correct the NO is before the IL. I spelled it correctly in the second post with the example.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: SuppressUnmanagedCodeSecurity

Jump to solution

Superb. When added the "by value" declaration to the procedure division header in the native subprogram, it works correctly. After that I tried to remove the attribute System.Security.SuppressUnmanagedCodeSecurity and it still seems ok. Do you think that this attribute should be still used ? Thanky you very much.

Now I'll try the directive NOILNATIVE.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: SuppressUnmanagedCodeSecurity

Jump to solution

I do not think that you specify the attribute as it doesn't appear to be required in this context. I read that it can be a security risk so you should be careful when using it.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: SuppressUnmanagedCodeSecurity

Jump to solution

Yes, I read it too and if it's not necessary I won't use the attribute. The only reason for which I was ready to use it was just very special combination of creating various visual objects within the form.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: SuppressUnmanagedCodeSecurity

Jump to solution

Thank you very very very much. For this moment it does work just the way I wanted. Thank you for your help.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.