Welcome to Neilpang's Blog!

记录生活,分享知识,传播乐趣

如何从snapnames获得域名转移码

2013-10-27

Neil

域名

在snapnames购买的域名会被系统自动加上转移保护，官方说只要你选择transfer out域名之后，转移锁会自动解除，同时系统把转移码发送到你的邮箱里面：

然后再保存一下：

正常情况下，域名锁已经解除，并且你的邮箱应该收到转移码了。

但是我这次转移却失败了。收到邮件：

This email acknowledges your request to transfer out of Moniker.com the following domains. It also includes the authorization codes your gaining registrar will require you provide to initiate the transfer from their side.

To maximize security, these domains will remain unlocked for only 10 days, after which time your transfer out request will expire and you will need to submit a new request to Moniker.com. If you did not request this transfer out, or if you require assistance, please go to our support center at http://support.Moniker.com

Below are your requested domains and the authorization codes. Please consult the registrar to which you are transferring the domains for instructions on how use these codes.

The Reason Given For Transfer Was: Change Of Ownership

Domain Name,Epp AuthInfo (if applicable)
----------- ----------------------------

Errors:
Domain Name: Error Description
----------- ----------------------------
XXXXXXXXXX: This domain can not be transferred out due to domain security lock.

说因为安全原因。

于是尝试手动去除安全锁：

然后：

框是灰色的，不能选。上面也说明了，安全锁只能在转出时自动解除，不能手动解除。

试了很多次，都不行，于是找到页面上的客服邮箱写信：

没想到，第二天，收到退信，这个邮箱竟然不存在。

没想到，这么坑爹。

怎么办。这难住了我几天。

最后抱着试一试的态度，点开support网站，找到提交问题的地方：

填写了要求转出的信息。

等了一天，这次终于收到了回复：

说已经解除了拍卖锁，然后我再次transfer out，果然成功了。

再去转别的域名，还是转不成功。于是我再次写信去，语气比较严重，要他们把我所有的域名都解锁。

好吧，大家记得以后有问题去support网站提交问题吧，不要直接发邮件了。

Read All
Windows 8.1 设置本地账户的方法

2013-10-21

Neil

其他分类

刚安装windows 8.1正式版, 安装完成之后, 提示设置账户. 貌似只能设置微软的在线账户, 之前的windows8有个选项可以只设置本地账户. 对于这种"改进", 我只想对微软说两个字: 呵呵.

幸好在网上找到了两个方法可以绕过:

1. 拔掉网线, 后退到上一步, 然后在下一步. 系统检测到你没有联网, 就不会提示设置在线账户了. 直接提示设置本地账户.

2. 如果你不喜欢这么暴力的方法, 还有比较文艺一点的. 在设置在线账户的框里面, 随便输入一个邮箱, 和一个密码, 系统检测不到账户, 就会在后面出现一行小字, 点击就可以创建本地账户了.

Have fun.

Read All
7z文件格式及其源码的分析(四)

2013-09-07

Neil

7zip
这是7z文件格式及其源码的分析系列的第四篇. 上一篇讲到了7z文件静态结构的尾header部分.这一篇开始,将从7z实际压缩流程开始详细介绍7z文件尾header的详细结构.

一, 第一个概念: coder.

在7z的压缩过程中, 一个非常核心的概念就是coder. 一个coder代表一个算法, 通常是指一个压缩或解压算法(也包括过滤算法和加密算法等). 例如, 在7z中lzma算法就是一个coder, deflate算法也是一个coder. 7z中用于加密的AES256算法也是一个coder.

所以概念上讲, 能处理一个文件流的算法就是一个coder. 这个"处理"的概念可以是压缩/解压, 加密等等.

(图1)

通常来讲, 一个coder只能处理一个输入流, 并且只有一个输出流. 比如把一个文件流压缩成一个输出流. 但是, 7z中有的coder可以把一个输入流处理成多个输出流, 反过来也可以把多个流处理成一个流. 比如7z的 BCJ2 coder, 它是一个过滤coder, 可以把一个exe文件过滤成四个输出流. 这样的话, 7z的coder概念得到了扩展. 就是可能同时处理多个输入流, 并且可能输出多个流:

