Welcome back, Demonoid.com

After 5 months of closing due to the threaten of CRIA – an association of record industry in Canada, Demonoid.com, one of the most popular bittorrent tracker and forum, reopened yesterday. The screenshot below shows the blank between April 11, 2008 and November 7, 2007 during which the site was closed.

Demonoid

On the days without Demonoid.com, I tried thepiratebay.org, mininova.org and some private trackers. However, ebooks, the part which I most interested in is not emphasised on these sites. That was the reason why I always kept visiting the site every time I was connected to the internet.

The registrations are still closed. If you want to get an invitation, please email me. My email address is on the top page.

如果你需要demonoid.com的邀请,请email我。

New Product from the King of Pirate?

几个小时前,门户级的IT业界资讯站cnBeta上发布了这样一条消息:小霸王出掌机,高清掌机开始接受预订

小霸王?一听说这个词汇,我相信很多同龄人都会和我一样心里涌起一种怀旧的情绪。在那个年代,小霸王简直成了任天堂Famicon的代称,甚至可以说比Famicon远远有名。那个时代的中国经济还相对闭锁,对软件的知识产权也完全没有概念,小霸王正是利用了这个契机,从事现在看来违法的行当起了家。

到如今,Famicon的热潮已过多时,在我想来小霸王应该已经借用当年的东风成功起家,然后借用其品牌优势转型开发数码产品——如早期的学习机,现在的电子词典、MP3/4甚至手机……可是好像最近几年的确没怎么听说过小霸王的牌子。现在突然又冒出这么一则新闻,难道是小霸王卧薪尝胆十年,终于决定推出中国独自产权的游戏机了?!

但是,看到了新闻的最后我就一下子心凉了:“支持上千款8位,16位游戏卡” ……原来,只是把当年盗版Famicon的小霸王游戏机做成小型掌机而已!

小霸王,你还要继续吃多久盗版的老底呢?!

网上商城卖的小霸王Z9、Z10掌机,附送220合一的FC游戏卡,连机器带卡才卖180元——的确,这盘游戏卡都是“淘金者”“冒险岛”“魂斗罗”“小蜜蜂”这样的,在国人看起来是“小游戏”的玩意,可是您是否知道在正版市场,这220个游戏中每个游戏都售价200元人民币以上?即便在今天的日本,这些卡带依然售价如此(因为厂商早在十年前就停止了销售,都是二手渠道,多少会有折扣)。

这样算起来,光是这一盘220合一的卡带,如果是正版就要4万元人民币以上。在21世纪的现在,小霸王你抗得住任天堂的官司吗? 就算任天堂放任不管,吃这Famicon的老底也是没有前景的。就算要盗版,你难道弄不出一个盗版的NDS,一个盗版的PSP吗?

猛然间我发现,其实这正说明了小霸王吃老本的原因所在:在这十几年二十来年中,小霸王不求进取,已经沦落得和中山市那些其他电子小厂一样的无名小卒了。

看看今天的许多IT风险资本,许多”Web 2.0”如雨后春笋般地崛起,在欣喜的同时也为他们担心:二十年后,他们的名字是会和现在一样显耀,还是只留在人们二十年前的回忆中呢?

小霸王Z9/Z10

A Glance at New VirtualPCCenter 2.0 of NEC

4月7日,NEC发布了虚拟PC型瘦客户系统VPCC的最新版本——VPCC 2.0。目前该产品只在日本国内出售,预计将来将会向全世界推广。

这次的VPCC 2.0系统中的新产品如下:

  1. 虚拟PC服务器采用最新的Express5800/120Rj-2
    120Rj-2虚拟PC服务器是安装VMware ESX Server 3.5,并负责管理和执行VM的服务器,自然是采用了极为强悍的系统配置。
    CPU为四核Xeon E5405,内存标配18GB,最大可扩展至48GB,本地存储由5块146.5GB的SAS硬盘构成。这样一台服务器,默认搭载10台Windows XP或Vista的虚拟PC,最大可扩展至50台虚拟PC。
  2. 入门级瘦客户机US110E
    US110E是去年的US110的精简版,价格低廉适合于入门用户。其CPU为ARM926EJ 400MHz,OS为Windows CE 5.0,重量仅为350克
  3. 支持双显示器的瘦客户机US300
    US300比起US110E要大得多也重得多(1.3Kg),价格也高出一截。其CPU为VIA C7 1GHz,单从主频上看要远远高于US110/US110E,不知道性能会更强劲?此外其OS是Windows XP Embedded SP2 + Feature Pack 2007,应该比Windows CE有着更好的设备兼容性和性能,此外RDP客户端也被升级到了6.0,全面支持Vista的各种效果。
  4. SigmaSystemCenter Software Thinterminal 2.1
    这个产品的名字有点长,不过用途倒是很广。这个软件存储于CD-ROM或者USB-ROM中,将其直接连接在一般的PC上启动,就可以使PC成为瘦客户机,而不需要任何其他的操作系统。
    由于它的系统需求很低(只需奔腾2 CPU,96MB内存的PC即可),需要已经近乎废弃的旧电脑可以被再次利用,作为瘦客户机发挥余热。

