简介：面向仍在使用VC6.0进行C++桌面开发的程序员，这份压缩包围绕PNG图片加载与透明化处理给出可编译的GDI+实践示例，适合需要为老项目补充现代图像显示能力、又不想整体迁移工具链的中级开发者参考。包内共70个文件，以34个GDI+相关头文件、3个cpp源文件和工程配置为主，另含8张PNG素材及lib、exe、dsp、dsw等编译链接文件，压缩包约4.73MB，工程结构完整，可直接在VC6.0中打开对照。已有716人学习。资源重点演示GDI+的启动与关闭、位图载入、Alpha通道与颜色矩阵调节、Graphics绘制及资源释放流程，并配有带PNG表盘的时钟示例，便于理解透明图层在对话框程序中的实际用法。借助现成工程与素材，读者能较快搭起可运行环境，掌握老版本VC下PNG透明绘制与窗口透明处理的排错思路，并据此改造自己的项目。

1. VC6.0 加载 PNG 并透明化：一枚老工程里还在跑的图像需求

手上有个 VC6.0 维护的老项目，界面上要贴一张带透明通道的 PNG 图标，结果LoadImage、CImage、GDI+ 全都不认，图片一贴上去要么黑底要么白底。这不是玄学，是 VC6 自带的 SDK 里根本没有 PNG 解码器，GDI 只认 BMP、ICO、WMF 这几样。VC++ PNG透明处理 这件事在老工程里被反复问，核心就两件事：把 PNG 解成 32 位 BGRA 像素，再按 alpha 做逐像素混合或走 AlphaBlend。这篇把我在这类工程里落过的做法拆开讲清楚——libpng 编译、内存解码、预乘坑、逐像素合成，适合还在维护 MFC/VC6 界面、手头只有 VS6 那一套工具链的从业者。

2. 选型：libpng 还是自己写解码器

2.1 三条路线的取舍

在 VC6 环境里加载 PNG，实际能走的路只有三条，先把边界说清楚再动手，不然编译到一半才发现方向不对，时间全扔进去了。

VC6 那年头 GDI+ 还没随 SDK 铺开，很多人机器上是事后装的 Platform SDK。而 libpng 是纯 C 写的，VC6 编出来毫无压力，所以我一般直接上 libpng + zlib 源码编译，把.lib一起塞进工程，比配 SDK 稳。注意别用最新的 libpng 版本去喂 VC6，新版本用了stdint.h、long long之类 VC6 不认的东西，要挑一个对 C89 友好的老版本，或者手工把pngconf.h里的PNG_USE_CONFIG_H、整型定义改掉。

2.2 编译 libpng 到 VC6 工程

我把 zlib 和 libpng 的源码直接加进工程当源码编译，而不是外部.lib，好处是调试时能跟进去，坏处是文件多。步骤是这样：

第一步，在工程里新建一个静态库配置或者干脆把.c都 add 进当前工程（zlib的adler32.c、crc32.c、inflate.c、deflate.c、trees.c、inftrees.c、inffast.c、zutil.c，libpng 的png.c、pngread.c、pngset.c、pngget.c、pngrutil.c、pngtrans.c、pngmem.c、pngerror.c、pngwutil.c、pngwrite.c）。链接时 VC6 的cl对长文件名不友好，路径尽量短。

第二步，改pngconf.h。VC6 没有stdint.h，把PNG_CONFIGURE_LIBPNG相关分支关掉，确认PNG_INT32/PNG_UINT32用的是unsigned long（VC6 的long是 32 位，能对上）。同时定义PNG_DEBUG 0，开PNG_NO_READ_tEXt之类裁剪用不上的块处理可以省体积，但初版别裁，先跑通。

第三步，工程设置里 C/C++ 的Struct member alignment保持默认 8 字节，Runtime Library和你主工程一致（多线程 DLL 还是静态 CRT 要对齐，VC6 里这个不对齐会报一堆LNK2005重定义）。

// png_loader.h —— 把解码封装在一个块里，主工程只认这个接口 #ifndef PNG_LOADER_H #define PNG_LOADER_H typedef struct { int width; int height; unsigned char* bits; // 32 位 BGRA，预乘前 int hasAlpha; // 0/1 } PngImage; // 从文件加载，返回 0 成功；失败时不分配 bits int PngLoadFromFile(const char* path, PngImage* out); // 释放 void PngFree(PngImage* img); #endif

