0
102 May 13, 2006 at 09:26

Hi all,

I was wondering whether this C++ code has any C# equivalent:

void main()
{
unsigned char function[] = {0x90,    // NOP (no operation)
0xC3};   // RET (return)

typedef void(*VoidFunction)();

((VoidFunction)&function)();
}


This is the first step towards run-time code generation. I’ve read about delegates and unsafe pointers, but this would require a real function pointer to native code. Any ideas?

Thanks!

Nick

#### 19 Replies

0
101 May 13, 2006 at 09:56

I don’t think that’s possible. C# is a purely managed language.

If you want to do something like that from C# you likely need a C++/CLI class.

0
101 May 13, 2006 at 11:29

Would something like this not do the job (albeit with a huge overhead compared to c++) scroll a bit down to ‘high-level assembler’:

0
101 May 13, 2006 at 11:30

Hi Nick
I don’t think that there is inline assembly nor function pointers in c# so this is a solution that came to my mind you can write your unmanged c++ code , assembly or shellcode in unmanaged DLL and call functions in it using Interop Services in C#.
i hope i have helped.

0
102 May 14, 2006 at 12:15

Thanks! Would it be possible to pass a C# memory buffer filled with x86 binary code to a native DLL and execute it there?

0
101 May 14, 2006 at 14:23

You can do whatever you want once you’re in the DLL

Search for “C# DLLimport”

Of course windows wont let you run arbitary code.
You have to allocate a buffer and change the protection on it.
I cant remember the particular code

0
101 May 14, 2006 at 14:44

Sure

http://msdn2.microsoft.com/en-us/library/bd99e6zt.aspx
Also see
http://www.pinvoke.net/ for listing of most Windows API for using with c#’s pinvoke.
and like dave said you should reallocate the buffer in the native DLL and copy the passed contents to that new buffer to use it.

0
101 May 14, 2006 at 15:21

@Nick

Thanks! Would it be possible to pass a C# memory buffer filled with x86 binary code to a native DLL and execute it there?

I would really recommend using C++/CLI for such things. Its much easier to handle. Since .NET allows to mix languages freely you can do that stuff in a C++/CLI class (C++/CLI allows to mix managed and unmanaged code) and use that one in C#.

0
101 May 15, 2006 at 08:34

@Axel

I would really recommend using C++/CLI for such things. Its much easier to handle. Since .NET allows to mix languages freely you can do that stuff in a C++/CLI class (C++/CLI allows to mix managed and unmanaged code) and use that one in C#.

Well, I have the feeling that Nick is aiming for a softwire-alike system for c# :) (which isn’t a bad idea at all, imho)

0
102 May 15, 2006 at 11:55

@roel

Well, I have the feeling that Nick is aiming for a softwire-alike system for c# :) (which isn’t a bad idea at all, imho)

Exactly. I wish to combine the nice language that is C# with the incredible power offered by soft-wiring technology. C++ is great too but it has clear flaws and stopped evolving…

0
101 May 15, 2006 at 12:07

C++ hasn’t stopped evolving, but besides that, C++/CLI has a lot of new features that can be used on the unmanaged side as well ;)

0
101 May 15, 2006 at 12:33

@.oisyn

C++ hasn’t stopped evolving, but besides that, C++/CLI has a lot of new features that can be used on the unmanaged side as well :)

I would do a thin wrapper with the C++/CLI, which then uses a native dll. C++/CLI is definitely a real improvement compared to the Managed C++, but as it being a new technology there might be some bugs and not sure the quality of the compiled code either. At least the Managed C++ is almost useless for a real production use because of that (like calling destructors twice for an object in some cases…).

0
101 May 16, 2006 at 06:33

@kariem2k

Hi Nick
I don’t think that there is inline assembly nor function pointers in c# so this is a solution that came to my mind you can write your unmanged c++ code , assembly or shellcode in unmanaged DLL and call functions in it using Interop Services in C#.
i hope i have helped.

C# can use the reflection classes to use MSIL inline generally speaking and
I do believe C# has function pointers but I’m not entirely sure (unsafe code is so much fun!!)

As for the main question, NO you CANNOT use native assembly in managed
languages since the binaries are compiled to a high-level assembler which in
turn are compiled to native assembler by the JIT engine upon execution.

You can probably use C++ with Managed Extensions to use assembler but
for most projects I wouldn’t recommend it since you’ll be breaking that wonderful
cross-platformness that C# has (assuming you have an environment on that platform such as .NET, ROTOR, DotGnu, or Mono).

0
101 May 16, 2006 at 07:58

Prozac:
I am afraid you did not understand me.
inline assembly is machine asm not the MSIL that can be written inside your c,c++ code directly.

As for the main question, NO you CANNOT use native assembly in managed
languages since the binaries are compiled to a high-level assembler which in
turn are compiled to native assembler by the JIT engine upon execution.

You can use(not include) native(unmanged) Dlls in c# just with DllImport attribute you can call any function from any Unmanaged dll,Microsoft has to do that to enable the programmers to use windows API.

You can probably use C++ with Managed Extensions to use assembler but
for most projects I wouldn’t recommend it since you’ll be breaking that wonderful
cross-platformness that C# has (assuming you have an environment on that platform such as .NET, ROTOR, DotGnu, or Mono).

I don’t think he want to make his app cross-platform because of a simple thing shellcodes are not portable like any low level assembly application,you need much work to make it portable.

0
101 May 16, 2006 at 08:28

@juhnu

I would do a thin wrapper with the C++/CLI, which then uses a native dll.

You don’t need the native DLL. C++/CLI allows switching from managed to unmanaged code on the function level (the compiler will do that for you).

0
101 May 16, 2006 at 08:59

@Axel

You don’t need the native DLL. C++/CLI allows switching from managed to unmanaged code on the function level (the compiler will do that for you).

Yeah I know that, but you have to do marshalling between .NET and native C++ types at some point anyway. If you separate your code for different dlls it’s pretty easy to know what is actually compiled to IL and what not. Also as the C++/CLI is really new technology it probably has some bugs, which might make a larger use unpractical for the time being - it’s predecessor the Managed C++ suffered from this very problem.

0
101 May 16, 2006 at 09:08

Also as the C++/CLI is really new technology it probably has some bugs

Well it’s not that new, technically it’s just managed C++ with a revised syntax. The fundamentals are basically the same.

0
101 May 16, 2006 at 12:33

@.oisyn

Well it’s not that new, technically it’s just managed C++ with a revised syntax. The fundamentals are basically the same.

So are the bugs too? ;) Seriously C++/CLI is a language on it’s own right and addresses many shortcomings of the Managed C++. You are making it sound
merely like a face-lift.

0
102 May 16, 2006 at 12:58

@Axel

You don’t need the native DLL. C++/CLI allows switching from managed to unmanaged code on the function level (the compiler will do that for you).

Interesting! I haven’t looked at C++/CLI yet.

So is C++/CLI undisputably better than unmanaged C++? I mean, could it replace it completely? Does it inherit unmanaged C++’s flaws or is it more like C# with unmanaged support?

Thanks. :happy:

0
101 May 16, 2006 at 16:07

@juhnu

So are the bugs too? :blink: Seriously C++/CLI is a language on it’s own right and addresses many shortcomings of the Managed C++.

Well most of the shortcomings were actually in the syntax itself. And sure it’s new, as it also targets .Net 2.0 while Managed C++ only targets 1.1, and it has some more interesting new features. And it’s a language on it’s own because MS took the liberty to standardize it at ECMA, but that has got nothing to do with the actual implementation of course :P.

But under the hood, like pinning pointers for example and the rest of the interface with .Net itself, they’re very similar.