代码跨平台，怎么就成了忽悠?

//=====================================================================
//TITLE:
//    代码跨平台，怎么就成了忽悠?
//AUTHOR:
//    norains
//DATE:
//    Thursday 19-August-2010
//Environment:
//    NULL
//=====================================================================

     当自己还在忙于代码间的平台移植时，忽然看到CSDN论坛的一篇推荐文章《纯忽悠程序员的开发要求（1）：编写代码时要考虑跨平台》（http://topic.csdn.net/u/20100809/16/99b233cd-9fd1-49a6-a531-7de40ec9de3e.html?25630），一下子就愣住了，咋要求跨平台就成了忽悠了？

     仔细看了一下文章，终于发现问题的根源，作者是认为在Windows，linux，unix这些系统间考虑跨平台性不必要。可问题是，跨平台难道就仅仅限制于这些大相径庭的系统之间么？代码跨平台的范围可就广了，即使是同样打着Windows旗号的各个系统，也必须考虑这跨平台的问题！

     不信？不可能出现这种情况？那我们先来看看实际情况。我公司是做车载的，方案很多，有采用intel嵌入式+Windows XP的，有ARM9 + Windows CE 5.0的，还有ARM11 + Windows CE 6.0。车载市场和个人PC机不太相同，举个最简单的一条，开机就必须显示一个UI。虽然硬件平台不同，操作系统迥异，但对于客户而言，展现于他们眼前的UI基本上是类似的。

 那么问题就来了，是不是该为每一个操作系统定义一套UI呢？估计大家都会对这个建议摇头。因为无论是Windows XP，还是Windows CE 5.0，或是Windows CE 6.0，他们的基本程序流程都是一样的，根本就没必要分开定义。那是不是意味着同一套代码可以放之四海而皆准？答案其实是否定的。

     举个简单的例子，GetProcAddress函数是Windows XP和Windows CE都具有的，调用方式也一样。但别以为一切都顺利，在Windows XP中，GetProcAddress的lpProcName形参是LPCSTR，而Windows CE却是LPCTSTR！不要小看这ANSIC和UNICODE的差异，这可能会导致代码字符串储存的方式不同！

     当然还不仅仅如此，比如Windows CE中有SetEventData函数，但如果是在Windows XP里，还是用C++的话，那么这函数是没有的。如果想要同一套代码共存于两个系统，那么你就要决定，在Windows XP下程序进程间的数据交换，是采用自己动手写SetEventData的方式，还是选择另外的方式？这问题难道不值得思考么？

     这还是小儿科的话题。如果涉及到进程句柄，文中所提到的三个操作系统更是表现大为不同，如表：

    而同一系统的每个函数调用的返回值之间的不同（注意，这里说的不是同一个函数，在不同系统中的数值不同。因为这个内存地址，即使在同一系统中，按运行的时间前后，也可能不同的。这里指的函数间应该相同的返回值，比如hInstance应该和GetModuleHandle(NULL)调用相等的这种情形），又间接影响到需要用到句柄实例的函数，比如说LoadBitmap，LoadIcon等等。

     当然，这些差异可能在具体的工程中只出现一两处，但你是决定为这两三行代码而重写整个系统架构，还是对这两三行代码做跨平台的特化？可能选择前者的不多，更多的是选择后者。而后者，不就是代码的跨平台么？这样的情形，难道考虑代码的跨平台也是忽悠？