Замена FAR ничем и PASCAL на __stdcall - PullRequest
1 голос
/ 29 октября 2009

Я обращаюсь к DLL через:

int (__stdcall *Send) (char *);
Send = (int (__stdcall *)(char *)) GetProcAddress(hmModule,"Send");

Исходный вызов использует:

int (FAR PASCAL *Send) (char FAR *);
Send = (int (FAR PASCAL *)(char FAR *))GetProcAddress(hmModule,"Send");

Есть ли минус, чтобы заменить FAR ничем и PASCAL на __stdcall

1 Ответ

3 голосов
/ 29 октября 2009

Удаление FAR может ограничить все модули, которые находятся в одном сегменте. Это, вероятно, хорошо, если это небольшая программа.
Редактировать: FAR, однако, является пережитком прошлого и не относится к целям win32, и его можно удалить в большинстве случаев.

Изменение соглашения о вызовах влияет только на возможное взаимодействие с внешними модулями, вызывающими эти методы. (он также может оказывать минимальное влияние на производительность, хотя я даже не уверен в этом).

Редактировать: НО ВАУ ...! Нет! не может быть сделано, Я не заметил, что это был метод WinAPI, т. е. тот, когда соглашение о вызовах было легко определено для вас ... и то же самое, вероятно, относится и к FAR, это, вероятно, необходимо.

На следующий день редактировать , с помощью hya, дополнительные детали ОП
Целевая функция определена в windef.h как

extern "C" int APIENTRY Send (LPCSTR sCmd)

Благодаря поддержке очень многих ОС, версий компиляторов и локально определенных значений, windef.h [вполне достаточно] упражнение комбинаторной логики. При большинстве [не MAC] путей и при условии, что windef.h относительно неизменен в этой области, APIENTRY сводится к

...
#define APIENTRY  WINAPI
...
#define WINAPI   __stdcall

И поскольку для тех же путей PASCAL также выдает __stdcall, первая «загадка» раскрыта, в этом конкретном контексте (то есть, как правило, не MAC, MSC-компилятор 8.0 или выше (или компилятор, определяющий _STDCALL_SUPPORTED ...) )

Что касается FAR или ничего, это менее понятно (для меня), но также большинство путей в макросах windef.h приводят к тому, что эти два макроса не производят ничего. Я думаю, это потому, что компилятор использовал бы целевую модель памяти, чтобы выяснить, что было коротким и длинным указателями. Во всяком случае, целевой прототип использует LPCSTR, то есть указатель «дальний / длинный», и это, вероятно, то, что создал компилятор. Аналогично для модификатора FAR, используемого с самой функцией, это тоже не нужно, поскольку компилятор заглушает дальний вызов согласно модели памяти и / или неявно.

Итак, вышеизложенное объясняет, почему, ДА, изменения, сделанные с PASCAL до __stdcall и с FAR до ничего , в порядке и должны привести к функциональному двоичному файлу . (возможно, будет перепроверено и т. д., если вы смените компилятор и / или целевую ОС).

Спасибо за этот вопрос, так как это побудило меня вернуться к вопросам, которых я давно не видел.

...