戰魂小筑

     病毒，說白了就是可以做任意事情的破壞性程序，這不算什么，大不了只是一個地方黑社會。
木馬，簡而言之就是只要給我聯網，我就可以黑掉你
     微軟已經把Windows系統給做爛了。exe可以在管理員權限下任意運行，從而導致病毒木馬的泛濫。其實轉過頭來看很多手機操作系統，例如Android，也是使用WindowsXP后為exe引入的manifest概念，但是卻從根本上解決了很多安全性弊病
     Android中，每個運行入口，必須有一個manifest來讓OS知道你這個程序需要做什么，由OS為你配備網絡，磁盤讀取等等需求。
     如果將病毒的訪問權限降低，例如跑在虛擬機里面，病毒就沒有毒了，木馬即便能獲取機密信息，也發不出了。
而Windows呢，由于本身概念設計的缺陷，一個程序寫好后擁有完全權限進行訪問，OS并不了解一個程序能做什么，只有當這個程序調用API時才知道，但有時也決定于調用時的數據，比如只有打開系統盤文件才受到限制。于是乎，很多商家看到了money，使用API HOOK，rootkit等等底層鉤子來模擬出了一套超級虛擬機，妄想用一個軟件控制住另外一個軟件的訪問，簡直是癡人說夢。
     也許你會說，UNIX/Linux不是在這方面做的很好么？引入用戶及權限，默認不在管理員下運行。這點Windows也做了，不過很好么？看看UAC，Linux下運行也很麻煩。 
     試想下，如果Windows也擁有和Android一樣的manifest機制，那么病毒掃描也就僅僅需要檢查manifest文件就可以。對于老的程序，可以開啟一個權限自動檢查模式進行運行，一段時間后，自動為這個老程序生成新的manifest，如果以后發現這個老程序有侵入系統的問題，馬上修改這個manifest就可以解決問題。
     你可能要說，如果程序試圖修改自己的manifest呢？這個可以在操作系統內核進行驗證，沒哪個程序能修改Windows內核吧？就是這個道理，如果manifest的checksum與以前的不一樣，那就需要一些用戶手動驗證。

用VC2005/2008編譯代碼時，經常要鏈接其他lib，最傳統的方法就是在Linker->Input->Additional Dependencies中添加對應的lib。

另外一個功能是project中的Project Dependencies，在Depends on里可以選擇工程依賴的項目

一直以來，我一直認為Project Dependencies只是來決定編譯順序的，在項目很多，而且又需要經常編譯時，一般就會調節下這個里面的依賴，讓工程編譯順序可以正確。但一般情況下這個功能在我的機器上是睡覺的

后來，突然發現，Project Dependencies是可以幫助項目鏈接lib的，也就是說，對于在同一個Solution的項目的lib依賴，可以不進入->Input->Additional Dependencies中進行添加。

這個功能是保存在Solution內的，因此可以被源代碼管理軟件給別人共享

功能對比：

傳統手動添加lib

優點：

   適合大部分的編譯器，可以深刻理解linker的流程，項目被移出Solution后也不用重新設置其他關聯項目，傳統而有效

缺點：

   設置比較麻煩

項目依賴添加lib

優點：

    既解決了lib引用，也決定了編譯順序

缺點：

    如果即使用傳統方法，又使用項目依賴，可能會造成不預定的多次編譯

    離開VC后，很難適應其他IDE或者編譯器

    其他項目依賴的基礎庫被移出Solution后再倒回來后，需要重新設置依賴

    Solution丟失，關聯也就丟失，單獨編譯某個項目，需要重新設置依賴

總結

既然用MS的東西，就選擇MS的優化功能，這是MSDN推薦功能。

如果既要保持跨平臺的習慣，可以繼續使用傳統方法，因人而異

MS的東西讓電腦和編程都變的簡單，但并不一定是最強大的，這就是2|8定律

原文：http://blog.csdn.net/superjoel/archive/2009/03/21/4011475.aspx

IndieLib簡介
IndieLib是一個2.5d引擎，使用它可以簡化游戲開發的難度，提高游戲開發的速度。內部它使用Direct3d做硬件加速，但它并沒有使用DirectDraw或者ID3DXSprite，而是直接將材質渲染在多邊形上。它的設計重點是快速2d渲染，但同時也可以渲染3d模型。IndieLib的主要特點是：

