如果一个程序员从来没有在Linux，Unix下开发过程序，一直在Windows下面开发程序， 同样是工作10年， 大部分情况下与在Linux，unix下面开发10年的程序员水平会差别很大。
这篇文章并不是想贬低Windows下面开发的人，做Windows开发的人看了可能会感觉不舒服，我并不是这个意思，我只是说说我自己的感受。
我最早开始学习编程也是在Windows下面的， 学的是VB，后来转到VC++，当时用的是VC6.0， 做Windows下面的开发5年后转入Linux下面做开发的，开始在Linux下面做开发的时候， 也做过很多Windows下面的项目，在Linux下面做开发确实比我在Windows下面做开发多学到了很多的东西，从开源代码里面吸取了丰富的营养，我不是说我是个高手， 只是说在Linux下面学习，你会进步的更快。
不过我需要强调一下，我这里说的是 “大部分情况下”，意思就是说“在同样勤奋，同样努力程度，同样基础知识，同样工作年限，同样是做应用程序的开发” 的情况下，如果说的不对，希望大家在下面发表看法。
可能大家会奇怪， 为何会出现这种情况呢 ？听我慢慢道来！
开源与闭源
Windows下面的程序基本都是封闭源代码的，特别是10年前，在Windows下可以说找不到可用的开源的软件，现在的情况比以前好多了， 很多Linux下面开源的程序被移植到Windows下面来，但是Linux下面开源的程序增加的更多了。
以前在Windows下面写应用程序， 需要用到MFC，WINSOCK，ODBC，FILE IO等， 可以找资料的地方主要是微软官方的文档MSDN，也只有MSDN才是最全的地方，下来是第三方网站 vckbase， CSDN， codeproject 这几个网站。
但是从这些网站找到的代码，都是针对一个特定的小功能，为了演示如何实现这个小功能而写的代码，写代码的水平参差不齐，风格各异，都是一些demo性质的小东西，简单研究看看代码，就可以集成到自己的应用程序里面。
如何构建一个完整的应用程序， 架构良好的应用程序， 大学里面不会教你， 一切都得靠自己摸索。在公司里面做项目获得提升，直到项目商用，后期维护修改代码时， 回头看自己写的代码， 才深刻体会到，自己当时写的代码架构是多么的不合理，维护修改是如此的困难。
如果在互联网上找不到自己需要的资料，就只能靠自己想一些实现的方法，虽然功能完成了， 可能完成的时候还很有成就感，但是等那天你突然发现有人实现这个功能，并且用了一个巧妙的方法， 这是你才突然恍悟， 我当时为何就想不到这么实现呢？
在Windows下面开发， 不太容易找到可以参考的类似你要完成功能的开源项目。一切都得靠自己。但是在Linux下面就不一样了， 当你要开发一个新项目时， 可以想想有没有什么开源项目也完成了类似的功能， 可以下载到源代码来做一个参考， 对其中的算法， 架构设计等做一个详细的了解，然后自己开发的时候就会比较得心应手了，可以避免别人犯过的错误，少走很多弯路。
要学习的知识量不一样
学习window下的开发， 你需要学习很多的Windows API。截止到2009年9月，Windows总API数量为2258个， 并且Windows API 的参数多， 参数类型复杂，要记住这么多东西不是一件容易的事情，至少也和学习一门外语一样，大学英语四级要求掌握的总词汇量达到4500个单词。可想而知， 学会这么多的API用法，有多难了吧。
那么学习Linux下， 要掌握多少API呢 ？Linux下的内核API， 全部算下来也才335，但是这些内核的API只有编写驱动的时候才能用到， 开发应用程序基本用不到内核的API，开发应用程序的API基本都是C的API，而 Linux所有的C的API个数是279个， 也就是说你只需要掌握不到300个的API， 就可以顺利的在Linux下面开发应用程序了，相比学习Windows下面的那一堆API来说， 你是不是可以省下很多时间来学习其他知识呢？
下面我就举个简单的例子：
CreateFile ReadFile OpenFile WriteFile DeleteFile ReadFileEx WriteFileEx CloseHandle
上面这些API是Windows下面对文件操作的API， 总共是8个，看看CreateFile的参数吧，
HANDLE WINAPI CreateFile( __in LPCTSTR lpFileName, __in DWORD dwDesiredAccess, __in DWORD dwShareMode, __in LPSECURITY_ATTRIBUTES lpSecurityAttributes, __in DWORD dwCreationDisposition, __in DWORD dwFlagsAndAttributes, __in HANDLE hTemplateFile );
这些参数的意义和类型， 请问你需要花多少时间来掌握呢 ？
我们在看看Linux下面对文件操作的C的API有几个，
fopen fwrite fread fclose
共四个，我们在看看参数吧
FILE *fopen( const char *filename, const char *mode );
两个参数， 请问你需要花多少时间掌握呢。可能有的人会提出意见，说上面C的API也能在Windows下面运行啊？
没错， 是能在Windows下面运行，但是你就掌握这跨平台的C的API够吗？难道所有在Windows下面开发的人都喜欢用C的API， 不会用Windows本身的API吗？你不需要学习Windows下面的API吗？你的同事使用了CreateFile这个函数， 你不需要搞懂他吗？你不需要看同事的代码吗？你不需要去维护别人写过的代码吗？
如果你还是这么想，那我还可以再举其他例子！就拿创建线程的例子吧，下面是2个在Windows下面创建线程的例子， 第一个是创建安全工作线程， 第二个是创建界面线程，还有一个函数我没有放下面， 是创建不安全的工作线程的，具体的原理大家可以参考《win32多线程程序设计》，作者：（美）Jim Beveridge & Robert Wiener 著，侯捷 译 这本书。
//线程安全的工作线程函数
uintptr_t _beginthreadex(
void *security, unsigned stack_size, unsigned ( *start_address )( void * ), void *arglist, unsigned initflag, unsigned *thrdaddr );
//界面线程函数
HANDLE WINAPI CreateThread( __in LPSECURITY_ATTRIBUTES lpThreadAttributes, __in SIZE_T dwStackSize, __in LPTHREAD_START_ROUTINE lpStartAddress, __in LPVOID lpParameter, __in DWORD dwCreationFlags, __out LPDWORD lpThreadId );
做Windows下面的开发， 上面两个创建线程的函数我们都必须掌握。当然了， 你也可以只需要知道 _beginthreadex 来在Windows下面通吃，但是当看到别人的代码使用CreateThread的时候， 你可不要不习惯，MFC里面很多人都用CreateThread。掌握这么多的API累吧 ？就和你上学的时候背单词一样累。
下面我在列一下Linux下面创建线程的函数
int pthread_create( pthread_t *restrict thread, const pthread_attr_t *restrict attr, void *(*start_routine)(void*), void *restrict arg);
看到了吧， 你只需要知道这个就可以了。
C的API 绝大部分都可以再Windows下面运行，在Windows下面学习开发， 你不但要懂得C的API， 你还需要多花时间来学习Windows系统本身的API， 你可能要说， 这么说应该是Windows下面学得多啊， 我要说的是你掌握的API是很多， 但是对于一个软件来说， 最最重要的是系统架构，数据结构，架构设计的好， 对后期的代码维护，功能修改都很关键， 这也就是新手写的代码， 到最后连他自己本人都很难维护的原因， 更别说让别人来维护了。
API相当于基本功， 系统架构， 数据结构是内功，基本功练的越快，我们就越有更多的时间来练习内功。练习内功，我们要多向高手学习。
在学习Windows 下面开发应用的道路上， 我们需要掌握更多的API， 学习后， 让我们的路越走越窄， 没有特别丰富的开源代码可以参考， 水平提高的速度很慢。
可喜的是， 现在很多开源的项目被很多人移植到了Linux下面， 也有很多的开源项目是跨平台的， 常用的是 wxWidget界面库， 用法类似MFC， 还有qt这个界面库， 也很强大，还有开源的3D引擎OGRE， 架构非常好，很值得学习其架构模式。
但是Linux下面的开源库要远远比Windows下面的开源库丰富得多， 我们可以方便的从高手的代码里面学习数据结构，学习设计模式，学习编程技巧，这也就是Linux下面的程序员， 可能会比Windows下面的程序员水平更高的原因， 毕竟见多识广嘛， 熟读唐诗三百首，不会作诗也会吟啊！
标签：__,下面,Windows,程序员,API,开发,Linux From： https://www.cnblogs.com/dbasql/p/18669481