关于两个单词的历史故事

两个新单词
在之前的一篇文章中 , 我们知道了关于BEAR,BUNNY和PIGLET这三个有意思单词背后的历史故事 , 今天我们会提到两个新的单词:BOZOSLIVEHERE和TABTHETEXTOUTFORWIMPS 。 看看它们背后有什么有意思的故事 。
历史课时间
早在”Real-Mode”的Windows时期 , 所有的回调函数都需要被导出 。 这个要求是因为一些比较复杂的技术原因 , 如果有人真的关心这个原因的话 , 我可以找时间给大家讲讲 , 但是我想 , 应该没那么多人会关心这个吧 。 基于上面的原因 , 所有标准窗口类(包括文本框 , 列表框 , 勾选框等)的窗口过程函数被从USER模块中导出 , 另外还有其他的一些回调函数 , 例如定时器回调函数 。 这些函数会作为对通用的内部函数集合的一个补充 , 这样USER , KERNEL和GDI模块就可以协调它们各自的功能 。
有一些人对这些内部函数进行了逆向工程 , 并将它们的原理写到了技术书籍里 , 结果就是 , 很多程序员看了这些书籍并使用书中所介绍的方法 。 对此 , 我们感到非常惊讶 , 因为这些函数本应该作为内部函数使用的 。 当我们决定对这些内部函数进行重新设计(例如 , 为它添加一个新的参数 , 或者当它不再被需要的时候删除它)的时候 , 我们发现有些应用程序不能像以往一样正常工作了 。
因此 , 我们不得不将这些变更再改回去 。 而那些我们冥思苦想的新功能不得不被重新设计 , 或者被重定向到其他模块 , 或者被整个的抛弃 。 (如果我们想删除一个函数 , 我们还是可以这样做的 , 但是旧的函数必须保持它原来的功能 。 从操作系统的角度来看 , 它基本上就是一段不再被调用的代码片段 , 它存在的意义就只是因为某些应用程序想欺骗操作系统或绕开操作系统中一些基本准则) 。 为了给这些开发者一些”小教训” , 通常这些函数的名字都显得十分愚蠢可笑 。
例如 , BOZOSLIVEHERE原来是文本框的窗口过程函数名称 , 而不是更加具有描述性的EditWndProc 。 这样的话 , 一些想直接使用这个窗口过程的开发者会因为懒直接链接到EditWndProc , 而不是通过GetWindowLong(GWL_WNDPROC)来获得 。 当Windows2.0发布的时候 , 新版本不再需要将窗口过程导出了 , 于是我们将它们全部都移除了 , 只是为了找到那些不能正常工作的应用程序 。 所以我们不得不把他们放回去 , 但我们会给这些函数起一起看起来愚蠢可笑的名字 , 用来提醒这些应用程序不应做这些违反原则的事情 。
在Windows95时期 , 当所有窗口过程被转换为32位版本的时候 , 这个问题变得更加糟糕了 。 因为 , 旧版本的窗口过程都是16位的 , 所以我们不能简单的将32位的窗口过程以名称BOZOSLIVEHERE来导出 。 我们只能编写一个转换函数来将”不合法的”16位函数调用转换为对应的”不合法的”32位版本函数调用 。
【关于两个单词的历史故事】这只是应用程序兼容性方面的冰山一角 。 如果要我写写关于应用程序做的那些坏事以及我们如何又让它们重新工作 , 我估计可以写上个把月 。
所以每当人们指责微软在操作系统升级过程中恶意破坏应用程序兼容性的时候 , 我都会十分生气 。 我花了许多不眠之夜修复第三方应用程序中的错误 , 以便它们可以继续运行在Windows95上 。
在这些应用程序中 , 游戏可算是最糟的 。 而且 , 游戏开发商甚至不在乎他们的游戏不能在Windows95上运行 。
总结
现在你知道为什么你的程序依然可以在Windows95上跑了吧?
关于两个单词的历史故事
文章图片


    推荐阅读