Do you need to use Far Pascal?
Author
Hey all,
I was wondering if Far Pascal call is still needed. I read that is was used in the 16-bit windows day. But every where I read didnt give me a concrete answer as to if it is still need or not. So is it still needed? and could you explain why?
Thank you in advance
I kind of explain it here, at least the FAR part. The PASCAL part is explained here. These days it's only needed in the rarest of situations. With straight C code you'll find cdecl and stdcall with user code and in some cases fastcall with device driver code. With C++ you'll find those three as well as thiscall. So the concrete answer is NO it's not needed.
If you look at the define for FAR it's defined as:
#define FAR far
if you look at the define for far you see:
#define far
Meaning that the preprocessor effectively removes FAR from the code.
I'm not sure how the pascal calling convention ended up in the Windows SDK. It's also used in classic Mac SDKs. Microsoft's SDK was probably 'inspired' by the Mac OS.
Windows still needs WinMain and message procs defined with PASCAL, or it won't link correctly. This also applies to other types that are defined as stdcall, such as WINAPI, APIENTRY and, CALLBACK.
The only advantage I see to using the pascal calling convention (on the x86 platform) would be writing an assembly language routine. The values could either be popped or accessed using the stack pointer, in the correct order.
Since 'the art' of writing assembly language routines is dead, it's mostly a legacy issue now.
[Edited by - cdoty on March 20, 2007 11:30:21 PM]
#define FAR far
if you look at the define for far you see:
#define far
Meaning that the preprocessor effectively removes FAR from the code.
I'm not sure how the pascal calling convention ended up in the Windows SDK. It's also used in classic Mac SDKs. Microsoft's SDK was probably 'inspired' by the Mac OS.
Windows still needs WinMain and message procs defined with PASCAL, or it won't link correctly. This also applies to other types that are defined as stdcall, such as WINAPI, APIENTRY and, CALLBACK.
The only advantage I see to using the pascal calling convention (on the x86 platform) would be writing an assembly language routine. The values could either be popped or accessed using the stack pointer, in the correct order.
Since 'the art' of writing assembly language routines is dead, it's mostly a legacy issue now.
[Edited by - cdoty on March 20, 2007 11:30:21 PM]
Quote:Original post by cdoty
Windows still needs WinMain and message procs defined with PASCAL, or it won't link correctly. This also applies to other types that are defined as stdcall, such as WINAPI, APIENTRY and, CALLBACK.
As you just indirectly pointed out, in the modern Windows SDK, PASCAL gets defined as __stdcall, not pascal. So in reality WinMain does not need PASCAL, it just needs __stdcall.
Quote:Original post by cdoty
The only advantage I see to using the pascal calling convention (on the x86 platform) would be writing an assembly language routine. The values could either be popped or accessed using the stack pointer, in the correct order.
My understanding for the justification of pascal/stdcall instead of cdecl calling conventions is that having the callee fixup the stack on exit saves you a few bytes per function call. When factored in over the course of a large project that can save considerable memory.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
