CruiseControl是一个自由，开源软件，使用BSD类型的license。最早的时候，该软件是由ThoughtWorks公司的员工开发出来用于该公司自身内部项目的，随后则变成了一个独立的应用软件。

CruiseControl.NET是CruiseControl的.NET版本。还有一个Ruby版本的CruiseControl，被称为CruiseControl.rb。

对于使用Windows平台，以及Visual Studio集成开发环境的团队来说，使用CruiseControl.NET的好处在于他整合了MSBuild，NAnt，VSS等微软平台下常用的软件开发中的工具，并且非常易于在.NET平台下对他的功能进行扩展。

我们可以利用MSBuild来编写构建脚本，利用CruiseControl.NET配置实现持续集成，每日构建，自动化测试，邮件通知等功能。

安装CruiseControl.NET需要先安装.NET Framework 2.0以及支持ASP.NET的Web server（比较典型的如开启了ASP.NET的IIS服务器）

CruiseControl.NET提供了两种查看和管理构建流程的方式：

1. 通过Web Dashboard，也就是通过网页查看

2. 通过CCTray客户端（该客户端是一个常驻程序，可以随时点开查看当前的构建状况，并且可以在构建成功或失败后弹出提示）

安装CruiseControl.NET

从ThoughtWorks的网站下载当前最新的Release版本：

http://confluence.public.thoughtworks.org/display/CCNET/Download

在服务器上安装该CCNet安装程序（服务器需要是Windows的，并且有.NET2.0运行环境与支持ASP.NET的WebServer）

配置CruiseControl.NET：

安装目录下有名为ccnet.config的xml格式的配置文件，用于配置当前的CCNet服务器。

对于一个比较简单的项目，我们的持续集成需求包括：

1. 从源代码管理服务器上取下最新的源码

2. 构建

3. 构建成功后，将文件发布到我们指定的目录

我们还可能会需要每日构建，每天夜里0:00开始一次所有项目的构建，并将结果发布到指定位置。

项目之间往往存在互相依赖，如果被依赖项发生了更改，应该有办法让所有依赖了该项目的项目都依次构建。

下面以一个简单的例子描述如何配置CruiseControl.net服务器。

打开ccnet.config文件，该文件是一个xml格式的文件，可以在配置文件中编写多个project，每个project都对应着一个<project> </project>块。

<cruisecontrol>

<project name=”MyProj1”>

</project>

<project name=”MyProj2”>

</project>

</cruisecontrol>

每个Project块的配置类似下面的例子：

<project name=”Project 1″ queue=”Q1″ queuePriority=”1″>

<workingDirectory>yourWorkingDirectory</workingDirectory>

<artifactDirectory>yourArtifactDirectory</artifactDirectory>

<category>Category 1</category>

<webURL>http://server1/ccnet/server/local/project/testProject/ViewLatestBuildReport.aspx</webURL>

<modificationDelaySeconds>2</modificationDelaySeconds>

<maxSourceControlRetries>5</maxSourceControlRetries>

<initialState>Stopped</initialState>

<startupMode>UseInitialState</startupMode>

<triggers>

<!–yourFirstTriggerType .. –>

<!–yourOtherTriggerType .. –>

</triggers>

<!– state type=”yourStateManagerType” .. –>

<!– sourcecontrol type=”yourSourceControlType” .. –>

<!– labeller type=”yourLabellerType” .. –>

<prebuild>

<!– yourFirstPrebuildTask .. –>

<!– yourOtherPrebuildTask .. –>

</prebuild>

<tasks>

<!– yourFirstTask .. –>

<!– yourOtherTask .. –>

</tasks>

<publishers>

<!– yourFirstPublisherTask .. –>

<!– yourOtherPublisherTask .. –>

</publishers>

<externalLinks>

<externalLink name=”My First Link” url=”http://somewhere/” />

<externalLink name=”My Other Link” url=”http://somewhere.else/” />

</externalLinks>

<parameters>

<textParameter name=”Build Name” default=”Unknown” />

</parameters>

<linkedSites>

<namedValue name=”ohloh” value=”5623″ />

</linkedSites>

</project>

具体的属性含义可以参考文档：

http://confluence.public.thoughtworks.org/display/CCNET/Project+Configuration+Block

对于Project块，有几个比较重要的内容值得详细说明：

1. Queue

<project name=”Project 1″ queue=”Q1″ queuePriority=”1″>

这里有一个queue属性，以及对应的queuePriority属性。说明的是该project被放置于哪个queue中，如果不加指明，那么每个project都会被放置到一个独立的queue中。

Queue的作用是什么？

想象一下存在两个项目A和B，并且B依赖A。如果正在构建B的时候，trigger又启动了一个Build开始构建A，但是由于B依赖A，因此在构建B的过程中，需要打开A的目标文件进行读取（例如B使用A的lib文件进行link）。如果A此时恰好要写入该目标文件，则会发生文件访问冲突。进而造成A的构建流程失败。

我们想到或许可以将B依赖的文件拷贝一份出来，从而避免出现使用文件和写入文件冲突的情况，但是很快我们就会意识到这也行不通——因为可能我们在拷贝文件的时候（这里需要打开并读取A的输出文件），遇到了A正要写入文件的状况。

总结一下，对于相互之间存在依赖的项目，我们不应该让他们不受控制的并发构建，而是必须要有一个先后顺序——这里就是Queue的用处所在。

CruiseControl工作的时候，是以queue为单位进行的，当trigger或者人工通过force build触发了一次构建，这次构建会被置放到queue中，并且根据queuePriority决定被插入的位置。

这样，可以保证一系列相互之间存在依赖关系的项目在一个队列中依次进行Build，避免因相互依赖项目同时构建而导致的文件读写冲突等问题。

2. Triggers

触发器是实现我们的各种构建需求的工具。比如，每天夜里0:00产生一次Nightly Build，比如每次Check in之后都进行一次Continuous Integration Build，比如基础项目构建成功了，应当引发所有的依赖该基础项的项目都产生一次构建。等等。

要实现上述的功能，我们可以使用CruiseControl.NET提供的诸多类型的trigger达到目的，或者选择其中若干进行组合使用。

最常用的trigger之一是Interval Trigger，我们可以设置Interval的间隔时间，每隔这么长的时间，触发器就会被触发一次。配合SCM工具对源代码的检查，我们可以利用Interval Trigger实现持续集成。（每隔1分钟触发一次，检查源码仓库是否有新checkin的代码，如果有则Build）

Project Trigger可以使得当前项目获知依赖项目构建成功的消息，当制定的Project构建成功之后，Trigger会被触发

