VLC播放器2.0,2.1版本在Windows下字幕中文（或其他非拉丁）字体存在BUG。
如果一个字体的名称是非拉丁/非ASCII字母但是登录项是拉丁/ASCII字母，那么这个字体不能选择用作VLC的字幕字体。
比如你的Windows的系统区域是中国大陆简体中文，你将用不了宋体、微软雅黑等拥有中国大陆简体中文名的字体，只得使用没有中国大陆简体中文名的字体如DFKai-SB,Microsoft JhengHei等(Windows 10下建议选择Microsoft JhengHei)。繁体和日文等也有类似情况。
因此进行如下设置，然后一定要重启 VLC。
最近小米2 总是报告系统空间不足,一般的应用的安装，升级都搞不定了，网上搜索了一下，找到了无损分区的调整办法，本文对于步骤进行了精简，原文有些过于繁琐了。
1.下载Mi2 Repartition 解压到“C:\Mi2 Repartition”下（D盘也可以）。其中含Android命令行工具、WinHex十六进制编辑软件、userdata分区挂载可使用空间调整工具resize_data，以及处理过程中的backup备份文件夹。（精简了DiskGenius，因为实际上是用不到的，原文过于折腾了）
2.下载高通 Qualcomm HS-USB QDLoader设备驱动 Qualcomm_HS-USB_QDLoader_Driver 之所以不用小米的 MiFlash ，原因在于驱动里面的qcCoInstaller.dll 经常莫名奇妙的丢失，导致驱动安装不上，一直报错。（注意目前这个驱动已经可以通过Windows Update正常获得，因此不再需要）
3.下载支持Linux Ext4格式无损调整分区（前移后挪双向均支持）的软件：Paragon Hard Disk Manager 14 Pro (原作者的百度网盘分享），如果不能正常下载可以使用本站下载
4.如果是64位系统，则重启机器，启动时候按住 F8，选择“禁用驱动程序签名强制”（注意目前这个驱动已经可以通过Windows Update正常获得，因此不再需要禁用驱动签名，更新一下驱动即可正常使用了）
5.确保手机电池电量充足，最好是满电状态。
1.正常开机状态下，在“设置-其他高级设置-开发者选项”中打开“USB调试”。电脑端按键盘Win+R（限Windows系统。Mac OS请出门左转），输入cmd回车，打开命令行窗口，输入cd C:\Mi2 Repartition回车。然后按顺序运行下图中的三条命令。注意运行命令时手机屏幕上是否提示操作权限，请给予允许：
#注释：运行命令时手机必须已获得完整root权限。开发版自带完整 root权限，如运行命令时手机屏幕上提示有程序被禁用root权限，进入“安全中心-权限管理-ROOT权限管理”中允许给予root权限再重新运行命 令。稳定版需自行处理获得完整root权限。稳定版系统如何获取完整root权限的方法请论坛自学
如下图所示
2.关机，按住音量-键，再短按开机键，进入fastboot启动环境。然后运行以下命令：
#注释：本命令在fastboot状态下擦除手机aboot逻辑区块中的数据
#注释：去掉aboot模块后，重开机才能已Qualcomm MMC Storage模式在PC上加载手机内部存储器</span
然后长按开机键约10秒，听到USB设备断开并重新加载的声音后松开电源键。此时会安装并加载Qualcomm HS-USB QDLoader设备驱动，让设备进入MMC Storage内部存储模式
#注释：需安装小米手机驱动（MiFlash线刷工具软件中集成），否则无法安装Qualcomm HS-USB QDLoader设备驱动
#注释：如安装Qualcomm HS-USB QDLoader驱动后，在Windows设备管理器中发现此设备前有黄色感叹号无法启动的情况，需在设备管理器中禁用此设备，断开并重新连接USB后， 在设备管理器中启用此设备，即可正常加载。此问题是PC系统驱动环境引起。
3.打开Paragon Hard Disk Manager 14，首次运行出现如下画面,选择箭头指向的按钮点击即可。
为了规避出现软件报告调整分区时发现cross-link files而拒绝操作报失败的情况，请按下图所示操作，强制让软件忽略文件系统完整性检查，即可顺利调整分区大小（图为HDM 15版本，与教程中使用的14版操作上无区别）
开始调整分区，划出用来合并到系统分区的空闲分区
然后执行合并系统分区的操作（下图是网络图片，跟上图有些差别，分区信息仅仅作为示意图）
同样点击 "Apply"之后等待合并空闲分区完成。
4.打开WinHex，在软件主界面按Ctrl-D打开硬盘克隆功能，严格按下图操作，然后确认写入操作。写入完毕后aboot分区数据即已恢复，可长按电源键约10秒正常开机进入系统了
#注释：“357410”是aboot分区在MMC存储器中的起始扇区号。这个aboot分区起始扇区号357410可在DiskGenius软件中选中aboot分区，在分区参数中看到，可自行验证。2和2S所有型号都相同，都填这个数
5.将之前放进sdcard中的resize_data文件移动到根目录/system/bin/中，试验中发现，/system 是只读的，无法拷贝进入，此时可以拷贝到 /目录下面也可以，两者分区相同，因此理论上面调整起来应该是一样的。（注意，目前尝试的小米2的特殊版本，到Android 5.0之后，已经不需要这个程序，系统启动后会自动调整分区）
平常Linux管理方面最重要的任务之一就是，检查文件系统的完整性。Linux文件系统有可能在各种各样的情况下受到损坏，比如系统崩溃、突然断电、磁盘断开，或者文件节点（i-node）不小心被覆盖等等。因此，定期检查文件系统的完整性是个好主意，以便尽量减小文件系统受到损坏的风险。而说到检查和修复Linux文件系统，fsck是一款实用的工具。
我在本教程中将介绍如何借助fsck工具，实现文件系统的自动检查。
系统一启动，就触发文件系统自动检查机制
如果你希望系统一启动，就自动触发fsck，那么有一些方法可以设置在启动过程中实现无人值守的fschk，这些方法具体取决于特定的Linux发行版。
在Debian、Ubuntu或Linux Mint上，编辑/etc/default/rcS，如下所示。
# 启动过程中，自动修复出现不一致性的文件系统
在CentOS上，使用下列内容，编辑/etc/sysconfig/autofsck（要是它没有，就创建）。
强制定期检查文件系统
如果文件系统很庞大，你可以强制定期检查文件系统，而不是每次系统启动时检查文件系统。为了实现这个操作，先要借助tune2fs命令，找到文件系统配置。下面这个命令行显示了文件系统相关参数的当前值。请注意：/dev/sda1是文件系统超级块所在的分区。
从tune2fs的输出结果中，我们不仅可以看到文件系统的状态（干净与否），还可以看到与文件系统检查有关的一些参数。"Maximum mount count"（最大挂载次数）这个参数是指文件系统检查被触发后的挂载次数。"Check interval"（检查时间间隔）这个参数显示了两次文件系统检查之间的最长时间。在大多数Linux发行版上，这些参数并不是默认情况下被设置的，这意味着并不进行任何定期的文件系统检查。
如果想强制每隔30次挂载就检查文件系统，请运行下面这个命令。
如果想强制每隔3个月就检查文件系统，请使用下面这个命令。
现在确认刚添加上去的文件系统检查条件已正确设置。
强制下一次系统重启时，进行一次性的文件系统检查
如果你想在下一次系统重启时触发一次性的文件系统检查，可以使用这个命令。
一旦你在类似上面的顶层目录（/）中创建了一个名为forcefsck的空文件，它就会在你下一次重启时，强制进行文件系统检查。系统成功启动后，/forcefsck则会自动被清除。
最近接到用户的投诉，在Windows 7 32位的机器上，UMDF驱动频繁崩溃，关键是SetUnhandledExceptionFilter 设置的异常过滤竟然一丁点用都没有，查询了半天，才注意到UMDF框架把UnhandledException接管了，你完全是无力反抗。
然后去MSDN上查询，根据Determining Why the Reflector Terminated the Host Process微软文档，WER会在“%windir%\system32\LogFiles\WUDF”目录下面生成DUMP文件，测试之后发现，是否生成完全依赖WER的心情，捣鼓到后来，干脆完全不生成DUMP文件了，另外他偶尔生成的也都是MiniDump ，作用有限。“Users\All Users\Microsoft\Windows\WER\ReportQueue”目录下面的报告数据，也是时有时无，阴晴不定。
继续Google，微软文档 Collecting User-Mode Dumps 设置如下的注册表
这样设置之后，正常的应用都可以在D:\Temp 下面生成崩溃记录，但是WUDFHost.exe 就是不能生成崩溃DUMP，貌似是WUDFHost.exe 用其他低权限用户账户运行，导致没办法生成转储文件。
继续Google，ProcDump进入视野，着实是个好的工具软件，非常好用。于是写了个批处理文件来跟踪WUDFHost.exe的异常。
应用崩溃的时候，会在当前目录下面生产对应的.dmp文件。
下面为简单的用法例子
有些软件可能要求系统的 Glibc 高于某个版本才可以正常运行。如果您的 Glibc 低于要求的版本，为了运行这些软件，您就不得不升级您的 Glibc 了 。您可以寻找已经编译好的 rpm 包或者使用源代码的方式升级 Glibc。
使用源代码方式升级 Glibc 是需要小心考虑的事情，因为整个系统几乎所有应用程序都依赖于原有的动态库，升级的时候，执行"make install"命令会打断旧的动态库链接，改为指向新的库文件。在这个过程中，不同的链接指向新旧不同版本的库文件，很容易导致系统崩溃，崩溃后，一般是无法重新启动的。
笔者使用的Linux发行版本是Mandriva Linux release 2006.0，其Glibc版本是2.3.5，内核版本是2.6.12-12mdk。由于某些需要，笔者必须升级原来的Glibc到更高的版本。经过实 践，成功使用源代码的方式安全地把Glibc从2.3.5升级到2.6。使用相同的方法，也能成功升级到Glibc2.4或Glibc2.5。成功升级 后，还可以在新旧不同版本的Glibc之间自由切换。
如果您需要阅读有关升级Glibc的文档，可以阅读Glibc 2 HOWTO文档，该文论述了如何从libc5升级到libc6，但是现在的Linux发行版的Glibc都已经使用libc6，更多的需要是在libc6 的范围内，从低版本升级到更高的版本。另外您可以阅读Linux From Scratch项目有关如何安装Glibc的文档。笔者认为最有必要阅读的是Glibc源程序目录树下的INSTALL和FAQ文档，INSTALL详细 描述了有关各编译选项的具体作用，FAQ回答了很多具体的问题。
为了安全升级Glibc，在升级前必须做好详细的部署和备份，即使是升级失败，系统也要能够还原为原来的状态。升级Glibc失败后，一般是无法重新启动系统的，必须使用另外一个可以启动计算机的Linux系统启动，挂载升级失败的根文件系统，恢复系统的Glibc为原来的状态。因此，准备另外一个可以启动 的Linux系统，是必需的。
准备好另外一个可以启动的Linux系统后，接下来的工作是编译Glibc。编译前要执行"configure"命令，用户可以根据自己的需要，加入不同的编译选项，编译选项在INSTLL文件里有详细的说明。如果是升级当前的Glibc， 必须使用--prefix＝/usr选项，该选项指定当前即将编译的Glibc作为系统的标准动态库，安装的时候，Glibc会修改/lib，/usr等 目录下的文件和链接。如果--prefix不是指向/usr，譬如--prefix=/glibc, 安装的时候，Glibc只会在/glibc目录下生成目录，文件以及链接，安装后的Glibc不会成为系统的标准动态库。如果不指定 --prefix，Glibc缺省认为--prefix=/usr/local，安装后的Glibc也不会成为系统的标准动态库。编译Glibc的时候需 要使用Linux内核的头文件，如果内核的头文件太旧，执行"make"的时候，可能会失败，这时可以在configure的时候，使用--with- headers选项指定新内核的头文件的所在目录。笔者的Mandriva Linux release 2006.0的内核头文件就不能令Glibc2.6成功编译，但是却能令Glibc2.4和Glibc2.5成功编译，使用--with-headers 指向新内核的头文件后，Glibc2.6也能成功编译，下文将会有详细叙述。
Glibc安装的时候，会直接修改/lib，/usr/lib等目录下的文件和链接，为了在升级失败的情况下能够恢复系统的Glibc为原来状态，在安装新版本的Glibc之前必须对一些重要目录进行备份，至于哪些目录需要做备份，下文将会有叙述。
备份好重要目录后就可以安装Glibc了，必须由root用户执行make install命令，不同的Linux发行版，可能会有不同的结果。笔者使用的Mandriva Linux release 2006.0在这个过程中会出现错误，并且输入任何命令都无效，重新启动也无法再次进入Linux系统。出现的这样的错误是由于Coreutils的命令 都是依赖于/usr/tls/目录下的链接文件，这些链接文件都指向原来的Glibc动态库文件，而/lib/ld-linux.so.2已经被改为指向 新版本的Glibc动态库文件了，这些重要链接分别指向新旧不同版本的库文件，导致了执行Coreutils的命令无效。这个时候，就要用另外一个 Linux系统启动，把/usr/tls/目录下的链接修改为指向新版本的Glibc的库文件。
经过上述修改，重新启动计算机，如果能重新 进入原Linux系统，表明到目前为止升级过程都是正确的。这个时候，要再执行一次"make install"重新安装Glibc，正常情况下，这次不会出现任何错误，安装结束的时候，Glibc会给出安装成功的消息。如果修改/lib/tls /下的链接后重新启动计算机仍然不能进入原Linux系统，表明这次升级失败，只能再次使用另外一个Linux系统启动，挂载升级失败的根文件系统，把先前备份好的重要目录恢复为原来的名字，经过这样的恢复，一般是可以重新启动升级失败的Linux系统的。
升级的最后一步是执行"make localedata/install-locales"命令安装时区和地区数据库。
本文介绍的方法在升级过程中会出现一次链接错误，系统无法输入命令，重新启动也无法进入Linux，必须使用另外一个Linux系统启动，并挂载原根文件系 统，修正在升级过程中产生的错误链接，然后才能继续升级。因此在升级之前，一定要先确保拥有另外一个可启动的Linux系统。此外，还要备份下文将会论述 的一些重要目录，如果最终升级失败，需要用另外一个Linux系统启动，恢复原Linux系统的Glibc为原来的版本。
建议在升级之前，详细阅读Glibc源代码包内的INSTALL和FAQ文件。
本文假设进行编译的用户名字是xyz，用户目录是/home/xyz/，所有源代码都在/home/xyz/build/目录下编译。所有源代码压缩包都已 经拷贝到/home/xyz/build/目录下。升级Glibc的Linux系统的根文件系统使用hda5分区，其文件系统格式为xfs。
准备另外一个可启动的Linux系统的方法有很多，可以在硬盘上安装另外一个Linux发行版，可以在DOS环境下使用loadlin.exe启动一个 Linux系统，最简单的方式是使用Live CD，从光驱启动。无论使用什么形式，它都必须能挂载需要升级Glibc的根文件系统。
如果选择Live CD启动，Knoppix是一个很好的选择。您可以从Knoppix的网站下载iso文件，烧制成启动CD，也可以把Knoppix的系统文件拷贝到硬盘 上，在DOS环境下，执行loadlin.exe启动。笔者使用了Knoppix 5.0.1，制作成Live CD启动。参考资料有介绍如何使用 Knoppix 进行系统恢复。
Glibc的编译安装与一般的软件很类似，都是要经过configure，make和make install三个阶段。Glibc不能在源代码目录下编译，必须在一个空目录下编译。
编译Glibc是需要内核头文件的，笔者的Mandriva Linux release 2006.0的内核版本是2.6.12-12mdk，可以直接使用该版本内核的头文件升级到Glibc2.4 和Glibc2.5。如果升级到Glibc2.6，在make过程中，会出现以下错误：
这是由于2.6.12-12mdk的内核头文件太旧，为了顺利编译Glibc2.6，必须使用新的内核头文件。
2.1 编译Glibc2.4或Glibc2.5
如果要升级Glibc到2.4或2.5，configure的时候只需要--prefix=/usr一个选项，意思是该Glibc将会作为系统的标准动态库。
以升级到Glibc2.5为例，执行以下命令进行编译：
glibc-2.5.tar.bz2是Glibc2.5的源代码压缩包，执行"tar xjf glibc-2.5.tar.bz2"命令后，在~/build/目录下产生了glibc-2.5目录树，Glibc2.5的源代码就在这个目录里面。 Glibc不能在源代码目录下编译，因此执行了"mkdir glibc-2.5-build"命令，生成glibc-2.5-build目录，编译Glibc2.5时产生的文件，保存在这个目录下。如果顺利，将会成功编译，不会出现错误信息。
2.2 编译Glibc2.6
如果您打算升级到 Glibc2.6，使用版本为2.6.12-12mdk的内核头文件是不能成功编译的，必须使用新的内核头文件。configure的时候使用 --with-headers选项指向新的内核头文件的目录。Glibc的FAQ文档明确指出最好使用最新版本的内核头文件，而且编译时需要的内核头文件 的版本不需要与当前正在运行的内核版本一致。笔者试验了版本为linux-2.6.20.7和linux-2.6.18两个版本的内核头文件，编译时系统 运行的内核版本是2.6.12-12mdk，都可以成功编译Glibc2.6。
为了使用新版本的内核头文件，解开新版本的内核压缩包后，在源代码目录下执行"make menuconfig"，这将会进入内核的设置页面，不需要作任何处理，直接退出并保存。然后执行"make"，不需要等待make完毕，一开始看到
就可以按下ctrl+c停止编译内核。执行"make"的目的是在内核源代码目录树内生成一些重要的文件和软链接，其中在include/目录下产生一个名为asm的软链接指向asm-i386目录，没有这个链接，Glibc2.6是无法编译的。
假设使用linux-2.6.20.7的内核头文件，执行以下命令：
linux-2.6.20.7.tar.bz2是2.6.20.7版本的Linux内核源代码压缩包，执 行"tar xjf linux-2.6.20.7.tar.bz2"命令后，将会产生linux-2.6.20.7目录，Linux内核的源代码都在这个目录下，其中内核头 文件在linux-2.6.20.7/include/下。确保linux-2.6.20.7/include/asm已经产生后，就可以停止内核的编 译，然后进行Glibc2.6的编译：
glibc-2.6.tar.bz2是Glibc2.6的源代码压缩包，执行"tar xjf glibc-2.6.tar.bz2"命令后，在~/build/目录下产生了glibc-2.6目录树。
如果您的系统当前运行的内核已经升级到比较新的版本，例如2.6.20.7，configure的时候，就不需要--with-headers选项了，与 Glibc2.4或Glibc2.5的configure命令一样，只需要--prefix=/usr选项就可以了，但是前提条件是/lib /modules/uname -r/source指向内核的源程序目录，您可以用以下命令查看它指向哪里：
3.1 哪些目录需要备份？
安装Glibc前必须备份好原来的系统动态库，一旦安装失败，使用另外一个Linux系统启动，挂载升级失败的根文件系统，还原Glibc为原来的状态。可是哪些目录需要备份？Glibc在安装的时候，将会修改哪个目录下的文件？
Glibc 在安装时可以指定install_root选项，命令Glibc把该选项指向的目录作为根，文件都安装到这个目录下，通过观察Glibc在这个目录里生成了什么目录和文件，我们就可以知道Glibc在安装的时候到底会修改哪些目录了。假设安装到~/build/system_fake_root上：
安装后：
可以看出，Glibc的make install命令会修改/etc，/lib，/sbin和/usr目录下的文件。这里最重要的是/lib和/usr。一般来说/usr目录下有很多文件，占用硬盘空间很大，实际也不需要对整个/usr目录备份，使用以下命令查看Glibc会修改/usr/下的哪些目录：
经分析，笔者选择了备份/lib，/usr/lib，/usr/include，/usr/sbin和/usr/bin。您当然可以备份更多的目录，不过笔者发现备份上述5个目录已经可以恢复系统的Glibc为原来的版本了。
3.2 备份目录
使用su命令切换为root。执行:
经过以上步骤，就备份了以后还原用的目录。备份的目录名字使用原目录名后加上.2.3.5后缀，目的是区分不同的Glibc版本目录。
3.3 如何还原系统的Glibc
如果升级最终失败，导致系统无法启动，就必须使用另外一个Linux系统启动，还原上述备份的目录为原来的名字。以笔者的系统为例，升级失败的根文件系统使用hda5分区，其文件系统格式为xfs，将被挂载到/mnt/m1目录。使用Knoppix 5.0.1 Live CD启动后，打开一个控制台，执行"su"命令切换为root用户，执行以下命令
执行上述命令后，Glibc已经被恢复为原来的版本，系统应该可以正常启动。
3.4 如何知道当前的Glibc版本
Mandriva Linux release 2006.0的动态库是Glibc2.3.5。执行"/lib/libc.so.6"可以知道当前的Glibc是什么版本：
从以上输出可以看到，当前系统的Glibc版本是2.3.5，使用Gcc4.0.1编译，编译时运行的Linux内核版本是2.6.12。
Glibc的FAQ文档给出以下程序用于查看当前的Glibc的版本：
把上述程序写到chk_lib_v.c文件，执行以下命令编译：
执行chk_lib_v后有以下输出：
3.5 注意Coreutils依赖的动态库情况
Mandriva Linux release 2006.0系统的/lib/目录下有个tls目录。该目录下的文件是能否成功升级Glibc到2.6的关键。使用ldd命令查看Coreutils的应用程序依赖的动态库情况可以发现：
请注意上述的librt.so.1，libc.so.6和libpthread.so.0，它们都是位于/lib/tls/，而不是/lib/。换言之，ls的执行，依赖于/lib/tls目录下的某些动态链接库文件。tls是thread-local storage，当不同的线程使用同一个全局变量的时候，各线程将会在本地保留该变量的备份，查阅参考资料可以了解更多有关tls的信息。 Glibc2.4，Glibc2.5和Glibc2.6都支持tls。
/lib/tls/下有以下文件：
/lib/tls目录下的文件是一些很重要的动态库及软连接，其中包括libc.so.6，它们都是指向2.3.5版本的动态库文件。
4.1 第一次make install
切换到root用户，执行make install就开始安装Glibc了：
在安装过程中，将会出现如下错误：
安装失败后，输入任何命令都是无效的，系统只会重 复"relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference"的错误信息，重新启动计算机在启动中就会失败，根本无法进入原Linux系统。
出现这样的错误的原因是 Coreutils的应用程序都依赖于/lib/tls/下的动态库，在make install的时候，/lib/ld-linux.so.2从原来指向ld-2.3.5.so被改为指向ld-2.6.so，但这个时候/lib /tls/libc.so.6指向的仍然是/lib/tls/libc-2.3.5.so。/lib/ld-linux.so.2和/lib/tls /libc.so.6各自指向不同版本的库文件导致了Coreutils的命令执行失败，从而make install也失败。
这个时候， 就要用另外一个Linux系统启动，挂载升级失败的根文件系统，把原根文件系统的/lib/tls/下的链接全部改为指向2.6版本的库文件，具体就是 /lib/tls/libc.so.6，/lib/tls/libm.so.6， /lib/tls/libpthread.so.0和/lib/tls/librt.so.1这4个软链接分别指向libc-2.6.so, libm-2.6.so，libpthread-2.6.so和librt-2.6.so。libthread_db.so.1仍然是指向 libthread_db-1.0.so，但这个时候/lib/libthread_db-1.0.so已经是Glibc2.6版本的了，原/lib /tls/libthread_db-1.0.so必须被替换为Glibc2.6版本的libthread_db-1.0.so。
笔者使用Knoppix 5.0.1 Live CD启动计算机，启动后，打开一个控制台，执行"su"命令切换为root，执行以下命令：
上述命令就是把原根文件系统/lib/下的libc- 2.6.so, libm-2.6.so，libpthread-2.6.so和librt-2.6.so拷贝到/lib/tls/下，并把/lib/tls /libc.so.6，/lib/tls/libm.so.6，/lib/tls/libpthread.so.0和/lib/tls /librt.so.1这4个软链接从原来指向2.3.5版本的库文件改为指向最新的2.6版本的库文件。原/lib/tls /libthread_db-1.0.so下的文件被/lib/libthread_db-1.0.so替换。
4.2 第二次make install
修改了/lib/tls/下的链接和文件后，就可以重新启动计算机，进入原Linux系统，这次将会正常启动，登陆后，执行Coreutils的命令，例如 ls，已经不会出现"relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference"的错误信息。由于Glibc2.6没有彻底安装完毕，我们还要重新执行一次make install：
这次make install将不会出现错误，如果安装成功，到最后会有以下信息提示：
执行/lib/libc.so.6查看Glibc的版本：
这都表明当前系统的动态库已经使用了Glibc2.6。
如果把/lib/tls/下的链接改为指向2.6版本的库文件后，重新启动计算机仍然无法进入原Linux系统，就说明升级Glibc失败，只能再次使用另外一个Linux系统启动，恢复原系统的Glibc为原来的版本，请参考3.3节。
4.3 安装时区和地区数据库
虽然现在系统已经使用Glibc2.6，但是在X Window下，使用fcitx中文输入法的用户会发现按下ctrl+space不会弹出中文输入框。这是因为新的Glibc2.6还没安装时区和地区数据库。执行以下命令：
上述命令将会在/usr/lib/locale/下生成一个名为"locale-archive"的文件。重新启动X Window, 按下ctrl+space就可以调出中文输入框并输入中文了。
至此，升级Glibc完毕。笔者在升级到了Glibc2.6的Linux系统上使用了 VMware，Openoffice，Mplayer，Skype，Firefox，Thunderbird，Vim，Fcitx等一系列软件一段时间， 未发现由于升级了Glibc而导致的错误出现。
回到Glibc2.3.5 成功升级后，想在Glibc2.6和原来的Glibc2.3.5之间切换是很容易的。因为安装前对Glibc2.3.5的重要目录进行了备份，只需使用另 外一个Linux启动，挂载原Linux的根文件系统，把升级前备份好的/lib.2.3.5等目录的名字改为/lib等原来的名字即可。
使用Knoppix 5.0.1 Live CD启动，打开一个控制台，执行"su"命令切换为root，执行以下命令：
重新启动，系统将会使用原来的Glibc2.3.5，Glibc2.6的目录备份为原目录名后加.2.6后缀。
总结
使用源代码升级Glibc，做好升级前的准备是最重要的。首先要准备好另外一个可以启动的，能挂载原根文件系统的Linux系统。其次是对/lib， /usr/lib，/usr/include，/usr/sbin，/usr/bin等目录进行备份。成功升级后，可以在高低两个版本的Glibc之间自 由切换。
升级前只要做好上述两个准备，升级系统的Glibc是安全的。
由于不同的Linux发行版的系统环境不一样，因此使用源代码升级Glibc的过程可能会有差异，为了成功升级，读者必须在升级过程中根据自己的系统的实际情况作相应的调整。
链接地址
这是VisualSVN Server Manager启动时报出的一个启动错误，可能的问题有以下3种。
1：端口被占用：使用CMD命令
查看端口是否已使用，如果已使用则更换一个端口。
2：Repositories 的物理目录不存在，重新设置Repositories 物理路径。
3：服务VisualSVN Server Manager 服务的启动用户设置不正确，在系统服务中，找到 VisualSVN Server 点击右键——属性——登录选项卡,如果是网络用户，就尝试切换到本地用户试试，如果是本地用户，就尝试指定一下其他用户试试。
今天在卸载一个软件时，发生错误，提示信息如下:
无法访问Windows Installer服务。Windows Installer没有正确安装时可能发生这种情况...
截图如下:
在网上找了下原因，都知道是Windows Installer服务出现了问题，如没有启动它呀，
启动不了Windows Installer呀之类的...却没有给出一个有用的解决方法。
好不容易知道微软提供了一个 Windows Fix it 服务，网址如下
http://support2.microsoft.com/default.aspx?scid=kb;%5BLN%5D;290301
或者
http://support2.microsoft.com/fixit/zh-cn
或者
Fix problems that block programs from being installed or removed
经过一番折腾，搞定！
目前（2018.03.14)貌似微软关闭了这个网站，可以在本站下载Microsoft Fix it 51015。
这个工具微软的下载地址为http://download.microsoft.com/download/D/9/7/D97359C4-B5EA-40C7-9991-3EEF14D4848F/MicrosoftFixit51015.msi
VS2010 IE11 下调试BHO控件,在新版本的调试器中已经简化调试流程，简单的设置一下，就可以直接调试BHO的DLL文件了，方便很多。
如下图设置，点击工程属性，然后选择 “调试”在“要启动的调试器”中选择 “Web 浏览器调试器”，在“HTTP URL”中输入具体的网站地址，然后直接启动调试即可。
BHO 通常并不提供其自身的任何用户界面 (UI)。它们而是通过在后台响应浏览器事件和用户输入数据来发挥作用。例如，BHO 可以拦截弹出窗口、自动填充窗体或为鼠标手势添加支持。
有一种常见误解认为工具栏扩展项需要 BHO.但如果将 BHO 与工具栏配合使用，则可以实现更丰富的用户体验。(关于IE工具栏的编程,在另一篇文章中说明).
BHO 的生命周期与它所交互的浏览器实例的生命周期相等。在 IE 6 和早期版本中，这意味着要为每个新的顶层窗口创建(和销毁)一个新 BHO。在IE 7中则是为每个选项卡都创建和销毁一个新 BHO。
BHO 必须实现 IObjectWithSite 接口, 该接口提供了两个方法GetSite和SetSite。根据MSDN的说明:
我们主要是对后者进行调用,此方法方便了与 Internet Explorer 的初始通信，并会在其将要释放时通知 BHO。我们实现此接口，然后将 BHO 的 CLSID 添加到注册表中，就可以创建一个简单的浏览器扩展。过程如下:
1. 在Visual Studio中,选择VC++中的ATL项目, 创建一个新的项目MySolutionPlugin, 在随后的向导中,确认Server Type是Dll, Visual Studio会为我们创建程序的模板.
2. 为该项目添加我们的程序主体, (不熟悉visual studio的同学在资源浏览器里的右键菜单里选 add-->class, 可别选到New Item), 类型选ATL Simple Object , short name命名为RayBHO,各项属性如下:
a) “线程模型” ---“Apartment”
b) “聚合”---“否”
c) “接口”---“双重”
d) “支持”---勾上“IobjectWithSite”。
具体的含义请参考MSDN.
一般来说，Internet Explorer 至少调用SetSite方法两次: 一次用于建立连接，另一次则是在浏览器退出时。我们 BHO 中的 SetSite 实现将执行以下操作：
•存储对站点的引用。在初始化期间，浏览器将 IUnknown 指针传递给顶层 WebBrowser 控件，然后 BHO 将对它的引用存储在一个专用成员变量中。
•释放目前被占用的站点指针。Internet Explorer 传递 NULL 时，BHO 必须释放所有接口引用并且断开与浏览器的连接。
要实现SetSite,我们需手工在添加一个public的方法:
STDMETHOD 宏是将方法标记为虚方法并且确保其具有适用于公共 COM 接口的调用约定的一个ATL 约定, 它有助于区分 COM 接口和该类中可能存在的其他公共方法。其实现成员方法时应相应使用 STDMETHODIMP 宏。同时我们需要声明一个私有变量来保存Browser的指针"
私有变量
然后是SetSite的实现
从上面的介绍我们知道, 初始化期间，浏览器将传递一个对其顶层 IWebBrowser2 接口(我们对其进行缓存处理)的引用。浏览器关闭时将传递 NULL,为避免内存泄漏和循环引用计数，此时释放所有指针和资源非常重要。最后，我们调用基类实现以便继续执行接口合约的其余部分。
加载DLL 后，系统将通过 DLL_PROCESS_ATTACH 通知调用 DllMain 函数。由于 Internet Explorer 大量使用多线程，因此，对 DllMain 的频繁的 DLL_THREAD_ATTACH 和 DLL_THREAD_DETACH 通知会降低扩展和浏览器进程的整体性能。
如果BHO 不需要线程级的跟踪，我们可以在 DLL_PROCESS_ATTACH 通知期间调用 DisableThreadLibraryCalls 以避免新线程通知的额外开销。修改DllMain.cpp 中的DllMain函数:
要使BHO工作,我们还需要把BHO 的 CLSID 添加到注册表中。此条目会将 此DLL 标记为浏览器帮助程序对象，并使 Internet Explorer 在启动时加载 BHO。我们可以在MySolutionPlugin.idl中找到该BHO的CLSID.幸运的,Visual Studio会帮助我们实现这些, 你看到:
您的机器的CLSID可能有所不同, 接着打开RayBHO.rgs文件,添加入:
这一段是为了在注册表里添加一个双字节的NoExplorer=1的键,不让Windows Explorer加载该BHO,因此该BHO只能在ie中运行.
注意，这里的UUID字段跟MySolutionPlugin.idl 中的是一致的。
你可以编译这个BHO. 如果一切正常, 你可以在IE的管理加载项里看到这个BHO.
如果不幸报错: 该BHO无法被注册,根据我的经验,原因大概有2类,可以依次检查
1. 你是否有管理员权限以修改注册表,如不是管理员身份,可以在菜单上右击Microsoft Visual studio 2008,从右键菜单中选择"运行方式"...
2. 你的注册表条目语法是否正确,或者含有非法字符.
1. 4-way handshake sequence
2. Key Heirarchy
The EAPOL encryption key is the middle 128 bits of the PTK value.
And the first 128 bits of the PTK (KCK), is used in the computation(and validation) of the EAPOL frame MIC field value (4way handshake Message 1/2).
3. EAPOL Frame format
4 Key Data Format
Key data may be zero or more InformationElement(s) (such as the RSN information element), and zero or more key dataencapsulation(s) (KDEs) (such as GTK(s)).
4.1 RSN Information
4.2 GTK
If theEncrypted Key Data subfield (of the Key Information field) is set, the entireKey Data field shall be encrypted. If the Key Data field uses the NIST AES keywrap, then the Key Data field shall be padded before encrypting if the key datalength is less than 16 octets or if it is not a multiple of 8. The paddingconsists of appending a single octet 0xdd followed by zero or more 0x00 octets.When processing a received EAPOL-Key message, the receiver shall ignore thistrailing padding. Key Data fields that are encrypted but do not containthe GroupKey or STAKey KDE, shall be accepted.
If the GroupKey or STAKey KDE is included in the Key Data field but theKey data field is not encrypted the EAPOL-Key frames shall be ignored.
5. Sample 4-way Handshake
5.1 Message 1
The Authenticator sends an EAPOL-Key frame containing an ANonce.
Key data is zero.
5.2 Message 2
The Supplicant derives a PTK from ANonce and SNonce.
The Supplicant sends an EAPOL-Key frame containing SNonce, the RSN information element
from the Association Request frame and a MIC.
MIC is the KCK (The first 128 bits in the PTK).
Key data is RSN Information.
802.1X authentication, CCMP pairwise dna group cipher suites.
5.3 Message 3
The Authenticator derives PTK from ANonce and SNonce and validates the MIC in the EAPOL Key frame
The Authenticator sends an EAPOL-Key frame containing ANonce, the RSN from its Beacon or Probe
Response messages, MIC whether to install the temporal keys, and the encapsulated GTK
Should the MIC data be same with the one in Message 2 ?!
Key data is RSN Information + GTK, and the data is encapsulated by using of the AES algrithm with the KEK(The middle 128 bits in PTK).
5.4 Message 4
To be added.
原始链接 http://blog.csdn.net/stevenliyong/article/details/6599528