1. 簡單的接口和超強的易用性：使用entities來代表圖形實例，可以調用簡單的函數來設置它們的屬性。如"SetPos", "SetCollisionArea", "SetFade", "SetTransparency",等等

2. sprites移位、旋轉、鏡像和縮放

3. sprites Alpha blending, transparency, tinting and fading

4. 渲染任何尺寸的圖片(不一定非要是2的次方)。你可以載入10000x10000像素或更大的圖片，IndieLib在內部會自動將它們分割成小的區塊。還有，IndieLib可以自動丟棄顯示窗口以外的區塊，提高渲染速度。在IndieLib中，還可以使用攝像機(camera)，當使用攝像機時(如旋轉，拉遠拉近等)只有你看到的會被渲染。

5. SetGrid函數可以給sprites設定grids，所以當移動grid上的點時，可以得到如波浪等的特殊效果

6. 2d和3d攝像機(camera)概念，完全獨立于圖形?？梢苑奖愕囊莆弧⑿D和拉遠拉近

7. 可以方便的創建多個視角(viewport)，方便創建大屏幕分屏游戲

8. 隨意縮放，引擎會自動決定是否顯示圖形

9. 動畫系統，使用XML文件定義動畫文件

10. 高級碰撞檢測系統，使用xml文件定義碰撞區域。區域類型可以是圓圈、矩形和三角形。還可以將多個碰撞區域定義為組，從而方便檢測組成員的所有碰撞。定義碰撞區域后，你不用擔心移位、縮放等操作會導致碰撞失效。引擎會自動重新計算碰撞區域。(非常適合于街頭霸王類型的打斗游戲)

11. 位圖文字系統

12. 渲染3d Mesh(你可以方便的將2d與3d圖形混合起來顯示)。也可以對3d模型進行方便的移位、旋轉、鏡像和縮放操作。這個特性可以是你制作"New Super Mario Bros"這樣角色是3d，而場景是2d的游戲

13. 燈光系統，可以為3d模型加入燈光效果

14. 定時器(Timer)，開始、結束、暫停，可以方便的控制時間

15. 實體(Entity)類，用于2d或3d圖形，可以方便的控制圖形。

16. Image類，用于載入、保存不同格式的圖片文件，還可以實現gaussian, noise, equalize, saturation等特效

17. 直接blit基本圖形(矩形、圓圈、多邊形、直線等)

18. 鼠標、鍵盤輸入支持

IndieLib是一個開源引擎，它的License是LGPL，這就是說你可以將它用于商業項目。

本文轉自http://pop.pcpop.com/zpt/default.html?MainUrl=http://pop.pcpop.com/090716/5611772.html&referrer=http://www.google.cn/search?rlz=1C1_____enCN330CN330&sourceid=chrome&ie=UTF-8&q=

發帖時間：2009-07-16 15:18:34

最近美國登月40周年，鬧得沸沸揚揚。再加上日全食在成都的上演，讓我這個天文迷大呼過癮，7月25日深夜在看Discovery的RSS時發現有阿姆斯特朗的生平及介紹，馬上動手人肉了下整個登月過程，配合Google Moon,Celestia和搜索引擎，查到了本文的重要內容

登月到底是不是騙局

一直以來，我都相信美國登月是一個大騙局，好比2001年的美國911，日本的廣島和長崎的原子彈一樣。畢竟出于地球的領頭羊，一點小小的騙局不算什么。但是前幾天在網上的一些視頻，讓我有點動搖，片中這樣解釋：

有人懷疑

1. 為什么登月照片上沒有星空，月球上本來沒有大氣，應該看的很清楚才對

解釋：確實，照片上沒有看到星空，但是實際上這是膠片及曝光的原因。雖然月球反光率只有8%，但是這足以讓照相機的光圈焦點以月球地表為準，因此星空自然就不能看到。如果要出現也可以，那么除了星空意外的地方將是曝光過度。

2. 太陽光是平行光，光度無限均勻，但是在照片中的影子卻不是平行的，所以可以推斷是聚光燈所致