Multiple Trigger用于将多个Trigger用逻辑关系组合起来使用，例如，当使用And逻辑进行组合时，Multiple Trigger中只要有一个Trigger认为不应当触发构建，就不会被触发构建。

3. Tasks

当Trigger触发之后，就会开始构建流程，从而将Tasks块的所有Task依次执行一遍。

我们需要使用Task来完成主要的构建流程。上篇文章中曾经简单介绍过MSBuild，到了这里，我们就利用MSBuild来实现自动构建了。

<msbuild>

<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>

<workingDirectory>C:\dev\ccnet</workingDirectory>

<projectFile>build.xml</projectFile>

<targets>Build;Test</targets>

<timeout>900</timeout>

<logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>

</msbuild>

最简单的利用MSBuild的方式如上例所示。

projectFile是预先编写好的MSBuild的脚本文件，targets里面填写的是要执行MSBuild脚本中的哪个Target。（关于Target，可以参考此前总结的MSBuild简介里的相关内容，以及MSBuild自身的文档）timeout时间是指此次build如果超过多长时间则认为是超时失败。

4. Publishers

Publisher用于在构建流程走完之后将最终的结果发布出去。Publisher中可以有一系列的Task，与Tasks块中的Task的用法类似，包括调用MSBuild Task，在MSBuild脚本中执行操作等。

我们可以利用Publisher模块，将最新版本的SDK发布到服务器，或是创建提供给用户的安装包等。

通常情况下，我们采用IDE本身进行项目的构建，有时，也会采用命令行方式调用IDE程序Build我们的项目。（对于VC++项目来说，就是通过命令行调用devenv进行构建）

然而，当我们希望在持续集成工具当中实现项目的自动构建时，尤其是当依赖情况或者部署情况较为复杂时，我们希望有一个简单、易维护的工具实现构建——MSBuild就是我们所需要的工具。

采用MSBuild进行构建，需要我们编写MSBuild脚本——一种规定格式的XML文件。

MSBuild基本组成部分包括：Target（目标），ItemGroup（项），PropertyGroup（属性），Task（任务）。

其中：Target目标是MSBuild执行的基本单元。

我们在命令行中调用MSBuild /t:TargetName指定需要执行的目标。

每个Target中可以包含若干Task。

Task是基本的功能单元：例如拷贝文件，删除文件，创建/删除目录，使用Exec调用外部程序，调用VCBuild构建.vcproj项目，调用Csc编译.cs文件，等等。此外，你还可以通过实现ITask接口，创建自定义的Task。

PropertyGroup作为属性，起着类似于变量一样的作用，可以定义一个属性，并在后续的位置使用该属性，例如：

<PropertyGroup>
   <ProjFile>C:\Test\test.vcproj</ProjFile>
   <Rebuild>true</Rebuild>
</PropertyGroup>

<Target Name=”Build”>
   <VCBuild     Projects=”$(ProjFile)”     Rebuild=”$(Rebuild)”    />
</Target>

ItemGroup往往作为输入，例如：

<ItemGroup>
   <IncFiles Include=”C:\Test\*.h” />
</ItemGroup>

<Target Name=”Build”>
   <Copy    SourceFiles=”@(IncFiles)”    DestinationFolder=”c:\output\include”
/>
</Target>

实例：

假设我们有一个项目A，依赖一个动态连接库B，我们需要先构建B，将B的头文件和lib文件拷贝到A的包含头文件路径和Lib路径下，再构建A，然后将A发布到指定的路径下。

B的项目结构如下：

C:\B\B.vcproj

A的项目结构如下：

C:\A

\DepInclude

\DepLib

\Src\A.vcproj

\Output

对应的MSBuild脚本如下：

<ItemGroup>
   <BIncFiles Include=”C:\B\*.h” />
   <BLibFiles Include=”C:\B\Release\*.lib” />
   <BDllFiles Include=”C:\B\Release\*.dll” />
</ItemGroup>

<TargetName=”Build_B”>
    <VCBuild
      Projects=”C:\B\B.vcproj”
      Configuration=”Release”
      Rebuild=”true”     />
<Copy   SourceFiles=”@(BIncFiles)”
  DestinationFolder=”C:\A\DepInclude”
/>
<Copy   SourceFiles=”@(BLibFiles)”
  DestinationFolder=”C:\A\DepLib”
/>
</Target>

<Target Name=“Build_A” DependOnTargets=“Build_B”>
    <VCBuild
      Projects=”C:\A\Src\A.vcproj“
      Configuration=“Release”
      Rebuild=”true”
    />
</Target>

Build_A的Target使用了一个DependOnTargets属性，该属性的含义是当前Target要依赖前续的某些Targets，那些依赖的Targets必须先执行，然后才能执行当前的Target。

在本例中Build_B会rebuild整个B工程，并将结果的头文件和lib文件拷贝到A项目的依赖路径当中。

然而，往往现存有大量的积累代码是基于原生语言开发的，当我们决定采用C#时，必须考虑到与现存的软件组件交互的能力，具体而言——如何在一个以C++语言为主的项目中引入.NET组件？如何在.NET组件中使用C++代码库提供的功能？

在游戏项目中，比较理想的情况是底层的3D引擎采用C++编写，而上层编辑器则采用C#编写，这样可以兼顾引擎的运行效率和编辑器的开发效率。一个值得一提的案例是UDK（Unreal引擎的开发包），其中就采用了C++语言与.NET组件相结合的模式，其界面上相当一部分新功能是采用.NET开发的。

下面介绍下我总结的C++与.NET互操作的方法：

1. C++ –> .NET在C++语言中调用.NET

由于.NET组件被设计成COM兼容格式，我们可以像使用COM组件一样使用.NET组件。也就是说，我们可以创建.NET组件中的COM对象，并获取接口来使用它。

值得注意的是使用.NET编译出的dll模块，与采用Native语言构建的ActiveX模块或者其他COM DLL是有差别的，你无法使用regsvr32对其进行注册（没有导出DllRegisterServer, DllUnregisterServer）。

如果希望在C++中调用.NET代码，那么在实现.NET组件时，需要设置ComVisible属性，具体而言，就是在Properties\AssemblyInfo.cs 中，将[assembly: ComVisible(false)]（默认）属性，更改为：

[assembly: ComVisible(true)]，这样才能使用COM的方式访问到.NET组件中的接口。

将需要暴露给Native代码使用的功能抽象成接口，在.NET中实现该接口，并为之提供Guid（可以采用VC2005中的工具Tools/Create Guid），这样才能在Native代码中使用该接口，并用Guid创建这个接口的实例。例如下面这样：

