很长时间以来一直在DJGPP下工作，写过的程序没数过，怎么也有几万行了吧，其实在国内真正在DJGPP下工作的人似乎并不多，因为大多数的交流都和国外的同行们做，国内不太容易找到人能做深入的交流。DJGPP+ALLEGRO确实是很强的组合，做32位的代码很不错，因为免不了要做些界面，所以ALLEGRO通常必不可少，但ALLEGRO编译起来确实太慢了，我的有些程序没编译一次甚至可以上趟厕所，当然ALLEGRO在编译时是可以裁减的，但看看资料，好像并不是很简单，就做罢了，其实DJGPP生成的可执行文件也偏大，编译速度要是和TURBO C比也没法比，但人家生成的是32位编码，只好忍了。
DJGPP也有一些不够方便的地方，比如它的inline汇编用的是AT&T的格式，不太习惯，因为我以前做汇编都是在MASM上做，所以现在很少用汇编，除非万不得已，使用32位编码后，使用硬件中断相当的麻烦，尽管DJGPP的拥护者们提出了几种方案，但使用起来都很麻烦，要有十分清晰的头脑才能实现，所以我对硬件尽量不采用中断方式；还有32位编码时要得到内存的物理地址往往有困难，这导致了一些DMA操作受限制，对此我采用了两种方案，一种对于较小的内存块，从1M以内的地址分配，物理地址和线性地址应该是一致的，还有一种就是对于大内存块使用XMS分配内存，可以得到准确的物理地址，而DJGPP提供的函数里，没有能够给出物理地址的。这两种方法我都用过，没有问题。
RHIDE是个很好的开发环境，其实和TURBO C很像，所以上手很容易，但如果使用像ALLEGRO这样的库，设置上会有些不同，初学时可能会很不习惯，大都GNU下的东西都是这样，文档不全，设置复杂，不过人家免费。再有RHIDE的跟踪能力不是很好，尤其是有ALLEGRO或其他库时，往往单步运行会让你找不到北，一定要多设断点才可以跟踪到。
如果要使用网络，WATTCP支持的非常好，另外我还用过JPGALLEG，与ALLEGRO配合处理JPEG图片也非常好。
DJGPP也有一些不够方便的地方，比如它的inline汇编用的是AT&T的格式，不太习惯，因为我以前做汇编都是在MASM上做，所以现在很少用汇编，除非万不得已，使用32位编码后，使用硬件中断相当的麻烦，尽管DJGPP的拥护者们提出了几种方案，但使用起来都很麻烦，要有十分清晰的头脑才能实现，所以我对硬件尽量不采用中断方式；还有32位编码时要得到内存的物理地址往往有困难，这导致了一些DMA操作受限制，对此我采用了两种方案，一种对于较小的内存块，从1M以内的地址分配，物理地址和线性地址应该是一致的，还有一种就是对于大内存块使用XMS分配内存，可以得到准确的物理地址，而DJGPP提供的函数里，没有能够给出物理地址的。这两种方法我都用过，没有问题。
RHIDE是个很好的开发环境，其实和TURBO C很像，所以上手很容易，但如果使用像ALLEGRO这样的库，设置上会有些不同，初学时可能会很不习惯，大都GNU下的东西都是这样，文档不全，设置复杂，不过人家免费。再有RHIDE的跟踪能力不是很好，尤其是有ALLEGRO或其他库时，往往单步运行会让你找不到北，一定要多设断点才可以跟踪到。
如果要使用网络，WATTCP支持的非常好，另外我还用过JPGALLEG，与ALLEGRO配合处理JPEG图片也非常好。
www.ecgui.com