Executing the address from GetProcAddress

[Troy Anderson]

How do I execute a dynamically loaded C-API using GetProcAddress in
CompactFramework? I wrote some IL code to do this for full .NET; see the
listing below. This code works on the PC. However, it does not work in
CompactFramework. The library I am loading has been developed with eVC++.
NOTE: I know about P-Invoke but for my application I need to load DLLs and
functions that are specified at runtime (i.e., I do not know the DLL or
function name apriori; I know only the function signature).

Thanks

IL Code:

..assembly extern mscorlib {}
..assembly Canberra.Native {}
..module Canberra.Native.dll
..namespace Canberra.Native.Analysis {
.class public Engine
{
.method public static int32 Invoke(native int Fnc, native int DSC,
unsigned int16 Rec, int32& Arg1, int32& Arg2)
{
ldarg.s 4 // push Arg2
ldarg.2 // push Arg1
ldarg.2 // push Rec
ldarg.1 // push DSC
ldarg.0 // push Fnc
calli unmanaged stdcall int32(native int, int16, int32&, int32&)
ret
}
}
}

Client Code: (Note: LibraryServices is a wrapper over Win32 APIs in order
to run code on either PC or device)
using(LibraryServices LS = new LibraryServices())
{
uint Stat = (uint) LS.LoadLibrary(m_EngineResource);
IntPtr EnginePtr = LS.GetProcAddress(m_EngineEntryPoint);

//Invoke the engine
Stat = (uint) Canberra.Native.Analysis.Engine.Invoke(EnginePtr, Handle,
(ushort) Record, ref Arg1, ref Arg2);
}

 

[Guest]

'calli' operation is not supported in CF v1.

 

[Troy Anderson]

What can I use as a replacement to 'calli'?

Thanks

 

[Sergey Bogdanov]

Why don't just use GetModuleHandle, GetProcAddress, CallThunk from
OpenNETCF?


IntPtr hMod = Core.GetModuleHandle("_DLL_");
IntPtr pfn = Core.GetProcAddress(hMod, "_Func_");
ct = new CallThunk(pfn, 2);
ct.Call(...);


Best regards,
Sergey Bogdanov

 

[Guest]

An unmanaged shim DLL that you call that in turn loads the desired library.

-Chris

 

[Troy Anderson]

This is not what I would like to do. I want a completely managed option. I
am looking to develop a 100% platform independent solution. A shim DLL will
require me to distribute a DLL per processor type I am supporting (i.e., one
for ARM, one for XScale, one for SH3, ...) I want to distribute one .NET EXE
or DLL that can run on any processor or platform. I have been developing
..NET assemblies like this for some time now and it make code management and
distribution trivial.

Thanks

 

[Guest]

And I assert that striving for a 100% managed solution is not a realistic
option for most robust solutions. The CF is great, but there still are
areas that native code performs the task far better, and abandoning it for
platform agnosticism isn't a decent sacrifice. Per-processor distribution
has been the norm in CE for some time and has been solved reasonably well.
Add to that the fact if you're targeting PPC you're in a single processor
environment anyway.

Why try to smash the square peg into the round hole? Use the tool that
exists for the job.

-Chris