这个头文件只暴露宽高、像素指针和是否带 alpha 三个信息，主工程不用管 libpng 的类型。接口返回 int 而不是抛异常，因为 VC6 时代工程普遍不开异常，调用方用if (ret != 0)判断更省心。参数说明：path用 ANSI 路径，VC6 工程基本是Multi-Byte字符集；out由调用方分配结构体内存，函数内部只负责填字段和分配bits。

2.3 为什么不用 GDI+ 的二郎腿

有人会说系统自带 GDI+，一行Bitmap::FromFile就完事。问题在于 VC6 工程通常没有gdiplus.h的 include 路径和GdiplusStartup的初始化封装，要额外引 SDK；更关键的是老工程常常跑在 XP 甚至更老的机器上，GDI+ 版本差异会导致部分带 alpha 的 PNG 渲染出灰边。而 libpng 路径全程可控，预乘与否、通道顺序都由自己决定，出问题能断点进源码。代价是多编几个文件，一次配好之后再也不用管。选型上我一般把话讲死：要长期维护、要能断点、要支持 8/16 位深，走 libpng；只是临时贴一张图且机器确定有 GDI+，走 GDI+ 更快。

3. 解码：从文件到 32 位 BGRA 的完整链路

3.1 走内存解码而不是回调

libpng 有两种读法：一种是png_init_io绑FILE*，另一种是png_set_read_fn绑自定义回调。老工程里图片经常打成资源或者放在加密包里，读出来已经是内存块，所以我一律用回调读内存，接口里再包一个从文件读的版本。回调函数签名是void (*png_rw_ptr)(png_structp, png_bytep, png_size_t)，从内存里搬指定字节数即可。

下面这段是核心解码，注意它强制png_set_expand+png_set_bgr+png_set_strip_16，目的是一次性把各种边角格式规整到 8 位 BGRA：

#include "png.h" #include "png_loader.h" #include <stdio.h> #include <stdlib.h> #include <string.h> typedef struct { unsigned char* data; size_t size; size_t pos; } MemReader; static void mem_read_cb(png_structp png, png_bytep buf, png_size_t len) { MemReader* r = (MemReader*)png_get_io_ptr(png); if (r->pos + len > r->size) { png_error(png, "read overflow"); return; } memcpy(buf, r->data + r->pos, len); r->pos += len; } static int decode_png(unsigned char* filebuf, size_t filesize, PngImage* out) { png_structp png = NULL; png_infop info = NULL; png_bytep* rows = NULL; MemReader reader; int colorType, bitDepth, interlace; int rowbytes, i; int ok = -1; // 签名校验：8 字节，别省，读错文件会直接崩在 libpng 里 if (filesize < 8 || png_sig_cmp(filebuf, 0, 8) != 0) return -1; reader.data = filebuf; reader.size = filesize; reader.pos = 0; png = png_create_read_struct(PNG_LIBPNG_VER_STRING, NULL, NULL, NULL); if (!png) return -1; info = png_create_info_struct(png); if (!info) { png_destroy_read_struct(&png, NULL, NULL); return -1; } // setjmp：libpng 出错走 longjmp，必须有一个合法的落点 if (setjmp(png_jmpbuf(png))) { png_destroy_read_struct(&png, &info, NULL); if (rows) { free(rows); rows = NULL; } return -1; } png_set_read_fn(png, &reader, mem_read_cb); png_read_info(png, info); png_get_IHDR(png, info, (png_uint_32*)&out->width, (png_uint_32*)&out->height, &bitDepth, &colorType, &interlace, NULL, NULL); // 统一规整通道与位深 if (colorType == PNG_COLOR_TYPE_PALETTE) png_set_palette_to_rgb(png); if (colorType == PNG_COLOR_TYPE_GRAY && bitDepth < 8) png_set_gray_1_2_4_to_8(png); if (png_get_valid(png, info, PNG_INFO_tRNS)) png_set_tRNS_to_alpha(png); if (bitDepth == 16) png_set_strip_16(png); if (colorType == PNG_COLOR_TYPE_GRAY || colorType == PNG_COLOR_TYPE_GRAY_ALPHA) png_set_gray_to_rgb(png); // 关键：让 libpng 直接吐 BGR 顺序，配合 alpha 即 BGRA png_set_bgr(png); png_read_update_info(png, info); rowbytes = (int)png_get_rowbytes(png, info); out->hasAlpha = (png_get_color_type(png, info) & PNG_COLOR_MASK_ALPHA) ? 1 : 0; out->bits = (unsigned char*)malloc(rowbytes * out->height); rows = (png_bytep*)malloc(sizeof(png_bytep) * out->height); if (!out->bits || !rows) goto cleanup; for (i = 0; i < out->height; i++) rows[i] = out->bits + (size_t)i * rowbytes; png_read_image(png, rows); png_read_end(png, NULL); ok = 0; cleanup: if (rows) free(rows); png_destroy_read_struct(&png, &info, NULL); if (ok != 0 && out->bits) { free(out->bits); out->bits = NULL; } return ok; }