這里我仔細研究了下，其實這是一個透視作用，當然影子最后會匯集到一點

最有意思就是旗幟了

3.太空人在插旗時，視頻里的旗幟飄揚過度，好像在空氣里一樣，這很明顯是在地球上模擬出來的

解釋：有人在真空和空氣中做過旗幟的搖擺試驗，證明在沒有空氣阻力的真空中，旗幟搖擺時間明顯長于空氣中

4. 有關于太空人跳躍的動作很像是在地球上做的

解釋：有非官方人士，使用NASA為培養太空人而專門設計的飛機，在高空做俯沖動作來模擬月球的1/6重力，實際視頻拍攝下來與登月視頻中一致。但是，如果按照在地球上，用維亞吊住宇航員來做拍動時，很明顯動作是不連貫的

那么我們可以完全相信登月是真的？看完下面再接著說

資料：美國阿波羅計劃一共發射過17個航天器，其中，1~10號均為前置計劃，從無人探測器到最后10號載人航天器在距離月面100多公里的上空訓練，從11號開始到17號，美國一共排除12名宇航員登上月球，其中13號因為故障，中途撤回地球，其余都順利返回。

外界資料中，18，19，20號在計劃中，但是最后由于某些原因取消了，但某NASA內部資料管理員在很久前爆出了這樣的資料：

1976年8月16日，準備已久的美國阿波羅20號飛船，對月球進行了從未公開登錄任務...《靈憲》記載：“嫦娥，羿妻也，竊西王母不死藥服之，奔月?！币驗殒隙鸪粤恕安凰乐帯?，就注定了“嫦娥奔月”的故事不是“神話”，而是一個預言，一切都在悄悄地進行著...
阿波羅20號 秘密升空 俄美聯合 探索月球遠古飛船
1. 阿波羅20號確實上天了，而且執行的是秘密任務；
2. 阿波羅20號的秘密任務是蘇美兩國聯合執行的；
3. 阿波羅20在月亮上發現了古代黃種人的女性木乃伊。
古代黃種人的女性木乃伊，是否就是中國古代神話中的嫦娥？？以及后羿射日的傳說真相是什么？
■后羿射日的傳說真相■
后羿射日是一個古老的傳說。很多人把它當成了神話故事，但本人認為這個神話背后一定隱藏著某種真相。也許我們可以從另外一個角度來理解。是否我們可以這樣解釋，這是一場遠古時代（外星）高科技的戰斗。我們可以這樣理解那十個太陽，一個是真的另外九個是外太空飛行器，從他們通體發光發熱這一點是不是像今天所說的UFO呀。也許是有一群外星人他們駕駛者可以噴火發光的太空船來我們這個當時還未開化的原始之地玩。但他們干擾了人類正常的生活并給人類帶來了麻煩，并且他們還用噴火器殺死了勸解他們的人類代表女丑。但這一切似乎都被它們的首領即天帝發現（好像那時他也管轄著人類，從這一點分析也許我們人類，還真是人造的或是外星人促進了我們的進化），并且派來了他的代表后羿（帶著發射架和導彈即是傳說中的神弓神箭）勸說他們會去，但他們不聽勸說也許后羿生氣了就用導彈把他們打了下來，這就是三條腿的黑烏鴉（也許是他們的飛行器用三腳架支承，打下來的飛行器肯定是壞了的燒胡了的所以說黑色烏鴉，也許那時的詞匯沒有今天這樣發達古人只能那樣記載）。還有那個所謂的長生不老藥也許就是我們所說的轉基因藥物，或說是抗衰老藥物。

以下圖片是嫦娥，請不要在一個人時觀看，有點嚇人

以下是這個研究的完整中文譯文及配套資料

http://www.tudou.com/programs/view/aSHsMr2PRr0

如果你是天文迷，有理由看完所有的視頻，里面資料實在太珍貴了

記得小學時就看過百科全書里說過阿波羅號在月球背面發現過月球基地及UFO，當時由于無法上網，找不到資料。那么多年以后終于在網上找到這個說法的來源

