分类： 草草笔记

【阅读提示】

本文成文于2015年12月，距离现在屏幕前的你看到已经过去了很久，内容仅供参考。

 

BAT（百度、阿里、腾讯）的软件素以流氓著称，然而有时因为很多原因，不得不使用他们的软件。然而用就用吧，还经常被其骚扰，QQ的自动更新进程就是一例。

如果你使用的是Windows Vista及以上版本的Windows系统，并且开启了（或者没有关闭）UAC（用户账户控制），那么在平常使用QQ的时候，下面的对话框你一定经常见到：

（图片来自网络）

这东西烦人到什么程度呢，如果你点击「否(N)」或者直接关闭它，那么每个小时它都会蹦出来一回炫耀存在感，不管QQ开没开。

最要命的是，腾讯可能用了一些非常规的手段来试图启动和保护这个自动更新进程，如果直接对其进行删除，或用建立同名空文件夹的方式，下次你的QQ可能就没法用了，会要求你重装。

经过搜索，终于找到一种（或许）一劳永逸的方法来将其屏蔽、同时又不会让QQ弹窗报错的方式。以下方法来自网络，以Windows 7为例。 继续阅读 “Day 3593 一劳永逸地禁止「QQ安全防护更新进程」” →

某公司给开发的软件，非要将机器上的Office替换成2010版本，然而2010版除了KMS（虽然有自动的）似乎没有像早期版本那样永久破解的，郁闷。

总之，使用KMS激活工具（如KMService、Office Kit之类）如果出现0x8007000D错误，按以下步骤尝试：

1. 使用VLK（Key Manager Office 2010 VL）写入大客户密钥后再试。
2. 重置激活次数（Rearm），注意每次重装Office 2010后只能重置4次。
3. 如果仍然失败，删除以下注册表键值，然后『修复』安装（此时可能无法卸载）Office 2010即可：
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform

2015-11-26追加：如果本机之前安装的是Office 2013等高于2010的版本，则在安装2010后可能无法用以上工具进行正常激活，此时需要在安装完成后，删除以上注册表键值，然后进行修复，并按照提示重新启动，然后启动任一Office组件（如Word），按照提示接受协议并等待配置完毕，然后再进行激活即可。

新买了一个USB蓝牙适配器，实在是受够了之前买的便宜货无法跟BlueSoleil破解版好好协同工作了，于是买了个号称是Broadcom正版芯片的。

结果死活装不上驱动，由于系统是新装的，所以以为是硬件有问题，再拿到其它机器上，安装和使用都一切正常。

被折腾了三天，期间设备管理器给出的最多的提示是：

在安装该设备时出现错误：
这个设备的驱动程序安装文件丢失一个需要的项。这可能是由于 INF 是为 Windows 95 或更新版写的。请与您的硬件供应商联系。

仔细检查过驱动的版本，确定是Windows 7 x64的，找了很多解决方案都不行。

折腾到第三天，看到有个类似的蓝牙设备不识别的问题，里面提到\Windows\inf\key.inf损毁导致的问题，恢复之后就安装成功了，想起之前也有个类似的帖子提到bth.inf，但是给出的解决方法是删掉bth.inf和bth.pnf，然后重启让系统自行更新这两个文件，当时进去找的时候就只看到PNF没看到INF，但没想到缺了并不会自动补回来。

找到bth.inf放进去，重新刷新硬件，立刻就安装成功了。

虽然我还是想不通为什么新装的系统会缺少一个基础文件……

问题：

Windows XP系统启动后，（如果设置了本地连接/其它任何网络连接在任务栏上显示图标）网络连接图标半天也不出现，此时右键单击网上邻居，选择「属性」也没有反应，需要最短等待大约30秒（较新的机器）至10分钟（比较老的机器）才能正常使用网络功能。此时，如果使用「带网络连接的安全模式」启动，则不存在这个问题。

原因：

通常在安装了.Net Framework 4.0的Windows XP中出现，原因是安装该运行时后，系统会增加一个名为「Microsoft .NET Framework NGEN v4.0.30319_X86」的服务，该服务用于在系统启动时用最长10分钟的时间将高优先级的.Net程序编译为本机映像，以提高运行效率，但在较慢的机器上会严重拖慢启动速度（.Net的运行效率问题）。

解决：

1. 直接禁用服务：启动服务管理器（开始-运行-services.msc，回车），找到「Microsoft .NET Framework NGEN v4.0.30319_X86」并将其启动方式修改为「手动」。
2. 提前让NGEN干完活：以下方法来自此帖子，因为不如直接禁用服务方便，请有需要者自行翻译：

