extern

[Ken Lerman]

In article <1990Jul10.004710.20500 at Octopus.COM> stever at octopus.UUCP (Steve Resnick ) writes:
[.... stuff deleted ....]
>
>I wish the boys in Redmond Washington would adhere to that philosophy.
>After spending a weekend debugging some OS/2 code I have learned to loathe
>dearly MS's macros. In the OS/2 programmers refrences, Quick Help, and other
>MS blessed/produced products they all refer to these "improved" types and 
>declarations. an example is:
>
>#define EXTERN extern
>#define far FAR
>#define pascal PASCAL
>
>What's wrong with extern far pascal foo() vs EXTERN FAR PASCAL foo()?
>And why should I use "SEL n" when I mean "unsigned n"? I would bitch a lot
>less if I didn't have to have MANY books open to figure out what these silly
>things meant! (oddly enough, if I ask MSC to generate protos for my EXTERN
>FAR PASCAL functions, they get generated correctly..)
> 

>Seems like we keep working towards standardization and someone in the infinite
>glory wants to change it for us.... *sigh*
> 
>Steve Resnick -<stever at octopus.COM apple!octopus!stever sun!vsi1!octopus!stever>
>408/241-1533 Process Scientific, Inc.
>"0x2B|~0x2B THAT is the question!"

What is wrong is that far and pascal aren't ANSI C to begin with.  And
Microsoft has decided that for version 6.0, "__far" is better than "far"
(because ANSI reserves identifiers beginning with "__" to the compiler
writer.)

So if you followed the Microsoft "standard", all you have to do is use
the new set of macros and your code works.

Then if you would like to port your code to some other machine, you
can #define FAR to nothing.

At least Microsoft has an excuse for the near/far crap we have to put
up with.  They can blame it on the wizards at Intel who decided that
compatibility with previous chips is more important than usability.

The jerks at DEC screwed up external references all by themselves.
Rather than change some of their other software, they decided to foist
off their poor excuse for a compiler as C under VMS.

Ken