FAR par rien et par PASCAL __stdcall

Question

J'accès à une DLL par:

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

L'appel initial utilise:

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

Y at-il inconvénient de remplacer FAR par rien et par PASCAL __stdcall

Answer 1

La suppression de FAR peut imposer à tous les modules d'être dans le même segment. C'est probablement bien si c'est un petit programme.
Editer: FAR est cependant une relique du passé et ne s'applique pas aux cibles win32, et peut être supprimée dans la plupart des cas.

La modification de la convention d'appel n'affecte que l'interopérabilité possible avec des modules externes appelant ces méthodes. (il peut aussi avoir des effets sur la performance, mais je ne suis même pas sûr de cela).

Modifier: MAIS WOW ...! Non! ne peut pas être fait, Je n'ai pas remarqué que c'était pour une méthode WinAPI, c'est-à-dire un quand la convention d'appel a été facilement définie pour vous ... et la même chose vaut probablement pour FAR, il est probablement nécessaire.

lendemain modifier, avec hya, des détails supplémentaires de l'OP
La fonction cible est définie dans Windef.h comme

extern "C" int APIENTRY Send (LPCSTR sCmd) 

Avec son soutien à de très nombreux systèmes d'exploitation, les versions du compilateur et des valeurs définies localement , windef.h est [assez assez] un exercice de logique combinatoire. Avec la plupart des chemins [non MAC], et en supposant Windef.h est relativement stable dans ce domaine, APIENTRY se résume à

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

Et puisque pour les mêmes chemins, PASCAL produit également le premier __stdcall « mystère » est résolu, dans ce contexte particulier (ie généralement non MAC, compilateur MSC 8.0 ou supérieur (ou un compilateur définissant _STDCALL_SUPPORTED ...)

En ce qui concerne FAR ou rien, c'est moins clair (pour moi), mais aussi , la plupart des chemins dans les macros windef.h conduisent à ces deux macros comme ne produisant rien, je pense que c'est parce que le compilateur utiliserait la cible modèle de mémoire pour comprendre ce qui était des pointeurs courts et longs. Quoi qu'il en soit, le prototype cible utilise LPCSTR, c'est-à-dire un pointeur "long/long" et c'est probablement ce que le compilateur a produit. De même pour le modificateur FAR utilisé avec la fonction elle-même, ceci n'est pas nécessaire non plus, le compilateur talonnant pour un appel éloigné selon le modèle de mémoire et/ou implicitement.

Donc, ce qui précède explique pourquoi, YES, les modifications apportéesPASCAL-__stdcall et de FAR à rien sont OK et devrait se traduire par une binaire fonctionnelle. (probablement à re-vérifier etc, si vous changez le compilateur et/ou le système d'exploitation cible).

Merci pour cette question, car cela m'a incité à revoir les problèmes que je n'avais pas vu depuis un moment.