昨天46级能够查分了，研究了一下……
主页面调用了一段javascript，验证码竟然是本地验证的…… 这个不说，其实最后查分就是通过XMLHttpRequest直接查…… 就没什么加密一类的事情……
之后找了一下，好像XMLHttpRequest这个东西还只有Javascript里面才有，python用起来还不方便…… 用FireBug试了一下，因为这个查分系统的请求里面没有数据，所以这个请求其实很简单，拿urllib糊弄一下就好了……
另外关于FireFox里面不能查的问题，貌似是FireFox的XMLHttpRequest在send(null)的时候HTTP头里面没有Content Length字段，其实send("")就可以了……
另外，最后这个系统还检查一下Referer，至少不是什么都不干……
1 import urllib
2 import urllib2
3
4 id = "Your ID"
5 t = "4"
6 url = 'http://cet.99sushe.com/cetscore_99sushe0902.html?t=' + t + '&id=' + id
7 values = {}
8 headers = { "Referer" : "http://cet.99sushe.com" }
9
10 data = urllib.urlencode(values)
11 req = urllib2.Request(url, data, headers)
12 response = urllib2.urlopen(req)
13 the_page = response.read()
14 result = the_page.split(',')
15
16 print "Listening :",result[0]
17 print "Reading :",result[1]
18 print "Mixed :",result[2]
19 print "Writing :",result[3]
20 print "Total :",result[4]
21 print "School :",result[5].decode('gb2312')
22 print "Your Name :",result[6].decode('gb2312')
23 print "Name1 :",result[7].decode('gb2312')
24 print "Name2 :",result[8].decode('gb2312')
25 print "Name3 :",result[9].decode('gb2312')
2009年2月25日星期三
2009年1月29日星期四
关于A20地址线的那些事情
从前在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
后来某天看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
2009年1月27日星期二
80x86 保护模式 内存访问 学习总结
话说这个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之类的了……
家里翻到一本老教材，《微型计算机技术及应用——从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之类的了……
2008年12月31日星期三
Blog Moved
这个Blog就用来发技术性的文章了~
这个blog没救了，最晚也就2008/12/31，之后就回滚成1991年了…… 走了走了……
Old Blog Link: http://computer.mblogger.cn/henryhu/posts/49530.aspx
2008年9月3日星期三
urxvt 的性能
转了KDE4之后，觉得 urxvt 的性能有严重下降，甚至都及不上 Konsole 了。
今天在网上搜，看见有说用 Xft，AA 越多，越慢……
想起我的 urxvt 用的Xft ，而且没有必要。改了之后，明显快多了么！
结论：新东西常常想着CPU强悍了，就不管性能了…… 或者 urxvt 因为是从旧时代过来的，还是怀旧啊。
看看这个数据吧。
我在我的Home目录，进行 find .操作。共71120行。
wc数据： 71120 72439 4312676
用Xft:
urxvt*font: -*-terminus-medium-r-*-*-14-140-*-*-*-*-*-*,-*-wenquanyi bitmap song-*-*-*-*-13-*-*-*-*-*-*-*
比较好的一次：0.128u 0.391s 0:10.98 4.6% 50+2947k 0+0io 0pf+0w
一般在12s左右徘徊
用x字体:
urxvt*font: xft:Terminus:pixelsize=14,xft:WenQuanYi Bitmap Song:pixelsize=14
比较烂的一次：0.177u 0.531s 0:02.66 26.3% 36+2121k 0+0io 0pf+0w
一般在2s左右徘徊
不输出（输出到 /dev/null）：0.067u 0.405s 0:00.47 97.8% 43+2541k 0+0io 0pf+0w
5～6倍的差距啊！ Xft在干嘛……
Old Blog Link: http://computer.mblogger.cn/henryhu/posts/85620.aspx
今天在网上搜，看见有说用 Xft，AA 越多，越慢……
想起我的 urxvt 用的Xft ，而且没有必要。改了之后，明显快多了么！
结论：新东西常常想着CPU强悍了，就不管性能了…… 或者 urxvt 因为是从旧时代过来的，还是怀旧啊。
看看这个数据吧。
我在我的Home目录，进行 find .操作。共71120行。
wc数据： 71120 72439 4312676
用Xft:
urxvt*font: -*-terminus-medium-r-*-*-14-140-*-*-*-*-*-*,-*-wenquanyi bitmap song-*-*-*-*-13-*-*-*-*-*-*-*
比较好的一次：0.128u 0.391s 0:10.98 4.6% 50+2947k 0+0io 0pf+0w
一般在12s左右徘徊
用x字体:
urxvt*font: xft:Terminus:pixelsize=14,xft:WenQuanYi Bitmap Song:pixelsize=14
比较烂的一次：0.177u 0.531s 0:02.66 26.3% 36+2121k 0+0io 0pf+0w
一般在2s左右徘徊
不输出（输出到 /dev/null）：0.067u 0.405s 0:00.47 97.8% 43+2541k 0+0io 0pf+0w
5～6倍的差距啊！ Xft在干嘛……
Old Blog Link: http://computer.mblogger.cn/henryhu/posts/85620.aspx
2008年6月13日星期五
FreeBSD 的 x11-themes/gnome-icons-crystal 的小问题
这也就是个图标主题，但是装好之后每次运行gedit等gtk+程序，就会说
Gtk-WARNING **: Theme directory of theme CfG-Crystal-SVG-1.2.0 has no size field
不知道是什么问题。本来以为缺了什么。后来去网上搜，发现类似的问题都是Theme directory 24x24/... of theme *** has no size field.
也就是说，对应的 theme directory 名字不见了。
由此怀疑index.theme内容有问题。打开一看，注意到有两个连续的逗号，而两个逗号之间是一个 theme directory 名字……
于是，把逗号删掉，问题解决……
交了一个 PR ，不知道会不会解决…… 说起来还是作者的问题。
Old Blog Link: http://computer.mblogger.cn/henryhu/posts/83455.aspx
Gtk-WARNING **: Theme directory of theme CfG-Crystal-SVG-1.2.0 has no size field
不知道是什么问题。本来以为缺了什么。后来去网上搜，发现类似的问题都是Theme directory 24x24/... of theme *** has no size field.
也就是说，对应的 theme directory 名字不见了。
由此怀疑index.theme内容有问题。打开一看，注意到有两个连续的逗号，而两个逗号之间是一个 theme directory 名字……
于是，把逗号删掉，问题解决……
交了一个 PR ，不知道会不会解决…… 说起来还是作者的问题。
Old Blog Link: http://computer.mblogger.cn/henryhu/posts/83455.aspx
2008年5月12日星期一
Compiz-Fusion的阴影(shadow)问题终于修复了
好久了，compiz-fusion没有阴影，或者显示奇怪的阴影，一直不知道是什么问题。
今天去网上搜，终于找到了。
原来是NVidia的驱动覆盖了xorg-server的libwfb模块，而NVidia的模块有问题，于是阴影就出问题了……
解决方法也很简单，把NVidia备份的xorg-server的模块链接回去就可以了。
我这里是这样：
模块目录：/usr/local/lib/xorg/modules
备份的那个（原来是xorg-server的）：XXX-libwfb.so.%%.xorg-server-1.4_8,1
NVidia的： libnvidia-wfb.so.1
装好NVidia驱动后，libwfb.so指向libnvidia-wfb.so.1。删掉之后，把它指向那个备份的就可以了。或者直接把备份的拷贝成libwfb.so。
说起来用xorg-server提供的模块也没有什么不同啊，不知道为什么NVidia要自己搞一个，搞出来还没有原来的好…… 汗……
近期升级至compiz-fusion 0.7.4，真好！……
Old Blog Link: http://computer.mblogger.cn/henryhu/posts/82456.aspx
今天去网上搜，终于找到了。
原来是NVidia的驱动覆盖了xorg-server的libwfb模块，而NVidia的模块有问题，于是阴影就出问题了……
解决方法也很简单，把NVidia备份的xorg-server的模块链接回去就可以了。
我这里是这样：
模块目录：/usr/local/lib/xorg/modules
备份的那个（原来是xorg-server的）：XXX-libwfb.so.%%.xorg-server-1.4_8,1
NVidia的： libnvidia-wfb.so.1
装好NVidia驱动后，libwfb.so指向libnvidia-wfb.so.1。删掉之后，把它指向那个备份的就可以了。或者直接把备份的拷贝成libwfb.so。
说起来用xorg-server提供的模块也没有什么不同啊，不知道为什么NVidia要自己搞一个，搞出来还没有原来的好…… 汗……
近期升级至compiz-fusion 0.7.4，真好！……
Old Blog Link: http://computer.mblogger.cn/henryhu/posts/82456.aspx
订阅：
博文 (Atom)
评论
# 回复: Moved to MSN 2006-1-3 8:54 Hearson
请教一下，你怎么到未来的？
# 回复: Moved to MSN 2006-1-4 12:19 HenryHu
这里的时间可以设置的~
用于置顶~