Can C# Call This DLL?

[Mark Jerde]

I need to call a Win32 DLL. The API supports both Windows and Linux, but
I'm only concerned with Windows. I'd like advice whether I can use C# or
whether I'll have to dust off my old C++ books. I would prefer to learn C#
rather than go back to C++.

The API starts with

#ifdef (WIN32)
#define MyAPI __stdcall
#else
#define MyAPI
#endif

There are bitmap mask #define statements.

All integer values are little-endian.

There are many "typedef" and "typedef struct" statements with char, const,
void, sint8, uint8, uint16, uint32, and sint32 elements, arrays and
pointers.

There are "typedef struct" statements with union elements.

To ease cross-platform use, the API defines its own memory management. This
is one typedef:

typedef void * (MyAPI *MyAPI_REALLOC)
(void * Memblock,
uint32 Size,
void * Allocref);

And the part I'm the least sure can be done in C# is the asynchronous event
mechanism. Here is one of the typefefs.

typedef MyAPI_RETURN (MyAPI *MyAPI_ModuleEv entHandler)
(const MyAPI_UUID *UUID,
void* AppNotifyCallba ckCtx,
MyAPI_ID ID,
uint32 Reserved,
MyAPI_Event EventType);

Can C# easily work with this API? (*)

Thanks!

-- Mark

(*) Several years ago I wrote some ugly VB6 code to deal with a DLL that had
VB-unfriendly pointers and unicode strings. Therefore I assume it is
"possible" to use this DLL from C#. I guess I'm asking whether or not it is
"easy" or "reasonable " to call the DLL from C#.