(图2)

这里可以先简单的体验一下压缩的过程了:

1. 简单压缩过程, 把文件流交给lzma coder压缩.

(图3)

2. 多coder串联, 理论上可以串联任何两个coder, 而且串联的级数也是没有限制的, 可以串联任意多级. 当然, 由于熵的存在, 串联过个压缩coder是没有意义的.

这里示例的是最常用的一种方式,就是压缩并且加密.

(图4)

注意上图中的o1, 和 i2. o1是第一个coder的输出流, i2是第二个coder的输入流. 在实际操作中, 这两个流其实是同一个流, 直接把第一个的输出当做第二个的输入.

解压的过程就是上面的逆过程.

上图就是比较完整的一次压缩过程了.

二, 第二个概念 Folder, 不是文件夹.

这里的Folder要特别注意, 它不是我们通常指的文件夹. 它也不是任何物理上存在的东西.

7z在开始压缩之前, 会把文件分类, 大体上是按文件类型以及文件是否需要加密来分类的. 比如说, 把所有的exe文件分成一类(一个Folder), 或者把所有需要加密的文件分在一起. 等等. 具体分类方法以后再说. 这个分类方法并不重要, 7z的实现用的方法比较简单. 实际上如果要实现7z的压缩器的话, 这个分类方法你说了算. 你可以给每个文件划分成一个Folder.

我们看一个例子:

(图5)

在这个例子中, 我们共有5个文件需要压缩.

1. 首先, 通过一定的分组方法, 我们分成了两个Folder, 第一个Folder包括: a.exe, b.exe 和 c.dll 三个文件. 第二个Folder包括:a.txt 和 b.txt.

2. 对Folder1来说, 它包含三个文件, Folder1就简单的把三个文件串联起来,当做一个大文件, 作为输入流 i1 给Coder1 用. 后面的过程就就是上面的图4 的内容了.

在7z源码的: \CPP\7zip\Archive\7z\ 这个目录下,有 7zFolderInStream.h 和7zFolderInStream.cpp 专门处理把多个文件串联伪装成一个文件的任务. 从Coder1 的角度看, 它只知道有个文件流 i1, 并不知道这个i1 是一个真实的文件还是由一个Folder伪装的.

实际上, 7z概念上最小的压缩单位不是文件, 而是Folder, 它会先把所有的文件都归到一个相应的Folder中, 然后让这个Folder作为文件流, 流过若干个Coder. 我们再抽象一下上面的压缩过程:

(图 6)

上图中的字母 'i' 表示输入的意思, 'o' 表示输出. 后面的数字表示序号. 简单解释一下, 这个Folder流最初是作为Coder1 的输入流i1. Coder1 的输出流是o1. 这个o1又作为 i2 输入给Coder2用, 然后又是Coder3.

值得注意的是最后一个coder的输出流 o3. 它就是压缩的最终输出结果了. 它在7z中叫做一个PackedStream. 就是打包的流. 我们叫做p1吧. 如果有多个Folder, 那每个Folder就会有一个或多个PackedStream. 所以所有文件压缩之后就会有 pn. 这n个packedStream会被按顺序存储在 7z的文件主体, 就是上一篇文章中介绍的第二部分.

