一般来说,将16位Windows程序转换为Win32需要做什么?我敢肯定,我不是唯一一个继承代码库并惊讶地发现潜伏在角落里的 16 位代码的人。
有问题的代码是C。
wParam
和的含义lParam
在很多地方都发生了变化。我强烈建议您保持偏执,并尽可能多地使用消息破解程序。它们将为您省去无穷无尽的头痛。如果我只能给你一条建议,那就是它。STRICT
. 它将帮助您int
在应该使用的地方捕获 Win16 代码库HWND
,HANDLE
或其他东西。转换这些将极大地帮助此列表中的#9。hPrevInstance
没用。确保它没有被使用。TCHAR
s,而是意味着您最好将OpenFile
,_lopen
和_lcreat
with替换为CreateFile
, 以命名显而易见的LibMain
现在是DllMain
,整个库格式和导出约定都不同了GlobalAlloc
, LocalAlloc
, GlobalFree
, 和LocalFree
应该替换为更现代的等价物。LocalLock
完成后,清理给LocalUnlock
和朋友的电话;他们现在没用了。并不是说我可以想象您的应用程序会这样做,但请确保您WM_COMPACTING
在那里时不要依赖。SendMessage
或PostMessage
发送指向进程外窗口的指针。您需要切换到更现代的 IPC 机制,例如管道或内存映射文件。SendMessage
并等待消息被处理是非常酷的。现在这可能是个坏主意。考虑是否PostMessage
不是更好的选择。int
为DWORD
等等。编辑:正如@ChrisN 指出的那样,将 Win16 应用程序移植到 Win32 的官方指南已存档,并且都充实并补充了我的上述观点。
除了让您的构建环境正确之外,您还需要解决以下几个细节:
包含整数的结构将需要从 16 位更改为短或加宽到 32 位。如果您更改结构的大小并将其加载/保存到磁盘,您将需要编写数据文件升级代码。
每个窗口的数据通常使用 GWL_USERDATA 与窗口句柄一起存储。如果您将一些数据扩大到 32 位,您的偏移量将会改变。
POINT & SIZE 结构在 Win32 中是 64 位的。在 Win16 中,它们是 32 位的,可以作为 DWORD 返回(调用者会将返回值拆分为两个 16 位值)。这在 Win32 中不再有效(即 Win32 不返回 64 位结果)并且函数被更改为接受一个指针来存储返回值。您将需要编辑所有这些。GetTextExtent 等 API 会受此影响。同样的问题也适用于某些 Windows 消息。
在 Win32 中不鼓励使用 INI 文件以支持注册表。虽然 INI 文件功能仍然有效,但您需要小心处理 Vista 问题。16 位程序通常将其 INI 文件存储在 Windows 系统目录中。
这只是我能回忆起的几个问题。自从我进行任何 Win32 移植以来已经有十多年了。一旦你进入它,它非常快。当涉及到您将习惯的移植时,每个代码库都会有自己的“感觉”。您甚至可能会在此过程中发现一些错误。
MSDN 上的文章将16 位代码移植到 32 位 Windows中有一个权威指南。
最初的win32 sdk 有一个工具可以扫描源代码并标记需要更改的行,但我不记得该工具的名称。
当我过去不得不这样做时,我使用了蛮力技术 - 即: 1 - 更新 makefile 或构建环境以使用 32 位编译器和链接器。或者,只需在您的 IDE 中创建一个新项目(我使用 Visual Studio),然后手动添加文件。
2 - 构建
3 - 修复错误
4 - 重复 2&3 直到完成
该过程的痛苦取决于您要迁移的应用程序。我在一小时内转换了 10,000 个线路程序,在不到一周的时间内转换了 75,000 个线路程序。我也有一些我刚刚放弃并从头开始重写(大部分)的小型实用程序。
我同意 Alan 的观点,即反复试验可能是最好的方法。
这里有一些很好的提示。
同意编译器可能会捕获大部分错误。此外,如果您使用“近”和“远”指针,您可以删除这些名称——指针只是 Win32 中的指针。