工资翻倍吧！

Firefox is recommended to view the blog :)

    今天, 我们继续解决vs2005编译, link到msvcr80.dll, 但是找不到dll的问题.
    可以先看一下之前的某篇文章: VC++ Redistributable Package 的作用 = =b

    Redistributing Visual C++ Files
    这篇实际上就是描述了要发布link到crt的时候, 应该怎么做, 以及会出现的问题, 这些在之前都提过.

    Troubleshooting C/C++ Isolated Applications and Side-by-side Assemblies
    告诉我们如下有用的信息:
1. Building Visual C++ projects without manifest generation is not supported. Any C/C++ program built in Visual C++ 2005 has to include a manifest describing its dependencies on Visual C++ libraries.
2. If the manifest is embedded inside the binary, ensure that the ID of RT_MANIFEST is correct for this type of the binary. For applications, ID should be equal to 1, for most DLLs ID should be equal to 2.
3. On Windows XP, if an external manifest is present in the application's local folder, the operating system loader uses this manifest instead of a manifest embedded inside the binary. On Windows Server 2003 and later versions of Windows, the opposite is true—the external manifest is ignored and the embedded manifest is used when present.
4. It is recommended that all DLLs have a manifest embedded inside the binary. External manifests are ignored when a DLL is loaded though a LoadLibrary call.
5. the CRT assembly can also be installed as a private side-by-side assembly in the application's local folder. If the operating system fails to find the CRT or any other assembly as a shared assembly, it starts looking for the assembly as a private assembly. It searches for private assemblies in the following order:
    *) Check the application local folder for a manifest file with name <assemblyName>.manifest. In this example, the loader tries to find Microsoft.VC80.CRT.manifest in the same folder as appl.exe. If the manifest is found, the loader loads the CRT DLL from the application folder. If the CRT DLL is not found, load fails.
    *) Try to open folder <assemblyName> in appl.exe's local folder and if it exists, load manifest file <assemblyName>.manifest from this folder. If the manifest is found, the loader loads the CRT DLL from <assemblyName> folder. If the CRT DLL is not found, load fails.
    最后一个解决了我们的问题 !!

    这里有一个side-by-side assembly(SxS) 的概念. 首先是assembly, 程序集, 疑似.NET的概念啊.
    A Windows side-by-side assembly is described by manifests. A side-by-side assembly contains a collection of resources—a group of DLLs, Windows classes, COM servers, type libraries, or interfaces—that are always provided to applications together. These are described in the assembly manifest.
    SxS assembly解决的是一个dll versioning conflicts的问题, 方法是通过一个manifest文件.
    然后是isolation applicaton的概念.
    Isolated applications are self-describing applications installed with manifests. Isolated applications can use both private assemblies and shared assemblies.
    好的, 越说越离谱了, 又牵涉到了private assembly和shared assemblies.
    A private assembly is an assembly that is deployed with an application and is available for the exclusive use of that application. That is, other applications do not share the private assembly.
    A shared assembly is an assembly available for use by multiple applications on the computer. On Windows Vista and Windows XP, side-by-side assemblies can be installed as shared assemblies. Shared side-by-side assemblies are not registered globally on the system, but they are globally available to applications that specify a dependence on the assembly in manifests.
    是不是糊涂了.. 个么SxS assembly和private/shared assembly到底是个什么关系呢? SxS只是一种机制, 加一个manifest文件, 来避免dll的版本冲突. 而private/shared是具体的实现方式. 举个例子, vs2005的crt dll默认使用的方式就是shared SxS assembly, 而如果我们把vs2005的crt dll放到应用程序的当前目录下, 在建立一个manifest文件, 那么这就是private SxS assembly.

    dll 版本冲突, 也叫做dll hell, 是个什么东西: The End of DLL Hell. 而且很久很久以前就有了相对于的解决方案: Implementing Side-by-Side Component Sharing in Applications (Expanded). 那如果不是SxS assembly, 像一般的dll调用算什么? DLL/COM Redirection on Windows.

    既然SxS assembly那么好, 那我们怎么自己建一个呢? 这是一个相当相当麻烦的过程.... 我都懒的看了.
Guidelines for Creating Side-by-side Assemblies
Installing Side-by-side Assemblies

    下载点这里. 

    先截张图:


    qterm 0.4.1依然有如下很明显的bugs: 