每个Folder 包含了哪些文件, 每个文件大小等等这些详细信息都存贮在7z的尾文件头中了. 在7zformat.txt中有这一段:
```
      NumFolders
      Folders[NumFolders]
      {
        NumCoders
        CodersInfo[NumCoders]
        {
          ID
          NumInStreams; //表示这个coder 所接受的输入流的个数, 一般是1个
          NumOutStreams; //表示这个coder的输出流的个数, 一般是1个.
          PropertiesSize //一个int值, 表示后面Properties的字节长度
          Properties[PropertiesSize] // 字节数组, 表示这个coder的一些设置信息, 比如压缩级别, 或者AES加密的IV等等. 
        }
        NumBindPairs  // 表示bindpair 的个数. bindpair表示输入流和输出流的绑定关系.  例如上面的图6中, o1和i2是绑定的, o2和i3是绑定的.
        BindPairsInfo[NumBindPairs] //bindpair的数组, 记录每一个bindpair.
        {
          InIndex;  //这个绑定的输入index,  就是上图中对应的 i后面的序号. (不好意思, 画图的时候没注意,图上下表是从1开始的,但是实际上,你懂的, 都是从0开始的.所有上面图中的下标都要减一.)
          OutIndex; //绑定对应的输出index, 就是对应上图中o后面的序号.  同上. 
        }
        PackedIndices //这表示这个folder最终输出的packstream在所有packstream中的序号.
      }
      UnPackSize[Folders][Folders.NumOutstreams] // 这是一个二位数组, 记录每个Folder对应的输出流的个数.
      CRCs[NumFolders] //这是一个Crc的数组, 没个folder 流的crc, 7z目前没有使用这一个字段. 
```
稍微解释一下上面的结构:

1. NumFolders, 显示一个int32值, 它记录了7z文件中共有多少个Folder.

2. 后面那是folder数组, 一次排布每个Folder. 每个Folder结构如下:

3. NumCoders, int32值, 记录了这个Folder总共进过了几个coder.

4. 后面就是它的所有Coder的数组, 每个coder的结构: 显示一个coder 的id. 就是coder的唯一标示符. 这个id的定义在: DOC/目录下的 methods.txt.

5. 更详细的信息, 请看上面代码后面的注释吧.

6. 我再强调一点,我画图的时候没有注意,所以图中的i和o后面的序号都是从1开始的, 实际上,你懂的, 每个存储的序号都是从0开始的, 没有例外. 如果你发现哪里的序号和我说的不一样, 请检查这个. 没有例外, 所有的序号都是从0开始的. 包括以后我可能会画的图. 记住都是从0开始的.

7, 再有一点就是, 比如上图中的folder经过了 coder1, coder2 和coder3 这三个coder. 实际才存储这三个coder的时候, 是按逆序存储的, 就是先存Coder3, 然后是coder2, 最后是coder1. 这是为了方便解压.

上面的图6就是一次比较完整的压缩流程, 解压的流程就是反过来, 先分别构建coder1, coder2 和coder3, 然后逆向流动就最终解压了.

每个Folder都会经过一次完整的压缩过程.

好了, 主要的压缩过程和结构已经介绍完了. 下一篇将给大家介绍剩下的文件详细信息的存储方式, 以及最终的Header的生成方式.

最后还是欢迎大家访问我的独立博客: http://byNeil.com

写这么多字, 画图都不容易, 帮顶一下吧, 小伙伴们.
Read All
7z文件格式及其源码的分析(三)

2013-08-31

Neil

7zip
上一篇在这里. 这是7z文件格式分析的第三篇, 相信有了前两篇的准备,你已经了解了7z源码的大致结构, 以及如何简单调试7z的源码了. 很多同学是不是迫不及待想要拔去7z的神秘外衣,看看究竟了. 好, 这就带你们一探乾坤. 本文开始,我们详细介绍7z的文件存储结构.

要了解7z的结构, 当然最好从官方的说明开始, 尽管这个说明非常简略, 但它的确是我入门时的救命稻草.

打开源码的 "DOC" 目录. 这里面就是官方所有的文档了. 其中只有二个文档跟结构相关:

1. 7zFormat.txt, 这是我们的主角, 里面介绍了7z文件的大体结构.

2. Methods.txt, 这里面介绍了7z压缩算法id的编码规则, 以后会用到.