Disable Search Companion in Windows XP

Windows XP默认的搜索工具,据说是为了表示亲切友好弄成了一只狗的形象。但是实际上由于其过于傻瓜化的操作,使得高级用户在进行查找时反倒觉得难用。而User Interface上又没有提供简单的傻瓜用户-高级用户切换方式(像控制面向那样),就只能靠更改下面的注册表来达到目的:

HKEY_CURRENT_USER → Software → Microsoft → Windows → CurrentVersion → Explorer → CabinetState

在这里新建如下注册表值:

名字:Use Search Asst
类型:String(字符串)
值:no

之后重新打开一个搜索界面,就会发现搜索界面已经换成了清爽方便的高级搜索模式。

Search Companion Advanced Search

Run Windows Vista on Your Mobile Phone

Intel Atom可曾想过,在你的手机上运行Windows Vista呢?现在这已经不是一个梦想,而是活生生的现实了。

Willcom公司于3月3日宣布,他们正在与Intel,Microsoft和Sharp共同开发一款新的手机。这款新的手机将于6月正式发布,操作系统为Windows Vista。

既然操作系统是Windows Vista,而不是一向用在掌上电脑和手机上的Windows CE,那么说明硬件就是一个完整的x86平台了。这么小的x86平台,是如何实现的呢?

其实,这要完全得益于Intel于今年3月初发布的Intel Centrino Atom Processor Technology,也就是开发代号为“Menlow”的低功耗超微型x86平台。

Atom是一个大小只有25平方毫米的45纳米技术CPU芯片,完全取代了它的前一代Intel A100/A110(90纳米工艺)。其频率为800MHz到1.87GHz,FSB为533MT/s。

不仅是手机,很多UMPC(Ultra Mobile PC)估计也会采用Atom。目前市面的UMPC多采用Intel A100/A110,AMD Geode或者是VIA C7系列。要买UMPC的人估计又要观望一下了。

A Cool Utility – MSN Messenger History Merger

对于在同时在公司和家里使用MSN Messenger/Windows Live Messenger的人来说,聊天记录的管理就成了一个问题——尤其是聊天记录里面的信息比较重要的时候。

Messenger的聊天记录是以XML形式保存,每条消息使用一个标签记录。理论上讲,只要合并这些标签,再更改一些参数(例如表明会话数的FirstSessionID和LastSessionID属性),就可以将多个聊天记录合并为一个。

但是,这些操作如果一个一个手动来做,是非常耗费时间的。有没有一个工具,能够傻瓜式操作,自动将两个Messenger的聊天记录文件夹合并为一个呢?

微软的开源项目网站CodePlex上就有这么一个开源工具:MSN Messenger History Merger

http://www.codeplex.com/MsnHistoryMerger

该工具就是专用的MSN Messenger的XML聊天记录合并工具。目前的最新版的1.5版。需要注意的是,该工具需要.NET Framework 2.0才能运行。

Install ESX Server 3.5/3i onto ESX Server

已经有许多文章介绍如何在VMware Workstation上安装ESX Server,而在一台ESX Server上安装ESX Server其实也是大同小异。这里就把安装时的关键步骤记录一下。

# 下面的文章中,将直接安装在硬件的ESX Server称为【Host ESX Server】,将安装在Host ESX Server上的ESX Server称为【Guest ESX Server】

1. 做好Guest ESX Server的设置

就如同安装其他Guest OS一样,通过VI Client或者VirtualCenter连接到Host ESX Server,并创建一台VM。 创建时,OS类型选择“其他”,vCPU为2个,内存为1GB或更多即可。

2. 将网卡类型改为e1000

在创建好VM之后,不要急着安装。
在安装Guest ESX Server时,由于ESX Server无法识别默认的AMD网卡,需要手动编辑.vmx文件,将网卡类型改为ESX Server能够识别的“e1000” 。