逐段说明。png_sig_cmp那八字节校验不能省，我见过直接把.jpg改名成.png的素材，缺少校验时 libpng 会拿着错误的块长度往下读，最后在png_error里 longjmp，调试器里看是一堆无意义栈。setjmp这一段是血泪经验：libpng 的错误处理默认是longjmp回png_jmpbuf，如果没设落点，程序会直接终止，不是返回错误码。所有malloc出来、跨 longjmp 还活着的指针（这里的rows）必须在 setjmp 分支里释放，否则错误路径下就漏了。

png_set_strip_16在只想要 8 位显示时必开，否则 16 位 PNG 出来是每通道两字节，按 32 位 BGRA 去读就全花了。png_set_bgr让 libpng 输出 BGR 顺序，这样 alpha 在最后一位，凑成 Windows 的BGRA（也就是COLORREF反序但 alpha 在尾），AlphaBlend和手工混合都能直接用。png_get_rowbytes拿到的行字节数是规整之后的，不能自己拿width*4硬算，灰度转 RGB、调色板展开都会改变它。参数上唯一要留意的是png_set_gray_1_2_4_to_8在不同 libpng 版本里名字不一样，1.2.x 叫这个，1.4 之后改成了png_set_expand_gray_1_2_4_to_8，编译报未定义就先查版本。

3.2 文件读入口和内存管理

文件读入口只是把整个文件读进内存再调decode_png，重点是读完立刻释放文件缓冲，别让解码期还挂着一份原始数据：