namespace XDll
{
    [Guid("1DE25FAA-4AA1-4819-B1FF-0D507567685E ")]
    public interface IXSystem
    {

    }

    [Guid("603F977B-34CF-40ca-BB30-B6BC25D2A370")]
    public class ImplXSystem : IXSystem
    { 

    }
}

在.NET组件构建完成后，需要使用regasm工具，将其中的COM接口导出成tlb文件，以供给C++代码使用。Regasm工具通常安装在.NET Framework的目录下，例如：

“C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm”

命令行如下：

“C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm” X.dll /tlb:X.tlb

这里注意一点，安装.NET framework并不会自动将上述路径加入到系统路径中，因此运行regasm时需要键入完整的路径。

在Native代码中调用.NET代码时（VC2005开发环境），需要做以下几件事：

#import <mscorlib.tlb> raw_interfaces_only

#import “X.tlb” no_namespace named_guids

这两行将一些必要的接口导入，X.tlb是前述步骤中使用regasm工具导出的文件，其中包含了使用C++语言描述的.NET组件中的接口。

通常情况下，Visual Studio会在$CURRENTUSER$\local settings\temp\目录下生成一个后缀名为.tlh的文件，其中包含了.NET库导出的诸多CLSID_X以及IID_X等GUID，以及各COM接口，C++代码可以直接使用该文件中的GUID与接口声明。

接下来使用.NET组件接口与使用COM接口基本相同：

CoInitialize(NULL); // 初?始?化?COM相?关?

IX* pIX;
CoCreateInstance(CLSID_X
                 , NULL
                 , CLSCTX_INPROC_SERVER
                 , IID_IX
                 , reinterpret_cast<void**>(&pIX));

注意这里的CLSID前缀的Guid与IID前缀的Guid的区别，前者是实现类的Guid，后者是接口的Guid，我们这里调用CoCreateInstance的意义在于，创建一个Guid为CLSID_X的实现类，并返回给我一个Guid为IID_IX的接口，我将会以这个接口去访问该实现类。

这里的CLSID_X与IID_IX都是在导出tlb文件时自动生成的GUID数据结构，可以在Native代码中直接使用。

当使用了.NET组件的程序被发布时，需要将上述tlb中的各种ID注册到目标机器的注册表的相应键值中。比如，CLSID就需要导入到目标机器的注册表的HKEY_CLASSES_ROOT\CLSID键中。这一步可以通过regasm的/regfile功能实现，该功能可以导出所有需要的信息到注册表中。

最后当使用完毕之后，记得需要调用创建的COM接口的Release()方法。

pIX->Release();

以及清理：

CoUninitialize();

2. .NET组件调用Native代码(C++)

由于.NET组件是出现于C++之后，微软在设计时就已经基于COM模型设计其二进制接口，因此很容易可以让以前的原生语言来调用，而C++语言则诞生得更早，没有定义二进制标准，要想让.NET组件调用，只能把自己实现成COM组件的模式。关于如何用Native语言实现一个COM组件，可以参考更加专业的参考书：《COM技术内幕》，《COM本质论》等。本文主要提及在实现COM接口时值得考虑的两种思路。

根据实际应用场景的不同，我们可能面临不同的技术选择：

场景1： .NET组件依赖于C++库，完全基于C++库构建，并且C++模块不会反向依赖.NET组件

这种情形下，由于依赖结构简单，我们可以将整个C++库采用C++CLI封装，有一些开源库采用了这种做法，比如SlimDX项目（这是一个为了可以在.NET中使用DirectX的项目，将DirectX采用C++CLI封装，最终提供了一套面向.NET的开发框架。）再如ManagedOgre或者OgreDotNet，都将Ogre引擎封装在C++CLI中从而提供在.NET中操作OGRE的方案。

场景2： .NET组件依赖于C++模块，C++模块又依赖.NET组件

.NET中需要调用底层的一些服务做一些事情，例如采用底层接口绘制一个三维场景，置放于.NET模块的窗口中。同时可能C++模块又要依赖.NET组件，比如一个.NET控件需要在一个以C++语言为主开发的编辑器中被调用。

形成类似于下面这样的关系，Native Code与Managed Code互相依赖：

这里，我们可以将.NET对C++模块的依赖提取成一个.NET接口，而后C++代码实现该接口，从而消除.NET对C++代码的直接依赖，将之转变成C++模块对.NET接口的依赖。这是一种在重构中经常使用的手法。

举一个简单的例子来说明这个问题：

namespace XDLL
{
    interface XInterface
    {
        void Foo();
    };

    public class XModule
    {
        private XInterface ix;

        XModule(XInterface ix)
        {
            this.ix = ix;
        }

        void Foo()
        {
            this.ix.Foo();
        }
    }
}

假设我们的C#模块中有一个类XModule，需要使用C++代码提供的某种功能，我们不直接调用C++代码（这产生一个.NET到C++的直接依赖），而是调用一个自己定义的接口XInterface，这个接口会被暴露给外部，C++代码实现该接口，并在初始化过程中传入.NET组件。

将上述依赖关系变成下面这样：

## 理想的情况当然是引擎用C++实现，而后底层提供一个C++CLI的封装，这样编辑器以及上层控件都采用C#开发，既可以兼顾引擎部分的运行效率与编辑器的开发效率，这样就可以保证依赖关系始终是上层编辑器直接依赖引擎。但是如果遇到某些现实状况，例如编辑器已经由C++开发，后期的部分控件界面期望采用C#开发，这样就需要采用类似于上文中的方案，将依赖关系反过来处理。

1、Windows的消息队列与消息循环

所有创建了窗口的Windows程序，都需要运行一个消息循环，我们在无数的Windows编程书籍中都可以看到这样的经典代码：

1:  while (GetMessage(&msg, hWnd, 0, 0) > 0)

2:  {

3:      TranslateMessage(&msg);

4:      DispatchMessage(&msg);

5:  }

这里的hWnd就是创建的窗口句柄，上述循环会不断的把该窗口(hWnd)相关的消息取出来，并分发到消息处理函数当中。

GetMessage函数是用来获取当前线程消息队列当中的消息的，其中的第二个参数如果传递一个窗口句柄，那么就会获取该窗口相关的消息，如果传NULL，那么会将线程消息队列中所有的消息都取出来。如果创建了多个窗口，而只对其中一个窗口句柄调用GetMessage形成消息循环，那么别的窗口都会毫无响应。