我们从7zFormat.txt文件开始.
```
Archive structure
~~~~~~~~~~~~~~~~~ 
SignatureHeader
[PackedStreams]
[PackedStreamsForHeaders]
[
 Header 
 or 
 {
 Packed Header
 HeaderInfo
 }
]
```
上面就是7z文件的总体结构了. 我来稍微解释一下. 上面的代码中, 从波浪线往后开始算. 7z的文件结构基本上分为三部分:

1. 前文件头(就是最前面的header).

2. 压缩数据.

3. 尾文件头(就是放在文件末尾的header).

一, 前文件头就是上图中的 "SignatureHeader". 它是32个字节定长的. 前文件头其实记录的信息很少, 它的主要目的是记录尾文件头的位置, 压缩的主要结构都是存在尾文件头中.

它的结构如下:
```
SignatureHeader
~~~~~~~~~~~~~~~
 BYTE kSignature[6] = {'7', 'z', 0xBC, 0xAF, 0x27, 0x1C};
ArchiveVersion
 {
 BYTE Major; // now = 0
 BYTE Minor; // now = 2
 };
UINT32 StartHeaderCRC;
StartHeader
 {
 REAL_UINT64 NextHeaderOffset
 REAL_UINT64 NextHeaderSize
 UINT32 NextHeaderCRC
 }
```
先是固定的6个字节的值, 前两个字节的值是字母 '7' 和'z' 的ascii值. 后面四个字节是固定的: 0xbc, 0xaf, 0x27, 0x1c

然后是两个字节的版本号, 注意主版本号在前面, 次版本号在后面. 目前的版本号是: 0.2, 注意这是7z文件格式的版本号, 不是7z软件的版本号.

然后是四个字节的 UINT32 的值, (注意, 7z的所有数据都是采用小端在前的存储, 所以要注意这四个字节的实际存储顺序是低位字节在前面, 高位字节在后. 后面的所有数据都是这种结构, 所以以后就不再强调了. ) . 这4个字节的值是做什么的呢? 先抛开这四个字节本身, 前文件头的32个字节中, 已经用去了 6 + 2 +4 =12 个, 还剩下20个字节. 对了, 这四个字节就是剩下的20个字节的CRC校验值. 具体的CRC算法源码, 在源码中的 "C" 文件夹下的 '7zCrc.c' 和 '7zCrc.h'.

最后这20个字节要一起介绍了. 先是8个字节的UINT64的值, 它记录的是尾文件头(上图中的NextHeader)与前文件头的距离, 这个距离是不算前面这32个字节头的, 也就是抛开前面32个字节开始计数的(解压器通过读取这个值,然后从第33个字节开始直接跳过这个距离, 就可以找到尾文件头了). 然后是8个字节的值, 记录了尾文件头的大小(解压的时候, 通过这个值就能读出尾文件头的长度了). 最后还有4个字节的值, 它也是一个Crc校验值, 是整个尾文件头的校验值.

这里需要注意的是, 上图中用的是 "REAL_UINT64" 这个表达方式, 它的意思就是我们通常理解的占8个字节的UInT64的值(当然是小端存储的啦). 这里用了"real", 真. 那是不是还有"假"的InT64呢. 答案是肯定的. 7z为了兼容压缩大文件(大于4G),这个问题曾一度是zip文件的噩梦, 早期的zip只能压缩小于4G的文件, 并且压缩后的总文件大小也不能超过4G, 后来专门做了标准升级. 好了扯远了. 7z一早设计就考虑到了大文件的问题, 所以很多地方都必须用int64来表达, 这样也会带来一个问题, 就是绝大多数case下, 都不可能超过4G(试问一下,你平时有多少压缩文件超过4G 呢), 所以呢, 就会造成8个字节的int64根本用不上, 多余的字节浪费了. 尤其在小文件压缩的时候, 很影响压缩比. 所以呢, 7z采取了一种巧妙的方法. 就是int64并不是都用8个字节存储, 它用一种简单的编码方式,进行变长存储. 在这个文件中也有描述:
```
REAL_UINT64 means real UINT64.
UINT64 means real UINT64 encoded with the following scheme:
Size of encoding sequence depends from first byte:
 First_Byte Extra_Bytes Value
 (binary) 
 0xxxxxxx : ( xxxxxxx )
 10xxxxxx BYTE y[1] : ( xxxxxx << (8 * 1)) + y
 110xxxxx BYTE y[2] : ( xxxxx << (8 * 2)) + y
 ...
 1111110x BYTE y[6] : ( x << (8 * 6)) + y
 11111110 BYTE y[7] : y
 11111111 BYTE y[8] : y
```
上面就是编码方式: 就是根据第一个字节的内容来判断后面还有多少个字节.