int PngLoadFromFile(const char* path, PngImage* out) { FILE* fp = fopen(path, "rb"); long len; unsigned char* buf; int ret; if (!fp) return -1; fseek(fp, 0, SEEK_END); len = ftell(fp); fseek(fp, 0, SEEK_SET); if (len <= 0) { fclose(fp); return -1; } buf = (unsigned char*)malloc((size_t)len); if (!buf) { fclose(fp); return -1; } if (fread(buf, 1, (size_t)len, fp) != (size_t)len) { free(buf); fclose(fp); return -1; } fclose(fp); memset(out, 0, sizeof(PngImage)); ret = decode_png(buf, (size_t)len, out); // 解码完原始缓冲就没用了 free(buf); return ret; } void PngFree(PngImage* img) { if (!img) return; if (img->bits) { free(img->bits); img->bits = NULL; } img->width = img->height = 0; img->hasAlpha = 0; }

fopen用"rb"是必须的，文本模式在 Windows 上会把0x1A当 EOF，PNG 里出现这个字节的概率不低，踩一次能查半天。PngFree只负责释放bits，结构体本身由调用方管理，这是为了配合 VC6 工程里常见的「结构体放栈上、像素放堆上」的习惯。注意memset(out, 0, ...)要在解码前做，这样即使解码中途失败，PngFree也不会去 free 一个野指针。

4. 透明合成：逐像素混合与 AlphaBlend 两条路

4.1 预乘这件事必须先讲清

透明化真正的分水岭不是「有没有 alpha」，而是「alpha 有没有预乘」。PNG 文件里存的是非预乘的 straight alpha，即 RGB 是原始颜色、A 单独存；而 Windows 的AlphaBlend（msimg32.dll）默认按预乘（premultiplied）来解释源位图。直接把 libpng 解出来的 BGRA 丢给AlphaBlend，半透明边缘会发亮、发白，深色底上尤其明显。

两个办法：一是把像素预先乘好再交给AlphaBlend，二是完全不用AlphaBlend，自己按公式算。我一般选后者，因为老工程里msimg32.lib不一定链上，而且要控制混合结果最直接的就是自己算。非预乘的混合公式是：

out = src * a + dst * (1 - a)

a 取 0~1。用整数做就是除以 255。如果走AlphaBlend的预乘路径，得先把每个通道乘上 alpha：

// 转成预乘 BGRA，供 AlphaBlend 使用 void PngToPremultiplied(PngImage* img) { int i, n = img->width * img->height; for (i = 0; i < n; i++) { unsigned char* p = img->bits + i * 4; unsigned int a = p[3]; // BGRA 里 alpha 在 p[3] p[0] = (unsigned char)(p[0] * a / 255); // B p[1] = (unsigned char)(p[1] * a / 255); // G p[2] = (unsigned char)(p[2] * a / 255); // R // p[3] 保持不变 } }

这段只能在确认要交给 AlphaBlend 或 DirectDraw 前调用一次，调两次就乘两遍，颜色会越来越暗，这是最典型的翻车点。反过来，如果你自己逐像素混合，就不要调这个函数，直接用 straight alpha 算。判断依据记住一句：AlphaBlend要预乘，手动混合要非预乘。

4.2 逐像素混合到目标 DC

最稳的落地方式是把 PNG 解出的 BGRA 逐像素混到目标位图上，再一次性 BitBlt 到窗口。这样做的好处是不依赖msimg32.dll，混合结果可断言、可单测。下面按目标 DC 的 DIB 内存直接做：

// 把 img 混合到 dstBits 指向的 32 位 DIB 上，(x,y) 为左上角 // dstBits 的格式是 32 位 BGRA，行序自下而上（bottom-up） void BlendToDib(const PngImage* img, unsigned char* dstBits, int dstW, int dstH, int x, int y) { int i, j; for (j = 0; j < img->height; j++) { int dy = y + j; if (dy < 0 || dy >= dstH) continue; // 越界直接跳 // DIB 行序自下而上，需要翻转 unsigned char* drow = dstBits + (size_t)(dstH - 1 - dy) * dstW * 4; const unsigned char* srow = img->bits + (size_t)j * img->width * 4; for (i = 0; i < img->width; i++) { int dx = x + i; if (dx < 0 || dx >= dstW) continue; const unsigned char* s = srow + i * 4; unsigned char* d = drow + dx * 4; unsigned int a = s[3]; if (a == 0) continue; // 全透明，保留目标 if (a == 255) { // 不透明，直接覆盖 d[0] = s[0]; d[1] = s[1]; d[2] = s[2]; continue; } // 非预乘混合：out = src*a/255 + dst*(255-a)/255 d[0] = (unsigned char)((s[0] * a + d[0] * (255 - a)) / 255); d[1] = (unsigned char)((s[1] * a + d[1] * (255 - a)) / 255); d[2] = (unsigned char)((s[2] * a + d[2] * (255 - a)) / 255); } } }

参数上，dstW/dstH是目标 DIB 的宽高，x/y是粘贴左上角坐标，允许为负（这时会被continue裁掉，所以图标贴边不会崩）。a == 0和a == 255两个短路分支不只是优化，也避免全透明像素把目标色算成非整数除法误差。drow里那一行dstH - 1 - dy是核心：Windows 的 DIB 默认 bottom-up，行号要翻转，忘了这一步图像会上下颠倒，这是新手最常见的翻车。

目标 DIB 的建立，常见做法是CreateDIBSection配BITMAPINFO，biBitCount = 32、biCompression = BI_RGB，然后SelectObject到内存 DC，画完BitBlt到GetDC(hWnd)。这样混合操作全在内存里跑，屏幕刷新只发生一次，不会闪烁。注意BI_RGB的 32 位 DIB 最高字节不保证被擦，CreateDIBSection出来先memset成底色，不然可能出现花边。

5. 避坑：五个在 VC6 上真踩过的坑

5.1 现象：编译报png_set_gray_1_2_4_to_8未定义

原因：libpng 版本不同，1.4 之后这个函数改名为png_set_expand_gray_1_2_4_to_8，1.2.x 才是老名字。解决：在pngconf.h或你自己的兼容头里用#if判版本号，或者干脆只用png_set_expand，它在新老版本里都覆盖灰度展开。别硬改函数名，改完换版本又炸。

5.2 现象：图片贴上去边缘发白、发亮，尤其半透明处

原因：把非预乘的 PNG 数据直接喂给了AlphaBlend。解决：要么调PngToPremultiplied只乘一次，要么改走 4.2 的逐像素混合。排查方法很直接——把 alpha 全改成 255 重新贴一张，如果边缘不白了，那就是预乘问题而不是颜色通道顺序问题。

5.3 现象：贴图上下颠倒

原因：DIB 是 bottom-up 存储，代码里没做行翻转，或者翻转了两次。解决：统一在「写目标 DIB」这一层翻转，源数据（libpng 解出的）始终按 top-down 解释。约定好之后，所有贴图函数都照这个约定写，避免一处翻一处不翻。

5.4 现象：程序在png_error处直接退出，栈里看不出调用来源

原因：没有setjmp(png_jmpbuf(png))，libpng 用 longjmp 当错误出口，没设落点就走默认 abort。解决：创建read_struct后立刻setjmp，并在分支里销毁 struct、释放rows。注意 longjmp 会跳过中间栈帧的析构，C++ 对象别放在 setjmp 和 longjmp 之间。

5.5 现象：链接期LNK2005一堆重定义

原因：libpng 和主工程的 CRT 配置不一致，或者同时链了静态 libpng 和以源码形式加入的 libpng。解决：确认Runtime Library全工程一致；libpng 只保留一种引入方式（源码或.lib，二选一）；VC6 的Ignore Libraries里明确忽略重复的那一个。

6. 进阶：把解码封成可复用资源位图

6.1 跟工程资源体系对接

老工程里图片多数打在.rc里，用FindResource/LoadResource拿到的是HGLOBAL，转成内存块后直接喂给decode_png即可，不需要落盘。我一般写一个薄封装：

// 从资源解 PNG，HINSTANCE 传 AfxGetInstanceHandle() 或 GetModuleHandle(NULL) int PngLoadFromResource(HINSTANCE hInst, LPCTSTR resName, LPCTSTR resType, PngImage* out) { HRSRC hr = FindResource(hInst, resName, resType); HGLOBAL hg; unsigned char* p; int ret; if (!hr) return -1; hg = LoadResource(hInst, hr); if (!hg) return -1; p = (unsigned char*)LockResource(hg); if (!p) return -1; memset(out, 0, sizeof(PngImage)); ret = decode_png(p, SizeofResource(hInst, hr), out); // LockResource 拿到的内存不需要 free，由系统管理 return ret; }

注意LockResource得到的是模块资源内存，不能 free，这是很多人习惯性配对UnlockResource反而越界的地方。资源类型用自定义字符串（比如"PNG"）比用RT_RCDATA更清晰，.rc里写IDI_LOGO PNG "logo.png"就行。

6.2 验证透明是否正确

别靠肉眼看。做一个「棋盘格底」验证：准备 8×8 的灰白方格目标 DIB，把 PNG 混上去，存成 BMP 用画图打开。如果半透明区域能透出下面的格子且没有白边，说明预乘和混合都没问题；如果边缘一圈发灰，多半是源数据做过预乘又被当 straight 处理。另一个硬指标是逐像素断言：挑 alpha=128 的像素，混合后通道值应落在(src+dst)/2 ± 2之内，超出就是公式用错了。

6.3 一句教训

从那以后我每次接这类老工程的图像活，都强制先只验三步：签名校验返回是否正确、解码后rowbytes是否等于width*4、AlphaBlend前有没有且仅有一次预乘。这三步任意一步错，后面调半天合成都是白费。VC6 的调试器不像现在顺手，能靠断点和这几条断言把问题圈在解码层，比在混合层猜颜色要省太多时间。希望帮到你。

本文还有配套的精品资源，点击获取