Windows C 多线程编程的库支持
Windows C 多线程编程的库支持
线程实质上是程序中的执行路径。也是 Win32 安排的最小执行单元。线程包括堆栈、CPU 寄存器的状态和系统计划程序执行列表中的项。每个线程共享所有进程的资源。
进程包括一个或多个线程和代码、数据和内存中的其他程序资源。典型的程序资源是打开的文件、信号灯和动态分配的内存。当系统计划程序给予其中的一个线程执行控制时，即执行程序。计划程序确定应当运行哪些线程以及它们应当何时运行。较低优先级的线程可能必须等到较高优先级的线程完成任务后才能运行。在多处理器计算机上，计划程序可以将单个线程移到不同的处理器以“平衡”CPU 负荷。
进程中的每个线程都独立运行。除非使这些线程相互可见，否则线程分别执行，对进程中的其他线程一无所知。线程共享公共资源，但是，必须使用信号灯或其他进程间的通信方法协调它们的工作。
1、多线程编程的库支持
如果在执行 printf 函数时有线程被 Win32 计划程序挂起，则程序的其他线程中的某一个可能会开始执行。如果第二个线程也调用 printf，数据可能会损坏。为避免这种情况，必须限制对函数使用的静态数据的访问，一次只允许一个线程访问数据。
因为每个线程具有不同的堆栈，所以不需要序列化对基于堆栈的（自动）变量的访问。因此，只使用自动（堆栈）变量的函数是可重入的。标准 C 运行时库（如 LIBC）的可重入函数的数量有限。对于需要使用通常不可重入的 C 运行时库函数的多线程程序，应该使用多线程库 LIBCMT.LIB 来生成。
多线程 C 库：LIBCMT.LIB 和 MSVCRT.LIB
支持库 LIBCMT.LIB 是可重入库，用于创建多线程程序。调用共享的 MSVCRT70.DLL 中代码的 MSVCRT.LIB 库也是可重入库。当应用程序调用这些库中的函数时，可以应用下列规则：
所有库调用必须使用 C (__cdecl) 调用约定；使用其他调用约定（如 __fastcall 或 __stdcall）编译的程序必须使用它们调用的运行时库函数的标准包含文件。
传递到库函数的变量必须由值传递或转换为指针。
使用 LIBCMT.LIB 生成的程序不与它们所调用的任何动态链接库共享 C 运行时库代码或数据。
LIBCMT.LIB 和 MSVCRT.LIB 以外的其他选择
如果不使用 LIBCMT.LIB 来生成多线程程序，必须执行下列操作：
使用标准 C 库并且只允许可重入函数集进行库调用。
使用 Win32 API 线程管理函数，如 CreateThread。
通过使用 Win32 服务（如信号灯和 EnterCriticalSection 及 LeaveCriticalSection 函数�
相关文档：
--摘自 《Oracle Pro*C 程序开发》 --Create/Modify Email：xingchengli@gmail.com
SQLDA 的结构如下：
struct SQLDA
{
long N; /* Descriptor size in number of entries */
char **V; Ptr to Arr of addresses of main variables */
long *L; /* Ptr to Arr of lengths of buffe ......
转贴自：http://blog.sina.com.cn/s/blog_629562fe0100gs2l.html
稍作修改
gSOAP是一个夸平台的，用于开发Web Service服务端和客户端的工具，在Windows、Linux、MAC OS和UNIX下使用C和C++语言编码，集成了SSL功能。
下载地址：http://sourceforge.net/projects/gsoap2
官方网站：http://genivia.com/Products/g ......
前面的文章《搭建基于 NetBeans 的 OpenGL 开发环境》提到了 NetBeans 和 MinGW 的配置，当时记得好像以前写过步骤，就随手略过了。今天收到网友的提醒才发现是我记错了，在这里补上，同时谢谢你！
步骤如下：
下载自动 MinGW 安装程序，这对初学者来说是比较方便的方式，缺点就是下载速度慢得不如蜗牛。
运� ......
到最后还是自己解决了，导致该问题的原因是在linux启动到最后出现：
/bin/sh: can't access tty; job control turned off
而出现该错误的原因和解决方法google后有千百种，尝试了很多种都没有帮我解决问题。
下面是我自己的解决方法：
1. vi /etc/inittab 第一行添加
console::sysinit:/etc/init.d ......
参考网址：http://www.uclibc.org/
GNU的Glibc是一个非常宠大而完整的库，至少对于嵌入式系统来说，其体积显得过于大了一些。uClibc的提出较好的解决了这样一个问题。uClibc尽可能的兼容Glibc，大多数应用程序可以在很小或完全不修改的情况下就可能使用uClibc替代glibc。通过uClibc来代替Glibc，可以在不改变应用程序功� ......
