Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!uw-beaver!entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: extern
Message-ID: <2569@dataio.Data-IO.COM>
Date: 13 Jul 90 21:29:17 GMT
References: <1990Jul9.190744.1437@Solbourne.COM> <1990Jul10.004710.20500@Octopus.COM> <5353@stpstn.UUCP>
Organization: Data I/O Corporation; Redmond, WA
Lines: 27

In article <5353@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes:
<In article <1990Jul10.004710.20500@Octopus.COM> stever@octopus.UUCP (Steve Resnick ) writes:
<<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()?
<Microsoft has decided that for version 6.0, "__far" is better than "far"
<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.

The FAR macro is still entirely unnecessary. To port to a machine that does
not have far:

#define far

To port to the new _far keyword:

#define far _far

There is no point to the FAR macro (and the other similar ones).