登录到Host ESX Server的Service Console,在/vmfs/volumes/下找到创建好的VM的.vmx文件,用vi编辑器在其中加入如下行:

ethernet0.virtualDev = “e1000″

这里,ethernet0是第一个虚拟网卡,如果创建VM时设置了多块网卡,需要分别设置。设置好之后,可通过启动VM时的Boot Menu来确认。

Ethernet
默认的网卡类型:AMD Am79C970A

e1000
更改后的网卡类型:Intel E1000

3. Host ESX Server硬件的CPU必须支持VT (Virtualization Technology) (如果是AMD CPU,则是AMD-V)

Intel的VT或AMD的AMD-V是在CPU级别提供对虚拟化支持的技术。在ESX Server上安装32位的操作系统,如Windows XP时,打开或关闭VT功能对性能不会造成多大影响,但是在ESX Server上再安装ESX Server时,不使用VT却能让ESX Server虚拟机的启动时间变慢到10倍以上。

(我在不开启VT的情况下,在一台双Xeon CPU,12GB内存的ESX Server 3上安装ESX Server 3i,经过4小时的100%CPU占用率之后我放弃了)

4. 打开VMware的后门

要让ESX 3.5/3i顺利地运行在Host ESX Server上,还需要打开VMware的“后门”,否则很有可能会见到VMware中的“紫屏”(可以和Windows中的“蓝屏”媲美)。

要打开这个后门,允许在虚拟机上安装ESX Server,需要在.vmx文件中增加如下两行:

monitor_control.vt32 = “true”
monitor_control.restrict_backdoor = “true”

这个后门不仅避免了“紫屏”等死机、不稳定等问题,更是将启动速度再提高10倍。我在打开VT的情况下启动Guest ESX Server花费了30分钟,在即打开VT,又打开这些后门选项之后,只花费了2分钟。

5. 在Host ESX Server上允许Promiscuous Mode

做好上面的一切之后,你应该就可以顺利安装Guest ESX Server了。可是安装完成启动之后,却发现无法通过VirtualCenter来管理它——甚至连ping Guest ESX Server的Service Console都ping不通!这是为什么呢?

原因在于Host ESX Server上,连接着Guest ESX Server的vSwitch的设置。vSwitch默认是不允许promiscuous mode(允许网卡监听发往其他MAC地址的包的模式)的。但是在Guest ESX Server中,网卡只是一个桥接(bridge)作用,并不直接绑定MAC地址。因此,必须在Host ESX Server中允许promiscuous mode,Host ESX Server才能正确地将包传递给Guest ESX Server的Service Console(3i则是管理用IP)。

Promiscuous Mode

到这里,就可以体验ESX 3.5/3i的神奇世界了。

How to Determine the Availability of Intel VT from ESX Server

Intel VT (Virtualization Technology) is a set of processor enhancements, which enables virtualization platforms to offload workloads to system hardware, thus run virtual machines at “near native” performance.

Especially when you want to install virtualization software onto another virtualization platform, Intel VT can greatly improve the performance. For example, you may want to install VMware ESX Server 3i onto VMware ESX Server 3 or VMware Workstation 6.

On an ESX Server, to determine whether Intel VT is enabled, you can use the esxcfg-info command. Although you can reboot the machine and go to BIOS setting to confirm it, this command should be the most convenient way.

Logon to the Service Console, and type:

esxcfg-info -w | grep VT

you will get the following output if VT is enabled:

|—-VT Support…………………………………………3

(Values other than 3, such as 0, 2 should mean “no VT available” and “VT disabled” respectively, although I am not very sure)

NOTE: The above flag is only for ESX Server 3.0.x. In ESX Server 3.5.x, it is called “HV Support”, not “VT Support”. Therefore you have to change the command as following in ESX 3.5:

esxcfg-info -w | grep HV

MAC Address for Virtual Machines

虚拟世界的MAC地址

先看一下真实世界的MAC地址是如何分配,如何保证没有重复的。

每块网卡都有一个MAC地址,MAC地址是一个6字节、也即48bit的数据。前3字节称为OUI,是由IEEE组织注册给网络设备生产商的;每个厂商拥有一个或多个OUI,彼此不同。后三字节则是由网络设备生产商分配给自己生产的每一个拥有MAC地址的设备,互不重复。

在VM的世界中,每一台拥有虚拟NIC(网卡)的设备当然也拥有MAC地址。这虚拟网卡的MAC地址,当然也是按照规定,前三字节为OUI,后三字节逐一分配给每个设备。