1) Run cmd.exe from Start > Run
2) Type cd\
3) Type cd Windows\Microsoft.NET\Framework\v2.0.50727
4) Type NGEN executequeueditems and press Enter
5) It will take about 10minutes depending upon system speed. After the process is complete, the following prompt will appear in the command prompt
C:\Windows\Microsoft.NET\Framework\v2.0.50727>
6) Type exit to close the command prompt.
After performing these steps, your computer will boot up at usual speed.

最近给单位写了一个内网用的工资条查询页面，结构很简单：财务人员将从集团财务系统中导出的Excel表格上传，处理后为每位员工建立账户（当然已存在的不会重建，重名的也有处理方案，因为和主题无关不详细展开），建立对应年月数据表并填充数据，员工使用账号密码登录后可查看自己的「电子工资条」。做这个东西的初衷据说是财务不愿意打印纸质工资条了，ft。

整套程序中其他部分都是基本的PHP+MySQL流程，唯独如何对Excel表处理是个难点，必须要感谢PHPExcel，使得读取Excel表格不再是最困难的部分。在编写表格读取代码的过程中，还发现了PHP一个有趣的特性：

　　在处理字符变量的算数运算时，PHP 沿袭了 Perl 的习惯，而非 C 的。例如，在 Perl 中 $a = ‘Z’; $a++; 将把 $a 变成’AA’，而在 C 中，a = ‘Z’; a++; 将把 a 变成 ‘[‘（’Z’ 的 ASCII 值是 90，'[‘ 的 ASCII 值是 91）。注意字符变量只能递增，不能递减，并且只支持纯字母（a-z 和 A-Z）。递增／递减其他字符变量则无效，原字符串没有变化。

——PHP文档《递增/递减运算符》

也就是说，如果要以列为单位递增读取表格中的内容，无需手工编写代码处理列名称（Excel的列名称是A、B、C……AA、AB、AC……XFD之类，不同版本的Excel末列名称不同，但都是1-3个字母的顺序组合），只需要使用类似下面的代码即可：

……
for($col = 'A'; $col < 'ZZ'; $col++) {
$phpExcel_Sheet -> getCell($col.$row);
}
……

一番努力后，程序已可以正确处理财务部早先给出的样表，但是由于本单位的特殊情况，还有另一套工资表要处理，这个版本的工资表格式上与先前的样表无异，只是工资项目比较多，即：先前的样表最大到Z列，而另一版本的最大列为AW。

由于PHP没有简便的方式将关联数组按索引进行读取（话说为啥不支持？），程序中拼合最终入库的数据时是这样处理的：

……
$lastcol = array_keys($xls_itemname)[sizeof($gz_itemname)-1]; //获取末列Key
foreach($xls_data as $data_row) {
for($col = 'E'; $col < $lastcol; $col++) {
$json_array[$xls_itemname[$col]] = $data_row[$col]; //为生成类似 {'基本工资':'800.00', '岗位薪酬':'1000.00',...}这样的JSON做准备
}
$json = json_encode($json_array);
……
}
……

结果，以上代码在处理第一批样表（末列为Z）时工作良好；但到了第二批样表，上传后直接运行超时，将debug信息打印出来，发现虽然$lastcol的值正确取到了AW，但程序在处理到AW列后并未停止，一路飙到了不知道哪里去，直到达到PHP的最大运行时间被掐断为止。

调试了很久都不知所措，最后只好用另一种方式进行临时补救：

……
//不再取$lastcol
foreach($xls_data as $data_row) {
for($col = 'E'; $col < 'ZZ'; $col++) {
if(isset($xls_itemname[$col]) == FALSE) break; //当取到未定义的列名时跳出
……
}
}
……

这种方法的运行效率想必比较低，但是至少可以正常运行。

猜测与PHP特殊的字母递增运算的实现有关系，但是我还是不知道为什么。

当三星840 EVO SSD（120G，估计与容量没关系）与Windows 7 x64配合使用时，在极其罕见的情况下，会导致选择电源菜单下的「睡眠」后，未进入睡眠状态而立即返回登录界面，即屏幕只黑一下然后立刻就回到登录界面。

解决方法：将页面文件设置为「无页面文件」，重启后再重新建立页面文件即可。

上次出现这个问题是今年3月，五个月后的今天又来一遍，因为之前用机械硬盘时从未见过这个问题，所以怀疑与SSD有关，但也不敢确定。

2015-09-03：又来了一遍……最近准备加内存，干脆不设页面文件了。

直接说方法：要使用PsExec在启用了UAC的远程系统上运行程序，需要这样做：

RunAs /user:domain\user “psexec \\remote-computer-name -h executable-file”

而不能这样做：

psexec \\remote-computer-name -u domain\user -h executable-file

详细原因见此：http://www.riosec.com/articles/Windows-UAC-PsExec

顺便把内容复制过来留给自己看：

Recently I ran across a scenario where the Microsoft Sysinternals tool PsExec would not work against a Windows 7 domain-joined computer. The command was failing with an “Access Denied” error. On Vista and newer, User Access Control (UAC) issues a restricted token to processes, but PsExec requires an elevated token. On the local system’s Microsoft-Windows-UAC\Operational log the following event appeared: The process failed to handle ERROR_ELEVATION_REQUIRED during the creation of a child process.

Further research found that newer versions of PsExec have a command argument (-h) to specify elevated rights.

However, even with specifying -h PsExec was still failing with “Access Denied”. After some digging, I discovered that it’s all about how the authentication credentials are presented to the remote system. UAC has an exception for remote connections using domain credentials, so that machines can still be administrated remotely (otherwise, there would be no way to respond to UAC prompts). When connecting remotely and authenticating with NTLM using a domain account, Windows 7 issues an elevated token.

With PsExec when you specify the username on the command line it causes an explicit (local) authentication to occur on the remote system, and Windows issues a limited rights token, causing PsExec to fail. However, if you authenticate as the target user on the local computer (using RunAs or logging in directly), and then use PsExec with implicit (NTLM) authentication to the remote computer, the process gets the elevated token on the remote system and it works.

This behavior becomes more obvious when using telnet. The built-in Windows telnet client automatically authenticates using NTLM (top window in the screen shot below), and the user is given an elevated token. However, logging in with the same user from a third-party telnet client results in a restricted token (bottom window).

因为一些事情，从其它部门弄来一台Mac Pro 1,1 2007年款的台式机，而因为某些原因需要给这台跑着OS X 10.4 “Tiger”机器升级到10.9 Mavericks。由于对OS X下操作的不熟悉，以及苹果对直接从Mac App Store中升级至新版系统时所做的限制，足足折腾了两天才达到目的。

网上有教程，但都是英文的，我不确定那些高大上的中文论坛里是否有教程，不过估计搜不到是有付费墙之类的，所以还是记录一下自己折腾的过程好了： 继续阅读 “Day 3353 Mac Pro 2007全新安装OS X Mavericks” →

盘长这样，可以明显看到有一圈银色，那个是可以制作的坏道，如果使用按Sector复制的工具，读到这里就会因为读不下去而制作镜像失败。

这张盘是某部门下发的软件数据盘，因为某些奇怪的原因，在对应需要装的机器上无法识别，但是又必须尽快安装，于是处理方法如下：

1. 使用IsoBuster的Extract RAW模式将光盘制作成镜像，当读到那圈银色的坏道时会出错，这时取消操作，会出现是否删除文件的提示，点击否即可。
2. 此时制作出来的文件因为文件尾没有封口，是不能直接载入虚拟光驱软件的（尝试使用7-zip之类的软件也会出错），但UltraISO可以识别，所以在UltraISO中打开镜像文件，然后对其进行另存，文件就会被修正到可用状态。
3. 在Daemon Tools Lite之类的软件中载入镜像安装即可。

话说现在已经是软件任意派发然后通过各种方式限制使用授权了，某些部门还在用这种落后的方式防拷，真是不思进取。

P.S. 这张盘检测安装程序是否是从光盘引导的方式是检测两个隐藏文件（不是简单的加了隐藏属性，而是从ISO目录中隐藏），所以通过制作镜像的方法很轻易就能绕过去。

事情是从今年初安装了Visual Studio 2013 Community Edition后开始的，每次启动Excel 2007时都会出现以下Windows Installer的提示，让它走完或者按取消，下次启动Excel 2007都会重复出现：

解决方法：

1. 如果系统配置了UAC，则去Office安装目录中「使用管理员权限运行」Excel.exe。
2. 点击Excel左上角圆圆的Office图标，选择「Excel选项…」，点击左边的「加载项」，然后在右边找到「管理：」，下拉选择「COM加载项」。
3. 在新弹出的「COM加载项」管理窗口中，取消选择「Chinese Translation Addin」即可（如出现「无法更改 HKEY_LOCAL_MACHINE中注册的……」请重做第一步）。

至于具体原因不得而知，因为给出这个解决方案的是Excel某次启动后给出的提示：「似乎中文翻译加载项出错了太多次，要禁用它吗」，点了确定就OK了。