2012-01-26 5 views
2

У меня возникла серьезная проблема. У меня есть код C#, который загружает DLL, закодированную в C, которая вызывает DLL, закодированную на C++. Все нормально, пока я не хочу передавать указатель массива от уровня C до уровня C++.Передача указателя на функцию в DLL

Вызывающий код в C заключается в следующем:

#include <windows.h> 
#include <winbase.h> 
#include <windef.h> 

int sendDLL(int* , int); 

typedef int (*SendFunc)(int*); 

int sendDLL(int* msg , int msgLength) 
{ 
    int status = 0; 
    SendFunc _SendFunc; 

    HINSTANCE serialLibrary = LoadLibrary("sender.dll"); 

    if (serialLibrary) 
    { 
     _SendFunc = (SendFunc)GetProcAddress(serialLibrary, "UssSend"); 
     if (_SendFunc) 
     { 
      status = _SendFunc(msg); 
     } 

     FreeLibrary(serialLibrary); 
    } 

    return status; 
} 

Теперь реальный поворот в том, что передавая указатель не достаточно: сообщение, которое передается будет переписан в DLL, и мы должны читать еще раз, пока не вернется _SendFunc(...).

Если я запустить программу из Visual Studio (самый высокий уровень - C#), я получаю следующее право, когда status = _SendFunc=(msg); называется (это точно, если закомментировать, ошибка не возникнет.)

Необработанное исключение типа «System.AccessViolationException» произошло в TestRS232.exe

Дополнительная информация: Попытка чтения или записи защищенной памяти. Это часто свидетельствует о том, что другая память повреждена.

Это способ, которым это можно решить?

+2

Как 'UssSend()' знает размер массива, на который указывает 'msg'? 'serialDLL()' принимает параметр 'msgLength', который (предположительно) содержит число элементов, на которые указывает' msg'. – hmjd

+0

Вы также можете быть заинтересованы в [этой статье, относящейся к NXCOMPAT и DEP] (http://blogs.msdn.com/b/ed_maurer/archive/2007/12/14/nxcompat-and-the-c-compiler.aspx). – hmjd

+0

Вероятно, вы должны показать нам метод багги, а не тот, который называет его ... – Nuffin

ответ

0

ОК, проблема решена, ошибка была гораздо более очевидно, что я когда-либо думал: значение возвращаемое _SendFunc(...) не int но long, и это вызвало сообщение выше.

Извините за вопрос, а также за помощь для всех.

+1

Вы уверены, что это была единственная причина? AFAIK, как int, так и long, 32 бит даже на Win64, и оба типа возвращаются в том же регистре процессоров, поэтому запутывание int и long должно фактически быть «ошибкой, с которой вы можете избавиться» в Windows. – wolfgang

+0

Да, я уверен, исправляя int «status» var, чтобы долго его решить, хотя я думал о том же, что и вы. – petermolnar

+0

I второе мнение Вольфганга ... Изменение от 'int' до' long' на Windows не может быть решателем. Обратите внимание на несоответствия конвенционных соглашений: что такое прототип 'UssSend'? Это '__cdecl' или' __stdcall'? –

Смежные вопросы