[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 400
  • Last Modified:

Are system calls more reliable from MFC than .NET?

Are there any known problems with making system calls (such as Desktop calls, WIndowing calls, or ShellExecute or CreateProcess) in .NET? Is it better to write such an application in MFC?
0
jobrems
Asked:
jobrems
1 Solution
 
Jaime OlivaresSoftware ArchitectCommented:
As far you specify marshalling properly, it will have the same reliability as MFC. Indeed you don't call from MFC (unless you are using a MFC wrapper class), you call natively the WinAPI applications.
Of course there is a little cost to invoke WinAPI function from .net, since .net makes additional checkings.
0
 
alb66Commented:
Sometimes is more easy to make system calls from native code (MFC) because you can use "ready to use" include files. As jaime_olivares said you have also  little better performance.
0
 
multithreadingCommented:
There are a million ways to get into trouble making calls into the various DLLs from C#, but if you know enough to program in C++, and if you know the CLR well, then you are unlikely to run into them. Given that you can probably avoid the various problem areas in maping functions, the choice of language comes down to what you are gaining and what you are losing, with regard to these system calls, by using .Net.

The more complicated the call, the more likely you are to have problems. If you call a method that takes no arguments and returns nothing, then there isn't much room for trouble. On the other hand, if you call a method that takes a struct, which contains pointers to other structs, and returns a handle, you have several complications. In addition to needing to build a object hierarchy in .net with pointers, you have gotten back a handle (like you would expect to see with some of the calls you mentioned) which (depending on the level of support for that particular RAW handle) may not be directly useable in .Net. Getting back handles etc. can force you to make more system calls, and the next thing you know, you are writing a C++ application, except that you keep having to look up #defines for all kinds of int values etc., and figuring out how you are going to represent things in C#. All of that is before we get into any object lifetime issues...

Look at the overall application. How many different calls are you going to need? What are the arguments and return values? If the calls can be made using regular c# types, and you aren't getting pulled into the vortex, then c# is your answer. If you find that looking up and defining the calls and argument types is taking you more time than you are saving by using c#, then use C++ instead.
0
 
jobremsAuthor Commented:
Thanks for your detailed answer. I also wanted to know: Are there some system calls which, when made from unmanaged code in .NET, execute incorrectly or with unexpected results?
0
 
multithreadingCommented:
It's kind of complicated. Most calls work fine. Calls that involve callbacks can get you into trouble. I've also seen people frequently get into trouble with calls that take pointers to character buffers. There are other ways to get into trouble, but the more you know the less likely that is to happen. I think the best advice would be only programmers with a solid understanding of the CLR, C/C++, and the Win32 API should be making these mappings. There is a little bit more to it than meets the eye, especially with calls that take pointers to various objects. In the hands of someone with a thorough understanding of the various issues, you will be fine.
0

Featured Post

[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now