1) ansi拷贝一直都不对. 
2) 暗灰始终被显示成了高亮. 
3) 配置文件latin-1编码, 所以...乱码...
4) ansi显示没有做无缝处理比较难看:

    前一篇: http://gonwan.ycool.com/post.2809593.html

    本文主要讲一下win32下debug的一些机制.

    我们都知道, 要正确的debug一个程序, 需要该程序的.pdb(Program Debug Database)文件, 而源码其实是不需要的. 源码的使用只是为了使debug更直观, 比如M$免费提供windows的.pdb文件, 而不提供源码就可以debug.
    msdn上只提供了.pdb文件很少的信息, http://msdn.microsoft.com/en-us/library/yd4f8bd1(VS.80).aspx, 只告诉你里面存了点什么东西. 更详细的可以看这个: http://www.debuginfo.com/articles/gendebuginfo.html. 原来也一直以为要源码才能debug的, 现在知道了: 其实.pdb文件能帮助debugger知道程序里变量很函数的地址, 只凭这点vs里的debug view里已经能看到变量的值了. 此外, 因为.pdb文件里还有程序中每个位置与每行代码对应的mapping, 这才能让我们关联到源码.
    vs的dumpbin工具可以用来查看程序对应的.pdb文件绝对路径, 并且告诉你search的顺序: http://msdn.microsoft.com/en-us/library/44wx0fef(VS.80).aspx. 这里还有详细的说了debug信息的匹配: http://www.debuginfo.com/articles/debuginfomatch.html.

    好了, 我们来做一个实验吧..
    建一个最简单的console程序, 声明一个变量, 调一把printf(). main()函数最前面加一行__debugbreak();用来产生exception调用vs的JIT debug. 把vs关掉.
    *) cmd下运行该程序, vs能正确被调用且能debug到源码.
    *) copy一份到另外的目录, cmd运行copy的那份, 情况同上.
    *) 把原始那份的.pdb文件全部删掉, cmd运行copy的那份, 情况还是同上. 说明了vs寻找.pdb的策略就是当前文件夹也会search到.
    *) 把原始那份的.cpp文件也删了吧, cmd运行copy的那份, 源码显示不出来了=v=. 但是vs的debug信息中, local变量的值还是依然能看到.

    然后我们还有一个没有解决的问题就是: vs是怎么search源码的呢? 这个google不到答案, 似乎就是根据.pdb中的源码信息来的, 不过如果源码不存在呢? 试了一下, 在vs里设置多加一个source的folder是不行的, 把源码copy到预定义的folder下倒是可以=v=... 囧.

    记得以前写service的时候debug很痛苦, 也缪找到很好的debug的方法, 而且__debugbreak()用了也不行, 现在找到了: 就是attach到service的那个process=v=... 记得一定要设断点, 不然自然是跑过了. __debugbreak()为什么不行的原因在这里, 听起来很有道理:

Why did I say that DebugBreak's reliance on the JIT debugger is, in fact, a problem? Because just-in-time debugging feature in Windows is designed so that JIT debuggers can operate reliably only if they are started by an application running under an administrative user account. If our service is running under a non-administrative user account (e.g. LocalService or NetworkService), DebugBreak will not be able to launch JIT debugger for it. As a result, DebugBreak – based approach can be used only with services running under LocalSystem or another user account with administrative rights.

    为什么要弄这个东西? 1来我要学学QT, 2来Fterm太不好用了尤其e文的系统到处乱码还不如自己编译一个来玩.
    本文假定你用的编译器是vs2003, vs2005会有不可知的问题..嗯.

    QTerm依赖qt(qt GUI支持, 废话), openssl(ssh支持), python(python脚本支持)这3个库, 所以要编译QTerm, 首先要编译这3个库.

1. openssl的编译:
    这个是最简单的了, 我用的是0.98g版. 0.98h似乎vs2005编译有点问题, 不敢用. 然后看文档吧, 源码包下有一个install.w32文件, 会教你怎么编译的. 或者看这里的中文版.
    搞定后把include, dll, lib全部提出来.

2. python的编译:
    选的是2.4.5版, 因为官方的qterm4win32用的是2.4.x, 避免不必要的兼容性麻烦.
    依然是看文档, /PCbuild/readme.txt文件, 其实都是废话. 假设你已经打开了那个叫做pcbuild.sln的solution文件. 我们要编译的只有一个叫做pythoncore的project, 这是一个dll. 编译应该能直接过, 但是对于vs2005来说, 这里有一个bug: http://bugs.python.org/issue1350409. 上面提供了一个patch, 不过似乎没有backport到2.4.x stream=.=... 个么手动改吧皑皑.
    搞定后吧include, dll, lib全部提出来. 然后把/PC/pyconfig.h也复制到include目录, 编译qterm时会有用的.

3. qt的编译:
    这个东西的版本非常的重要.
    先来说说opensource版. qt3.3.x系列的opensource版普遍有字体显示问题, 尤其是中文字体. 3.3.4稍微好了一点, 似乎算一个special build, 估计是TrollTech的人亲自参与了吧. diff一下3.3.4和3.3.5的代码会发现, 这两个版本的代码差异不是一点点, 无语的是入口函数的signature变了, 以至link到3.3.4的qt的程序, 换一个3.3.5的dll就不认了. 具体可以查看/src/kernel/qtmain_win.cpp, /src/kernel/qapplication_win.cpp. 所以对于break changes的build, 我还是不用了.
    然后是commercial版. 官方支持的自然要好很多, 字体问题几乎是没有的. 安装程序和license电驴上都有, 不过目前非常的难找就是了shy. 安装过程非常的简单, 不过最好先开个包含vs2003的cmd, 然后运行安装文件, 不然会提示找不到vs200x路径. 建议只build release版本就可以了, 如果再build debug版的话, release版会被覆盖... 囧..... 而qt4是不会出现这种情况的.
    整个build过程大概15min左右还是比较快的(P4 2.6c HT, 512M的机器). 搞定后把生成的obj文件删掉减少磁盘占用.
    诶.. 难道一定要用commercial版才能让qterm正确编译并运行么? 不是的.. 你可以用opensource版编译(建议3.3.4以上版本), 然后发布的时候替换opensource的为commercial版的qt dll. 关于commercial的dll, 其实很多程序都包括的, qterm官方发布的唯一一个windows版本里就有一个qt-mt334.dll. 不过qterm很无耻的用的就是commercial版, 并不是替换的策略.
    反正一句话, 方便一点就直接用commercial版吧=v=.