这里需要补充说明一个概念：消息队列是操作系统为每个需要处理消息的线程创建的，任何线程只要调用过与消息有关的函数（如，GetMessage，PeekMessage），操作系统就会为该线程创建消息队列。可能有人会问，那没有窗口的线程，操作系统也有必要为其创建消息队列么？这是有可能的，因为我们可以通过诸如PostThreadMessage的Api向别的线程或者本线程发送消息，如果目标线程没有消息队列，会导致这个函数返回失败。

做一个验证上述想法实验：

我们撰写类似于如下代码（所有的示例代码我都已经在Windows7系统上编写程序做过实验，这里忽略与要说明内容无关的细节并不影响对原理的理解，就不再将完整代码附上，读者感兴趣的话可以自行实验）

1:  HWND hWnd1 = CreateWindow(...);

2:  HWND hWnd2 = CreateWindow(...);

3:  while (GetMessage(&msg, hWnd1, 0, 0) > 0)

4:  {

5:      TranslateMessage(&msg);

6:      DispatchMessage(&msg);

7:  }

上述程序创建了两个窗口，但是消息循环只传递了其中一个窗口的句柄，那么我们看到的两个窗口中，hWnd2所属的窗口会毫无响应——无法移动也无法关闭，就好象死了一样，另一个hWnd1则可以正常拖动，关闭（这是由于我们将hWnd1的消息取出来并分派处理了）。

如果我们将消息循环稍作改动，GetMessage的参数不再传递某一个窗口的句柄，而是传递NULL：

1:  while (GetMessage(&msg, NULL, 0, 0) > 0)

2:  {

3:      TranslateMessage(&msg);

4:      DispatchMessage(&msg);

5:  }

则两个窗口都可以正常响应消息了。

更进一步，我们是否可以GetMessage，而不调用DispatchMessage将其分发到窗口处理函数，而是直接把Get出来的Message自行处理呢？答案是可行，但需要区分使用的场合：

1:  while (GetMessage(&msg, NULL, 0, 0) > 0)

2:  {

3:      TranslateMessage(&msg);

4:      WNDPROC fWndProc = (WNDPROC)GetWindowLong(msg.hwnd, GWL_WNDPROC);

5:      fWndProc(msg.hwnd, msg.message, msg.wParam, msg.lParam);

6:  }

上述代码（源自winprog.org）是可以工作的。但是对于WM_TIMER类型的消息，需要回调到Timer的回调函数中，就需要另作处理了。当你创建的窗口很多的时候，或者有Timer类型消息的时候，这种做法就可能带来麻烦，但是通过尝试，可以弄明白实际上是DispatchMessage替我们回调了窗口处理函数，并没有什么神秘之处，我们也完全可以绕开DispatchMessage。

另外在某些特殊场合，这种写法则有特别的用处：比如想在一个已存在的控件（例如系统的TreeCtrl）中添加框选一系列Item的功能，则可以在收到控件中鼠标点下消息的时候，开启一个局部的GetMessage循环，在自己的局部消息循环中等候鼠标抬起的消息，并在鼠标抬起消息中检查选框的范围，并选中相应元素。

延伸：模态对话框与非模态对话框的本质区别在哪？为什么前者会将界面控制权完全接管，而后者则可以让用户继续操作其他窗口？

在MFC中调用CDialog::DoModal() 或者 在.Net中调用继承自CommonDialog的ShowDialog() 都会在该函数当中创建一个局部的消息循环，从而将上一级消息循环阻断。直到该函数返回，我们才得以继续处理上一级消息。这便是模态对话框。

而调用CWnd::Create创建出来的对话框实际上则共用了同一级的消息循环，成功创建窗口之后GetMessage(&msg, NULL, 0, 0)也会得到针对新窗口的消息，从而让新创建的窗口与原来的窗口保持并行。

对比两者，我们可以发现模态与非模态对话框的本质区别实际上就在于是否存在一个局部的消息循环，以及该消息循环是否阻断了上一级消息循环的运行。

2、线程与消息

网上经常可以搜到UI线程（User Interface Thread）和工作线程(Working Thread)的说法，认为UI线程就是创建了窗体的线程，从而操作系统会提供消息队列，而工作线程则无消息队列——我认为这种说法有欠妥当，为了查找UI线程这种说法的起源，我在MSDN当中搜索了User Interface Thread，发现这个UI线程的概念是MFC给出来的，默认情况下派生自CWinApp的类都会默认工作在User Interface Thread中，我并没有发现Windows自身提供UI线程这个概念的证据，而且也没有什么理由让我相信操作系统会针对线程是否创建了窗体而对当前线程提供什么特别对待。我倾向于认为是这个来自于MFC的概念被多数人误解了。

操作系统可能为任何线程创建消息队列，只要该线程调用了消息获取函数，甚至都不需要该线程创建任何窗口。

为了验证上述想法，我们可以做下面这样一个实验(代码出自使用PostThreadMessage在Win32线程之间传递消息一文)：

其中ThreadProc是程序运行期间创建的线程，该线程默认是没有消息队列的，因此如果主线程直接以它的线程id调用PostThreadMessage，会返回FALSE，并在GetLastError中得到1444号错误——MSDN中的解释是ERROR_INVALID_THREAD_ID 1444 Invalid thread identifier。而经过调用了PeekMessage之后，ThreadProc运行的Thread已经拥有了消息队列了，之后主线程或其他线程再调用PostThreadMessage就可以正常运行了。(这里的HANDLE hStartEvent是用来保证上述顺序的同步事件。)

此外，该程序是Console版的程序，从头至尾没有创建过window，与MFC更无瓜葛，可以证实我们的想法——任何线程都可以有消息队列，Windows并没有提供什么特殊的UI线程之一说。

 1:  #include "stdafx.h"

 2:   #include <Windows.h>

 3:  #include <process.h>

 4:  #include <stdio.h>

 5:  

 6:  #define MSG_SEND_OVERTHREAD WM_USER + 100

 7:  HANDLE hStartEvent; // thread start event 

 8:  

 9:  unsigned _stdcall ThreadProc(PVOID param)

10:  {

11:      MSG msg;

12:      PeekMessage(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE);

13:      if (!SetEvent(hStartEvent)) //set thread start event 

14:          return 1;

15:  

16:      while(true)

17:      {

18:          if (GetMessage(&msg,0,0,0)) //get msg from message queue

19:          {

20:              switch(msg.message)

21:              {

22:              case MSG_SEND_OVERTHREAD:

23:                  char * pInfo = (char *)msg.wParam;

24:                  printf("%s\n", pInfo);

25:                  delete pInfo;

26:                  break;

27:              }

28:          }

29:      }

30:      return 1;

31:  }

32:  

33:  int main()

