Windows Boot Manager显示中文有些夸张，特别是中英文混合使用的时候，中文菜单项总是显得很长很长。
其实改成英文的很方便：
bcdedit /set {bootmgr} locale “en-US”
当然还要改所有含有中文的菜单项，不妨给它们起个英文名，如将”较早版本的Windows”改成“Windows XP”:
bcdedit /set {ntldr} description “Windows XP”
谁动了我的环境变量
突然之间，我的Visual Studio 6.0不能编译任何程序了，总是提示如下错误：
Making help include file...
Compiling resources...
Compiling...
Command line error D2004 : '/Zm' requires an argument
Error executing cl.exe.
就在约1个小时前还是可以的，而且这一个小时内我一直在看代码，并没有安装或卸载过任何软件。
查看plg文件，也没有什么异常。找到错误代码D2004相关的介绍，然后添加/Zm100选项，但错误照旧。
将整个Visual Studio目录copy到另一台Server 2008系统上，竟然是好的。也就是说问题并不是VS6本身，可能是系统环境或动态库的问题。
目前的系统之前已休眠过多次，上次重启约在一周前，还是因为无线网络没有反应才重启的，但在此之后直到现在一切都工作良好。第一反应就是该重启系统了，但在重启之前还想再调查调查，毕竟重启或许能消除问题，但并不能真正解决它。
即然VS6 GUI环境不行，那就尝试下makefile。结果makefile方式编译成功，意料之外！
就在进行makefile的cmd窗口中，查看了下环境变量，发现环境变量竞然是ifskit 2003的编译环境。重新打开了一个cmd窗口，结果还是ifskit 2003的环境，相当诡异。
我之前编译ext2fsd以创建browser文件时用过ifskit 2003，这个窗口到还是是打开的，并没有关闭。但它怎么可能会成为系统默认环境的呢？误操作？我并没有更改过环境变量！难道是系统出错？
百思不得其解之际，想起来之前explorer崩溃过一次，我只得重新加载了explorer.exe进程。随即打开procexp查看explorer.exe进程的Environment：
问题原来在这里！explorer崩溃时我一般会在taskmgr里重新加载explorer.exe，有时也会在cmd窗口里。而这次，却是在ifskit 2003的编译环境里加载的，结果此环境就被explorer.exe作为子进程继承过去了。然后Visaul Stuido 6.0作为explorer的子进程也继承了同样的环境，结果编译时用错了的编译器。
先验证一下，CTRL-ALT-DEL调出taskmgr，然后加载了一个新的cmd.exe，查看环境变量，确定是正确的，不再是ifskit 2003的编译环境了。然后以新的环境重新启动Vistal Stdio 6.0，尝试编译程序，编译成功，至此问题解决！
用Windbg替代VSJitDebugger
习惯了Windbg，准备用Windbg替代Vistual Studio的VSJitDebugger.exe来做Postmortem Debugger。但尝试了下面两种办法都没有成功：
- 1, Windbg –I （设Windbg为默认的debugger应对Unhandled User Mode Exceptions）
- 2, 直接改注册表:[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
直到在http://msdn.microsoft.com/en-us/library/ff542967.aspx里才看到，64位系统里对64位和32位程序有不同的设置：
1, A failing 64-bit application will be debugged according to the settings stored in the \\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug key.
2, A failing 32-bit application will be debugged according to the settings stored in the \\HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug key. However, if the Debugger value in this key specifies an application in the %windir%\system32 directory, Windows will look in %windir%\syswow64 instead.
将两处的AeDebug都设成Windbg后，分别对64位和32程序进行测试，Windbg被加载并成功attach到问题进程上。
D:\Documents> type AeDebug-Windbg.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
"UserDebuggerHotKey"=dword:00000000
"Debugger"="\"C:\\Program Files\\Debugging Tools for Windows (x64)\\windbg.exe\" -p %ld -e %ld -g"
"Auto"="1"[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\AutoExclusionList]
"DWM.exe"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug]
"UserDebuggerHotKey"=dword:00000000
"Debugger"="\"C:\\Program Files\\Debugging Tools for Windows (x64)\\windbg.exe\" -p %ld -e %ld -g"
"Auto"="1"[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\AutoExclusionList]
"DWM.exe"=dword:00000001
IE8 下载即崩溃
这几天Green Browser一直不老实工作，只要我点下载或另存文件就异常退出，升级成最新版本问题也没能解决。然后检查IE8，同样会出异常退出，看来是IE8的问题。
先禁掉可疑add-on插件，问题照旧，还是不能下载任何文件。启动IE8 w/o add-on模式，问题还是存在，这下快轮到我崩溃了。
调用Visutal Studio分析，发现问题在Wpc.dll模块中，stack trace如下：
Wpc.dll!WPCSecurity::CheckSID() + 0x1d bytes
Wpc.dll!CWpcSettings::Initialize() + 0x11 bytes
Wpc.dll!CWebSettings::Initialize() + 0x3a bytes
Wpc.dll!CWindowsParentalControls::GetWebSettings() + 0x68 bytes
> ieframe.dll!InitWPCSettings() + 0xeb bytes
ieframe.dll!CheckFileDownloadSettings() + 0x26 bytes
ieframe.dll!CDocObjectHost::CDOHBindStatusCallback::_ProcessCONTENTDISPOSITIONBindStatus() + 0x11d bytes
ieframe.dll!CDocObjectHost::CDOHBindStatusCallback::_ProcessSecurityBindStatus() + 0x7a6f0 bytes
ieframe.dll!CDocObjectHost::CDOHBindStatusCallback::OnProgress() - 0x15 bytes
urlmon.dll!CBSCHolder::OnProgress() + 0x40 bytes
urlmon.dll!CBinding::CallOnProgress() + 0x31 bytes
urlmon.dll!CBinding::OnTransNotification() + 0xfb50 bytes
urlmon.dll!CBinding::ReportProgress() + 0x2c bytes
urlmon.dll!COInetProt::ReportProgress() + 0x58 bytes
urlmon.dll!CTransaction::DispatchReport() - 0xa bytes
urlmon.dll!CTransaction::DispatchPacket() + 0x31 bytes
urlmon.dll!CTransaction::OnINetCallback() + 0x83 bytes
urlmon.dll!TransactionWndProc() + 0x28 bytes
user32.dll!_InternalCallWinProc@20() + 0x23 bytes
user32.dll!_UserCallWinProcCheckWow@32() + 0xd3 bytes
user32.dll!_DispatchMessageWorker@8() + 0xee bytes
user32.dll!_DispatchMessageW@4() + 0xf bytes
ieframe.dll!CTabWindow::_TabWindowThreadProc() - 0x32182 bytes
ieframe.dll!LCIETab_ThreadProc() + 0x4433 bytes
iertutil.dll!CIsoScope::RegisterThread() - 0x3227 bytes
kernel32.dll!@BaseThreadInitThunk@12() + 0xe bytes
ntdll.dll!___RtlUserThreadStart@8() + 0x23 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
ieframe.dll!InitWPCSettings() 尝试加载Wpc.dll，然后在Wpc中发生异常。Wpc.dll是处理Parental Controls的模块，对此了解不多，网上也没有多少介绍。
先找到我上次做的系统备份，是一个月前做的，竟然没找到这个文件，于是揣测是近期新装的程序或Windows update安装的。但到底是什么软件还很难去定位。
c:\Windows\SysWOW64>dir Wpc.dll
2009/07/14 09:16 308,736 Wpc.dll
c:\Windows\SysWOW64>dumpbin /headers wpc.dll |grep version
9.00 linker version
6.01 operating system version
6.01 image version
6.01 subsystem version
0 Win32 version
查看PE文件头，OS竟是6.1，资源中的版本号是1.0.0.1。这里要注意一点：Windows 6.1是Windows 7，Microsoft比较搞笑。我当前的系统是Windows Server 2008 AMD64，是Windows 6.0，就试着用另一台Visata AMD64的Wpc.dll替代这个，结果竟然正常运行。看来IE8 crash是这个Wpc.dll的问题。
再检查一下Vista系统的Wpc.dll
C:\Windows\SysWOW64>dir Wpc.dll
2008/01/21 10:51 296,960 Wpc.dll
C:\Windows\SysWOW64>dumpbin /headers Wpc.dll | grep -i version
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
8.00 linker version
6.00 operating system version
6.00 image version
6.00 subsystem version
0 Win32 version
Vista系统的Wpc.dll资源中的版本号也是1.0.0.1。看来二者是用同一source code分别针对Vista和Win7做的不同的编译。
同时将本系统的64位Wpc.dll恢复成Vista系统的，至此Green Browser/IE8下载又正常工作了。
CMD shell窗口是可以更宽的
今天刚发现原来Windows的 CMD(cmd.exe) 窗口可以调宽度的，对常使用vi看代码或用mutt读邮件的人来是个相当好的消息。打开CMD窗口属性，修改Layout里Windows Size的Width即可。
我虽是个Windows平台上的程序员，除Vistual Studio外，Cygwin和WinDDK也同样是必备工具，差不多天天都会用到。但在CMD窗口下用vi和mutt的体验并不怎么好，特别是看Windows代码，80字节宽的窗口限制让代码看来起很乱，所以我一般会用gvim。
现在可以在CMD窗口里用vim –On分屏打开两件文件了。
用WinDDK环境build MFC程序
WinDDK的source/makefile编译支持batch command方式，相当方便。实际上用它来编译MFC程序也是可能的。但要注意一点：对使用UNICODE程序，要设置USE_MFCUNICODE=1，不是USE_MFC=1。用错地话link会搞错入口函数，你的程序运行时就会报Access Violation.
庞大的Visual Studio Ide环境或SDK程序包可以不用在安装了。
Z:> type .../test/sources TARGETNAME=test TARGETPATH=obj TARGETTYPE=PROGRAM
SOURCES= test.cpp test.rc
C_DEFINES=$(C_DEFINES) -D_UNICODE -D_AFXDLL INCLUDES=.;..\sys\;$(DDK_INC_PATH);$(SDK_INC_PATH);$(MFC_INC_PATH);$(INCLUDES)
TARGETLIBS=$(DDK_LIB_PATH)\user32.lib \ $(DDK_LIB_PATH)\kernel32.lib \ $(DDK_LIB_PATH)\comctl32.lib \ $(DDK_LIB_PATH)\ws2_32.lib
USE_MFCUNICODE=1 PRECOMPILED_CXX=1 PRECOMPILED_INCLUDE=stdafx.h