今天下載lua的Windows二進(jìn)制發(fā)布luabinaries 的時候，發(fā)現(xiàn)luabinaries的發(fā)布包含兩個dll,lua5.1.dll,lua51.dll，其中l(wèi)ua5.1.dll大小合適，lua51.dll只有11K，感覺不像是個有用的lua dll，對此比較不解，查看了luabinaries的文檔，
文檔中如此解釋：
The LuaBinaries DLL packages have a dll proxy called "lua51.dll". It can be used to replace other "lua51.dll" released by other distributions. It will simply forward calls to the "lua5.1.dll". There is no compiled source code involved in the forwarding.
也就是說，lua51.dll完全是一個lua5.1.dll的代理類，沒有任何實際的代碼，僅僅是做一個到lua5.1.dll的forwarding。
不過文檔解釋了lua51.dll是什么，卻沒有解釋為啥會需要一個這樣的東西呢？我還從來沒有見過類似的情況。要說有一點點類似的情況的話，也是以前做反外掛的時候，知道可以通過替換現(xiàn)有的dll，并且完全模擬原來dll的接口，并將不需要hack的函數(shù)全部forwarding到原來的dll中。對于lua怎么會需要這樣的功能呢？
于是我google了一下，發(fā)現(xiàn)了原因：
The standard DLL name "lua51.dll" has been selected more than
three years ago. Around twice every year someone comes along and
thinks "Oh, we absolutely need a dot in the DLL version number".
Alas, Windows does not like an extra dot in there. Many things
break when you have an extra dot in DLL names. Depends on the
version of the OS, on the specific system call, on the library or
tool used ... it's hopeless. So please let's forget about it.
--Mike
來自lua-users.org的一個帖子 。
原來是3年前有人確定了一個lua51.dll名字的動態(tài)庫，并且，有人覺得我們非常需要在5和1之間加一個點，不然lua的5.1版豈不是看成lua的51版了？
對此，有人進(jìn)一步提出了疑問 ，認(rèn)為這個問題怎么這么久了竟然沒有人修復(fù)？
接著有人回答了：
But who's duty is to resolve the issue?
It's clearly not an issue of Lua as a language. It's just a consequence of (a very popular) LuaBinaries once releasing lua5.1.dll that became a de facto binary standard, then authors of many third-party Lua libraries were releasing binary packages compatible with LuaBinaries.
Note: I'm not blaming LuaBinaries; that was just one unfortunate decision that is difficult to be undone. --
Shmuel
我們知道了：
LuaBinaries做出了一個錯誤的決定，但是已經(jīng)發(fā)布了，很多第3方的庫也發(fā)布了，并且依賴于LuaBinaries的這個lua51.dll，于是：
that was just one unfortunate decision that is difficult to be undone.
那僅僅是一個過去做下，現(xiàn)在難以撤銷的不幸決定。。。。。。。。。。。。
有的東西存在了，即使是不合理的存在，因為它存在了一段時間了，因為慣性，它還會存在在那里。編程中，這種情況經(jīng)常出現(xiàn)。突然讓我想起上個項目中，大家經(jīng)常對項目中蹩腳代碼存在原因的解釋：“歷史原因”。
對于代碼來說，即使大家都知道可以重構(gòu)，但是重構(gòu)是有代價的，很多時候大家就妥協(xié)在歷史原因當(dāng)中。
對于語言來說，C++就是對歷史進(jìn)行最大妥協(xié)而產(chǎn)生的語言，大家都承認(rèn)，假如當(dāng)年C++不兼容C的話，C++根本就得不到現(xiàn)在這樣的流行程度，也都承認(rèn)，因為C++兼容C，（常常被稱為歷史的包袱）C++在語言的優(yōu)美程度上損失了太多。
想起國內(nèi)某個大牛有過類似的感慨，“現(xiàn)在每做一個設(shè)計決定的時候都非常小心，因為那可能會被使用非常非常長的時間，當(dāng)它還能正常工作的時候，甚至不會有人想要去重寫它“
呵呵，僅僅將這個有趣的事件作為編程中的一個軼事來看吧。
本文來自CSDN博客，轉(zhuǎn)載請標(biāo)明出處：http://blog.csdn.net/vagrxie/archive/2010/07/23/5756804.aspx