WinCE下调用CreateDIBSection问题

[ljan]

Wince下，需要实现一个接口，读一个bmp file，返回一个hbitmap handle。
当前case，打开一个22*22的16位bmp文件，

大致调用如下：
hBitmap=CreateDIBSection(hDc,(BITMAPINFO *)lpImgData,DIB_RGB_COLORS,
(void **)&ptData,NULL, 0);
memcpy(ptData, lpPtr, ImgSize);

ImgSize 是lpImgData的BITMAPINFOHEADER中的biSizeImage，数据为970
(或者BITMAPFILEHEADER 里的 bfSize- bfOffBits，也是970)
我在win32下，这个接口返回的句柄，在外面使用都没问题。
Wince一调用，就在其他调用接口的地方，老是死机。
我同事说， ImgSize应该用(lpImgData的BITMAPINFOHEADER中的) biWidth*biHeight*2 = 22*22*2 = 968
用970 copy，会把其他的memory覆盖到?

似乎按照我同事的方法，调用了一下，确实没出错，但是我不知道原因是什么，为什么1个是970，另一个是968，差2个字节。

有人知道那种用法对吗?

[cnzdgs]

bmp文件是怎么来的？可能是生成文件时结构填写有误。图象大小应该是（biWidth*biBitCount+31）/32*4*biHeight。

[TianChong]

你这个情况是由于对各项所表示的值混淆所致的，正确的理解如下：

位图文件头主要用于识别位图文件。以下是位图文件头结构的定义：

typedef struct tagBITMAPFILEHEADER {
WORD bfType;
DWORD bfSize;
WORD bfReserved1;
WORD bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;
　　其中的bfType值应该是“BM”（0x4d42），标志该文件是位图文件。bfSize的值是位图文件的大小。bfReserved1, bfReserved2 为保留字，值为0。bfOffBits为位图文件大小与DIB（设备无关的位图 Device-indepentent bitmap）位图数据的大小之差。如：

BITMAPFILEHEADER bmfHdr;
bmfHdr.bfType = 0x4D42; // "BM"
dwDIBSize = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + dwPaletteSize + dwBmBitsSize;
bmfHdr.bfSize = dwDIBSize;
bmfHdr.bfReserved1 = 0;
bmfHdr.bfReserved2 = 0;
bmfHdr.bfOffBits = (DWORD)sizeof(BITMAPFILEHEADER) + (DWORD)sizeof(BITMAPINFOHEADER) + dwPaletteSize;

看这里>>>
-------------------------------------------------------------
bfSize的值是位图文件的大小。
bfOffBits为位图文件大小与DIB（设备无关的位图 Device-indepentent bitmap）位图数据的大小之差。
-------------------------------------------------------------

[ljan]

由于我用的bmp，是16位bmp，所以没有调色表数据。
bfOffBits
Specifies the offset, in bytes, from the BITMAPFILEHEADER structure to the bitmap bits

msdn上描述，bfOffBits，表示从BITMAPFILEHEADER结构开始，也就是从文件头开始，到位图文件真正的数据的偏移量
那么bfSize - bfOffBits，不就是位图数据的真正size长度? 我这里计算这个size长度，是不包括bmfheader bminfo 调色表

没看出你说的，理解混淆啊

[cnzdgs]

在正常的情况下，可以从结构中获取biSizeImage ，也可以用bfSize-bfOffBits来计算。对于这张图，根据结构取出的值是970，说明结构中的内容不正常，可能是后面附加了两字节自定义的信息，也可能是制作bmp文件是计算错误。对于这种情况，应该自己来计算实际的长度，忽略结构中记录的长度。

[ljan]

我用paint创建了一个24位的22*22位图，以上3种方法，计算bit size就一样了。看来可能是位图文件有些问题，我打开里面的数据，在文件末尾有2个00
明天让我同事创建1个16位的位图，再check一下，明天结贴^_^

不过，有一点比较奇怪，
CreateDIBSection会在系统内开辟一块memory，这个具体size不知道系统如何确定，如果只开968个字节，那么我拷贝970个字节，越界操作, wince里面死机

win32里面，为什么这样操作，系统都不挂呢?

[ljan]

(22*16+31)/32*4*22 = 968，奇怪了，那我想问下，正常方式取bmp文件bit size，以下2种方法对吗?
lpImgData的BITMAPINFOHEADER中的biSizeImage
(或者BITMAPFILEHEADER 里的 bfSize - bfOffBits

[ljan]

bmp文件，是另一个同事写的接口，我们的bmp文件，是整合在一个大文件中，需要取某个bmp文件，传1个id进去，调1个接口，将bmp整个信息和size，返回给我们使用

[hylovett]

帮顶

[cnzdgs]

越界不一定会引起问题，如果越界部分是未分配的地址空间，在访问时就会抛出异常；如果越界部分覆盖了其它数据，则后果是无法预料的，可能导致程序运行到其它函数时出错，如果越界覆盖的数据不重要，则可能体现不出问题。

[ljan]

找同事创建了一个16位的bmp，方式也蛮简单：
1. 打开photoshop，新建，输入宽22，高22，其他默认
2. 然后另存为，格式bmp
3. 再点击save
4. 文件格式选择windows，深度:16

这样创建出来的bmp，biSizeImage就为970，有些奇怪。可能是photoshop保存时，做了啥调整之类的。

[ljan]

非常感谢cnzdgs的帮助，特别越界操作那块，又帮我理清了下。