• 抽象的力量——读SICP

    无数的事实证明,人脑的能力是非常有限的,尤其是应对海量的、毫无关联的信息以及十分复杂的过程之时,我们很容易便迷失于其中,难以理出一丁点头绪。与人类相反,计算机却是特别擅长于处理海量信息,他们先天比人类更适合于进行严密的逻辑演绎推理,处理复杂而又精细的事物。所以,作为提升生产力的手段,我们常常使用计算机代替我们从事这一类的工作,从而避免麻烦,也避免犯错。

    可是,问题是,作为一名和计算机打交道的软件工程师,我们却不得不混迹于复杂诡谲的逻辑之中,绞尽脑汁寻求答案。只因为计算机只是一个严谨的实践者,需要我们提供解决问题的步骤。

    如何解决困难的问题,构建复杂的系统?我们采用的方式便是控制复杂度,其重要手段便是抽象。这种策略是非常Brain-Friendly的,它使得我们在任何时候都只关注问题的某一部分,而忽略其他细节。

    未完,继续阅读→
  • 【Ruby】require背后的故事

    接触ruby有一段时间了,说起来自己和这门语言倒挺有缘。学生时代的时候,曾经沉迷于一款叫做RPG Maker的软件。当时和朋友以班上的同学为原型写了一部武侠剧,并计划用RPG Maker制作成游戏,乐此不疲。这个RPG Maker在内部使用了一门脚本语言来描述其游戏逻辑,这门语言便是Ruby。于是乎为了修改游戏框架、拓展引擎原有特性,自己花了不少功夫学习Ruby。可惜最后,由于高考临近,Ruby随着RPG Maker一块儿,淹没在了记忆的深处。

    最近突然间有了兴趣,又把Ruby拿出来看看,却发觉这五六年间,Ruby语言的变化之大,是我难以预期的。无论是语言特性本身,还是周边的开发工具、程序库,都较之前有了较大的发展,于是重温变成了重新学习。

    既然是学习,光说不练可不行,于是乎又一边开始学习起了Ruby on Rails来,希望能够学以致用。RoR在Ruby社区内可是有着响当当的名号,可以说Ruby之所以名声大噪,很大程度上都是由于RoR的功劳。RoR是一个纯粹的开源软件,它凝聚了世界上最优秀Ruby程序员的勤劳和天分。而我自己,也由于对RoR的研读,了解到了不少Ruby的精妙之处。喟叹之际,便也想对其抽丝剥茧,习其精髓,并记录于博客之中,以飨诸位同好。 Y(^_^)Y

    未完,继续阅读→
  • SRS Audio Sandbox破解纪实

    最近挺忙的,本来需要各种为前路做准备,无奈自己天生属于低血压型的人,偏偏就是提不起劲儿来干正事儿,却把大好的一天光阴全交代到SRS的分析工作上了。虽然说这多少算不务正业,不过由于本人有着严重的软件新版本强迫症,故这算是给自己的一个开脱理由吧。

    这款软件的破解工作展开比较容易,没有加壳,直接上工具分析之。首先请出OllyDBG来,通过查找字符串引用和查找API MessageBox引用的老法子,很容易就定位了大概的关键代码位置。

    未完,继续阅读→
  • 关于异常和异常错误处理的思考

    程序员们无时无刻不在于Bug和错误做着斗争。早在面向过程的C语言时代,错误一般是通过函数接口的返回值来指定的。我们事先对接口做好返回值约定,然后调用者根据约定内容检查调函数回值,从而得知了函数调用的结果。典型的约定,有比如返回NULL表示调用失败,有比如返回0表示成功其他表示各种错误原因等等。这种方式在当时看上去是个比较完美的解决方案,但是,随着程序的规模增大,这种方式日渐显出了疲态。

    未完,继续阅读→
  • 【译】Android位图颜色模式的问题

    最近开始了android上的编程之旅,在了解2D图形编程时,令人蛋疼的发觉android上仅支持ARGB8888、ARGB4444、RGB565以及Alpha 8这么几种颜色模式,而不支持RGB888这种格式。原本以为即使不支持RGB888我用ARGB8888总行吧,但后来了解到,即使我在内存中用ARGB888颜色模型表示图像,在该图像拷贝到屏幕帧缓冲区的过程中,它也会变成RGB565颜色模式。我们知道,RGB565最多只能表示2^16=65536种图像,这对于RGB888所能表示的2^24=16777216种颜色来说显然在表现力上要略逊一筹。这集中表现在显示某些带有渐变效果的图片时,出现了一条条的颜色带,而不是原始的平滑的渐变效果。后来得知android使用了Dither(抖动)这种技术,以欺骗人类眼球的方式加以补偿。

    当然,以这个问题为出发点,后来又引发了诸多问题,而这篇文章解决了我不少问题,特在这里翻译出来供大家分享之。

    未完,继续阅读→
  • 关于Condition Variable为什么需要一个Mutex的思考
    1. Linux下:
    pthread_mutex_lock(&mutex);
    pthread_cond_wait(&cond, &mutex);
    doSomething();
    pthread_mutex_unlock(&mutex);
    未完,继续阅读→
  • Hello World程序背后的故事解密(二)—— 程序之生

    近几个月实在是太忙了,偶然想起来博客上一看,离上次写文章居然过了两个月有余,于是手痒痒想加把劲,再码点儿技术文上来^_^

    这个系列是为了挖掘出一个简单的类似Hello World程序隐藏在CRT之下的复杂性,因此在上次分析了“编译器选项和CRT”之后,今天我想再来简单分析一下从程序进程建立直到程序运行到C/C++入口函数处发生的那点儿事儿。

    未完,继续阅读→
  • 记一款宽带拨号器加密算法逆向实例

    这两天闲来无事,想起来许久之前曾答应朋友试着分析一下这个拨号器加密方式,花了几天时间分析,于是有了本文。下面将描述加密过程的技术细节,以及一些破解的心得。

    首先,该拨号器存在三个平台的三个版本,但鉴于Windows下拨号过程需经过两次麻烦的握手(一次失败拨号,获取失败的返回值并参与第二次加密过程,从而最终生成密文),我最终选择了Linux版本来进行分析。

    未完,继续阅读→
  • 关于Visual C++增量链接以及.textbss

    好的,文接上回,本文我就来讲讲微软link.exe连接器的Incremental Liking这个特性。当然这个其实不是微软linker独有的特性,很多链接器都有这个特性,这个特性实际上是为了提高链接速度的。

    想象一下这个场景,我写了两个函数foo()和bar(),其中foo()在0x400100处而bar()紧接着保存在0x400200处。现在我将foo()改写了一下,添加了一些perfect的功能,然后编译了新的代码。不过现在的麻烦是foo()不可避免的变大了,他现在需要200h字节来保存了。那么链接器该怎么办?

    未完,继续阅读→
  • PE文件格式系列(一)——探究PE文件常见Section作用

    最近由于各种原因想要研究一下PE文件,要彻底研究PE和COFF文件格式当然是非研究微软自己的技术白皮书——《Microsoft Portable Executable and Common Object File Format Specification》不可了。于是花了一点时间看看,有些心得,和大家分享一下。

    首先本文不是讨论PE文件格式本身的,这属于技术规范的范畴,大家要是感兴趣可以参看上文中提到的微软的资料。要是不太喜欢E文的朋友也可以在网上找到很多描述PE格式的文章,在就不再这里赘述了。再说,就算我想讲,估计也讲不好(受限于本人的语文水平orz)

    未完,继续阅读→
  • Hello World程序背后的故事解密(一)—— 编译器的选项和C运行时库

    作为一个程序员,想必大家都会对HelloWorld这个程序是深有感触吧。是的,就是这个程序第一次带我们进入了神奇的计算机编程的世界,指引我们开始走上了程序员这条充满了艰辛和快乐的路。HelloWorld对我们这群程序员来讲意义是非比寻常的,因此我想更加深入的研究一下C语言版的HelloWorld程序,撕开它的外衣,将隐藏在简单表象下的运行时秘密拿出来给各位看看。

    未完,继续阅读→