战魂小筑

     病毒，说白了就是可以做任意事情的破坏性程序，这不算什么，大不了只是一个地方黑社会。
木马，简而言之就是只要给我联网，我就可以黑掉你
     微软已经把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)概念，完全独立于图形。可以方便的移位、旋转和拉远拉近

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++静态库本身的毛病（CRT内存分配及静态，全局变量问题）就变得尤为严重。

而使用动态链接库的接口方式也是有一部分程序这样使用的，如果为了安全或者加密，可以将动态链接库放到自己的包内，使用从内存读取dll的技术，这样安全，工程架构又清晰