34:  {

35:      HANDLE hThread;

36:      unsigned nThreadID;

37:      char szBuf[1024];

38:      //create thread start event

39:      hStartEvent = ::CreateEvent(0,FALSE,FALSE,0);

40:      if(hStartEvent == 0)

41:      {

42:          printf("create start event failed,errno:%d\n",GetLastError());

43:          return 1;

44:      }

45:      //start thread

46:      hThread = (HANDLE)_beginthreadex( NULL

47:          , 0

48:          , &ThreadProc

49:          , NULL

50:          , 0

51:          , &nThreadID );

52:  

53:      if(hThread == 0)

54:      {

55:          printf("start thread failed,errno:%d\n",GetLastError());

56:          CloseHandle(hStartEvent);

57:          return 1;

58:      }

59:  

60:      //wait thread start event to avoid PostThreadMessage return errno:1444

61:      ::WaitForSingleObject(hStartEvent,INFINITE);

62:      CloseHandle(hStartEvent);

63:      int count = 0;

64:      while(true)

65:      {

66:          char* pInfo = new char[100];

67:          //create dynamic msg

68:          sprintf(pInfo,"msg_%d",++count);

69:          //post thread msg

70:          if( !PostThreadMessage(nThreadID

71:              , MSG_SEND_OVERTHREAD

72:              , (WPARAM)pInfo

73:              , 0))

74:          {

75:              printf("post message failed,errno:%d\n",GetLastError());

76:              delete[] pInfo;

77:          }

78:          ::Sleep(1000);

79:      }

80:      CloseHandle(hThread);

81:      return 1;

82:  }

3、对上述的诸多概念做一番小节如下：线程第一次被建立时，系统假定线程不会被用于任何与用户相关的任务，这样可以减少线程对系统资源的要求。但是一旦线程调用了一个与图形用户界面相关的函数，例如检查消息队列或窗口创建，操作系统就会为线程创建一些额外的资源，以便它能执行和用户界面有关的任务。特别的，系统会为该线程分配一个THREADINFO结构（参考下图，来源于《Windows核心编程》第四版 26-1），并将该数据结构与线程联系起来，此后该线程就拥有了自己的消息队列集合（意味着我们可以向该线程发送消息PostThreadMessage等）。

向一个线程传递消息可以使用PostThreadMessage，这个函数的接口很明确，要求传递一个线程Id，但是还有PostMessage和SendMessage这样的API，要求传递的是窗口句柄，这可能就是我们此前会迷惑于消息队列是跟窗口相关还是跟线程相关的原因。事实上，在调用PostMessage或SendMessage的时候，系统要根据传入的窗口句柄，确认是哪一个线程创建了该窗口（我们也可以通过GetWindowsThreadProcessId自行获取是哪个线程创建了一个窗口），然后系统分配一块内存，将消息参数存储在这块内存中，并将这块内存增加到相应线程的登记消息队列中。

SendMessage和PostMessage有一个值得注意的区别：

PostMessage是简单的将消息登记到目标线程（创建窗口的线程）的消息队列中。

而SendMessage是一个阻塞调用，调用者必须要等待消息处理后，函数才会返回。（注意，这并不意味着调用SendMessage的线程就是处理消息线程，前文提到过，处理窗口消息的线程必须是创建窗口的线程，如果一个线程调用SendMessage向不是由它创建的窗口发送消息，则会挂起调用线程，直到另外的线程处理完消息，才会唤醒该线程。）

线程中可以有消息循环，消息循环将线程中的消息取出来并且进行处理——可以自行根据消息的类型进行处理，也可以交给DispatchMessage处理，该API会回调窗口类中的窗口处理函数（依据该窗口所属窗口类别WNDCLASS的不同分别回调不同的消息处理函数）。如果线程创建了窗口，那么窗口的各种响应事件全部是由消息循环以及相关处理完成的，一个消息循环可以处理很多个窗口的消息。

消息循环可以有多个，可以在上一级消息循环的某个消息的处理过程中，局部创建一个消息循环，模态对话框就是采用这种机制创建出来的。

#1 确认了消息队列是隶属于线程而非窗口，补充了部分说明，本文参考了《Windows核心编程》第四版 第26章 窗口消息的部分内容，感谢redcoder同学热心指出

前段时间曾经总结过一些在win32平台下基于SVN开发的一些注意事项，主要是在利用svn官方发布的二进制库进行开发过程中使用的方法和一些值得注意的问题。

由于svn官方发布的win32平台下的二进制文件是基于vc6编译的，在使用vc2005进行开发时，会遇到因CRT冲突而引起的link错误。因此，如果是使用vc2005（我推测使用VC2003也会遇到同样的问题，尚未验证）附带的CRT库与svn官方发布的binary进行link，那么无论如何都会出现crash的问题。最为彻底的解决方案，还是自行编译svn源码。

在win32下编译svn源码说明：

 首先需要从官方下载一份SVN源码，版本可以根据需要选取，比如最新的Release 1.6.3(目前已经更新到1.6.6)可以在这个地址下载到：

http://subversion.tigris.org/downloads/subversion-1.6.3.zip

以及svn所需的依赖包：

http://subversion.tigris.org/downloads/subversion-deps-1.6.3.zip

如果需要支持ssl的话，还需要下载openssl（根据实际需要选择相应版本）：

http://www.openssl.org/source/

如果需要BerkeleyDB的话，需要下载WindowsBDB(BDB是可选的，如果不使用BDB，则默认使用FSFS)：

http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=688&expandFolder=688&folderID=2627

此外还有Windows libintl：

http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=2627&expandFolder=2627&folderID=8100

解压svn源码包，可以在subversion-1.6.3目录中找到这么一个官方发布的说明文件INSTALL。该文件详述了安装通过源码编译SVN所需依赖的工具及第三方库，并且给出了详细的步骤。

网上同样有一个INSTALL的说明，可以在这里访问到:

http://svn.collab.net/repos/svn/trunk/INSTALL

编译开源项目的话，其附带的INSTALL说明都是最重要也是最全面的参考。网上搜索的其他资料，也会有相应的参考价值，但无论如何，其信息的来源也是INSTALL。因此编译开源项目时，认真阅读INSTALL是最重要且效率最高的。

从Google上进行一下简单的搜索的话，可以找到一篇介绍svn源码编译的文章，在这里：http://rocksun.cn/?p=103

为了后续的步骤方便，我们需要先准备编译所必须的一些东西：

包括Perl：http://www.activestate.com/activeperl/

Python：http://www.python.org/download/

安装Python以及Perl，比如分别安装到D:\Python26以及D:\Perl。安装好之后，将python以及perl的bin目录设为系统目录并重新启动使之生效。

