[Mono-devel-list] plans for a native AES wrapper.

Allan Hsu allan at counterpop.net
Thu Jul 21 15:32:11 EDT 2005

On Jul 21, 2005, at 10:04 AM, Paolo Molaro wrote:

> As explained a few days ago in another mail: internal calls have
> nothing to do with speed. They only belong inside the general
> purpouse mono if they are generally useful or in your specialized
> embedding app. So they are not appropriate as a substitute for
> pinvoking into an unmanaged lib.
> lupus

I think I may have misread the part of the wiki that talks about  
embedding mono (http://mono-project.com/Embedding_Mono):

"The Mono runtime provides two mechanisms to expose C code to the CIL  
universe: internal calls and native C code. Internal calls are  
tightly integrated with the runtime, and have the least overhead, as  
they use the same data types that the runtime uses.
The other option is to use the Platform Invoke (P/Invoke) to call C  
code from the CIL universe, using the standard P/Invoke mechanisms."

Does that text actually list *three* options, not two? It also seems  
to suggest that internal calls are faster than *something*.  I had  
previously thought that it was comparing native calls to p/invoke.  
Was I wrong?

We've written both a p/invoke and an internal call Rijndael wrapper.  
There is a negligible performance difference between the two. We may  
still ship the internal call implementation for reasons unrelated to  
performance; it reduces our library dependencies and makes it harder  
to do something malicious via library substitution.


Allan Hsu <allan at counterpop dot net>
1E64 E20F 34D9 CBA7 1300  1457 AC37 CBBB 0E92 C779

More information about the Mono-devel-list mailing list