由于虚拟网卡的”制造商“是VMware,XenSource,微软等虚拟平台软件的生产商,OUI当然就分配给了他们。

 

VMware VM所使用的OUI

按照VMware ESX 3的[Server Configuration Guide]的说法,VMware的使用下面的三个OUI作为VM的MAC地址:

  • 00:0C:29 – 用于自动生成的MAC地址
  • 00:50:56 – 用于手动设置的MAC地址
  • 00:05:69 – 曾经用于旧版本的VM(大约是在ESX 1.5的时代),在ESX 3中已经不再使用

但是在实际应用上,我发现00:50:56这一MAC地址段并不是完全用于手动设置的MAC地址:

  • 00:50:56:00:00:00 – 00:50:56:3F:FF:FF
    这一段MAC地址可以用于手动设置的MAC地址
  • 00:50:56:40:00:00 – 00:50:56:FF:FF:FF
    这一段(我的推测,不一定准确),则是用于ESX 3上的自动生成的MAC地址(包括VM和Service Console)

 

MAC地址的生成

OUI有了,后三字节如何生成呢?要知道虚拟机是经常被创建和销毁的,这一点不像实体PC。网卡生产商可以计算每年生产多少块网卡,从而为每块网卡分配不同的MAC地址; VMware却不可能计算出每年有多少台VM、有多少块虚拟网卡被创建。

VMware ESX Server的算法是,使用散列算法,通过VM的UUID来生成MAC地址。VM的UUID是每一台VM特有的、128bit的ID,是由ESX Server硬件SMBIOS的UUID、加上VM的路径生成的。因此,一台虚拟机的虚拟网卡的MAC地址就与下面四个因素有关:

  • VMware的OUI
  • Host (ESX Server)的SMBIOS中的UUID
  • VM在服务器上的路径
  • 网卡的实体名 (Entity Name),用来确保同一VM上的不同网卡有不同的MAC地址

 

MAC地址冲突的检测与解决

MAC地址一旦生成,就不会再有变化,除非上面所述的四项因素发生改变(最可能发生的就是第三项,VM在服务器上的路径改变)。

尽管如此,由于散列算法本身的特征,还是有万一发生MAC地址冲突的可能(可能性极小,和年末ジャンボ中头彩的几率差不多)。ESX Server会不断跟踪和检测运行中和挂起(Suspend)的VM,以保证没有MAC地址冲突。但是已经关闭电源的VM是不在检查对象之内的。

因此,万一一台VM启动时ESX检测到MAC地址冲突,它会分配给VM的虚拟网卡一个新的MAC地址。所以从这个意义上说,VM的MAC地址是可能发生变化的——只是这个概率实在太小。

 

手动指定MAC地址

手动指定MAC地址仅用于一些极其特殊的情况,通常是进行P2V的时候。例如,某物理服务器上的软件,其License已经与该服务器的MAC地址绑定,如果MAC地址改变则软件无法运行;再如,某些底层网络软件以MAC地址来鉴别机器时,为了不做更改能够继续使用,在P2V的时候也要手动指定MAC地址。

打开一个VM的.vmx文件,可以看到如下设置:(如果有多块NIC的话,那么就会有ethernet0、ethernet1、ethernet2……)

ethernet0.addressType = "generated"
ethernet0.generatedAddress = "00:0c:29:9b:fb:18"

这说明该NIC是自动生成的MAC地址。只需如下更改即可变为手动分配的MAC地址:

ethernet0.addressType = "static"
ethernet0.address = "00:50:56:00:00:01"

其中的00:50:56:00:00:01就是手动指定的MAC地址。

Settings for CETSC – RDP Client on Windows CE

Windows CE被很多Thin Client采用,作为嵌入式的操作系统。在WinCE based Thin Client上,通常使用RDP协议与远程桌面进行连接,对Windows CE Terminal Services Client (cetsc.exe)的配置也就非常重要。

启动CETSC后,CETSC读取.rdp文件中的设置,或是根据注册表HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client下的设置连接远程主机。下面就是一个可以设置的选项列表(对.rdp文件和注册表均适用)。注意此处以在Thin Client上广泛使用的Windows CE 5.0为例;Windows CE 6的设置有所不同。此外这些设置不适用于Windows Mobile。