如果第一个字节的最高位是 0, 那后面就没有字节了. 范围在 0-127.

如果第一个字节的最高两位是 1, 0, 表示它后面还有一个字节. 读取方式是: ( xxxxxx << (8 * 1)) + y

依次类推, 不再详细介绍了.

它的写入方法在: \CPP\7zip\Archive\7z\7zOut.cpp 文件的第204行:
```
void COutArchive::WriteNumber(UInt64 value)
{
  Byte firstByte = 0;
  Byte mask = 0x80;
  int i;
  for (i = 0; i < 8; i++)
  {
    if (value < ((UInt64(1) << ( 7  * (i + 1)))))
    {
      firstByte |= Byte(value >> (8 * i));
      break;
    }
    firstByte |= mask;
    mask >>= 1;
  }
  WriteByte(firstByte);
  for (;i > 0; i--)
  {
    WriteByte((Byte)value);
    value >>= 8;
  }
}
```
它的读取方法在: 7zIn.cpp 的第210行:
```
UInt64 CInByte2::ReadNumber()
{
  if (_pos >= _size)
    ThrowEndOfData();
  Byte firstByte = _buffer[_pos++];
  Byte mask = 0x80;
  UInt64 value = 0;
  for (int i = 0; i < 8; i++)
  {
    if ((firstByte & mask) == 0)
    {
      UInt64 highPart = firstByte & (mask - 1);
      value += (highPart << (i * 8));
      return value;
    }
    if (_pos >= _size)
      ThrowEndOfData();
    value |= ((UInt64)_buffer[_pos++] << (8 * i));
    mask >>= 1;
  }
  return value;
}
```
这里贴出来给大家参考一下. 其实, 后面提到的Uint64如果没有特别说明是8个字节, 那它都是采用这种压缩方式存储的. 但是注意UInt32 无论何时都是占4个字节的, 没有采用压缩.

二, 第二部分比较简单, 它会比较大, 简单的说, 它就是文件压缩后的压缩数据存放地点. 结构如下:
```
[PackedStreams]
[PackedStreamsForHeaders]
```
简单的说, 7z会把文件压缩成若干个"Pack", 就是包的意思, 这里就是按顺序存储这些pack的. 每个pack的位置和大小信息都会记录在尾header中, 解压的时候就会从这里读出pack,然后解压出来. 这里都是简单的排布压缩后的数据, 所以没有多少细节需要介绍的.

三, 真正复杂的主角出场了, 尾文件头, 就是7z中所谓的 nextHeader.

Header structure
~~~~~~~~~~~~~~~~
{
ArchiveProperties
AdditionalStreams
{
PackInfo
{
PackPos
NumPackStreams
Sizes[NumPackStreams]
CRCs[NumPackStreams]
}
CodersInfo
{
NumFolders
Folders[NumFolders]
{
NumCoders
CodersInfo[NumCoders]
{
ID
NumInStreams;
NumOutStreams;
PropertiesSize
Properties[PropertiesSize]
}
NumBindPairs
BindPairsInfo[NumBindPairs]
{
InIndex;
OutIndex;
}
PackedIndices
}
UnPackSize[Folders][Folders.NumOutstreams]
CRCs[NumFolders]
}
SubStreamsInfo
{
NumUnPackStreamsInFolders[NumFolders];
UnPackSizes[]
CRCs[]
}
}
MainStreamsInfo
{
(Same as in AdditionalStreams)
}
FilesInfo
{
NumFiles
Properties[]
{
ID
Size
Data
}
}
}

