I am trying to convert C# project to Delphi, the C# code itself is importing functions from native dll let us name it ‘dmp.dll’ which I don’t have the signature of its native functions and I have to look at how these functions are imported in c# and try to import them in Delphi code, and I did import a lot of them and they work fine, but now I am struggling with this function (StartLogging). This is how they imported in C#:
[DllImport("dmp.dll", CharSet = CharSet.Auto, EntryPoint = "StartLogging")]
public static extern int StartLogging(String AdapterName,
PLOG_RECORD_CALLBACK LogRecordCallback,
SafeWaitHandle StopLoggingEvent);
no problem about PLOG_RECORD_CALLBACK, but the problem is on this parameter SafeWaitHandle which is class exists in Microsoft.Win32.SafeHandles namespace. How can I port it to Delphi? What is the equivalent data type to it in Delphi?
And here is how they use it in the C# Code:
AutoResetEvent StopEvent = new AutoResetEvent(false);
The class AutoResetEvent exists in System.Threading
Then they call the method like this:
StartLogging(comboBox1.Text, CallbackProcedure, StopEvent.SafeWaitHandle);
Then at the last and to stop the logging they use:
StopEvent.Set();
I am really confused and I don’t know how to do this, appreciate your help.
Thanks
You can probably use SyncObjs TEvent. If you create it with the ManualReset argument set to False, it should work about the same way. Just pass the Event.Handle (which is a THandle and is compatible with anything in the API expecting one).
I don't have a sample of using a non-manual reset event, but an example of creating a TEvent can be found in the accepted answer here; to make it a non-manually reset (IOW, AutoReset), just change the second parameter to False.
Like David Hefferman said in a response to the approved answer: TSimpleEvent (System.SyncObjs) works the same way as the AutoResetEvent of C#.
It can be used like:
_WaitEvent := TSimpleEvent.Create(nil, resetmanual {boolean}, false, '', false);
_WaitEvent.SetEvent;
_WaitEvent.WaitFor;
If you use the manual reset, just simply use:
_WaitEvent.ResetEvent;
Related
Given the following c++ class in foo.dll
class a{
private:
int _answer;
public:
a(int answer) { _answer = answer; }
__declspec(dllexport) int GetAnswer() { return _answer; }
}
I would like the pInvoke GetAnswer from C#. To do that, I use the following method:
[DllImport("foo.dll", CallingConvention = CallingConvention.ThisCall, EntryPoint= "something")]
public static extern int GetAnswer(IntPtr thisA);
And I pass in an IntPtr that points to an a (that I got from somewhere else, it's not important). CallingConvention = CallingConvention.ThisCall makes sure it's handled correctly
What's cool about this question is that I know I'm right so far because it's already working great! Using Depends.exe, I can see that "GetAnswer" is exported as ?GetAnswer#a##UAEHXZ (Or something close - the point being that it's been name mangled). When I plug the mangled name into the "something" for the EntryPoint everything works great! It took me about a day before it dawned on me to use Depends.exe, so I'm going to leave this here as a help to anybody who has a similar issue.
My REAL Question is: Is there any way to disable C++ name mangling on GetAnswer so that I don't need to put the mangled name in as my entry point. Having the mangled name in there seems like it could break, because my understanding of name mangling is that it can change if the compiler changes. Also it's a pain in the butt to use Depends.exe for every instance method that I want to pInvoke.
Edit: Forgot to add what I've tried:
I don't seem to be able to put extern "C" on the function declaration, although I can stick it on the definition. This doesn't seem to help though (which is obvious when you think about it)
The only other solution I can think of is a c-style function that wraps the instance method and takes an instance of an a as a parameter. Then, disable name mangling on that wrapper and pInvoke that. I'd rather stick with the solution that I already have, though. I already told my co-workers that pInvoke is great. I'm going to look like an idiot if I have to put special functions in our c++ library just to make pInvoke work.
You cannot disable mangling for a C++ class method, but you may well be able to export the function under a name of your choice using /EXPORT or a .def file.
However, your entire approach is brittle because you rely on an implementation detail, namely that this is passed as an implicit parameter. And what's more, exporting individual methods of a class is a recipe for pain.
The most sensible strategies for exposing a C++ class to .net languages are:
Create flat C wrapper functions and p/invoke those.
Create a C++/CLI mixed mode layer that publishes a managed class that wraps the native class.
Option 2 is preferable in my opinion.
You may be able to use the comment/linker #pragma to pass the /EXPORT switch to the linker which should allow you to rename the exported symbol:
#pragma comment(linker, "/EXPORT:GetAnswer=?GetAnswer#a##UAEHXZ")
Unfortunately, this does not resolve your need to look up the mangled name using depends or some other tool.
You do not have to disable the mangled name which actually contains lots of information of how the function itself is declared, it basically represents the whole signature of the function after the function name gets de-mangled. I understand you already found a word-around and the other answer has been marked as a correct answer. What I am writing below is how we can make it work as you desired.
[DllImport("foo.dll", CallingConvention = CallingConvention.ThisCall, EntryPoint = "#OrdinalNumber")]
public static extern int GetAnswer(IntPtr thisA);
If you replace "#OrdinalNumber" with the real ordinal number of GetAnsweer, such as "#1", it will work as you desired.
You may just consider the EntryPoint property is the same as the function name we pass to GetProcAddress where you can either pass the function name or the ordinal number of the function.
Your approach to calling non-static function members of a C++ class is indeed correct and thiscall is used correctly and that is exactly thiscall calling convention comes in play in C# P/Invoke. The issue with this approach is that you will have to look into the DLL's PE information, Export Function Information and find out the ordinal number for each function you would like to call, if you have a big number of C++ functions to call, you may want to automate such a process.
From the Question Author: The solution I actually went with
I ended up going with a c-style function that wraps the instance method and takes an instance of an a as a parameter. That way, if the class ever does get inherited from, the right virtual method will get called.
I deliberately chose not to go with C++/CLI because it's just one more project to manage. If I needed to use all of the methods on a class, I would consider it, but I really only need this one method that serializes the class data.
I'm using from C# a C++ library that wasn't quite developed for using from another languages, but it's difficult to change something now. I'm using [DllImport] calls, and nearly everything works fine.
But know I need to use a "backward" call from C++ to C#. So, in C# I need to subscribe to the C++ function. In C++ it is implemented like this:
INTF_API void __stdcall Intf_InstallHandler(Intf_MailHdlPtrType Hdl)
typedef void (STDCALL *Intf_MailHdlPtrType)(InstanceNoType instno,
const MailType* mail, rsuint16 mailsize);
(I've removed a few arguments from the method to make it simplier. They are two bytes - not important)
So in C# I have:
public delegate void MailEventHandler(byte Instance, MailType Mail, UInt16 MailLength);
MailHandlerDef defHandler = (f) =>
{
var structure =
(MailType)Marshal.PtrToStructure(f, typeof(MailType));
handler(structure);
};
Externs.Intf_InstallMailHandler(defHandler);
[DllImport(DLL_NAME, CallingConvention = CallingConvention.StdCall)]
public static extern void Intf_InstallMailHandler(byte Instance, [MarshalAs(UnmanagedType.FunctionPtr)] MailHandlerDef MailHandler, PrimitiveType Primitive);
We have different primitives (in C++ dll every method is a primitive, and every method is implemented as a call-and-wait method, or as an async method, where mailHandler is called on the end of the computation), and all primitives work, except one.
If this primitive is called, the NullRef exception is thrown, without any stacktrace. And I already lost my mind in trying to search what causing this. Intresting is that this doesn't work at our large application (even I tried to switch everyting off, and just call it at start up), but on my small test application it works.
Any help is appreciated.
you could use a .Net CLI C++ wrapper which would then call your standard C++ code.
I have a C++ program which does some processing on a char search[500] array. The dodge here is that the search[] has to be assigned value from C# program.
Consider, that I have this C# program which gets user's input from textbox and have to send this string to C#.
I have been able to export the data, functions and variables from C++ to C#, but I am not familiar how the reverse is done.
[DllImport("Test.dll", EntryPoint = "fnmain", CallingConvention = CallingConvention.Cdecl , CharSet = CharSet.Ansi)]
private static extern int fnmain();//pass what in parameter?
C++
//search[] parameter has to be here. What type to be assigned to get from C# and further get search[] char array
int main(char search[])
{
..
}
I think you want search to be a string. I believe CharSet.Ansi is all you need to make sure the interop converts strings to char *.
This may sound silly. Have you considered calling C++ program with command line arguments? If initialization takes a lot of time, you can use concepts of pipes or read/write from or to files. If you can do a little bit of socket programming, that would mean true asynchronous passing of data. Hope this helped.
I am working on my phd in chemistry and for that reason I need to write a software application to help me with the imaging of samples under a microscope. This microscope is fitted with an x-y-z nanopositioning stage. The stage is controlled using an unmanaged DLL written in VC++ by the hardware vendor. I could provide you with more specifics of needed but let me start with this;
One of the methods in the dll allows me to read settings for the axis of motion:
C++ syntax:
BOOL E7XX_qSVO (int ID, const char* szAxes, BOOL* pbValueArray)
Where BOOL is int 0 or 1 according to the convention.
My C# wrapper contains:
[DllImport("E7XX_GCS_DLL.dll", EntryPoint = "E7XX_qSVO")]
public static extern int qSVO(int iId, string sAxes, int []iValArray);
This seems correct to me. However when I try something like this in my main application (to query axis 1,2 and 3):
Int32 [] _iValues = new Int32[3];
E7XXController.qSVO(m_iControllerID, "123", _iValues);
I consistently get an array like this:
{6, 0, 10} while I should get {0, 0 , 0} according to the display on the device itself. The complementary function:
BOOL E7XX_SVO (int ID, const char* szAxes, const BOOL* pbValueArray) to set the same status bits on the stage also don't work...
Other commands in the dll work perfectly. I can pass strings and doubles in and out without troublem but not the BOOL type...
Do you guys have any idea what could be wrong?
BOOL in C++ is actually an "int" so make sure you use System.Int32 and not System.Boolean.
Alternatively it might be using COM data types i.e. VARIANT_BOOL, in which case you need do need System.Boolean.
Have you tried running dependency viewer to confirm the function prototype?
Have you tried specifying the MarshalAs attribute, e.g.:-
[DllImport("E7XX_GCS_DLL.dll", EntryPoint = "E7XX_qSVO")]
public static extern int qSVO(int iId,
[MarshalAs(UnmanagedType.AnsiBStr)]string sAxes,
[MarshalAs(UnmanagedType.LPArray)]int[] iValArray);
Also, have you tried literally passing the sAxes string as a char array, e.g.:-
[DllImport("E7XX_GCS_DLL.dll", EntryPoint = "E7XX_qSVO")]
public static extern int qSVO(int iId,
[MarshalAs(UnmanagedType.LPArray)]char[] sAxes,
[MarshalAs(UnmanagedType.LPArray)]int[] iValArray);
I've found that with interop you often need to experiment a fair bit to get it working, so try different combinations, check out the different members of the UnmanagedType enumeration and also play about with other people's suggestions too. However, please try the above two techniques and let me know whether they help sort it!
This isn't going to answer your question directly but a sweet tool for getting common Interop Win32 calls easily is using Pinvoke.net The even have a Visual Studio plugin.
http://www.pinvoke.net/index.aspx
The docs for your function say:
The VC++ compiler needs an extern "C" modifier. The declaration must also specify that these functions are to be called like standard Win-API functions. That means the VC++ compiler needs to see a WINAPI or __stdcall modifier in the declaration.
The default calling convention for DllImport is WinApi. On Windows, that's StdCall. But on CE, that's Cdecl. You want to make sure that you use the right calling convention. You might want to tray adding:
CallConvention = CallingConvention.StdCall
Also, specify our string character set:
CharSet = CharSet.Ansi
But it should work even without these. It's quite odd as your code looks right.
In my current employment, A major task is to take an existing engineering tool, and update it, as it has stopped working on the modern OS's.
Now the tool was written in FORTRAN, and most of the source file headers state something like:
C modified by (obfuscated) at dd. mm. 19yy to do something
The employees have cycled since then, and much of the documentation was either never done, or has been lost. So it's up to us to decipher how the program operates, and then recreate that functionality in a more modern language.
For this purpose we have chosen C#.
I am somewhat able to read FORTRAN, so deciphering the math, and logic have so far been straight forward, but I am stuck when comes to dllimports.
I have no clue who made the dll's, or where the source code is, but What I have determined is that they are responsible for some of the key calculations for some of our vendors components. Hence I cannot simply replace the dll with new code as I have no clue which equations are in there..
What I have found out is that the old program sent xml formatted data to the dll entries, and got an xml-like string back. I cannot however replicate it, as I am not completely sure how it works.
Can anybody explain this, or perhaps even translate this to a C++ / C# equivalent?
! interface for CalculateStuff.dll
INTERFACE
SUBROUTINE CalculateComponent(Input, Output)
!DEC$ ATTRIBUTES REFERENCE, ALIAS : '_CC#16' :: CalculateComponent
!DEC$ ATTRIBUTES DLLIMPORT :: CalculateStuff
CHARACTER*(*) Input, Output
!DEC$ ATTRIBUTES REFERENCE :: Input
!DEC$ ATTRIBUTES REFERENCE :: Output
END SUBROUTINE
END INTERFACE
Currently I have this snippet, (C#) but it seems to fail on me:
class CalculateStuff{
[DllImport("CalculateStuff.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall, EntryPoint = "_CC#16")]
public static extern void CalculateComponent(ref string input, ref string output);
}
edit 1: added charset
and now the program gave me this exception, its an improvement I think:
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
edit 2: recompiled as 32bit application, and now I get:
External component has thrown an exception.
edit 3: changed return type to void, as this makes completely sense to me.
edit 4: added the calling convention defined as stdCall, due to many comments hinting that, it didn't help.
have also tried defining the parameter types as string, or ref string nothing changes.