Mail Archives: djgpp/1998/11/01/19:25:56
Tal Lavi wrote:
>
> HELP!!!
>
> I can't seem to read a .bmp file correctly under DOS DJGPP(2.01).
> One of my problems is that there are just too much ways to read a file!
> But, let's start from the top:
>
> I open the file like this: FILE f*=fopen("foo.bmp","rb");
> Is "rb" correct? Is that how binary files are opened for reading?
Yep.
> Now, I want to read some words, BUT NOT STORE THEM, just check for a valid
> value and move on:
>
> if (getw(f)!=0) return(1);
>
> Not only that the correct value is not read, but getw seem to actually read
> 4 bytes! and it also moves the file pointer in ftell by 4 instead of 2!
> Is that even possible?
Sure. On DJGPP, an `int' is 32 bits. The idea of a "word" being 16
bits is an 8086-ism; `getw', being more general, usually refers to the
processor's wordsize, which is typically the size of its registers (32
bits on a protected-mode 386), which is typically the size of `int'. So
`getw' reads an `int', which is 4 bytes long.
You've just learned why `getw' is not portable. You should use `fread':
short s;
fread(s, sizeof(short), 1, f);
This will still only work on platforms with a 16-bit `short', but that
is much more widespread.
> getc, by the way, moves the file pointer by 1, not by 2, and it reads the
> correct value each and every time.
`getw' also returns the correct value; i.e. what it's supposed to. You
just didn't expect it. `getc' is supposed to read one `char', and it
does. `getw' is supposed to read one `int', and it does.
> When I want to retrieve some values, and store them, I should use fscanf,
> right?
If they're in text, yes. If binary, no.
> My question is: how can I read a DWord? What is the correct masking letter?
You can't read raw binary numbers with `?scanf'; use `fread' as above.
> And another thing: how are the bytes arranged in the DWord? I mean: if a
> DWord contains the value 128, in which of those four bytes, will the value
> 128 be stored? ______
The 386 stores multi-byte integers least-significant byte first, so 128
will be in the low byte. More generally,
unsigned long l = 0x12345678;
unsigned char a[] = { 0x78, 0x56, 0x34, 0x12 };
should have the same bits.
> I just can't believe no one knows the answers to my questions in "misc
> questions"!!!
Is that an earlier post? I haven't seen it yet; perhaps you need to
repost it?
--
Nate Eldredge
nate AT cartsys DOT com
- Raw text -