4. qterm的编译:
    选的是0.4.1版. 我要骂人了, qterm的代码实在写的有点恶心. 0.4.0版的prj文件错误一堆, 主要是少文件, 很多文件. 0.4.1版好了很多, 不过还是少, 还有一些编译error, 一些很低级的warning, 看changelog会发现, 最长的一次更新之间用了1年还多...==b. 0.5.x版更nb了.. 代码跟0.4.x完全不像了, 编译采用cmake控制, 不知道什么东西. 好了.. 现在丸子sensei开始讲解怎么改qterm的代码:
    *) 找到/qterm/qterm.prj文件, 打开.
    *) 找到 win32:INCLUDEPATH, win32:LIBS 这两行, 改成你自己openssl和python的路径.
    *) 找到SOURCE这一块, 加1个文件: ssh/getput.cpp
    *) 找到/qterm/ssh/types.h, 加一行:  typedef Q_UINT16 u_int16_t;
    *) 找到/qterm/trayicon_win.cpp, 最前面加一行: #include <windows.h>
    ok了.. 运行cmd到/qterm目录, 再运行: qmake -t vcapp qterm.prj  这样就生成了一个.vcproj的项目文件, 然后自己用vs200x爽去吧.
    这里对于不同的qt库, qterm的运行可能会不一样, 一下是一些测试:

qt link version	qt change dll version	run	font	style
3.3.7-free	3.3.7-free	modal dialog cannot move.	sometimes too small and cannot changed.	ok, but ugly.
3.3.7-free	3.3.4-commercial	ok	too large, changeable.	ok, windows style added.
3.3.7-free	3.3.4-commercial-self	ok	same as above.	ok, windows(xp) style added.
3.3.7-free	3.3.8-commercial	failed	x	x
3.3.4-commercial	3.3.4-commercial-self	ok	same as row 3.	same as row 3.
3.3.4-commercial	3.3.8-commercial	failed	x	x

    jz.. 等下传一个vs2003编译好的qt0.4.1上来.

    换了个bgm, 更以前风格完全不同的.

    已经很小心了, 一句话也没说错, 连约吃个饭都会被拒真是第一次. 没人要拉倒.
    公司的项目越做越无聊, 感觉Taipei那边的nc一堆. 凭什么你们linux那边搞不定的东西就要我们windows组改呢. 索性我coding的只是底层的library, 改的东西不多. 上层的逻辑1周了还没改完.
    周三, 另外一个项目, 做code review, 我就是要让你们知道, 什么叫做perfect.
    在家真的是一点书也看不进的. 奥运期间, 看比赛也就算了, 还喜欢叫... 提了一下自己租房子的事情, 反正不管同不同意我已经决定了.

    汇报完毕, 周末要做的事:
*) 还信用卡
*) 注掉某张银行卡
*) 喵一眼租房相关
*) 把上周买的那本书看完一半左右, 下周看完买新的
*) 日语日语日语

    下周要做的事:
*) 讨债, 都要1年了, 即使1k, 1k也要给我还出来


Resolution of Soul
KOTOKO

大切な人々のために
自分が何かを　今救えるのならば
この身体　引き換えにしてと
祈って　瞳を閉じたの
空に光る南十字星
闇に迷う二人を　輝らし出すよ
眠り覚ます　君の口づけが
魂までそそいだ

たとえ命を失くしても
守りたいものがあるから
行く手を阻む嵐にも
立ち向かってゆけると誓う
幾千の時を越えて
めぐり逢ったふたつの瞳に
ひとすじの希望の光を見つけたよ

ひたすらに前に進むこと
運命を背負って
ただ　生きてゆくことが
いつの日か　本当の夢を
見えないものにしていたね
頬を濡らす　無数の涙が
闇を輝らす
夜空の星に変わる　来世で逢う
約束を信じ　この瞳に刻もう

たとえ命を失くしても
守りたいものがあるから
別れを選ぶことさえ
大切って思えるよ今は
幾千の時を越えて
紡ぎあうふたつの夢に
約束の星　愛の力
呼び合うよ

たとえ命を失くしても
守りたいものがあるから
行く手を阻む嵐にも
立ち向かってゆけると誓う
幾千の時を越えて
めぐり逢ったふたつの瞳に
満天の星　愛の光
輝くよ

    每天把第二天要做的事情想一遍, 重要的事情完整的想一遍, 要怎么做, 要达到什么效果. 不然心里真的非常的没有底...