美國為了澄清登月事件的種種猜測，放出了月球探測衛星發回的照片，確實可見當年留下的登月艙。我們姑且相信登月是真，但是視頻里一些被剪掉或者被修改的痕跡，以及18，19，20號計劃的取消讓我們對美國到底看到什么表示非常懷疑和好奇。

網上居然還有人找到2008年某人拍攝出的UFO與這個太空船類似，這可能純屬搞笑和雷同

但據我看來，這個所謂“嫦娥”的駕駛員倒是和瑪雅神殿里描述出古代宇航員的樣子倒是頗有幾分相似

Celestia對于我來說簡直就是個非常好的東西，小時候就對太空充滿了興趣，一直夢想過設計一個太空游戲。雖然有諸如孢子，自由槍騎兵(Freelancer)等游戲，但是還是不能完全帶來完全真實的宇宙感覺。

因此就有了Celestia宇宙模擬器了

記得最早的1.02版本因為覺得軟件很不錯，因此動手漢化了一下（當年還漢化過N64模擬器），后來因為硬盤crash，所以什么東西都沒保存下來。最近同事弄了1.5版本來，在公司的N卡上跑一點問題都沒有，但是在家里那個古老的ATI9700本子上跑時，一看到地球就死機。

出于好奇，在官網上將源碼down下來編了下，居然沒有任何問題。但是依然死機。不過從調試窗口看到，在讀取一個BUMP時掛掉，打開CHANGELOG查BUMP，寫道：

1.04

* Added bump mapping.  Uses DOT3 bump mapping and only works on GeForce cards

居然是在1.04版本中加入了OPENGL的BUMP貼圖，使用DOT3混合，里面說，只支持N卡（當然好點的A卡也可以），徹底無語，看來出了換顯卡，看來想玩這個是不容易了

圖1 Motion Composer

圖2 DeTextureFrag紋理優化工具

Motion UI API特性一覽

1. 基于lua腳本的UI庫

2. C++提供Button,Checker,Label,EditBox,NoteBox(多行編輯) 原生控件支持

3. Lua提供

ColorPicker 支持顏色選取

ComboBox

DragBox  支持簡單的拖拽

Flash  支持Flash回放

ItemSource   列表控件基礎

ListBox

Menu

PropertyGrid   與.NET 使用方法一致，使用Reflection構建顯示

ScrollH

ScrollPage      橫向豎向均可卷軸容器

ScrollPanel     豎向卷軸容器

ScrollV

TreeBox

TreeSource  樹形控件基礎

Window

Dialog/Modal Dialog 模態對話框

4. 使用lua代碼本身作為布局文件

5. 支持代碼沙箱：

  核心模式：API完全訪問，編寫控件時使用

  核心引用模式：獨立沙箱，API完全訪問

  標準沙箱模式： 獨立沙箱，API訪問受限，可定制

6. 類似于魔獸世界的插件加載模式，自動掃描并更新需要加載的插件列表

7. 渲染器抽象，可隨意掛接任何渲染器

8. dll+接口加載方式

9. C++原生控件,皮膚的動態注冊

10. 延遲加載紋理及紋理管理

11. 位圖緩存,靜態渲染( Coming soon )

圖3 控件對齊磁性吸附線，皮膚修改

Motion Composer 編輯器特性一覽

1. 完全使用Motion UI API編寫

2. 類Visual Studio方式的控件編輯

3. 屬性編輯所見即所得

4. 拖拽方式改變父子關系

5. 拖拽方式復制控件及組件

6. 支持Play/Edit方式切換及控件預覽

7. 支持無限制REDO/UNDO

8. 支持類.NET方式 控件對齊磁性吸附線

9. 支持換膚，組件換膚

10. 支持圖片換膚

11. 支持動畫幀皮膚( Coming soon )

12. 支持九宮格換膚( Coming soon )

13. 支持DeTextureFrag紋理優化工具

   將零散紋理放置到大紋理上加載，編輯時與普通方式一樣(Coming soon)

   基于Multiplexing Deepness  Search Zero-Void Tree技術的外部工具支持。見圖2，本軟件尚在開發中

14. 類似于OSX的CoreAnimation，動畫切換API及編輯( Future version )

15. 支持編輯器換膚(Coming soon )

16. 自動存盤(Coming Soon)

