今天突然发现系统事件："Stormser 服务成功发送一个 开始 控件。"查这个服务，指向的是C:/PROGRA~1/RINGZS~1/STORMC~1/Stormser.exe，在暴风影音的安装目录中。这个文件的创建时间是2008年6月29日, 13:22:31，修改时间是2008年6月20日, 12:35:42。还有个刚创建的10001的目录，以及目录内的33.3MB的Storm3up.exe文件，创建时间都是2008年6月29日, 13:22:42。也就是说，暴风9天前弄出了Stormser.exe这个用于后台偷偷升级的文件，然后在我今天打开暴风看电影时，偷偷给我装上了Stormser 服务，并从暴风网站上偷偷下载了升级包。

注意：这一切都是偷偷进行的，深得“流氓软件”的真传！

暂时处理：停止该服务并sc delete stormser。以观后效。

汉芯一号曾经的定义：“汉芯一号”采用国际先进的0.18微米半导体工艺设计，在只有手指指甲一半大小的一个集成块上有250万个器件，而且具有32位运算处理内核，每秒钟可以进行2亿次运算。经过国内权威专家验证，认为这一成果接近国际先进技术，在某些方面的性能甚至超过了国外同类产品。

事后证明：这是一个集体性的科研造假和学术腐败事件。
汉芯事件无人负法律责任。

造假者：高智商。（有没有高学历？）
伙同造假者：高智商人群被money收买下的集体无意识。

结论：学术界的潜规则。

我初次听闻“汉语编程”是在很久以前，当时就觉得不可以思议，当然是从纯技术角度而言。我干编程有些年了，虽然没有拿到什么高级证书，但对于编程也自认为有一定的理解。编程不用英语或法语，改用汉语，这只是将人机沟通的表述符号变成另一套符号而已。可是最终CPU也只能执行0或1这样的机器码啊！那些多线程问题、事件响应问题、网络通讯问题、操作系统调用问题、数据访问问题、各种数据结构和算法，以及代码的可维护问题，还是需要程序员去思考，去编码。也许做汉编工具的公司能够提供全面的、细致的、用中文编写的开发文档，但这只不过是降低了程序员掌握编程的语言难度而已。直觉告诉我：汉语编程只是个华丽的包装，这些只会是一场闹剧。

没想到闹剧越演越大了。今天看到一篇文章：汉语编程将刻进长城“中华爱国功德榜”，就彻底让我惊诧莫名了。如果将所谓汉编这个包装刻到民族的骄傲－－长城上，那将是对真正程序员的一个无情嘲弄。难道是我误解汉编了？

于是我第一次去到汉编网站上看，想见识一下汉编到底有何神奇之处。首先看了编程环境的介绍－－图片都打不开，感觉就是一套简单的IDE；然后看了编程手册，觉得本质和C/C++/Java/Pascal的手册没有什么本质差别。如果说有不同，那就是感觉程序代码的写法非常奇怪，令我不适应。

我也不能妄下结论，于是下载了"市长信息管理31000.rar"，释放出一些chp, dll, exe文件，还有几个dbf和BAK文件。特别抢眼的是WINCON.DLL这个文件，于是到知识的海洋中畅游了一下，找到了http://www.itfact.net/read.php?68“徽剑: 汉语编程-汉芯之后的中国软件界大骗局”这篇文章。文中点出了WINCON.DLL的玄机。正是这个WINCON.DLL，暴露了所谓汉编的真实面目：“汉语编程就是win32forth的一个修改版！”

看来汉编这个包装非但不华丽，反而是丑陋的！

我特意按照该文的内容，删除了WINCON.DLL，然后运行汉编的sample 市长查询.exe，看到了win32forth对汉编发出的莫大嘲弄："missing procedures!"

 查看全文

中国式造假之一-华南虎事件今公布结果

于2007年10月12日开始出现的华南虎悬疑照片，在耗费8个月后，公众终于等来了迟到的公正--今天陕西省官方正式宣布照片是假的；当事人之一的周老虎已被逮捕。

