在Windows的集成开发环境中（Qt、VC、VS中均存在该问题）编写有关文件读取的C/C++程序，出现读取到0X1A的时候意外终止的情况，经调试检查发现0X1A经过读取之后被处理成0XFF（即EOF（-1）），但是Linux中（Redhat6.4以及Ubuntu14.04中测试）不存在这种解析错误的问题。关于出现这种问题的原因可参考：https://blog.csdn.net/zhoubl668

在使用Linux系统函数mmap()，将FrameBuffer映射到内存上来实现一个简单的贪吃蛇游戏时，在自己的Redhat 6.4上测试时，运行程序结果却提示：“No such device”。可是在/dev/下可以查看到fb0与fb都是存在的，并且操作权限是足够的。刚开始没有想到是驱动的问题，在网上站到了解决方案：问题是FrameBuffer驱动程序没有激活。问题截图如下：解决方案：

一、TCP/UDP通信编程在Qt中的实现方法：与Linux的TCP/UDP通信接口（Socket套接字）类似，只不过是对Linux的接口进行了一部分合并与包装，其具体图解分析如下：1、详解Qt TCP通信（QTcpSocket、QTcpServer）：针对上图进行一些简单的分析：QTcpServer用来创建服务器对象，服务器对象创建以后，调用成员函数listen()进行连接监听，其中li

一、系统调用（System Call）：在Linux中，4G内存可分为两部分——内核空间1G（3~4G）与用户空间3G（0~3G）,我们通常写的C代码都是在对用户空间即0~3G的内存进行操作。而且，用户空间的代码不能直接访问内核空间，因此内核空间提供了一系列的函数，实现用户空间进入内核空间的接口，这一系列的函数称为系统调用（System Call）。比如我们经常使用的open、close、read

所谓半双工通信，即通信双方都可以实现接发数据，但是有一个限制：只能一方发一方收，之后交换收发对象。也就是所谓的阻塞式的通讯方式。一、基本框架：1、首先搞清我们进行编程所处的的位置：TCP编程，具有可靠传输的特性，而实现可靠传输的功能并非我们将要做的事（这些事），我们要做的就是在内核实现的基础上调用系统的API接口直接使用。所以我们所处的位置就是位于应用层面与系统层面之间的。我觉得弄清这点是实现整

一、无名管道、有名管道与进程间通信：1、IPC–进程间通信与管道基本概念：（1）、IPC(进程间通信)：所谓IPC就是两个或者多个进程之间的数据交互(在不能直接进行信息交互的两个进程间增加一个“交互媒介”以达到信息交互的目的)。为什么不能直接交互？因为我们知道在应用程序执行时(即进程运行时)，其占有的用户空间只有0~3G，而用户空间不共享，不共享就无法传递信息；内核空间共享，所以要实现两个进程之间

在Linux系统中，标准输入、标准输出、标准错误三个设备文件是比较常用的标准设备文件，其中0（STDIN）、1（STDOUT）、2（STDERR）分别是指向标准输入、标准输出、标准错误的三个文件缓存的句柄。通常STDIN即键盘输入缓冲区，STDOUT和STDERR的设备则通常为显示屏。由于特殊需要，可能有时候我们需要的输入文件或（和）输出文件并非是键盘或（和）屏幕，因此需要输入输出重定位，Linu

我们都知道，C语言在UNIX/Linux系统下有一套系统调用（系统函数），比如文件操作open()、close()、write()、read()等，而标准C语言的库函数中也有一套对文件的操作函数fopen()、fclose()、fwrite()、fread()等.。那么同样是对文件的操作函数，标C与UC有什么区别呢？是标C效率高还是UC效率高呢？今天就让我们来一探究竟。程序作用：将0~999999

目录1、范围1.1、版权1.2、免责声明2、参考文献3、增强型数字诊断接口 - 简介4、内存组织4.1 、两线接口字段4.2、页4.3、 数据字段5、标识符与编码（地址A0H）5.1、物理设备标识符值[Byte0]5.2、物理设备扩展标识符值[Byte 1]5.3、连接器值[Byte 2]5.4、收发器合规代码[Byte 3-10、36...

前言：在C语言中，变量类型、循环控制、基础语法等与其他高级语言基本无异；而C语言（C++）特有的两把双刃剑指针和宏定义/宏函数使得C语言在底层开发中披荆斩棘、无所不能。这两个概念涉及范围比较广，其分支点也比较多，可谓星罗棋布，但这每颗星都足以照亮C语言因其开发周期、可维护性、可移植性等问题而显的黯淡的天空，使得这门语言灵活多变、操作犀利，令人难以揣摩却也深深着迷。首先，C的第一把双刃剑：指针，..