[Nicholas Paldino [.NET/C# MVP]]

Mark,

While you are using the stdcall convention for the functions, it's not
possible to tell whether or not you are exploring the functions correctly.
My guess is that yes, the functions are exported correctly, so you should
have no problem using this.

However, the only thing that is of concern is the memory management
routine. It looks like there is a routine for allocating memory, but I
can't see anything for deallocating memory. If you have that defined, then
you should be alright.

Other than that, there is no reason why you shouldn't be able to use
this from .NET.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

I need to call a Win32 DLL. The API supports both Windows and Linux, but
I'm only concerned with Windows. I'd like advice whether I can use C# or
whether I'll have to dust off my old C++ books. I would prefer to learn
C#
rather than go back to C++.

The API starts with

#ifdef (WIN32)
#define MyAPI __stdcall
#else
#define MyAPI
#endif

There are bitmap mask #define statements.

All integer values are little-endian.

There are many "typedef" and "typedef struct" statements with char, const,
void, sint8, uint8, uint16, uint32, and sint32 elements, arrays and
pointers.

There are "typedef struct" statements with union elements.

To ease cross-platform use, the API defines its own memory management.
This
is one typedef:

typedef void * (MyAPI *MyAPI_REALLOC)
(void * Memblock,
uint32 Size,
void * Allocref);

And the part I'm the least sure can be done in C# is the asynchronous
event
mechanism. Here is one of the typefefs.

typedef MyAPI_RETURN (MyAPI *MyAPI_ModuleEv entHandler)
(const MyAPI_UUID *UUID,
void* AppNotifyCallba ckCtx,
MyAPI_ID ID,
uint32 Reserved,
MyAPI_Event EventType);

Can C# easily work with this API? (*)

Thanks!

-- Mark

(*) Several years ago I wrote some ugly VB6 code to deal with a DLL that
had
VB-unfriendly pointers and unicode strings. Therefore I assume it is
"possible" to use this DLL from C#. I guess I'm asking whether or not it
is
"easy" or "reasonable " to call the DLL from C#.

[Mark Jerde]

Nicholas Paldino [.NET/C# MVP] wrote:

Mark,

While you are using the stdcall convention for the functions,
it's not possible to tell whether or not you are exploring the
functions correctly. My guess is that yes, the functions are exported
correctly, so you should have no problem using this.

However, the only thing that is of concern is the memory
management routine. It looks like there is a routine for allocating
memory, but I can't see anything for deallocating memory. If you
have that defined, then you should be alright.
I just typed one of the five typedefs. There are the standard
*MyAPI_MALLOC, *MyAPI_FREE, *MyAPI_REALLOC and *MyAPI_CALLOC. There is also
a "wrapper" typedef:

typedef struct MyAPI_memory_fu nctions {
MyAPI_MALLOC Malloc_func;
MyAPI_FREE Free_func;
MyAPI_REALLOC Realloc_func;
MyAPI_CALLOC Calloc_func;
void *AllocRef;
} MyAPI_MEMORY_FU NCS, *MyAPI_MEM_FUNC S_PTR;
Other than that, there is no reason why you shouldn't be able to
use this from .NET.

Hope this helps.
It does indeed. I get to learn something new. Thanks.

-- Mark
"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

I need to call a Win32 DLL. The API supports both Windows and
Linux, but I'm only concerned with Windows. I'd like advice whether
I can use C# or whether I'll have to dust off my old C++ books. I
would prefer to learn C#
rather than go back to C++.

The API starts with

#ifdef (WIN32)
#define MyAPI __stdcall
#else
#define MyAPI
#endif

There are bitmap mask #define statements.

All integer values are little-endian.

There are many "typedef" and "typedef struct" statements with char,
const, void, sint8, uint8, uint16, uint32, and sint32 elements,
arrays and pointers.

There are "typedef struct" statements with union elements.

To ease cross-platform use, the API defines its own memory
management. This
is one typedef:

typedef void * (MyAPI *MyAPI_REALLOC)
(void * Memblock,
uint32 Size,
void * Allocref);

And the part I'm the least sure can be done in C# is the asynchronous
event
mechanism. Here is one of the typefefs.

typedef MyAPI_RETURN (MyAPI *MyAPI_ModuleEv entHandler)
(const MyAPI_UUID *UUID,
void* AppNotifyCallba ckCtx,
MyAPI_ID ID,
uint32 Reserved,
MyAPI_Event EventType);

Can C# easily work with this API? (*)

Thanks!

-- Mark

(*) Several years ago I wrote some ugly VB6 code to deal with a DLL
that had
VB-unfriendly pointers and unicode strings. Therefore I assume it is
"possible" to use this DLL from C#. I guess I'm asking whether or
not it is
"easy" or "reasonable " to call the DLL from C#.

[Nicholas Paldino [.NET/C# MVP]]

Mark,

You aren't going to be able to use function pointers in .NET 1.1 or
before. If that is how your API is defining the memory management
functions, then you will not be able to use it.

However, in .NET 2.0, you will be able to take a pointer in memory, and
assign it to a delegate, which you can then call from managed code. If you
can get this pointer from your API, then getting a callable delegate is
very, very simple.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:OH******** *****@TK2MSFTNG P15.phx.gbl...

Nicholas Paldino [.NET/C# MVP] wrote:

Mark,

While you are using the stdcall convention for the functions,
it's not possible to tell whether or not you are exploring the
functions correctly. My guess is that yes, the functions are exported
correctly, so you should have no problem using this.

However, the only thing that is of concern is the memory
management routine. It looks like there is a routine for allocating
memory, but I can't see anything for deallocating memory. If you
have that defined, then you should be alright.

I just typed one of the five typedefs. There are the standard
*MyAPI_MALLOC, *MyAPI_FREE, *MyAPI_REALLOC and *MyAPI_CALLOC. There is
also
a "wrapper" typedef:

typedef struct MyAPI_memory_fu nctions {
MyAPI_MALLOC Malloc_func;
MyAPI_FREE Free_func;
MyAPI_REALLOC Realloc_func;
MyAPI_CALLOC Calloc_func;
void *AllocRef;
} MyAPI_MEMORY_FU NCS, *MyAPI_MEM_FUNC S_PTR;

Other than that, there is no reason why you shouldn't be able to
use this from .NET.

Hope this helps.

It does indeed. I get to learn something new. Thanks.

-- Mark

"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

I need to call a Win32 DLL. The API supports both Windows and
Linux, but I'm only concerned with Windows. I'd like advice whether
I can use C# or whether I'll have to dust off my old C++ books. I
would prefer to learn C#
rather than go back to C++.

The API starts with

#ifdef (WIN32)
#define MyAPI __stdcall
#else
#define MyAPI
#endif

There are bitmap mask #define statements.

All integer values are little-endian.

There are many "typedef" and "typedef struct" statements with char,
const, void, sint8, uint8, uint16, uint32, and sint32 elements,
arrays and pointers.

There are "typedef struct" statements with union elements.

To ease cross-platform use, the API defines its own memory
management. This
is one typedef:

typedef void * (MyAPI *MyAPI_REALLOC)
(void * Memblock,
uint32 Size,
void * Allocref);

And the part I'm the least sure can be done in C# is the asynchronous
event
mechanism. Here is one of the typefefs.

typedef MyAPI_RETURN (MyAPI *MyAPI_ModuleEv entHandler)
(const MyAPI_UUID *UUID,
void* AppNotifyCallba ckCtx,
MyAPI_ID ID,
uint32 Reserved,
MyAPI_Event EventType);

Can C# easily work with this API? (*)

Thanks!

-- Mark

(*) Several years ago I wrote some ugly VB6 code to deal with a DLL
that had
VB-unfriendly pointers and unicode strings. Therefore I assume it is
"possible" to use this DLL from C#. I guess I'm asking whether or
not it is
"easy" or "reasonable " to call the DLL from C#.

[Mark Jerde]

Nicholas Paldino [.NET/C# MVP] wrote:

Mark,

You aren't going to be able to use function pointers in .NET 1.1
or before. If that is how your API is defining the memory management
functions, then you will not be able to use it.
Bummer. They can't be called from C# unmanaged code either?
However, in .NET 2.0, you will be able to take a pointer in
memory, and assign it to a delegate, which you can then call from
managed code. If you can get this pointer from your API, then
getting a callable delegate is very, very simple.
My MSDN subscription has lapsed so this doesn't appear to be an option.
Plus they are betas and I need to distribute the app to users.

-- Mark

"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:OH******** *****@TK2MSFTNG P15.phx.gbl...

Nicholas Paldino [.NET/C# MVP] wrote:

Mark,

While you are using the stdcall convention for the functions,
it's not possible to tell whether or not you are exploring the
functions correctly. My guess is that yes, the functions are
exported correctly, so you should have no problem using this.

However, the only thing that is of concern is the memory
management routine. It looks like there is a routine for allocating
memory, but I can't see anything for deallocating memory. If you
have that defined, then you should be alright.

I just typed one of the five typedefs. There are the standard
*MyAPI_MALLOC, *MyAPI_FREE, *MyAPI_REALLOC and *MyAPI_CALLOC. There
is also
a "wrapper" typedef:

typedef struct MyAPI_memory_fu nctions {
MyAPI_MALLOC Malloc_func;
MyAPI_FREE Free_func;
MyAPI_REALLOC Realloc_func;
MyAPI_CALLOC Calloc_func;
void *AllocRef;
} MyAPI_MEMORY_FU NCS, *MyAPI_MEM_FUNC S_PTR;

Other than that, there is no reason why you shouldn't be able to
use this from .NET.

Hope this helps.

It does indeed. I get to learn something new. Thanks.

-- Mark

"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
I need to call a Win32 DLL. The API supports both Windows and
Linux, but I'm only concerned with Windows. I'd like advice
whether I can use C# or whether I'll have to dust off my old C++
books. I would prefer to learn C#
rather than go back to C++.

The API starts with

#ifdef (WIN32)
#define MyAPI __stdcall
#else
#define MyAPI
#endif

There are bitmap mask #define statements.

All integer values are little-endian.

There are many "typedef" and "typedef struct" statements with char,
const, void, sint8, uint8, uint16, uint32, and sint32 elements,
arrays and pointers.

There are "typedef struct" statements with union elements.

To ease cross-platform use, the API defines its own memory
management. This
is one typedef:

typedef void * (MyAPI *MyAPI_REALLOC)
(void * Memblock,
uint32 Size,
void * Allocref);

And the part I'm the least sure can be done in C# is the
asynchronous event
mechanism. Here is one of the typefefs.

typedef MyAPI_RETURN (MyAPI *MyAPI_ModuleEv entHandler)
(const MyAPI_UUID *UUID,
void* AppNotifyCallba ckCtx,
MyAPI_ID ID,
uint32 Reserved,
MyAPI_Event EventType);

Can C# easily work with this API? (*)

Thanks!

-- Mark

(*) Several years ago I wrote some ugly VB6 code to deal with a DLL
that had
VB-unfriendly pointers and unicode strings. Therefore I assume it
is "possible" to use this DLL from C#. I guess I'm asking whether
or not it is
"easy" or "reasonable " to call the DLL from C#.

[Nicholas Paldino [.NET/C# MVP]]

Mark,

If you do not have function definitions that are not exported, then in
..NET 1.1, you won't be able to make a call.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:uU******** *****@TK2MSFTNG P09.phx.gbl...

Nicholas Paldino [.NET/C# MVP] wrote:

Mark,

You aren't going to be able to use function pointers in .NET 1.1
or before. If that is how your API is defining the memory management
functions, then you will not be able to use it.

Bummer. They can't be called from C# unmanaged code either?

However, in .NET 2.0, you will be able to take a pointer in
memory, and assign it to a delegate, which you can then call from
managed code. If you can get this pointer from your API, then
getting a callable delegate is very, very simple.

My MSDN subscription has lapsed so this doesn't appear to be an option.
Plus they are betas and I need to distribute the app to users.

-- Mark

"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:OH******** *****@TK2MSFTNG P15.phx.gbl...

Nicholas Paldino [.NET/C# MVP] wrote:
Mark,

While you are using the stdcall convention for the functions,
it's not possible to tell whether or not you are exploring the
functions correctly. My guess is that yes, the functions are
exported correctly, so you should have no problem using this.

However, the only thing that is of concern is the memory
management routine. It looks like there is a routine for allocating
memory, but I can't see anything for deallocating memory. If you
have that defined, then you should be alright.

I just typed one of the five typedefs. There are the standard
*MyAPI_MALLOC, *MyAPI_FREE, *MyAPI_REALLOC and *MyAPI_CALLOC. There
is also
a "wrapper" typedef:

typedef struct MyAPI_memory_fu nctions {
MyAPI_MALLOC Malloc_func;
MyAPI_FREE Free_func;
MyAPI_REALLOC Realloc_func;
MyAPI_CALLOC Calloc_func;
void *AllocRef;
} MyAPI_MEMORY_FU NCS, *MyAPI_MEM_FUNC S_PTR;

Other than that, there is no reason why you shouldn't be able to
use this from .NET.

Hope this helps.

It does indeed. I get to learn something new. Thanks.

-- Mark

"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
> I need to call a Win32 DLL. The API supports both Windows and
> Linux, but I'm only concerned with Windows. I'd like advice
> whether I can use C# or whether I'll have to dust off my old C++
> books. I would prefer to learn C#
> rather than go back to C++.
>
> The API starts with
>
> #ifdef (WIN32)
> #define MyAPI __stdcall
> #else
> #define MyAPI
> #endif
>
> There are bitmap mask #define statements.
>
> All integer values are little-endian.
>
> There are many "typedef" and "typedef struct" statements with char,
> const, void, sint8, uint8, uint16, uint32, and sint32 elements,
> arrays and pointers.
>
> There are "typedef struct" statements with union elements.
>
> To ease cross-platform use, the API defines its own memory
> management. This
> is one typedef:
>
> typedef void * (MyAPI *MyAPI_REALLOC)
> (void * Memblock,
> uint32 Size,
> void * Allocref);
>
> And the part I'm the least sure can be done in C# is the
> asynchronous event
> mechanism. Here is one of the typefefs.
>
> typedef MyAPI_RETURN (MyAPI *MyAPI_ModuleEv entHandler)
> (const MyAPI_UUID *UUID,
> void* AppNotifyCallba ckCtx,
> MyAPI_ID ID,
> uint32 Reserved,
> MyAPI_Event EventType);
>
> Can C# easily work with this API? (*)
>
> Thanks!
>
> -- Mark
>
> (*) Several years ago I wrote some ugly VB6 code to deal with a DLL
> that had
> VB-unfriendly pointers and unicode strings. Therefore I assume it
> is "possible" to use this DLL from C#. I guess I'm asking whether
> or not it is
> "easy" or "reasonable " to call the DLL from C#.

[Willy Denoyette [MVP]]

Maybe I'm mising something, but I don't think you need to pass function
pointers to C++, the memory management functions are implemented in native
C++ code and called from C++ don't they?

Willy.

"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:uU******** *****@TK2MSFTNG P09.phx.gbl...

Nicholas Paldino [.NET/C# MVP] wrote:

Mark,

You aren't going to be able to use function pointers in .NET 1.1
or before. If that is how your API is defining the memory management
functions, then you will not be able to use it.

Bummer. They can't be called from C# unmanaged code either?

However, in .NET 2.0, you will be able to take a pointer in
memory, and assign it to a delegate, which you can then call from
managed code. If you can get this pointer from your API, then
getting a callable delegate is very, very simple.

My MSDN subscription has lapsed so this doesn't appear to be an option.
Plus they are betas and I need to distribute the app to users.

-- Mark

"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:OH******** *****@TK2MSFTNG P15.phx.gbl...

Nicholas Paldino [.NET/C# MVP] wrote:
Mark,

While you are using the stdcall convention for the functions,
it's not possible to tell whether or not you are exploring the
functions correctly. My guess is that yes, the functions are
exported correctly, so you should have no problem using this.

However, the only thing that is of concern is the memory
management routine. It looks like there is a routine for allocating
memory, but I can't see anything for deallocating memory. If you
have that defined, then you should be alright.

I just typed one of the five typedefs. There are the standard
*MyAPI_MALLOC, *MyAPI_FREE, *MyAPI_REALLOC and *MyAPI_CALLOC. There
is also
a "wrapper" typedef:

typedef struct MyAPI_memory_fu nctions {
MyAPI_MALLOC Malloc_func;
MyAPI_FREE Free_func;
MyAPI_REALLOC Realloc_func;
MyAPI_CALLOC Calloc_func;
void *AllocRef;
} MyAPI_MEMORY_FU NCS, *MyAPI_MEM_FUNC S_PTR;

Other than that, there is no reason why you shouldn't be able to
use this from .NET.

Hope this helps.

It does indeed. I get to learn something new. Thanks.

-- Mark

"Mark Jerde" <ma********@ver izon.no.spam.ne t> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
> I need to call a Win32 DLL. The API supports both Windows and
> Linux, but I'm only concerned with Windows. I'd like advice
> whether I can use C# or whether I'll have to dust off my old C++
> books. I would prefer to learn C#
> rather than go back to C++.
>
> The API starts with
>
> #ifdef (WIN32)
> #define MyAPI __stdcall
> #else
> #define MyAPI
> #endif
>
> There are bitmap mask #define statements.
>
> All integer values are little-endian.
>
> There are many "typedef" and "typedef struct" statements with char,
> const, void, sint8, uint8, uint16, uint32, and sint32 elements,
> arrays and pointers.
>
> There are "typedef struct" statements with union elements.
>
> To ease cross-platform use, the API defines its own memory
> management. This
> is one typedef:
>
> typedef void * (MyAPI *MyAPI_REALLOC)
> (void * Memblock,
> uint32 Size,
> void * Allocref);
>
> And the part I'm the least sure can be done in C# is the
> asynchronous event
> mechanism. Here is one of the typefefs.
>
> typedef MyAPI_RETURN (MyAPI *MyAPI_ModuleEv entHandler)
> (const MyAPI_UUID *UUID,
> void* AppNotifyCallba ckCtx,
> MyAPI_ID ID,
> uint32 Reserved,
> MyAPI_Event EventType);
>
> Can C# easily work with this API? (*)
>
> Thanks!
>
> -- Mark
>
> (*) Several years ago I wrote some ugly VB6 code to deal with a DLL
> that had
> VB-unfriendly pointers and unicode strings. Therefore I assume it
> is "possible" to use this DLL from C#. I guess I'm asking whether
> or not it is
> "easy" or "reasonable " to call the DLL from C#.