感叹：
1. 胆大妄为的造假者－－居然敢以自己的脑袋担保；
2. 聪明的造假者，知道没人能要他的脑袋；
3. 贪婪的造假者，无一不为追名逐利；
4. 沆瀣一汽的地方政府官员；
5. 碌碌无为的主管政府官员；
6. 看不见的潜规则

最后要赞一下：
1. 勇敢的质疑者，也是敢以自己的脑袋担保－－凭借的是自己的知识！
2. 强大的民意，不再是可以被随意强奸的！

试图解决注销/关机速度很慢的问题
原因是早就知道的：注销时一个应用程序或服务还在使用此注册表
解决办法也是早就知道的: uphClean
没想到的是：安装之后，效果非常好！以前注销需要等待一分钟以上，现在几秒内就能完成注销了:)

用uphClean UPHClean-Setup.msi 吧！

MS网站已经需要认证才能下载。

关键词: 适配器和绑定 NetBEUI协议

XP+SP2每次访问//server网络资源，都需要等待16秒后，才能打开服务器上的共享目录窗口。咬牙忍了又忍，终于忍不下去了。动手解决吧...
1)怀疑是WebClient的问题。ref: http://support.microsoft.com/kb/832161/zh-cn
可实际上SP2(甚至SP1)就已经解决了此问题。在我的计算机上，Web Client Network已经处在了"网络提供程序"的第三位。
2)还有提到Explorer\RemoteComputer\NameSpace注册项的问题。ref: http://hi.baidu.com/36933699/blog/item/c86588fd20c8951208244d15.html
看看我的NameSpace下的项，发现子项{D6277990...早已被修改为-{D6277990...了－－看来很早以前咱就想解决这个问题，可没解决了:(
虽然如此，但还是不死心，将令一个没有改名的子项{2227A280修改为-{2227A280，重启了几次计算机，对比测试，发现无效！
3)还想到"删除共享文档"的方法：注释了Explorer\MyComputer\NameSpace\DelegateFolders下的一些子项，也没有效果！
4)最后找到解决办法：
网络连接->高级设置->适配器和绑定->本地连接->去掉 网络文件共享和网络客户端下的 "NetBEUI协议"。确定后无需重启，访问速度就提高了，只需要等待3-4秒即可。

set FILE_FIX=unknown
set FILE_FIX=%DATE%
echo %FILE_FIX%

以上脚本执行结果将显示：
2008-06-10

如果将以上脚本包含于IF语句中：
set FILE_FIX=unknown
IF EXIST user.dmp (
 set FILE_FIX=%DATE%
 echo %FILE_FIX%
)

执行结果将显示为：
unknown

以上区别的原因在于“延迟环境变量扩充”特性。未启用该特性前，CMD读入完整的IF语句，同时将变量替换为变量的值，因此实际执行的是：
set FILE_FIX=unknown
IF EXIST user.dmp (
 set FILE_FIX=%DATE%
 echo unknown
)

该特性的启用方法有两种：

1. 以/V:ON 参数启动CMD脚本解释器
2. 在脚本中执行SETLOCAL ENABLEDELAYEDEXPANSION

最近可以登录传说中的ORACLE METALINK了。兴奋之余，又有压力：这么多的资源，责任也很重大啊！

关键字: HeapAlloc 0xC0000005 Access Violation

对于new/delete，CRT最终调用HeapAlloc/HeapFree来实现。

最近发现一个很早以前开发的程序偶尔会出现奇怪的0xC0000005异常。用drwtsn32日志定位到以前的一个DLL中：该DLL调用了NTDLL的0x7C9305D4处的代码，然后就出现了异常。对该处代码进行分析，发现是HeapAlloc的入口。

用debug版本的DLL运行程序，捕获到异常，stack显示是new调用HeapAlloc时出现异常。看到CRT源码中有#ifdef _MT，感觉跟多线程有关；查DLL工程设置：使用的是单线程运行库。

好久没有用VSS了。今天重新操刀安装配置：

1. 选择一台服务器，安装VSS软件和VSS6-SP6-enu.exe补丁；
2. 共享服务器上的Program Files\Microsoft Visual Studio\Common\VSS目录－－这个目录内已经有一个VSS DATABASE了；
3. 在服务器上通过VSS Admin工具创建VSS帐号，修改admin的空口令；
4. 如果要按project授权，需要在options中选中"Enable project security"；
5. 最后还要创建一个供远程登录的用户，并将VSS目录及子目录的完全控制权限授予该用户，否则远程VSS登录将出现奇怪的错误。

昨晚回家，开门就闻到扑鼻的异香－－不用说，是已含苞半个月的巴西木开花了！

今日早起，发现花瓣已经闭拢－这是要等到下午再行绽放。

有两个，一个是众所周知的at命令；还有一个是更高级的、替代at的schtasks命令。

C:>schtasks /?

SCHTASKS /parameter [arguments]

描述:
允许管理员创建、删除、查询、更改、运行和中止
本地或远程系统上的计划系统。替代 AT.exe。

参数列表:
/Create 创建新计划任务。

/Delete 删除计划任务。

/Query 显示所有计划任务。

/Change 更改计划任务属性。

/Run 立即运行计划任务。

/End 中止当前正在运行的计划任务。

昨天痛杀病毒、痛杀恶意插件后，小黑运行正常。

但今天上午突然蹦出提示：RUNDLL32: 找不到system32\dc1.dll文件。让我大惊失色：难道还有隐藏很深的注入点？

立即检查：

1. 用procexp查进程命令行为rundll32 C:\WINDOWS\system32\dc1.dll,Always 于是在注册表中搜索dc1.dll未果；搜索,Always 也无结果；
2. 查rundll32进程的父进程为svchost.exe -k netsvcs，在注册表CurrentControlSet\Services下查找netsvcs，找到很多，逐一检查，突然眼前一亮：Task Scheduler －－一定是它!
3. 转到任务计划，有一个5c1的任务计划，下次运行时间是10:01:00, 2008-05-14
4. 不用多说，立即删除5c1计划。
   C:>schtasks /delete /tn 5c1
   警告: 确实要删除任务 "5c1" 吗 (Y/N )? y
   成功: 计划的任务 "5c1" 被成功删除。

现在的黑客，点子挺多的 PF

正看电脑屏幕，突然感觉头晕，摇摇头发觉头还晕，就知道是地震了。抬头看窗外，发现窗帘也在摇晃。

大楼的大部分人立即疏散到地面：

摄自北京

昨天冒险上网寻找文件下载，结果碰到病毒了！虽然在第一时间kill了可疑进程，但IE会弹出广告页面，用HijackThis检查发现有个pctools.dll的BHO。

首先用改名法，删除了pctools.dll文件，但用HijackThis无法删除注册项。
怀疑是有driver保护，就去寻找可疑driver。注册表中的driver太多，就到system32\drivers目录中寻找修改时间最近的文件，结果找到了acpidisk和NetBI0(是零不是大写字母O)S这两个驱动。

删除驱动后，重启计算机，发现有RunDll32提示找不到某个DLL，于是到system32目录中寻找修改时间最近的文件，删除了可疑的文件。再检查IE BHO，发现还是无法删除BHO设置项。

于是手工到注册表中搜索pctools.dll项，删除时提示无法删除！一番折腾后，找到原因：原来是病毒制造者设置了拒绝的权限！对症下药，很快就删除了BHO相关的注册项。

最后剩下rundll32的问题了。在RUN启动项中没有找到，只好搜索注册表，发现了隐藏在policies\Explorer\Run中的两个入口3eab.dll和dc1.dll，处理之。

病毒凶猛！我是个IT人士，懂得一些计算机的基础知识，没有造成太大的影响，但一番折腾就浪费了我2个小时的时间！。如果是不懂计算机的普通用户呢？

想想还是下载了传说中的360卫士，发现很好用！这个工具还发现了以前我手工对付病毒所留下的文件和注册表痕迹。看来以后的安防工作就靠它了:)

想看排球1/4决赛，昨天9点准时登录奥运抢票网站，顺利地把票放到票篮子里，心说这改版的票务系统看起来很强劲嘛－－然后喜滋滋地去支付～结果却开始了一次史上最为漫长的一次次等待：“处理中，请等待。我们正在处理您的请求，请稍候。请不要刷新页面或者点击后退键。”

页面几秒就自动刷新一次，不一会IE历史中就充满了“处理中，请等待...”的记录。只好一边干活，一边偷看抢票结果。最后页面总算出来了，结果却是处理失败，于是只得从头再来！

抢了一上午，直抢得1/4决赛票也没了，我也没抢到。

下午买了3张小组赛的门票～虽然等待时间也很长，但总算买到了～

甚幸至哉

养了4年的巴西木，开始发花芽了！期待着花朵盛开！

今年会是个好年景～～～

紧张建设中的央视大楼－－远看有点像个大铁裤衩

Windows XP上IIS ASP使用Oledb方式连接Oracle10g数据库，提示错误：

ADODB.Connection (0x800A0E7A)
未找到提供程序。该程序可能未正确安装。
Error Type:
ADODB.Connection (0x800A0E7A)
Provider cannot be found. It may not be properly installed.

普通的应用程序却能正常访问数据库。以前的ASP用的是8i的client和server，从未遇到此问题。

后来找到原因：是Oracle目录的授权问题。

解决办法：将文件夹Oracle_HOME(如: D:\oracle\ora10g) 对IUSR_XXX用户进行授权，而且要选中：替换子目录权限。

另外，特意测试如下：

很诧异－－工业和信息化部清算司负责人16日说，“通过大量详尽调查，高额吸费基本不存在可能性，这是不法分子为推销所谓群呼设备利用互联网所做的欺诈性宣传，公众应谨防受骗上当。”

他提到：“用户只支付从自己号码到拨打的显示电话号码之间的费用。”

他还提到有关部门测试了65个号码，无一有收费问题。

实在不知道该说些什么。于是等待。

到18日 北京市公安局证实"回拨高额吸费"电话确实存在。

再继续等等，看看到底孰是孰非。。。

java虚拟机版本为1.4.2。启动java的数据库应用，立即报ORA-00600错。
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []

trace文件部分内容：
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
...

System name: Linux
Node name: orasrv
Release: 2.6.9-34.ELsmp
Version: #1 SMP Fri Feb 24 16:54:53 EST 2006
Machine: i686
...

ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Current SQL statement for this session:
SELECT VALUE FROM NLS_INSTANCE_PARAMETERS WHERE PARAMETER ='NLS_DATE_FORMAT'

最后发现是路径中另有一个jar包，大小是1,932,480 字节，其中的修改时间都是2000-9-14，其实就是8i下面的classes12.zip 文件！

删除这个坏事的jar文件后，问题得到解决。

有一个建好的数据，Oracle 9.2.0.4 for linux，字符集是缺省的WE8ISO8859P1，没有改成ZHS16GBK. 库中暂时没有任何数据。

由于字符集不是超集/子集关系，无法通过ALTER DATABASE CHARACTER SET修改字符集。

当时时间紧张，就没有重建数据库，而是直接修改prop$表，将NLS_CHAR字符集改为ZHS16GBK。
update props$ set value$='ZHS16GBK' where name='NLS_CHARACTERSET';
重启后建表、insert数据，一切正常。。。直到今天要exp出数据。

执行 exp userid=system owner=username ... 报错!
即将导出指定的用户…
. 正在导出 pre-schema 过程对象和操作
. 正在导出用户 USERNAME 的外部函数库名称
. 导出 PUBLIC 类型同义词
EXP-00008: 遇到 ORACLE 错误 6552
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
EXP-00000: 导出终止失败

隐隐感觉与当时的字符集设置有关。http://www.eygle.com/special/NLS_CHARACTER_SET_03.htm: “正式修改字符集时，Oracle至少需要更改12张数据字典表，而这种直接更新props$表的方式只完成了其中十二分之一的工作，潜在的完整性隐患是可想而知的。”

但是如何解决呢？后来搜索到未公开的INTERNAL_USE用法，强制完成字符集一致化，解决了问题。

喜欢看科普书籍。书中谈到光。

• 费马猜测：光总是走最短的路，或者说光总倾向于花最短的时间。
• 中学里学到的折射定律说：入射角和折射角间存在一个简单的关系 sinA/sinB=k

这两者之间有什么关系吗？

于是画了一个平面坐标图，写出在不同的入射点下，光从起点到终点时，需要花费的时间。这是一个入射点坐标的函数；于是动用很久没有用过的高等数学知识求倒，得到时间极值点的条件正好是：折射率k=sinaA/sinB

数学真有趣，不是吗？

有时计算机应用程序事件日志不停地出现大量的 HHCTRL id=1903 的事件：

• 事件 ID ( 1903 )的描述(在资源( HHCTRL )中)无法找到。本地计算机可能没有必要的注册信息或消息 DLL 文件来从远端计算机显示消息。部分事件包含了下列信息: http://go.microsoft.com/fwlink?LinkID=45839.
• The description for Event ID ( 1903 ) in Source ( HHCTRL ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer.

今天总算找到原因了：

• 当 TightVNC 1.3dev5 以服务运行时，在应用程序日志中，每5秒就会记录两条 HHCTRL id=1903 的事件。
• 当 winvnc.exe 以普通进程运行时，就不会有这个问题，但'Send Ctrl-Alt-Del'功能将不可用。
• 卸载1.3dev5 ，安装1.3dev6，结果同上。

听说用 RealVNC 就没有这个问题。待测试。
还有是不是可以修改 TightVNC 的部分代码然后重新编译呢？待测试。

这是榆钱树吗？

最近“响一声电话”诈骗泛滥成灾。运营商没有、也不愿对这种诈骗进行查处。

我想是否可以由过去的信息产业部，也就是新成立的工业和信息化部从收费政策上进行规范：呼转到信息台时，产生的信息费不是由主叫承担，而是由设置呼转方来承担。

举例：A号码设置呼转到信息台B；A拨打用户C，响一声就挂；C看到有未接电话A，于是拨打号码A，结果被转接到信息台B。

对C的收费分析：是否收取信息费？
A: 不应该向C收取信息费。理由：C并不知道呼叫被转接到信息台了。由C支付信息费，会侵犯C的知情权。而A是知道呼叫自己的电话都会被转接到信息台的；如果A不希望负担信息费，则A完全可以不设置呼转到信息台。因而由A负担信息费是合情合理的。

这样是否能根治“响一声电话”电话诈骗呢？

问题是这样的：一个InstallShield做的安装程序，在2000/XP上能正常安装，在Windows Server 2003 Standard Edition也正常，但在Windows Server 2003 Enterprise Edition中则表现得很怪：一些共享的DLL只能被安装用户所使用，其它用户登录启动程序时，报找不到DLL的错误。

查了一下这些DLL，发现没有安装到正常的C:\WINDOWS中，而在C:\Documents and Settings\Administrator\WINDOWS中。

查InstallShield工程得知安装目标为 <WINDIR>；

查<<MSDN>>得知：
在终端服务的多用户环境下，GetWindowsDirectory()返回的是每客户的window目录名。
GetSystemWindowsDirectory()能在多用户环境下获取共享windows目录名。

后来采用了简单的办法：修改InstallShield工程，将安装目标指向 <WINSYSDIR>.