17. 支持lua動態遠程調試(Coming Soon)

18. 支持動態事件生成及內嵌式調試？( Possible )

19. 支持UI資源打包( Future version)

開發時間30天

如果你用過GetOpenFileName中的OPENFILENAME的lpstrFilter參數，你會發現很無語

Pointer to a buffer containing pairs of null-terminated filter strings. The last string in the buffer must be terminated by two NULL characters.

看似沒問題，但是在使用中卻弊病很多：

1. 像腳本這類以0結尾，默認就根本不能傳字符串給這個函數進行filter的配置

2. 即便lua這類函數提供了lstring的支持，但也極為麻煩，需要在buffer后添加一個\0

3. 調試器里只能看到第一個\0結尾的字符串

真不知道這是MS哪個腦殘寫的API，為什么不定制下filter，或者干脆用別的方式來傳遞。。。

想在游戲中嵌入Google Chrome速度的瀏覽器么？看下Awesomium

以下圖片轉自http://www.pjhome.net/article/Diary/3D_browser_awesomium.htm

跨平臺

高性能

多核優化

Flash支持

透明層

腳本交互

事件通知

今天將部分工程從靜態鏈接庫改為動態鏈接庫，并使用接口方式創建時，原來lua調用的地方居然掛掉了，掛的地方是table在清除時，crash在newkey

google了一下，找到了一篇頗有參考價值的文章

A common error is to link C extension modules (shared libraries)
with the static library. The linker command line for extension
modules must not ever contain -llua or anything similar!

I.e. check your build process. If you are unsure where the two
copies of the Lua core come from, grep the binaries for some
characteristic error message, like "table index is nil".

我的lua封裝庫是與lua源碼一起封裝在一個靜態鏈接庫提供給所有程序鏈接使用。有些工程只有1個dll或者exe單獨鏈接，不會出現問題。問題很大程度上就發生于將一個lua源碼構成的庫鏈接給多個dll或者exe，或者混雜鏈接，這樣極易出現莫名其妙的table訪問到dummy_node的錯誤情況

因此，馬上調整，嘗試將這個庫改為dll。但是在一些模板函數偏特化上出現了鏈接問題。最后發現，動態鏈接庫完全就是模板的噩耗，雖然模板函數是內聯，對于全局的模板函數，將其放在頭文件中就會出現多重引用問題。因此放棄，將lua5.1的源碼放在一個dll中，將封裝庫放在靜態庫中，這樣就絕對沒有任何問題

工程結構

包含有靜態庫

motion.lib 一個UI邏輯的庫

HGErender.lib  使用一個motion的接口實現的HGE渲染器，與motion.lib沒有鏈接和依賴關系

一個exe靜態鏈接motion.lib和HGErender.lib

motion中加入了一些flash支持，將flash的包含放到了預編譯頭文件，這部分頭文件exe是沒有引用的

表現癥狀

exe可以正常運行，但是在motion中新添加的flash類實例化后無法看到成員

重編，重新link，清空重編無用

換用vs2005，依然無用，但是報了一個Error: error in OMF type information 錯誤

解決方法

嘗試將flash包含到預編譯頭的文件放到對外包含中，讓exe也能看到這一部分

問題解決

分析

VS的調試系統并不是完全開發，因此我們只能從一些表象來分析一些調試器原理及行為

這個bug的原因就在 作為調試入口的exe并沒有獲得完全的motion里調試的信息。如果將motion作為dll加載，理論分析不會出現這種問題。dll將被作為一個單獨的調試入口，需要單獨加載獨立的pdb。

本例中，靜態庫中的調試信息并沒有鏈接到exe，因此看不到成員的任何信息

擴展

大多數的游戲或應用程序都是使用靜態庫來做鏈接，這樣無論是編寫還是代碼安全都有所兼顧。但對于工程模塊之間的互相隔離，C/C++靜態庫本身的毛?。–RT內存分配及靜態，全局變量問題）就變得尤為嚴重。

而使用動態鏈接庫的接口方式也是有一部分程序這樣使用的，如果為了安全或者加密，可以將動態鏈接庫放到自己的包內，使用從內存讀取dll的技術，這樣安全，工程架構又清晰