编译svn源码第一步，将下载的svn源码包解压到X:\SVN\svn—trunk下。X可以是任意一个盘符。在我的机器上，我使用了F盘，下文中皆以F盘举例。

在F:\SVN\svn-trunk中解压了刚才下载的svn源码包以及依赖之后，可以在目录

F:\SVN\src-trunk\subversion-1.6.3中看到以下文件及目录：

以及文件：

Svn的编译需要依赖libapr以及libapr-util，SQLite，zlib，libintl可选，libneon/libserf二则择一，openssl可选，BerkeleyDB可选，libsasl可选，对Python,Perl,Java,Ruby支持的模块可选，以及KDELibs,GNOME Keyring可选。

我们依次先编译依赖项：首先进入到subversion-1.6.3\apr目录中。可以看到存在apr.dsw以及apr.dsp文件，这是VC6的工程文件。我们如果想在2005下编译的话，需要将其转换成sln及vcproj文件，简单的用vc2005打开该文件并保存即可。该目录下还有Makefile.win文件，是win下的makefile，我们打开makefile.win文件查看一下说明：可以得知如果需要编译.sln文件的话，需要置USESLN=1。

在VC2005的命令行中输入nmake -f makefile.win buildall checkall USESLN=1便可以开始编译apr了。Checkall表示编译完成后会去运行所有的测试用例。

编译完成后，当前目录下会多出2个文件夹，分别是LibR – StaticRelease，Release – DllRelease。如果选择Debug编译，则会生成LibD – StaticDebug， Debug – DllDebug。

类似的，我们将apr-util以及apr-iconv也编译好。

编译zlib：

进入zlib目录后，使用以下命令编译zlib库

nmake -f win32/Makefile.msc

编译openssl：

将此前下载的openssl解压到F:\SVN\openssl

阅读其INSTALL文档（INSTALL.W32）

使用VC编译openssl首先需要运行configure：

perl Configure VC-WIN32

接着运行

ms\do_masm

这里的do_masm是一个bat脚本，该脚本会生成nt.mak以及ntdll.mak分别是Release版本的静态和动态的库的make文件。如果想生成debug版本的make文件，可以通过修改do_masm.bat中的调用mk1mf.pl脚本处的参数实现，具体参数可以参考mk1mf.pl文件自身的说明。

接下来，创建动态链接库版本的ssl库用nmake -f ms\ntdll.mak，以及静态版本使用：nmake -f ms\nt.mak

生成的结果文件位于out32dll文件夹，以及out32文件夹中。

编译neon

进入F:\SVN\src-trunk\subversion-1.6.3\neon目录

nmake –f neon.mak

默认生成的是release版的libneon.lib (debug版为libneonD.lib)

可以用nmake –f neon.mak DEBUG_BUILD=1生成debug版的lib。

回到F:\SVN\src-trunk\subversion-1.6.3

运行python gen-make.py –help可以了解如何使用gen-make.py生成我们所需的svn编译文件。

由于在此，我打算选用neon, libintl, openssl(本例中并不打算使用BDB，如果需要BDB则需要增加—with-berkeley-db=DIR参数)进行编译，目前需要关注的几个重要参数如下：

–with-apr=DIR

–with-apr-util=DIR

–with-apr-iconv=DIR

–with-neon=DIR

–with-libintl=DIR

–with-openssl=DIR

–with-zlib=DIR

–vsnet-version=VER

运行

F:\SVN\src-trunk\subversion-1.6.3>python gen-make.py -t vcproj

–with-apr=apr –with-apr-iconv=apr-iconv –with-apr-util=apr-util –with-libintl=svn-win32-libintl –with-openssl=..\..\openssl –with-zlib=zlib –vsnet-version=2005

(其中的libintl需要解压到当前文件夹中)

即可生成vc2005的sln(subversion_vcnet.sln)文件了。

打开vc2005，选择Debug编译选项，对项目ALL进行编译。如果一切顺利，则会生成一个F:\SVN\src-trunk\subversion-1.6.3\Debug目录。内容包括svn的所有的lib及可执行文件。

将svn\svn.exe以及所有目录下的.dll文件拷贝到一个新建的bin目录下。将openssl的dll，apr, apr-util, apr-iconv的dll拷贝到同样的bin目录下，如下图：

运行svn –version看看结果吧～

最后，当我们有了自行编译的svn可以做什么？你可以做任何你想做的事——比如自己基于svn的接口进行开发（可以参考开源项目rapidsvn以及TortoiseSVN的源码）

1、静态库vs动态库

静态库的优势和劣势

动态库的优势与问题

2、静态C/C++运行库 vs 动态C/C++运行库 & manifest

3、关于动态库接口设计

库与代码重用

对于像C，C++这样的语言来说，库是扩展语言功能的重要手段，对于项目来说，代码库是节约开发时间，缩减成本，划分项目模块以利于多人合作，并通过重用已有代码而避免重复劳动的必要工具。开发一个稍具规模的项目，总免不了设计和划分模块，如何设计和划分，采取什么方案解决问题，总要面临诸多取舍。

最近跟动态库/静态库/动态静态CRT/MFC打了诸多交道。本文是对这段时间遇到的问题与思考的总结。

1. 静态库 vs. 动态库

静态库本质上就是编译好的目标代码(使用vc的话，编译.cpp文件或者.c文件之后会得到目标文件.obj，编译结束后，link程序会按照指定的要求将目标文件链接成最终的输出文件——常见的有.lib/.dll/.exe)的一份合集。

相比于动态库，静态库没有入口函数，不能独立执行，不能动态链接，一旦被链接到目标文件中，静态库的代码段/数据段都会被合并到目标文件当中去。这是静态库与动态库的本质区别。

由于上述差别，那么我们就很容易理解下面的情况：如果你在静态库中定义一个静态或全局对象，最终该对象会被链接到目标文件的数据段中（目标文件可能是某个dll也可能是exe）。

静态库的优势在于，简单易用，你无需考虑内存的申请与释放问题，因为静态库的代码段作为目标模块的一部分（EXE或DLL），在其中所调用的new/delete在链接阶段会被重定位到该目标模块的CRT函数地址。

对应的，如果你使用DLL，由于DLL中会自行初始化一份CRT堆，因此它的内存申请与释放是在有别于在EXE的CRT堆中进行的（两个不同的CRT堆），如果你从DLL中申请一块内存出来使用，最后也必须交还给DLL模块内部去释放。否则会产生Heap Collision，在Debug模式下，你会收到一个系统位于malloc中的断言，并了解到发生了什么。*

