5
A
답변
8
이것은 32 비트 코드에 대한 파스칼 호출 규칙에 적용되었습니다. Pascal은 OS/2 및 Windows 3과 같은 16 비트 운영 체제의 호출 규칙입니다. 왜 파스칼을 선택했는지 조금 추측 할 수 있습니다. 당시 조그마한 강아지 였지만 약간 효율적이었습니다. 640 KB가 당신이 함께 일해야 할 때 중요했던 것.
대부분의 Win32 함수는 링커에 표시되기 전에 내 보낸 함수가 어떻게 꾸며 지는지를 지정하기 때문에 true stdcall이 아닙니다. void Mumble (int arg)와 같이 _Mumble @ 4가됩니다. @ 뒤의 숫자는 활성화 프레임 크기를 나타냅니다. 그러나 대부분의 Win32 함수는 장식없이 내보내집니다. 아마도 프로그래머에게 GetProcAddress()를 작동시킬 수있는 싸울 기회를주기 위해서 일 것이다. 필자는 링커가 선언 된 API 함수 시그니처와 실제 함수 시그니처 간의 불일치를 감지 할 수 있도록 도와 주었다고 생각합니다. 전달 된 인수의 수가 불일치하는 것은 자동 kaboom입니다. 호출 수신자가 스택에서 더 많은 또는 더 적은 인수를 넘겨 받아 전달 된 이후입니다. 진단하기도 어렵습니다. stdcall의 취약점 인 cdecl 협약에는이 문제가 없습니다.
내부 호출은 stdcall, cdecl 및 thiscall 사이의 혼합 백입니다. 단일 단계 Windows 코드가 내가 좋아하는 일이 아니지만 필자가 패턴을 발견했다고 말할 수는 없습니다.
+2
심볼 장식이 부족하여 winapi 바이너리가 심볼 장식이 없으므로 (장식을 벗기거나 서기를 사용하는)'.def' 파일을 사용하여 GetProcAddress를 통해 간단하게 가져옵니다. – Necrolis
+0
좋은 지적, 네가 맞다고 생각해. –
4
stdcall로 컴파일 된 코드는 cdecl (대안)으로 컴파일 된 코드보다 상당히 작습니다. 결정이 내려 졌을 때, 더 작은 코드는 더 빠른 코드였습니다.
+0
실제로 나는 Hans Passant의 대답을 선호했지만, 뭐든간에. –
+0
오랫동안 Microsoftee 였으므로 귀하의 대답을 선택했습니다. – Benjamin
+0
그 주장에 대한 증거가 있습니까? 직관적으로 나는 그것이 stdcall과 cdecl 사이의 씻어 야한다고 생각하고 검색하는 것은 두 가지 호출 규칙 사이의 크기 비교를 생각지 않는다. –
왜 Microsoft는 API 협약으로 * stdcall을 선택 했습니까? – JustBoo
감사합니다 Constantin :) – Benjamin