标签：
之前我一直对windows api命名和用法感到很困惑，但是经过一些实践后再看回《windows程序设计》，对windows api有了自己的一些看法
1.首先windows是闭源的，所以可能由于安全性，或者人为设计漏洞等可能原因，而导致windows有些api调用看起来方式很怪异。
例如windows会用句柄来表示资源，很多时候会存在获取句柄，然后传句柄给api,然后再释放句柄，个人感觉这个方法有点麻烦。。。
好吧，其实c函数的fopen这类的操作也是要自己调用fclose，这是无可避免的吗？
还有就是很多windows回调函数，入口函数，api函数等会带WINAPI 和 CALLBACK等关键字，这些函数主要都是用来和Windows内核通讯用的，他们都被定义为stdcall，这是一种函数调用约定，参考这里，
我觉得就是为了与windows进行通讯所以规定使用的一套函数调用的规则，可以这样认为凡是会与windows进行交互的函数都会加WINAPI之类的修饰关键字？
2.windows存在兼容性，所以可能在api在更新过程中有些东西的设计思路可能会改变了，
或者一些新的api设计理念会与之前的不同（这个可能我要进一步了解才能有例子，我只是认为不可能一味兼容，应该是会有进步的）。
然而虽然有些东西在进步了，但是为了兼容旧版本的程序可能会有一些历史遗漏的误导点。
例如消息处理中的wParam和lParam，引用一段《windows程序设计》的解释：
WndProc 的第三和第四个参数分别被定义为WPARAM 和LPARAM，
这些名字的来源有点历史背景：当Windows 还是16位元系统时，WndProc 的第三个参数被定义为一个WORD，
这是一个16 位元的 无正负号短 （unsigned short）整数，而第四个参数被定义为一个LONG，
这是一个32 位元有正负号长整数，从而导致了文字「PARAM」前面加上了前置字首「W」和「L」。
当然，在32 位元的Windows 中，WPARAM 被定义为一个UINT，而LPARAM被定义为一个LONG（这就是C 中的long 整数型态），
因此视窗讯息处理程式的这两个参数都是32位元的值。这也许有点奇怪，
因为WORD资料型态在Windows98中仍然被定义为一种16 位元的 无正负号 整数，因此「PARAM」前的「W」就有点误用了。
还有就是带p,lp等的参数，再引用一段解释：
在这里提示一下资料型态和匈牙利表示法：其中的lpfn 字首代表「指向函数的长指针」。
（在Win32 API 中，长指标和短指标（或者近程指标）没有区别。这只是16 位元Windows 的遗物。）
3.为了简单而用别名缩写，为了明确而进行别名重定义，
例如它会用UINT表示unsigned int，我觉得这可能是和以前没有自动补全功能有关，程序员宁愿少打几行字所以定义了一些缩写。
4.关于匈牙利命名法，Windows api参数名字用到了匈牙利命名法。同时有些api函数名称，也可能会带参数类型。
例如SetWindowLong和SetWindowLongPtr,因为我觉得函数名带参数类型实在有点不习惯，初接触时还不知道加个Long表示的是什么，所以觉得这些名字很别扭。
暂时个人接触到的一些觉得有点神奇的点主要是上面这些，如果还有进一步的体会，可能会继续写下去。
windows总觉得奇奇怪怪。。。。同时这只是我一些愚见，以后可能还会修正，不能作为参考依据，所以要更深入更准确的解释，请找巨巨去吧。。。。
标签：
原文地址：http://www.cnblogs.com/riversHahaha/p/4595468.html
