Удаление 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
до ничего , в порядке и должны привести к функциональному двоичному файлу . (возможно, будет перепроверено и т. д., если вы смените компилятор и / или целевую ОС).
Спасибо за этот вопрос, так как это побудило меня вернуться к вопросам, которых я давно не видел.