尾header的结构非常复杂, 里面有很多压缩概念, 如若没有理解压缩过程, 单独的纯字节层面介绍是没有意义的.

我们下一篇开始介绍详细的7z压缩流程, 介绍7z是如何把一系列的文件, 压缩成一个大文件的, 怎样利用压缩算放, 怎样排布文件结构. 同时我们再一边来介绍这个尾header的结构.

希望大家多多支持, 给我动力写下去.

欢迎大家访问我的个人独立博客: http://byNeil.com

记得顶啊, 小伙伴们.
Read All
7z文件格式及其源码的分析(二)

2013-08-18

Neil

7zip

这是第二篇, 第一篇在这里: 这一篇开始分析7z的源码结构.

一. 准备工作:

1. 源码下载:

可以从官方中文主页下载:http://sparanoid.com/lab/7z/．　　为了方便，　这里直接给出下载链接：　http://downloads.sourceforge.net/sevenzip/7z920.tar.bz2　．

2. 工具准备:

源码中给的工程文件都是vc6.0的工程. 作者说他不喜欢新vs的界面. 哎. 不过没关系, 我们使用VS2008也一样可以. 有极少地方需要修改一下. 我们使用VS2008 sp1 作为开发环境.

二. HelloWorld:

我们在根目录下新建一个目录"7z", 把源码都解压到这个位置.

我们稍后再详细解释这些目录的意思. 先来一个helloworld, 程序员的最爱.

请直接打开这个路径: 7z\CPP\7zip\Bundles\Alone\

用vs打开其中的 Alone.dsw 文件. 提示要转换工程文件. 点击同意. 然后编译这个工程. 如果不出意外的话, 应该提示你编译成功了.

这个时候, 打开 c:\util\ 目录. 里面已经生成7za.exe. 注意, 这里是C盘的绝对路径 : c:\UTIL\7za.exe

好了, 这个7za.exe 就是一个包含全部7z功能的压缩,解压命令行工具了.

我们可以从命令行进入该目录. 输入 7za.exe 回车. 就能看到它的帮助信息啦.

我们先拷贝一个文件到这个目录, 比如拷贝一个test.txt 到c:\util\ 里面去. 我们用命令行来压缩它.

==============

c:\util>7za.exe a test.7z test.txt

==============

这个命令把test.txt 压缩成test.7z. 这两个文件名都是可以带路径的, 为了方便, 我们都拷贝到当前目录了.

恩, 我们再来试试解压.

==============

c:\util>7za.exe x test.7z -oout

==============

这个命令可以吧test.7z 解压到当前的out目录下.

试试这两个命令吧, 是不是还不错.

三, 目录结构详解:

我们先回到最外层目录:

7z源码基本上是按文件类型分类的.

1. 上面的ASM目录, 其中保存汇编代码. 为了极限的性能, 7z使用了部分汇编代码, crc计算, 和aes加密. 这两点都不是必须的, 实际上, 它们都有c语言的实现. 7z会检测, 如果cpu提供了硬件的aes指令, 就会使用硬件aes汇编指令, 而不会使用自己的aes函数.

2. "C" 目录是7z的核心. 实际上, 7z所有的核心算法都是用c语言实现的. 包括所有的压缩算法, 以及我们的主角7z打包算法. 这些c代码非常强悍, 部分代码可以跨平台编译, 甚至能在嵌入式平台上编译.

(a) 　这里面有几个工程文件值得我们注意, 找到这个位置: 7z\C\Util\7z

我们来编译它. 它会在debug目录下生成 7zdec.exe

这是一个最小化的指包含7z解压器的独立exe程序. 有了它就可以解压文件了.

(b) 找到这个目录, 7z\C\Util\Lzma

编译之后也会在绝对目录生成. c:\util\7lzma.exe. 这是一个lzma压缩算法的工具. 只能压缩或解压单个文件. 只包含lzma算法.