此处的叙述存在错误，更正如下：

一个DLL或许会，或许不会拥有一份自行初始化的CRT堆，这取决于DLL是通过动态链接MSVCRT还是静态链接LIBCMT。由于CRT是通过一个全局变量_crtheap维护着一个Heap（Windows环境下），并且会在CRT初始化的时候初始化CRT堆，因此，如果整个应用程序都是通过链接动态的msvcrt，使用同一份crt，则不会有问题。但是如果有任一二进制模块链接了静态crt，则会拥有一份自己的crt堆。严格来说，你应当小心的保证来自于某个CRT的堆内存最后也被交还给该CRT堆，否则会发生错误，在Debug模式下，当你调用free函数释放来自于另一个CRT堆的内存时，会有一个_ASSERTE(_CrtIsValidHeapPointer(pUserData));断言失败，提醒你用错了堆。

如果我们的DLL是链接了一个静态的CRT并且发布出去了，那么我们还是应当保证所有来自于该DLL的内存都由该DLL回收。其原因如上述分析所言，是由于该DLL拥有一份自己的CRT堆。

再有，如果你的静态库A依赖于静态库B的头文件，而目标应用程序EXE依赖了静态库A，那么你在链接静态库A的时候，也必须链接静态库B。否则会有静态库A中的某些符号无法被找到，从而导致链接失败。而动态库A如果依赖于一个静态库B，那么你无需在依赖该动态库的EXE中再次包含该静态库，因为该动态库A已经将该静态库B链接到A模块当中了，在DLL A中已经有了一份，如果EXE模块没有直接依赖于静态库B的话，那么就无需在EXE中再次link该静态库了。

上述问题也通常是混用静态库和动态库时可能遇到的一个问题：如果有一个静态库A，被动态库B和EXE C都用到了，而EXE C又需要使用动态库B，那么这份A的代码和全局数据就在动态库B和EXE C中存在了两份。第一，这是一种对空间的浪费；其次，这可能会引发问题，比如，当我在EXE C中new一份A中的某对象X的指针，并将该指针传入到动态库B中使用，表面上看似乎没有问题，但是如果这个对象X引用了A库中的全局/静态数据，就可能会引发问题，因为此时动态库B中存在有一份A库中的全局/静态数据，而EXE C中有另一份，如果这个全局/静态数据被X使用的话，那么就会得到前后不一致的上下文环境。具体可能产生什么问题要看具体的逻辑是如何组织的。在这种情况下，最好能将静态库A重新组织成一个动态库，这样就不存在多份代码以及多套全局数据的问题了；如果不能这么做，你可以根据具体的应用程序组织的形式，采取DLL导出A库接口，EXE使用DLL导出接口去访问A库而不直接链接A库本身的方法来变通，但通常这不是根本的解决方案。

另一方面，在DLL中可以包含自己的资源文件，而LIB中不能。因为DLL是一份完整的PE文件，而LIB只是若干个OBJ打包。这并不是说，使用LIB的时候不能使用资源(RC)，你可以将LIB中使用的RC文件，resource.h都include到目标应用程序当中，只要没有资源ID冲突就可以正常使用，就像是你在目标应用程序的资源当中定义了这些资源一样。而DLL中的资源则隶属于DLL自身，不会与EXE中的资源在ID号上产生冲突，只是在使用的时候还需要针对Resource做一些Handle上的设置（参考AfxSetResourceHandle），才能使得API访问DLL中的资源而非EXE中的。如果要编写一个带有资源的库模块，DLL确实是不二选择。

2. 静态&动态C/C++ runtime 以及 manifest

静态的C-runtime库叫做LIBC.lib，我们通常使用多线程的版本叫LIBCMT.lib，debug下的版本叫LIBCMTD.lib。而动态的C-runtime，在VC的环境下，我们使用的是MSVCRT.lib，以及debug下的MSVCRTD.lib（这两个lib实际是两个导出符号文件，实际的运行库位于msvcrt.dll/msvcrtd.dll中(VC6)，如果是VC2005的版本则是msvcr80.dll/msvcr80d.dll）

C++的runtime库，静态版的是LIBCPMT.lib/LIBCPMTD.lib。动态版的是MSVCPRT.lib以及MSVCPRTD.lib。（类似的，实际的运行库位于<VC2005中>msvcp80.dll/msvcp80d.dll）

在第一点的对比中已经提到过，如果同时又DLL模块依赖一个静态库，而又有一个依赖该DLL模块的EXE还依赖这个静态库，那么最终的内存中就会存在两份该静态库的代码以及全局数据。这一点对于C/C++运行库也是一样的。所需要注意的是，只要是基于C语言以及C++语言的程序，几乎所有的都会用到C/C++运行库，因此如果在规划一个项目的时候，发现有多个dll模块，那么最好是使用动态版的运行库，以避免最终的内存中出现多份不必要的运行库代码。

再有一点是关于XP之后的系统中，以及在VC2005之后的编译环境中，微软添加的manifest机制。该机制是为了解决同名但版本错误的DLL加载问题而提出的。比如，我们手上有两份VC编译器，分别是不同的版本，其中携带的MSVCR80.dll也是不同的版本，但是都叫MSVCR80.dll，如果我们在应用程序安装时，简单粗暴的将系统目录下替换成我们应用程序所依赖的MSVCR80.dll，那么可能会造成以往的应用程序无法正确运行的问题，因为他们可能依赖的是其他版本的MSVCR80.dll。

解决这个问题的途径是将一个dll的运行环境，版本，以及校验值等信息编码到一个目录名当中，而在安装应用程序时，将该版本的dll放置到对应名字的目录下，这样尽管dll名称一致，我们也可以找到所需要正确版本的dll。但是应用程序怎么知道需要依赖哪个版本的dll呢？如果应用程序不知道，即使系统中有正确版本的dll，操作系统也不知道应该去加载哪一个dll。

因此manifest文件就把该模块所依赖的模块都标明了，通过名称，校验码，版本等等信息以确保所指明的模块不会有歧义（用记事本打开一个manifest文件，你就可以看到上述信息），当该应用程序EXE或者DLL被操作系统加载时，系统就会根据该信息去查找对应模块，首先会在C:\Windows\WinSxS目录下找（打开这个目录，你就能看到大量不同版本的CRT/CPRT/MFC/ATL等等运行库），如果没有找到那么也会应用程序当前目录下找。

这就是为什么使用VC2005编译一个dll也好，一个exe也好，总会多生成一个manifest的文件的原因。所以如果使用了动态版本的CRT运行库，或者其他任何DLL，那么最好就不要关闭manifest生成的编译选项。

