>  If you konw the data to be 16 bits wide, read it as 
> a short, not as an int.
>You'll find that while the size of an int varies among systems, on most a
>short is 16 bits and a long is 32 bits. This will 
 `R> certainly work when moving
>from TC to djgpp as you're planning to do. 
 `R>      Yeah, I'm moving from TC to djgpp.  The thing is 
 `R> that everything's dumped
 `R> via structure to the file and I was hoping there was an 
 `R> easy way.  I'd assume
 `R> that this means I'll have to read the structures in one 
 `R> field at a time (and
 `R> it's a HUGE structure), correct?
No.  For example, let's say this was your struct in TC:
typedef struct tcfoo
{
  char   c;
  int    n;
  short  s;
  long   l;
  float  f;
  double d;
  char   array[32];
} TCFOO;
This is what you would have to do in DJGPP:
#pragma pack(2) /* 1 */
typedef struct djfoo
{
  char   c;
  short  n; /* 2 */
  short  s;
  long   l;
  float  f;
  double d;
  char   array[32];
} DJFOO;
#pragma pack() /* 3 */
Easy as 1, 2, 3!  :-)
1 - set the structure alignment to 2-byte alignment.  This is natural for 
16-bit systems (what you did in TC), whereas 4-byte is natural for 32-bit 
systems (such as pmode).  This is so that the padding - wasted space inside 
the structure - continues to be the same size.
2 - change all instances of int to short.
3 - restore your packing alignment.  Note that the program can be FASTER if 
it uses its "natural" alignment.  It is easier for the processor to pick up a 
4-byte value (i.e., long) if it is aligned on a 4-byte boundary, in a 4-byte 
(32-bit) system.  This is also required if you end up #include'ing other 
header files after this - they may expect "normal" packing so that when you 
create a standard structure to pass around (i.e., struct tm), it will be 
using the padding size expected by the already-compiled libraries.
Note that 1 & 3 are compiler specific (Watcom, for example, uses #pragma 
pack(pop) for #3), while the entire idea of forcing a size is non-portable to 
begin with.  The only reason I responded with non-portable code is because 
the standard, TTBOMK, doesn't allow for any of this, prefering to let the 
compilers handle things in whatever way is easiest/fastest.  So you're asking 
for inherently non-portable code - use at own risk.  :-)
Hope this helps!
---
---------------