DN> pleasing, or perhaps an accomplishment in itself, but unless 
DN> there is some intrinsic *technical* value in using a #define 
DN> (like a manifest constant or some other common value used in 
DN> many source places that may be subject to change at some future 
DN >date), then it should be avoided at all costs. IMVHO.

FA> In this case i was looking at my getch() function, which uses INT16.
FA> Unfortunately, there are at least three types of k/boards commonly in 
FA> use, and they're read with different values in AH 0x01,0x11,i forget the 
FA> third . So in order to make this function realize, which one to use i have 
FA> to access the CMOS to get the KB IDbyte, and set AH accordingly. 
FA> A #define would've been beutiful, but the way it is, the IDbyte has to be 
FA> fetched on each call or placed in a static char on the first call, but that 
FA> still adds an if statement. I think the #define (had it worked),would've 
FA> been justified for this one ?

And have your program not be able to be run when you change keyboard?!

Even if you do want to tie your executable down to a particular keyboard,
you can do it another way:

bcc -DUSE_STUPID_KEYBOARD

#ifdef USE_STUPID_KEYBOARD
#define XXX 0x01
#else
#define XXX 0x11
#endif

BFN.  Paul.
@EOT:

---