Value Type Description
AlternateShell String 如果指定了该值,则RDP连接后登录到指定的shell程序,或执行指定的应用程序,而不是登录到通常的shell (explorer.exe)。
AudioRedirectionMode DWORD 指定声音在哪里播放,默认值为0:
0 – 在远程主机播放
1 – 在本地 (Thin Client)播放
2 – 不播放声音
AutoReconnectEnabled DWORD 当连接异常中断时,是否允许自动重新连接,默认值为1:
0 – 不允许
1 – 允许
BBarEnabled DWORD 是否显示屏幕顶部的连接栏 (Connection Bar),默认值为1
0 – 不显示
1 – 显示
BBarShowMinimizeBtn DWORD 是否显示连接栏上的最小化按钮,默认值为1
0 – 不显示
1 – 显示
BBarShowPinBtn DWORD 是否显示连接栏上的固定按钮 (Pin Button),默认值为0
0 – 不显示
1 – 显示
BBarShowRestoreBtn DWORD 是否显示连接栏上的还原窗口大小按钮 (Restore Button),默认值为1
0 – 不显示
1 – 显示
BBarPinned DWORD 是否自动隐藏连接栏,默认值为1
0 – 自动隐藏连接栏
1 – 一直显示连接栏
BitmapCacheSize DWORD 以KB为单位指定内存里的位图缓冲区大小,默认值为1500,最大值为32000
BitmapPersistCacheLocation String 指定位图缓冲区的位于何处,默认值为\Temp
BitmapPersistenceEnabled DWORD 指定是否允许位图缓冲。默认值为0
0 – 不允许
1 – 允许
ColorDepthID DWORD 颜色深度,以bpp (bits per pixel)为单位。默认值为4
0 – 4 bpp
1 – 8 bpp
2 – 15 bpp
3 – 16 bpp
4 – 24 bpp
Compress DWORD 是否启用文件和目录压缩,默认值为1
0 – 不启用
1 – 启用
ConnectToServerConsole DWORD 指定是否连接到远程主机的Console session。对于Windows x68和Windows CE来说,可以用 mstsc /console 或 cetsc /console命令连接到Console session,不需要该选项。该选项只用于不使用Windows作为OS的Thin Client。默认值为0
0 – 不连接到Console session (连接到Terminal Services session)。
1 – 连接到Console session
由于Windows XP无Console session和Terminal Services session之分,该参数对XP无效。
DesktopHeight DWORD 以像素为单位指定屏幕高度,默认为1024
DesktopWidth DWORD 以像素为单位指定屏幕宽度,默认为1280
Disable Full Window Drag DWORD 指定拖动窗口时是否显示窗口内容。默认值为1
0 – 不显示
1 – 显示
Disable Menu Anims DWORD 是否允许菜单动画显示。默认值为1
0 – 不允许
1 – 允许
Disable Themes DWORD 是否允许显示主题。默认值为0
0 – 不允许
1 – 允许
Disable Wallpaper DWORD 是否允许壁纸。默认值为1
0 - 禁止壁纸
1 – 允许壁纸
DisableFileAccess DWORD 指定用户是否有权访问本地(Thin Client上面的)文件系统。默认值为1
0 – 允许用户访问本地文件系统
1 – 禁止用户访问本地文件系统
Domain String 要连接的远程主机所在的域
EnableDriveRedirection DWORD 是否允许重定向驱动器。默认值为1
0 – 不允许
1 – 允许
EnablePortRedirection DWORD 是否允许重定向串口 (COM口)。默认值为1
0 – 不允许
1 – 允许
EnablePrinterRedirection DWORD 是否允许重定向打印机。默认值为1
0 – 不允许
1 – 允许
EnableSCardRedirection DWORD 是否允许重定向智能卡 (Smart Card)。默认值为1
0 – 不允许
1 – 允许
KeyboardHookMode DWORD 设置Alt – TAB键的作用。默认值为2
0 – 显示本地 (Thin Client)的项目
1 – 显示远程 (Server)的项目
2 – 全屏时显示远程项目,窗口时显示本地项目
MaxReconnectAttempts DWORD 设置连接丢失时重新尝试的次数。默认值为20
MCSPort DWORD 设置RDP服务的端口。仅用于非Windows-based的Thin Client。
MRUx (x=0,1,2..) String MRU = Most Recently Used,最近访问过的主机列表
Password Binary 登陆远程主机用的密码
ServerName String 远程主机名或IP地址
StartFullScreen DWORD 是否以全屏模式开始远程连接,默认值为1
0 – 不以全屏模式
1 – 以全屏模式
UserName String 登陆远程主机用的用户名
WorkingDir String 工作目录