Jul
7
今天Sandy同学在开发一个网络相关应用的时候遇到了一个奇怪的问题。
大约是这样的一个单例类Foo（以下是类python的伪代码，实际是VB.NET），当调用方法 bar('remove', key, value) 的时候，经常（而不是总是）在for循环过程中报错，错误信息是 "循环过程中_pool已经被修改" 。
_pool 作为Foo的一个私有成员并且被 _mutex 保护着，理论上是不会出现这个问题的，然而各种排查的表现都指向了线程间的竞争问题，因为只有在调用到 bar('add', key, value) 的时候，_pool才有可能被修改到。
仔细查了一下MSDN上面Threading.Mutex的说明，在备注一栏中藏着一句话："拥有互斥体的线程可以在对 WaitOne 的重复调用中请求相同的互斥体而不会阻止其执行。"，也就是说，如果是同一个线程两次调用 bar 方法的话，这个 _mutex 就相当于失效了。
换用其他的互斥锁机制（例如Syncing）并不解决这个问题（事实上Mutex已经是第三个尝试选项了）。我们甚至试着采用Threading.Senaphore，然而却导致整个进程卡住。
于是debug.print把 Threading.Thread.CurrentThread.ManagedThreadId 输出到控制台，发现在出现错误之前是有多个不同的thread id，但是出错的时候，确实是同一个线程两次调用 bar 方法，也就是说 _mutex 确实不能解决这个问题。
经过各种排查，确认是正好在 do(key, value) 方法调用中出现的，然而 Sandy 同学信誓旦旦地保证，do(key, value) 方法绝对不可能递归地调用回到 bar 函数。由于 do(key, value) 内部调用了某个阻塞的网络请求，据此我推测，.NET的网络模型底层使用了线程+纤程的模型，那只能想办法了。通过查看 bar('add', key, value) 的调用栈，发现确实这是同一个请求，但是中间夹杂了一个未知的"外部过程"，也就是说空闲的线程被调度来做其他的事情了。
深坑一个，但是既然找到了原因，就可以考虑如何针对性地去解决它，初步的想法是，Semaphore理论上应该是可以解决这个问题的，可能之前没有细看MSDN、调用方式有点问题。
Sandy同学的想法是，既然 Mutex 已经过滤掉了线程间的冲突，那我们就自己模拟 Semaphore 来解决线程内的冲突，只要简单增加一个初始值为 0 的 _counter 变量 ，在 self._mutex.waitOne() 后面加上
并在 self._mutex.release() 之前执行 self._counter = 0 就可以了。
想法是美好的，但是一执行就卡死在 foo('add') 调用的 while 循环里。简单分析一下就能发现，这个线程既然一直在while循环里面，就不可能被调度回到 foo('remove') 的纤程去修改 _counter=0，于是就卡住了。
没办法，再回头去仔细看MSDN，Threading.Semaphore 确实没有类似Mutex这样的同线程调用，于是把这个代码按照Example重新写了一遍，但是还是卡死了……
然后我瞬间醒悟过来——这似乎根本就是一个因为.net底层实现导致的死锁！除非上层应用能控制线程调度的细节，否则无论是信号量还是修改过的Mutex（同一个线程不能多次获得的）都不能解决这个问题。于是暂时的结论是可能要采用自己实现的线程池来进行调度，但是改动似乎很大。
完。
UPDATE @ 20150720 后来仔细考虑了下，根本问题是在do(key, value) 内部调用的那个“阻塞”请求，在临界区内本就不该调用阻塞请求。按照.net的文档，那个请求应当是非阻塞的，但是不知道为什么在这里阻塞了。由于我对.net并不了解，我没有再继续追究了。
大约是这样的一个单例类Foo（以下是类python的伪代码，实际是VB.NET），当调用方法 bar('remove', key, value) 的时候，经常（而不是总是）在for循环过程中报错，错误信息是 "循环过程中_pool已经被修改" 。
class Foo(singleton):
_pool = {}
_mutex = Threading.Mutex()
def bar(self, action, key, value=None):
self._mutex.waitOne()
if action == 'add':
self._pool[key] = value
else: #'remove'
remove_keys = []
for key, value in self._pool.items():
if do(key, value):
remove_keys.append(key)
for key in remove_keys:
del self._pool[key]
self._mutex.release()
_pool = {}
_mutex = Threading.Mutex()
def bar(self, action, key, value=None):
self._mutex.waitOne()
if action == 'add':
self._pool[key] = value
else: #'remove'
remove_keys = []
for key, value in self._pool.items():
if do(key, value):
remove_keys.append(key)
for key in remove_keys:
del self._pool[key]
self._mutex.release()
_pool 作为Foo的一个私有成员并且被 _mutex 保护着，理论上是不会出现这个问题的，然而各种排查的表现都指向了线程间的竞争问题，因为只有在调用到 bar('add', key, value) 的时候，_pool才有可能被修改到。
仔细查了一下MSDN上面Threading.Mutex的说明，在备注一栏中藏着一句话："拥有互斥体的线程可以在对 WaitOne 的重复调用中请求相同的互斥体而不会阻止其执行。"，也就是说，如果是同一个线程两次调用 bar 方法的话，这个 _mutex 就相当于失效了。
换用其他的互斥锁机制（例如Syncing）并不解决这个问题（事实上Mutex已经是第三个尝试选项了）。我们甚至试着采用Threading.Senaphore，然而却导致整个进程卡住。
于是debug.print把 Threading.Thread.CurrentThread.ManagedThreadId 输出到控制台，发现在出现错误之前是有多个不同的thread id，但是出错的时候，确实是同一个线程两次调用 bar 方法，也就是说 _mutex 确实不能解决这个问题。
经过各种排查，确认是正好在 do(key, value) 方法调用中出现的，然而 Sandy 同学信誓旦旦地保证，do(key, value) 方法绝对不可能递归地调用回到 bar 函数。由于 do(key, value) 内部调用了某个阻塞的网络请求，据此我推测，.NET的网络模型底层使用了线程+纤程的模型，那只能想办法了。通过查看 bar('add', key, value) 的调用栈，发现确实这是同一个请求，但是中间夹杂了一个未知的"外部过程"，也就是说空闲的线程被调度来做其他的事情了。
深坑一个，但是既然找到了原因，就可以考虑如何针对性地去解决它，初步的想法是，Semaphore理论上应该是可以解决这个问题的，可能之前没有细看MSDN、调用方式有点问题。
Sandy同学的想法是，既然 Mutex 已经过滤掉了线程间的冲突，那我们就自己模拟 Semaphore 来解决线程内的冲突，只要简单增加一个初始值为 0 的 _counter 变量 ，在 self._mutex.waitOne() 后面加上
while self._counter != 0:
Threading.sleep(10) #10ms
self._counter = 1
Threading.sleep(10) #10ms
self._counter = 1
并在 self._mutex.release() 之前执行 self._counter = 0 就可以了。
想法是美好的，但是一执行就卡死在 foo('add') 调用的 while 循环里。简单分析一下就能发现，这个线程既然一直在while循环里面，就不可能被调度回到 foo('remove') 的纤程去修改 _counter=0，于是就卡住了。
没办法，再回头去仔细看MSDN，Threading.Semaphore 确实没有类似Mutex这样的同线程调用，于是把这个代码按照Example重新写了一遍，但是还是卡死了……
然后我瞬间醒悟过来——这似乎根本就是一个因为.net底层实现导致的死锁！除非上层应用能控制线程调度的细节，否则无论是信号量还是修改过的Mutex（同一个线程不能多次获得的）都不能解决这个问题。于是暂时的结论是可能要采用自己实现的线程池来进行调度，但是改动似乎很大。
完。
UPDATE @ 20150720 后来仔细考虑了下，根本问题是在do(key, value) 内部调用的那个“阻塞”请求，在临界区内本就不该调用阻塞请求。按照.net的文档，那个请求应当是非阻塞的，但是不知道为什么在这里阻塞了。由于我对.net并不了解，我没有再继续追究了。
Jan
22
本系列的上一篇已经是两年多前的事情了……
当时那个版本一直用到今天，已经有点勉强了，主要是基于XP的PE不能识别这两年新出的主板SATA（比如现在这块B85），很蛋疼，得先到BIOS里改成IDE模式再进PE才能操作磁盘。于是今天找了下小聪同学的TonPE，发现也已经物是人非，TonPE已经出售，风格大变，也不太好用了（安装包里的关键文件都用密码加密了，至于吗），哎，后妈就是不一样啊。幸好万能的互联网保存了早先发布的版本，于是找到了基于Win7的PE，Ton7PE_V3.3（基于Win8的Ton8PE_V4.0也能找到，但是在VBox里测试有问题，所以就没用它）。V3.3这个版本做得很赞，不仅能识别SATA，连USB3接口都能识别，而且所有文件都打包到一个WIM里头，不需要像上次那样做一些蛋疼的改动就能用。
装到U盘第二个分区的好处如上一篇所说：1. 跟U盘的正常数据区分开来，不会误删，甚至格式化U盘分区都无所谓；2. PE是单独的分区，而且永远不会被Windows载入，不用担心病毒感染；3. （相比于量产+ISO的U盘）在资源管理器里不会显示多余的分区。
具体的操作流程如下：
1. 用Disk Genius给U盘最后留下90M的空间，格式化成FAT16分区，激活该分区（即设置启动标志）
2. 用Disk Genius把TonPE_V3.3.iso里的内容导入（新版是在邮件菜单中选择“复制文件到当前分区”）到该分区（在分区参数右边有个“浏览文件”的TAB），或者可以在Linux下挂载后拷贝进去
3. 用BOOTICE.exe修改第二个分区的引导记录为“BOOTMGR引导程序”
然后就可以用这个U盘启动啦。
上面涉及到的所有工具/文件都放在这里啦： http://pan.baidu.com/s/1qW4PogW ，包括最原始的安装文件。
当时那个版本一直用到今天，已经有点勉强了，主要是基于XP的PE不能识别这两年新出的主板SATA（比如现在这块B85），很蛋疼，得先到BIOS里改成IDE模式再进PE才能操作磁盘。于是今天找了下小聪同学的TonPE，发现也已经物是人非，TonPE已经出售，风格大变，也不太好用了（安装包里的关键文件都用密码加密了，至于吗），哎，后妈就是不一样啊。幸好万能的互联网保存了早先发布的版本，于是找到了基于Win7的PE，Ton7PE_V3.3（基于Win8的Ton8PE_V4.0也能找到，但是在VBox里测试有问题，所以就没用它）。V3.3这个版本做得很赞，不仅能识别SATA，连USB3接口都能识别，而且所有文件都打包到一个WIM里头，不需要像上次那样做一些蛋疼的改动就能用。
装到U盘第二个分区的好处如上一篇所说：1. 跟U盘的正常数据区分开来，不会误删，甚至格式化U盘分区都无所谓；2. PE是单独的分区，而且永远不会被Windows载入，不用担心病毒感染；3. （相比于量产+ISO的U盘）在资源管理器里不会显示多余的分区。
具体的操作流程如下：
1. 用Disk Genius给U盘最后留下90M的空间，格式化成FAT16分区，激活该分区（即设置启动标志）
2. 用Disk Genius把TonPE_V3.3.iso里的内容导入（新版是在邮件菜单中选择“复制文件到当前分区”）到该分区（在分区参数右边有个“浏览文件”的TAB），或者可以在Linux下挂载后拷贝进去
3. 用BOOTICE.exe修改第二个分区的引导记录为“BOOTMGR引导程序”
然后就可以用这个U盘启动啦。
上面涉及到的所有工具/文件都放在这里啦： http://pan.baidu.com/s/1qW4PogW ，包括最原始的安装文件。
Nov
20
UPDATE@2014-01-09：注意，在gdb attach成功以后，这个进程会被暂停，可能会导致一些问题。
UPDATE@2017-11-11：用 lsof | grep deleted ，可以看到被删除的问题文件，记住占用该文件的PID， 到 /proc//fd （该进程打开的所有文件，按fd的值命名）下面可以看到这个文件的另一个链接，把这个链接的内容清空，也可以解决。
场景：Linux下，进程 p 打开了文件 f 并在后台持续地往 f 中写入日志。某日发现磁盘空间不够，把 f 删掉了，这时 ls 已经看不到 f 的存在，但是 df 发现磁盘空间占用并未减小，而 lsof 仍然可以看到该文件被占用（并显示一个 "(deleted)" 后缀）。更不幸的是，进程 p 是需要长期驻留在后台运行的，不能直接干掉它。
解决：简单地说就是替进程解决这个文件。
1) 根据链接文件名，可以查到该文件在进程中的 fd ：
$ ls -l /proc/[PID]/fd
2) 通过 gdb 连上该进程（一般需要root权限）
$ sudo gdb
(gdb) attach [PID]
3) 清除该文件所占空间
(gdb) call ftruncate(3, 0) #这里假定fd = 3
$1 = 0
这种方式治标，但不治本 —— 随着进程的继续运行，被删掉的 f 仍然会占用越来越多的空间；但是又不能残暴地直接 close(3) ，否则 p 的后续写入操作会出错，可能导致进程报错结束。
但是还是有办法的：
4) 移花接木
(gdb) call dup(3)
$2 = 4
(gdb) call open("/dev/null", 2) #注：2 = O_RDWR，x86/x86_64/arm上都是这个值。
$3 = 5
(gdb) call dup2(5, 3)
$4 = 3
(gdb) call close(4)
$5 = 0
注：未测试该招式是否可能因多线程竞争导致错误。
OVER.
UPDATE@2017-11-11：用 lsof | grep deleted ，可以看到被删除的问题文件，记住占用该文件的PID， 到 /proc/
场景：Linux下，进程 p 打开了文件 f 并在后台持续地往 f 中写入日志。某日发现磁盘空间不够，把 f 删掉了，这时 ls 已经看不到 f 的存在，但是 df 发现磁盘空间占用并未减小，而 lsof 仍然可以看到该文件被占用（并显示一个 "(deleted)" 后缀）。更不幸的是，进程 p 是需要长期驻留在后台运行的，不能直接干掉它。
解决：简单地说就是替进程解决这个文件。
1) 根据链接文件名，可以查到该文件在进程中的 fd ：
$ ls -l /proc/[PID]/fd
2) 通过 gdb 连上该进程（一般需要root权限）
$ sudo gdb
(gdb) attach [PID]
3) 清除该文件所占空间
(gdb) call ftruncate(3, 0) #这里假定fd = 3
$1 = 0
这种方式治标，但不治本 —— 随着进程的继续运行，被删掉的 f 仍然会占用越来越多的空间；但是又不能残暴地直接 close(3) ，否则 p 的后续写入操作会出错，可能导致进程报错结束。
但是还是有办法的：
4) 移花接木
(gdb) call dup(3)
$2 = 4
(gdb) call open("/dev/null", 2) #注：2 = O_RDWR，x86/x86_64/arm上都是这个值。
$3 = 5
(gdb) call dup2(5, 3)
$4 = 3
(gdb) call close(4)
$5 = 0
注：未测试该招式是否可能因多线程竞争导致错误。
OVER.
Nov
9
当主机内存想要回收一些虚拟机的内存时，应该怎么办？根据主机OS记录的内存使用情况来swap虚拟机占用的内存吗？不是的。
因为只有虚拟机的OS知道哪些内存是它最需要的，所以让它自己释放内存才是最好的选择。
怎么让它自己释放内存呢？对虚拟机比较了解的同学应该知道气球驱动（Balloon Driver）。其实原理很简单，就是在虚拟机里，使用一个进程申请并占用*一批内存，于是虚拟机的OS便会把它最不需要的内存释放掉一部分。然后这个进程再告诉主机OS我拿到这么多空间啦，你拿去用吧。
*注：申请内存和占用内存通常是两回事。实际上每次调用malloc（其实关键是brk系统调用）等函数分配内存时，系统只是在页表中标记，某些页已经分配给进程XXX，但是对应的地址空间并不是可用的。当进程使用到这个页的时候，会产生一个缺页中断，在中断例程中，系统才会真的从可用空间中分配一个页，然后再让进程继续使用。这个过程对于进程而言是透明的（不过可能会有一些延迟）。这种延迟机制在OS中大量使用，被实践证明是相当有效的，所以有拖延症的同学们，不要太担心哟，适当的拖延不见得是坏事。
说了这么多废话，其实没到这篇的主题。
最近觉得公司配的台式机内存不够了（4G），由于我经常开大量的程序和网页，直到内存不够用的时候才关（拖延。。），因此常常是开个虚拟机的时候空闲内存立刻下降到0，这时候各种卡顿，连鼠标都卡。于是自费在X东上买了一条南亚易胜的 4GB DDR3 1600（这个牌子最便宜。。据说这个牌子给许多其他品牌代工）。安装上去以后，内存不够的现象显著缓解，一口气开三个虚拟机，腰不酸腿不痛的。
但是才用了两天，又发现空闲内存*不多了，经常是才剩下几百MB，有时竟然只有几十MB。虽然任务管理器里说了，8G内存中有6G+是“已缓存”，但是还是怀疑是不是某个进程占用了太多内存。于是一个一个截，全都截掉，空闲内存也还是不到2GB。
*注：Win7任务管理器中的”空闲内存“是malloc以来马上就可以给分配的。“已缓存”是操作系统用内存来保存硬盘上的数据（因为硬盘太慢了）。“可用内存”包括了空闲内存和已缓存。当进程申请的内存超过空闲内存的大小后，OS可以将已缓存的一部分释放掉，但是这个过程需要占用一段时间，效率不如直接使用空闲内存。
于是写了个气球程序来测试。最初的程序很简单，就是while(1)死循环，申请4M内存，然后memset清零。编译，运行，梆！出错了。看了下，进程只申请了2G的内存就出错了，简单分析就知道了，因为我用的是mingw32，生成的32位程序只能申请最多2G的用户空间，再一次malloc的时候，返回的是NULL，于是memset就会导致非法内存访问。
解决办法很简单…………跑3个，然后就申请并占用了6G内存，结束掉之后，发现任务管理器中的已缓存只剩一点点，空闲内存有了6G+，效果显著。看来的确是都被缓存了，不是某个进程太坑爹。注意：如果多跑了一个，就会发现第四个进程速度显著变慢，甚至拖累系统变得相当相当慢，说明这个时候已经在使用swap（或者叫交换空间，虚拟内存，pagefile，页面文件，分页文件……）了，所以不得不慢。
当然，更好的解决方法是编译生成一个64位的可执行程序，这样就能够申请足够多的空间了。到mingw64去下载一个rubenvb编译好的gcc套装直接编译，或者安装个visual studio，都行。
实际上，让系统放弃所有的缓存并不是好事。在XP以及更早的windows系统中，大概是开发人员假设用户的内存总是不够用的，所以系统不会大量使用内存来进行缓存。所以在内存大降价而vista/win7还没出来的时候（大概是08～09年），在XP机器上看到1～2G甚至更多内存并不奇怪，用不完怎么办呢？RAMDISK大行其道，虚拟一个分区出来，速度快得不行。XP的继任者Vista和Win7效仿Unix/Linux系的做法，尽量将内存用于缓存，在很多情况下都可以通过避免磁盘IO来提高系统的反应速度。
因此这里给出个最终版本，默认只回收2G的缓存，再怎么样，缓存3～4G的数据应该已经足够应付日常应用了。
因为只有虚拟机的OS知道哪些内存是它最需要的，所以让它自己释放内存才是最好的选择。
怎么让它自己释放内存呢？对虚拟机比较了解的同学应该知道气球驱动（Balloon Driver）。其实原理很简单，就是在虚拟机里，使用一个进程申请并占用*一批内存，于是虚拟机的OS便会把它最不需要的内存释放掉一部分。然后这个进程再告诉主机OS我拿到这么多空间啦，你拿去用吧。
*注：申请内存和占用内存通常是两回事。实际上每次调用malloc（其实关键是brk系统调用）等函数分配内存时，系统只是在页表中标记，某些页已经分配给进程XXX，但是对应的地址空间并不是可用的。当进程使用到这个页的时候，会产生一个缺页中断，在中断例程中，系统才会真的从可用空间中分配一个页，然后再让进程继续使用。这个过程对于进程而言是透明的（不过可能会有一些延迟）。这种延迟机制在OS中大量使用，被实践证明是相当有效的，所以有拖延症的同学们，不要太担心哟，适当的拖延不见得是坏事。
说了这么多废话，其实没到这篇的主题。
最近觉得公司配的台式机内存不够了（4G），由于我经常开大量的程序和网页，直到内存不够用的时候才关（拖延。。），因此常常是开个虚拟机的时候空闲内存立刻下降到0，这时候各种卡顿，连鼠标都卡。于是自费在X东上买了一条南亚易胜的 4GB DDR3 1600（这个牌子最便宜。。据说这个牌子给许多其他品牌代工）。安装上去以后，内存不够的现象显著缓解，一口气开三个虚拟机，腰不酸腿不痛的。
但是才用了两天，又发现空闲内存*不多了，经常是才剩下几百MB，有时竟然只有几十MB。虽然任务管理器里说了，8G内存中有6G+是“已缓存”，但是还是怀疑是不是某个进程占用了太多内存。于是一个一个截，全都截掉，空闲内存也还是不到2GB。
*注：Win7任务管理器中的”空闲内存“是malloc以来马上就可以给分配的。“已缓存”是操作系统用内存来保存硬盘上的数据（因为硬盘太慢了）。“可用内存”包括了空闲内存和已缓存。当进程申请的内存超过空闲内存的大小后，OS可以将已缓存的一部分释放掉，但是这个过程需要占用一段时间，效率不如直接使用空闲内存。
于是写了个气球程序来测试。最初的程序很简单，就是while(1)死循环，申请4M内存，然后memset清零。编译，运行，梆！出错了。看了下，进程只申请了2G的内存就出错了，简单分析就知道了，因为我用的是mingw32，生成的32位程序只能申请最多2G的用户空间，再一次malloc的时候，返回的是NULL，于是memset就会导致非法内存访问。
解决办法很简单…………跑3个，然后就申请并占用了6G内存，结束掉之后，发现任务管理器中的已缓存只剩一点点，空闲内存有了6G+，效果显著。看来的确是都被缓存了，不是某个进程太坑爹。注意：如果多跑了一个，就会发现第四个进程速度显著变慢，甚至拖累系统变得相当相当慢，说明这个时候已经在使用swap（或者叫交换空间，虚拟内存，pagefile，页面文件，分页文件……）了，所以不得不慢。
当然，更好的解决方法是编译生成一个64位的可执行程序，这样就能够申请足够多的空间了。到mingw64去下载一个rubenvb编译好的gcc套装直接编译，或者安装个visual studio，都行。
实际上，让系统放弃所有的缓存并不是好事。在XP以及更早的windows系统中，大概是开发人员假设用户的内存总是不够用的，所以系统不会大量使用内存来进行缓存。所以在内存大降价而vista/win7还没出来的时候（大概是08～09年），在XP机器上看到1～2G甚至更多内存并不奇怪，用不完怎么办呢？RAMDISK大行其道，虚拟一个分区出来，速度快得不行。XP的继任者Vista和Win7效仿Unix/Linux系的做法，尽量将内存用于缓存，在很多情况下都可以通过避免磁盘IO来提高系统的反应速度。
因此这里给出个最终版本，默认只回收2G的缓存，再怎么样，缓存3～4G的数据应该已经足够应付日常应用了。
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
const int block = 1024 * 1024 * 8; //8M
int main(int argc, char *argv[])
{
int i = 0, reclaim = 2048;
if (argc > 1)
sscanf(argv[1], "%d", &reclaim);
for (i = 0; i < reclaim; i += 8)
{
char *c = (char *)malloc(block);
if (c == NULL)
return 0;
memset(c, 0, block);
printf("%4d MB\n", i);
}
return 0;
}
#include <stdlib.h>
#include <string.h>
const int block = 1024 * 1024 * 8; //8M
int main(int argc, char *argv[])
{
int i = 0, reclaim = 2048;
if (argc > 1)
sscanf(argv[1], "%d", &reclaim);
for (i = 0; i < reclaim; i += 8)
{
char *c = (char *)malloc(block);
if (c == NULL)
return 0;
memset(c, 0, block);
printf("%4d MB\n", i);
}
return 0;
}
Aug
8
这是第一个支持IBM PS/2和1.44MB 3.5寸软盘的DOS版本，可能是在家用PC上比较容易用虚拟机模拟的最古老的微软系操作系统。隐约记得这里头还有个BASICA解释器，比QBASIC还要老很多的那种，类似于文曲星上面的那个版本。
下载文件 (已下载 2030 次)
以前（大一之前）很喜欢玩这些东西，收集了不少东西，包括3.31, 6.22, win98/me/xp的DOS启动盘, windows 1.0 ~ 3.2（主要来自曾经的“bear5的软件地摊”），还有很多dos下的工具，tw ucdos 之类，甚至还有个VB DOS版。折腾bat、config.sys这些东西，玩得乐此不疲。如今突然想起，却发现它们静静地躺在硬盘的那个角落已经好多年了。
谨以此纪念那些二逼的时光。
下载文件 (已下载 2030 次)以前（大一之前）很喜欢玩这些东西，收集了不少东西，包括3.31, 6.22, win98/me/xp的DOS启动盘, windows 1.0 ~ 3.2（主要来自曾经的“bear5的软件地摊”），还有很多dos下的工具，tw ucdos 之类，甚至还有个VB DOS版。折腾bat、config.sys这些东西，玩得乐此不疲。如今突然想起，却发现它们静静地躺在硬盘的那个角落已经好多年了。
谨以此纪念那些二逼的时光。
Mar
23
以前一直纳闷，非特权用户不能编辑 /etc/rc.local ，应该如何实现开机启动任务的功能。。
刚刚详读了下 man 5 crontab ，才知道crontab的前五个参数除了可以用分时日月周之外，
还可以用一些预定义的类型（叫做Vixie cron），其中一个特殊的就是 @reboot ：
也就是说，只要运行crontab -e，加入一行
@reboot /home/username/my_rc.local
就可以实现个人用户的 rc.local 啦！
刚刚详读了下 man 5 crontab ，才知道crontab的前五个参数除了可以用分时日月周之外，
还可以用一些预定义的类型（叫做Vixie cron），其中一个特殊的就是 @reboot ：
引用
Instead of the first five fields, one of eight special strings may appear:
string meaning
------ -------
@reboot Run once, at startup.
@yearly Run once a year, "0 0 1 1 *".
......
string meaning
------ -------
@reboot Run once, at startup.
@yearly Run once a year, "0 0 1 1 *".
......
也就是说，只要运行crontab -e，加入一行
@reboot /home/username/my_rc.local
就可以实现个人用户的 rc.local 啦！
Nov
23
按照某帖子里的说法，禁用掉WMPNetworkSvc(Windows Media Player Netwroking SharingService)即可正常使用sysprep部署了。
好久没发这么短的Blog了，简直就是微博了，OVER。
好久没发这么短的Blog了，简直就是微博了，OVER。
Nov
15
其实最早是想把XP装进移动硬盘，这样的话只要有需要随时可以从移动硬盘启动一个完整的系统。可惜无论是从安装程序安装还是Ghost，都会在XP滚动条过去以后就挂断（蓝屏或者直接重启）。发现有个USBOOT好像能够把XP放进去，但是还得注册帐号什么的，操作步骤也很麻烦。
最近各种折腾，最终结果是手头有个2个USB3.0的U盘。朗科 U903 8GB(某东现在特价69，很值得买)：USB2.0下面读30M/s，写20M/s，USB3.0下读40M/s，写25M/s，延迟约1.1ms，也就是大约900IOPS；威刚S102 16GB(某东正常价139)，USB2.0读写也是30/20左右，3.0还没实测，延时0.6ms，约1600IOPS。虽然连续读写速度和HDD没得比，但是IOPS却要快一个数量级，于是蛋疼地想着，是不是把Windows装上去试试，说不定还能体验一下SSD的快感。
PE SATA 1.9.6 里面有个WIM安装器，说是支持USB HDD，于是试着往U盘里面塞了个Win7进去，发现不行（估计非得是移动硬盘）。昨天在公司的时候查了一下，发现一个神器PWBoot 3.0.2可以patch Win7，昨晚S102被czyhd同学拿去拷了BF3，于是回家后只能用U903试了。
下载下来运行，发现PWBoot选择install.wim以后就出现数组越界错误，安装没法用。只有patch功能可以使，只好曲线救国。看到网上有人说VHD的事儿，才发现原来Win7已经原生支持VHD的创建、挂载、启动（启动啊！），out了好几年啊……
不废话了，昨晚折腾了很久，最后实现U盘启动的方式是这样的：
0. 打开compmgmt.msc，创建一个VHD，FixedSize或者Dynamic都可以。
1. 安装VirtualBox 4.x，这个支持VHD作为磁盘
2. 把VHD作为磁盘，安装Win7
3. 安装完以后打开cmdline，执行 c:\windows\system32\sysprep\sysprep.exe /generalize /oobe /shutdown
4. 等到VBox关机以后打开compmgmt.msc，右键磁盘管理->附加VHD，选择好挂载上。
5. 运行PWBoot，选择Patch Windows，把VHD上的Win7打个补丁
6. 将VHD的Win7分区Ghost到U盘（5G+）
7. 如果VHD有个100M的分区包含了boot目录和bootmgr，则一并拷贝到U盘的根目录下面
8. 启动，等待安装驱动（相当慢……………………）
第8步已经剧透了，效果很烂。
虽然30M的读取不快，但是不应该是瓶颈，初步估计是因为USB协议的原因，导致系统的运行受到限制，甚至刷新桌面都要卡呀卡的。
不过用VHD启动是个挺好玩的事儿，回头有空可以折腾折腾……
最近各种折腾，最终结果是手头有个2个USB3.0的U盘。朗科 U903 8GB(某东现在特价69，很值得买)：USB2.0下面读30M/s，写20M/s，USB3.0下读40M/s，写25M/s，延迟约1.1ms，也就是大约900IOPS；威刚S102 16GB(某东正常价139)，USB2.0读写也是30/20左右，3.0还没实测，延时0.6ms，约1600IOPS。虽然连续读写速度和HDD没得比，但是IOPS却要快一个数量级，于是蛋疼地想着，是不是把Windows装上去试试，说不定还能体验一下SSD的快感。
PE SATA 1.9.6 里面有个WIM安装器，说是支持USB HDD，于是试着往U盘里面塞了个Win7进去，发现不行（估计非得是移动硬盘）。昨天在公司的时候查了一下，发现一个神器PWBoot 3.0.2可以patch Win7，昨晚S102被czyhd同学拿去拷了BF3，于是回家后只能用U903试了。
下载下来运行，发现PWBoot选择install.wim以后就出现数组越界错误，安装没法用。只有patch功能可以使，只好曲线救国。看到网上有人说VHD的事儿，才发现原来Win7已经原生支持VHD的创建、挂载、启动（启动啊！），out了好几年啊……
不废话了，昨晚折腾了很久，最后实现U盘启动的方式是这样的：
0. 打开compmgmt.msc，创建一个VHD，FixedSize或者Dynamic都可以。
1. 安装VirtualBox 4.x，这个支持VHD作为磁盘
2. 把VHD作为磁盘，安装Win7
3. 安装完以后打开cmdline，执行 c:\windows\system32\sysprep\sysprep.exe /generalize /oobe /shutdown
4. 等到VBox关机以后打开compmgmt.msc，右键磁盘管理->附加VHD，选择好挂载上。
5. 运行PWBoot，选择Patch Windows，把VHD上的Win7打个补丁
6. 将VHD的Win7分区Ghost到U盘（5G+）
7. 如果VHD有个100M的分区包含了boot目录和bootmgr，则一并拷贝到U盘的根目录下面
8. 启动，等待安装驱动（相当慢……………………）
第8步已经剧透了，效果很烂。
虽然30M的读取不快，但是不应该是瓶颈，初步估计是因为USB协议的原因，导致系统的运行受到限制，甚至刷新桌面都要卡呀卡的。
不过用VHD启动是个挺好玩的事儿，回头有空可以折腾折腾……