这可以用来测试lzma算法.

(c) 打开这个目录 7z\C\Util\LzmaLib.

这个工程用来生成只包含lzma算法的 dll. 以便你的程序调用lzma算法.

3. "CPP" 目录是也是7z的重点.

前面说了核心的算法都在C目录下面. 那么CPP目录是做什么的呢. 除了核心的算法之外, 7z还有非常丰富的外围功能. 就是他的文件管理器, 以及右键菜单支持等等. 这些与UI和系统相关的功能都是用c++实现的. 此外, C中的核心算法在cpp目录中都有c++的面向对象的封装. 我们来逐一介绍它的子目录:

a ) "Windows" 目录.

其中包含了与windows集成的功能. 包括菜单集成, 剪贴板支持, 文件io,等等.

b) "Common" 目录.

通用的工具类.

c ) 我们重点介绍 7zip 目录:

(1) "Archive" 目录. 包含各种 archive ("打包") 算法的代码. 因为7z不光支持7z文件, 还支持zip, rar, chm等等其他的打包文件格式.

这里面每个目录就是一种格式. 7z目录当然就是我们的主角7z格式了. ( 这里面的代码是对C文件夹里面的代码的c++封装. ) 这里面有一个工程文件.

打开这个工程文件, 然后在工程上面点右键,查看属性:

可以看到, 它的输出路径是: C:\Program Files\7-zip\Formats\7z.dll

这是什么意思呢? 对, 这个工程就是封装7z格式的dll. 这个工程的目的就是给我们演示如何让7z支持我们的自定义格式. 具体怎么实现自定义格式, 可以参考这个工程以及它周围的其他文件夹格式, 比如:Cab, Chm, 等等. 实现相应的com接口, 然后编译到这个目录下, 7z就能自动调用了. 以后有时间我们再详细介绍这个.

(2) 再来看 "Bundles" 目录.

这里面的Alone目录, 我们在前面写 helloworld 的时候已经见识过了. 它是一个包含全部7z功能的console 的exe.

其中我们再介绍另一个重要的目录, 就是Format7zF.

打开它, 编译, 会提示几个链接错误. 原因是因为作者使用的是vc6. 和我们使用的vs2008一些编译选项不支持了.

分别在这几个汇编文件上点击右键:

找到"CommandLine" 参数, 把其中的参数删除: -omf -WX -W3, 只保留 -c

然后再编译就会成功了.

编译完成之后, 它会在绝对目录下生成一个dll. C:\Program Files\7-Zip\7z.dll

这个dll是做什么的呢?

它是包含7z全部功能的dll. 第三方的程序可以调用这个dll实现7z的所有功能. 包括7z自己本身的文件管理器都是通过这种方式调用的.

好了, 基本上 7z源码的主要目录都介绍完了. 大家有什么疑问可以留言交流.

我们之后的讲解都将使用: 7z\CPP\7zip\Bundles\Alone 这个目录下的工程配合命令行参数来调试讲解. 因为这是一个包含7z全部功能的console程序, 简单好调试.

如果你不想了解7z的文件结构, 只是想在你的程序中集成进处理7z文件的功能. 那么已经足够了. 可以打开上面介绍的相应工程, 把源码集成到你的工程中, 或者直接调用: 7z\CPP\7zip\Bundles\Format7zF 生成的dll. 都是不错的选择.

下一节开始, 我们将开始讲解7z的文件格式结构了. 完成以后, 我会把地址更新到这里.

欢迎大家访问我的独立博客交流讨论. http://byNeil.com

Read All
等等,你可能误解nodejs了--通俗的概括nodejs的真相

2013-08-16

Neil

nodejs

最近刚把产品从cpp平台迁移到nodejs平台了. 很多以前关于nodejs的观念被颠覆了. 这里分享出来, 欢迎大家批评指正.