3. 关于动态库接口设计

如果动态库可能经常会更新版本，提供新的功能接口，那么如果使得动态库的升级无需改动依赖于他的可执行模块就是一个值得思考的问题。

具体要达到上述目标，需要保证的有以下几点：

a. 动态库中的类的内存布局不暴露给外界，也就是说动态库提供给用户的.h中，不应当有类的成员信息。这是因为，如果类的内部数据修改了，增加了一个变量或者减少了，那么这个类所占用的内存大小也就修改了，倘若有exe使用上一版本的类定义，new了一个类对象，那么一旦发生类定义修改的情况，这部分代码就必须要重新编译链接了。比较标准的做法是dll只向外界提供接口定义，而不提供实现定义，即提供的是一个类，但是类中只包含纯虚函数，而没有数据<这种做法有点类似于COM的思路>；或者是只提供一系列普通函数以及一个实现类的指针，这种做法有一个好处，如果添加新的函数接口，也无需重新更新外部程序，但是如果使用虚函数接口则不然。

b. 动态库中的类应当不给外界提供构造析构的能力，同样是基于上述原因，如果外界可以new/delete该类，那么当类的定义修改时就会出现不得不重新编译使用该库的应用程序的情况。倘若只通过dll中定义好的借口进行交互，则不存在这个问题。比如外部不能直接new一个对象，而是必须从一个dll导出函数中获取一个对象的指针，外部同样不能delete这个对象，而是必须将之送入另一个导出函数交给dll去删除。这样只要dll保持着两个接口不变，更新dll时是无需更新依赖该dll的应用程序的。（一个比较好的做法是将dll提供外界的接口类的构造析构函数设置为private）

c. Dll应当尽可能使用动态crt，如果用到了mfc应当尽可能使用动态mfc。这是为了避免dll与外部模块中存在多份重复代码的情况。同时如果有dll需要依赖的其他静态库，也应当尽可能使用该库的动态版本。

p.s. 如果想了解更多的关于静态库，动态库，C运行库方面的知识，可以参考《程序员的自我修养——链接装载与库》一书。

p.s.2 果然如pongba老大所言，将自己认为没有问题的知识写下来是一次很好的学习过程，写下本篇文章的过程中，我将原先认为明白的，但是实际并不见得就真的明白的问题，梳理清楚了很多。写的过程有助于把原先大脑中下意识存在的假设显现出来，在思维中再次加工，将原先不明确的概念搞清楚。

#1 更正了关于DLL与CRT堆内存的一处错误，感谢coldfall热心指正

 SVN（SubVersion）是目前开源的版本管理工具中较为流行的，最新的release是1.6.1。但是遗憾的是基于SVN开发的资料在互联网上异常的少。

         最近一段时间，我在工作上需要编写一个使用SVN进行版本管理的编辑器。（需要对编辑器生成的文件做版本管理以利于多人合作开发）起初是通过调用svn自身携带的的客户端程序svn.exe以实现相关功能，然而由于实际中的若干设计问题，最终的速度很不理想。于是产生了借用svn自身提供的api接口实现所需功能的想法。

         在实际使用svn提供的api时遇到了一些问题，经过多番查找资料以及尝试最终得以解决。将问题整理在此，以方便日后与我遇到类似问题的朋友。

         Svn提供的第三方开发接口sdk可以在这里下载到。目前最新的release是1.6.1。我在项目中实际使用的版本是1.5.6。开发需要的几个压缩包分别如下：

Svn发布的2进制可运行文件，包括客户端与服务端，以及所需的dll：

http://subversion.tigris.org/files/documents/15/45230/svn-win32-1.5.6.zip

Svn开发所需的lib及头文件以及文档：

http://subversion.tigris.org/files/documents/15/45236/svn-win32-1.5.6_dev.zip

Svn的调试符号文件：

http://subversion.tigris.org/files/documents/15/45234/svn-win32-1.5.6_pdb.zip

此外，在编写基于SVN的程序时，在链接时还有一些必要的库需要添加，分别是：

Berkeley DB for Windows:

http://subversion.tigris.org/files/documents/15/32472/db-4.4.20-win32.zip

libintl binaries for Windows:

http://subversion.tigris.org/files/documents/15/20739/svn-win32-libintl.zip

有了这几个包，就可以使用SVN提供的api开发基于SVN的第三方软件了。

         基于SVN1.5及之后的版本开发的时候，会遇到一个CRT冲突的问题，该问题会导致在调用svn_cmdline_init时，如果在error stream参数中传入非NULL值，则会直接crash。一个针对该问题的描述可以参见这里。

         我下载了调试符号以及源代码之后，跟踪调试到svn_cmdline_init函数当中，发现crash发生在一个CRT函数（setvbuf）的调用当中。实际跟踪调试的过程中发现，虽然该函数是crt中的函数，然而vc调试器却无法基于本地的调试符号正确跟踪到其源文件当中。

又该问题在1.4及之前的版本不存在。究其原因，我猜测可能是由于自1.5版本之后，SVN提供的库是基于动态链接的CRT库的。而svn本身的lib在编译时链接的crt与客户的VC6的CRT版本不符导致的。（1.4版本之前则是静态链接的CRT）

对该问题的描述还可以参见这里：

The problem is stderr — it is a FILE* which is a CRT type which means 
you have to be using the same CRT as the dll’s were built with. 
Unfortunately, there are a few API’s where raw CRT types crept in that 
aren’t wrapped by APR. 

You can either avoid those API’s, rebuild Subversion with your 
compiler, or link to the static libraries instead of the dynamic 
libraries and use the no-default-libs option to make sure that your 
CRT is linked in instead of the VC6 one (I believe this is how it 
worked prior to 1.5). 

DJ 

解决该问题的方法之一是自行编译svn的全部源码，而不使用官方提供的dev包。然而svn的源码编译要求的环境异常复杂（需要配置非常多的环境项：包括cygwin，python等等）。更简单的解决方案是使用静态链接版本的svn库。

svn_cmdline_init位于libsvn_subr-1.lib当中。该版本的lib在1.5及以后的版本开发包中是动态库，实际运行时需要libsvn_subr-1.dll的支持。同在该开发包中发布的还有一个静态版本的该库，名为svn_subr-1.lib。

但是链接静态版本的svn_subr-1.lib时，由于其中静态链接了CRT库，因此VC自带的libcmt.lib/libcmtd.lib会与之冲突。实际链接时会报出一堆同一个符号被多次链接的错误，只需将VC自带的libcmt.lib/libcmtd.lib设置忽略即可。