今天把程序完善了一下，然后重新运行。在碰见blogger的发布限制之前，我先遇到了程序Bug……今天往程序里面加了转移评论的功能，这个bug就是出在这个地方。有的blog是草稿，然后程序访问的时候，返回的是访问被拒绝。程序在这个页面里面找评论，于是挂了……改了之后，重新运行，碰见了blogger的发布限制……原打算明天再说，但是Roy的话给了我启发。虽然单个blog有限制，但是能够开多个blog，然后把那些blog导出，再导入技术blog。这样就解决了问题，使得整个搬家工作能够在一天内做完。现在看起来，Blogger的限制大约是每天50贴，还算合理。但是那些搬家程序不知道是怎么混的～另外，总结经验，以后要先尝试运行一遍，再将改动予以实行……
其实我有一个技术blog，但是没什么人去……原来架在mblogger.cn上，但是这个地方越来越缺乏管理，用户流失严重，就是懒得搬。话说这个也是我一开始写的blog。这个地方基于.Text平台，提供metaWeblog接口。我打算搬到blogger。在网上找了一下，有现成的博客搬家的地方。但是试了一下，都不能用……比如说，http://blogmover.redv.com/，这个地方能够读出原来的blog，但是写到blogger的模块出问题了……又如maikr，需要登录才能用，而网站挂了，于是注册不了……最后只好自己写一个搬家程序了……既然近期学习python，那么练一下也好。python自带xmlrpclib模块，能够和metaWeblog通讯。尝试了一下，metaWeblog的接口还真好用，不一会儿就能够读出blog了。话说python生产力就是高阿，随便弄一下就好了，有什么问题搜一下也能很快解决。如果…… 如果python不是用空格/缩进表示层次的话，那就更好了！然后去研究写到blogger的方法。这时候我发现，虽然metaWeblog基于blogger API，但是那是老的blogger API……新的Blogger被Google整合到了GData API框架里面，于是巨麻烦无比……Google的人们是不是太聪明了…… 总是觉得自己发明的东西比较好，不用现成的…… 然后弄出麻烦的东西，光了解就要不少时间……还好有python的gdata库，自带了访问blogger服务的样例。但是又有一个问题：貌似Blogger的GData访问方法被GFW掉了……只好改了，用SSL，又耗掉一堆时间……最后，折腾了一大堆，终于是把这个搬家程序写出来了……但是，最后用的时候碰见问题了： status 400Blog has exceeded rate limit or otherwise requires word verificationfor new posts COW！ 这可怎么搬家啊……
从前在BIOS里面见过关于A20地址线的选项，后来启动FreeDOS什么的时候好像也见过A20的事情，一直不知道是干嘛的……后来某天看BSD loader代码的时候，看见启用A20地址线的事情…… 于是去wiki上查了一下，原来是这么回事……8086那个时候，地址线只有20位，叫做A0~A19，也就是没有A20地址线的。2^20=1M，因此那时能够访问的内存范围是1M。那个时候也分段，地址由段寄存器左移4位，加上基地址，得到物理地址。段寄存器和基地址都是16位的，这样就能够访问20位的空间了。但是有个问题……段寄存器最大FFFF，基地址也是。所以地址最大是FFFF:FFFF，但是FFFF左移四位得到FFFF0，加上FFFF，得到10FFEF，也就是FFFFF+FFF0。但是物理内存只有1M，最大物理地址范围应该是0～FFFFF，因此多了FFF0，超出了物理地址范围。这样，访问到超出范围的时候，8086会自动做一个处理，把高位的1删掉，也就是10xxxx->xxxx，然后返回对应位置。 按理来说，这是个bug，8086应该返回个错误啥的。但是，既然这已经是事实了，有的程序就开始用这一点，来访问0～FFEF的内存范围，差不多是前64K少一些的范围。这就为日后的新CPU出了难题…… 80286，80386等等更NX的处理器出现了，他们支持访问更大的内存范围。自然，10xxxx和xxxx也就指向了不同的地方。但是，跑那些用到从前bug的老程序的时候，就出问题了…… 改了10xxxx的xxxx不变，导致乱七八糟的问题……IBM他们就脑残了一下，说，我们在A20地址线（也就是那个1的位置……）装个开关吧～ 然后又脑残一下，看见键盘控制器正好有一根线空着，就说，我们让键盘控制器来管这个开关吧～于是，著名的Gate A20就这么产生了……打开：输出0xd1到0x64端口，等8042（键盘控制器）空了，再输出0xdf到0x60端口 保护模式的操作系统，自然都需要访问1M以上的内存，而且不希望某一位地址一直是0。所以保护模式的操作系统启动步骤之一，就是打开A20。但是，IBM那些人们没想到，日后有些环境需要频繁切换A20端口，而键盘控制器是如此之慢…… 他们当初认为，这个切换发生频率很低，因此慢一点没关系…… 于是就有了Fast Gate A20的事情。利用0x92端口，读入之后，把第二位改成1，然后写回去，能快一点。但这个引起了新的bug。毕竟只有某些系统支持0x92端口的这个用发，而有些系统…… 改了0x92会导致没有显示之类的，所以有危险……后来么，intel也不爽了，就搞了个0xee端口，读打开A20，写关闭…… 速度比从前更快了…… 于是，这样就有了3中方法，由慢到快。某些程序就一个一个试，试了一个验证一下。但是，缓存又来捣乱。有的系统虽然开了A20，还是会把几个字节缓存起来，10xxxx和xxxx一样…… 总的来说，A20就是个麻烦的事情，当初搞个BIOS调用之类的也就over了么…… 不过现在的新的系统，基本上都没有A20的问题了，虽然打开A20还是系统启动的必要步骤之一……参见A20 – a pain from the past
话说这个80286搞出来的保护模式，又是分段又是分页，从前没好好研究过，从来就没有搞清楚过……家里翻到一本老教材，《微型计算机技术及应用——从16位到32位》，里面讲80386的章节，终于基本上讲清楚了……假设现在是即分段又分页的情况…… 首先，程序里面引用一个地址，其实指的都是逻辑地址。这样的引用需要两部分数据：段选择子以及段内偏移量。然后么，段选择子基本上就放在老的段寄存器里面，不过现在是起一个索引的作用。段选择子其实分几部分。总共16位，前13位是个索引，接下来1位指定是到LDT还是GDT里面找。最后两位是特权级。LDT和GDT，一个是局部描述符表，一个是全局描述符表，反正是两张表，存了一大堆的段描述符。表的位置放在LDTR和GDTR两个寄存器里面。现在研究内存访问，所以只讨论存储段描述符，每个8个字节，包括了段的开始地址（32位）、界限（20位），还有一堆标志什么的。用前面那个索引，从LDT或GDT里面找到描述符，然后就有了段基地址。之前需要检查偏移量符合界限，以及其他各种权限之类的检查。最后加上偏移量，我们就得到了线性地址～ 分段部分完成～ 然后，线性地址有32位。把它分为3段：10位，10位，12位。系统有一堆控制寄存器，其中，CR3里面，保存着页目录的基地址。页目录也是一个表，每项4个字节，每个里面都有一个页表基地址…… 当然还有一堆别的东西，什么权限、标志之类的……线性地址的第一段，10位，就是这个表的索引。把它乘以4（每项4个字节么……），加上CR3里面的基地址，就有了页表的基地址……页表的结构也差不多，也是4个字节一项。用线性地址第二段，10位，乘以4，加上页表基地址，就有了页基地址……最后，拿第三段，12位，加上业基地址，终于…… 我们得到了物理地址！ 接下来么，做一些数学计算。页内偏移量（线性地址第三段）有12位，2^12=4*1k=4k，和一页大小为4k吻合～线性地址前两段，每段10位，对应的表可以有1k项。所以，经过这两级，可以索引1M个页。每个页4k那么大，所以…… 总共4G。其实这个计算很NC对吧…… 总共32位，没有1位浪费，全都用来索引的情况下，当然可以索引2^32=4G……然后，一个页表有多大呢？一项4字节，共1024字节，所以一个页表4k大。总共1k个页表，所以页表总共占4M那么多地方。页目录表么，就4k大啦，比起页表也不算什么……然后，段的界限只有20位，2^20=1M，难道一个段只有1M那么大？其实剩下的标志里面有一个粒度位G，能够指定界限以1字节还是4k为单位。以4k为单位的时候，就能有1M*4k=4G那么大的段，这个就很完美了么～段选择子有16位，因此最多有2^16=65536个段，真多…… 然后，这样n级转换不是很慢么，所以系统里还有转换缓冲区。貌似这个区操作系统还可以控制，让哪些转换结果留在缓冲里面，这样下次碰见一个逻辑地址就不用多级转换了……另外，程序用到段选择子的时候，必然都在6个段寄存器里。所以，每次把东西扔到段寄存器里面去，CPU就把对应的段描述符装到一个隐藏的寄存器里面，这样，大部分时间就不用去查LDT/GDT之类的了……