"nodejs是做服务器端开发的, 它一定和web相关,几乎是用来做网站开发的." 这是我之前一直的观念. 相信这可能也是很多人对nodejs的初步认识吧. 但后来我才发现, 我可能错了.

第一个问题: nodejs到底是什么?

http://nodejs.org/ 官方主页上有一段解释: "Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices."

我们注意其中的几个关键字: nodejs是一个平台, 它构建在chrome的v8引擎之上, 能简易的构建快速,可扩展的网络应用程序.......

这里官方用的"网络应用程序", 整个描述没有提到"web", "server" 等等概念. 这段话的描述中, 有两个是重点, 第一,就是chrome的v8引擎. 第二, 是事件驱动的非阻塞io模型. 把握住这两点, 我觉得就算掌握了nodejs的真谛了.

这么说吧, 举个例子, 类比来说, 概念上, nodejs相当于.net, jvm 或者 python. 它是一个运行平台, 只不过它运行的是javascript语言而已. 类似地, .net一般运行C#, vb等编译过后的il. 而jvm一般运行java编译成的字节码, python一般运行python语言.

你可能要问, 那么nodejs是不是也能实现 .net等等这些平台的功能呢. 比如写个窗口桌面程序, 做socket网络通信, 以及访问磁盘文件等等.

恩, 这些问题的答案都是肯定的.

nodejs核心主要是由两部分组成的:

第一, 是v8引擎, 它负责把javascript代码解释成本地的二进制代码运行.

第二, 是libuv, 类似windows上的窗口消息机制, 它主要负责订阅和处理系统的各种内核消息. 而且它也实现了消息循环(是不是很耳熟? 没错, 这个几乎就和windows 的窗口消息循环是一个概念.). 它的前身是linux上的libev, 专门封装linux上的内核消息机制. 后来nodejs重写了它, 并在windows上使用iocp技术重新实现了一遍. 所以nodejs现在能跨平台运行在windows上了.

nodejs其实就是libuv的一个应用而已.

你自己写程序也可以集成libuv进来, 这样你的c++程序就有了消息循环了. 不再是简单main函数了. 你可以订阅系统的事件, 然后当事件发生时, 系统会调用你的回调函数, 就跟windows上的button click事件一样方便. 而且是跨平台的哦. 是不是很酷. 你几乎可以订阅所有的系统事件, 比如socket事件, 文件读写事件等等.

nodejs简单的说只是把javascript解释成c++的回调, 并挂在libuv消息循环上, 等待处理. 这样就实现了非阻塞的异步处理机制.

那么为什么是javascript而不是其他的语言. 很简单, 因为javascript的闭包. 这非常适合做回调函数. 因为我们一般都希望当回调发生时, 它能记住它原来所在的上下文. 这就是闭包最好的应用场景.

这里有libuv的详细介绍 http://nikhilm.github.io/uvbook/.

好像扯远了, 说nodejs的, 怎么扯到libuv了. 很简单, 因为 nodejs只是libuv的一个应用. 先了解libuv才能了解nodejs的实质和前世今生.

我们再回来说nodejs.

从另一个角度看, 上面的工作都分别由v8和libuv做了. 那么nodejs到底做了什么呢? 我们先看一下nodejs的文档: http://nodejs.org/api/

对了,除了用javascript封装libuv框架之外, nodejs就是实现了这些api 功能. 这些api大部分是用javascript写的, 也有一部分是c++写的.

这是nodejs官方的仓库, https://github.com/joyent 其中有很多nodejs的插件. 有了这些nodejs就可以实现非常丰富的功能了.

作为结尾, 写一个简单的nodejs 常规helloworld 程序.

//test.js

//=================

console.log("hello world!")

//=================

存成test.js. 然后运行: node test.js

就能看到效果了.

怎么样, 看起来是不是很像python的感觉. 但是用的是javascript哦. 用这个代替python, 是不是爽死了.

就到这吧. 关于libuv, 关于nodejs插件. 等等话题, 希望能跟大家沟通交流.

欢迎大家访问我的独立博客: http://byNeil.com

Read All