2009年03月28日

原创 libconv vs2003例子 编码转换 utf8 gb2312

因为要移植到linux不能使用win32的api多编码转换只能使用libconv, 用过atl的转换宏的一定认为他很方便很容易使用，不幸的是atl宏存在潜在的内存问题， 因为它是用释放的内存传递结果。 ~CW2AEX() throw() { if( m_psz != m_szBuffer ) { free( m_psz );//释放内存 } } operator LPSTR() const throw() { return( m_psz );//返回指针 } 反复试验了下虽然没有明确的发现内存问题但既然存在这种潜在的风险方法，是不能使用在服务器上了。 考虑用一个动态的字符串数组传递所有结果，并在函数结束的时候一起释放。 在函数体的开始位置声明宏 CONVHEAD展开后是 list convhead_buf 使用宏 #define U2G(in) (conv_utog(in, convhead_buf))? (*(--convhead_buf.end())).阅读全文>

发表于 @ 2009年03月28日 12:39:00|评论(loading...)|举报|收藏

2009年01月24日

原创 openGL的局限

找openGL和Directx3D还有OGRE 3D引擎的三本电子书，开始发愁先从哪里看起。3本书都是先通读了一遍的。一开始就不太喜欢DirectX，因为前几年成有过学DirectX的冲动。那个时候看一篇文章说一个人写了了很牛的3D引擎几十万行的代码如何如何。就找了两个例子去看，但因为不太熟悉com组件败下阵来。转而又去研究com组件，反正现在看起Directx也是不太喜欢。前几天看文章说openGL有被iphone支持，这说明了两个情况一iphone有或将要有显卡，二中小型3D网络游戏将可能登陆手机。兴致冲冲的又跑去拿起openGL的书看起来，在刚刚逝去的2个小时里在寻找openGL的例子,越google心越凉。linux占有率是４％，其中很多是服务器形式，桌面系统使用者就更可怜了。openGL通用性的确很好但一个程序里面不可能只有openGL的使用。当然不能移植代码越少通用性就会越高，但想象下把代码量很夸张的游戏做移植就不是说说哪么简单了。openGL的通用性固然很高但大型游戏软件的移植效率肯定比不上一个针对固定平台开发的游戏来的高。加上少数派平台的用户稀少，就不奇怪好的大型游戏为阅读全文>

发表于 @ 2009年01月24日 05:15:00|评论(loading...)|举报|收藏

2009年01月05日

原创 GDI绘制界面注意的几点


  GDI绘图和openGL等其他绘图方式都是将图片绘制在指定屏幕的像素点上，不同的是GDI没有也不需要3D硬件加速等功能！所以GDI理论上的速度只和硬件有关。GDI刷子等概念并没有显卡硬件加速功能，所以要使用双缓冲区的概念。GDI+在这方面有所改进但也不太乐观。所谓双缓冲简单的说就是把图片绘制完成处理后形成一张定格的图片后在输出到显卡。

    当使用GDI绘制图片时（GDI本来就是绘制简单图片使用的）理论上只是期待最后形成的图片，其间处理的过程所用的时间用户的能够忍受的。当使用GDI绘制界面就完全不同了，用户是不能忍受任何界面的延时。

    所以GDI绘制界面要尽量使用绘制好的图片，不要使用刷子等工具现画。这不是水平高低的问题，前面说过GDI是没有硬件加速功能使用刷子等绘图工具会占用cpu使用量。界面又是用户反复操作，当操作速度过快时就会大量占用cpu使机器性能下降。

    阅读全文>

发表于 @ 2009年01月05日 11:55:00|评论(loading...)|举报|收藏

2008年12月24日

原创 由0day漏洞看利用系统漏洞攻击。

        0day是难得被国内研究的比较广泛的系统漏洞，以前的系统漏洞很多都只限制在某个圈子里流行，很难有比较公开的资料供大家研究。这个漏洞从被微软公开下载补丁，到细节在国内被广泛传播只有短短的一两个月，或者更早的时间已经在某个圈子流行的。也许国内已经度过了从dos转型后系统安全技术由神秘到今天逐渐大众化的过程。        0day是一个比较典型的系统漏洞看代码是最初是某段xml的解析导致了系统崩溃。这个崩溃是由一个call 引用了一个已经被释放的地址造成的。而这段地址刚刚好是指向了image src变量的http://后面的一段 。这是一个动态分配的结构含有函数地址。在被释放后又错误的被调用引起的崩溃。阅读全文>

发表于 @ 2008年12月24日 13:56:00|评论(loading...)|举报|收藏

2008年10月07日

原创 版本号，软件工程的标尺

在这段的开始先介绍一本书 《编程匠艺》code craft.这本书的想法和我将要说的和已经说得向吻合，如果说是我吸收的某些这本书的思想，哪我将会补充这本书的没有提及的细节问题。编程匠艺看起来很空洞好像一个人赶工写出来的东西，很多技术细节都捎带过去 ，看得出来作者应该是一位很有经验的项目经理。 从这篇开始我会用简单的语言讨论在软件工程里的一些起着决定性的技术方法。尽量简单明了。 版本号是每个模块都应该有的，经过多年的演化版本大致分为4个部分。 主版本，子版本（辅版本），测试编号，生成编号 主版本代表一个软件大版本表示软件的，新建，重写，重构，大的模块添加删除，或者在交替开发模式里面代表不同的团队开发的版本。多个模块的软件可以只有一个公共的主版本。当多个团队合作开发时也可以做为每个团队的标志。 子版本或者叫辅助版本，代表模块内某个功能的添加删除，相对于主版本代表模块的次要的设计上的改动。 测试编号和生成编号，生成编号代表模块生成的次数，是模块同一版本的模块阅读全文>

发表于 @ 2008年10月07日 19:01:00|评论(loading...)|举报|收藏

2008年09月17日

原创 绩效管理项目持续发展（二）源点


        一个程序开始规划，编码，测试，发行，修改，再编码，再测试，再发行。
        大量的书籍试图找到一个在持续开发和质量收栈的完美解决方法。但也是大量的书籍告诉我们一个混乱的工程是如何在用户背离，程序员的背叛，投资商的哀怨中结束！银弹是不存在的！
        软件的根本矛盾在于评价软件好坏的标准由如弹簧！即使一个非常垃圾的软件在综合外力作用下也可能用户上千万！貌似很成功的背后是千头万绪的剪不断理还乱。 软件作为一个严谨的工程学本身是有着客观规律可循。软件工程起源于追求与需求的平衡点，越是精简高效率的代码可更改性越差，反之越是功能扩展良好的代码越庞大复杂。那么让我们回到日常的工作来，一个程序的工作就是规划，编码，测试，发行。如果是一个复杂到需要升级的软件，那么这个程序员就要一直的重复着这个过程阅读全文>

发表于 @ 2008年09月17日 22:26:00|评论(loading...)|举报|收藏

2008年09月07日

原创 绩效管理项目持续发展

绩效管理项目持续发展阅读全文>

发表于 @ 2008年09月07日 13:13:00|评论(loading...)|举报|收藏

2008年01月22日

原创 自动增加版本号

三个js文件叫increment.js，version.h，build.h 修改资源文件，参考上一篇文章。把3个文件拷贝到工程目录下面。在net2003的项目属性-〉生成事件-〉预生成事件-〉添加 $(ProjectDir)increment.js ==========================================代码如下 main(); function main() { var bDebug = false var Args = WScript.Arguments; if(Args.length > 0 && Args(0) == "/debug") bDebug = true; // Create shell object var WSShell = WScript.CreateObject("WScript.Shell"); // Create file system object var FileSys = WScript.CreateObject("Scripting.FileSyst阅读全文>

发表于 @ 2008年01月22日 10:15:00|评论(loading...)|举报|收藏

2008年01月18日

原创 define 宏几个细节

要做一个自动增加版本号的小东西。参考了http://www.biasecurities.com/blogs/jim/archive/2003/10/08/166.aspx和http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q237/8/70.ASP&NoWebContent=1都是使用编译器自带的脚本工具，我对bs的脚本很不感冒并且它的移植性很差而且还有个问题，不知道是我没找到还是什么，这个脚本有些不太好分的清楚一个大项目下的个个子项目导致一些奇怪的bug。脚本的使用主要是对头文件的修改，网上一些非脚本的程序使用的方法是对资源文件的修改，第一种方法说了会有一些奇怪的bug第二种方法是会导致提示资源文件被编译器以外的修改的重新加载的提示。当是单一工程的时候还可以忍受，多个工程的时候会非常的痛苦。所以我打算使用js的脚本来写，js的脚本是可以在系统下直接运行的，提供了有限的库。可以阅读全文>

发表于 @ 2008年01月18日 20:31:00|评论(loading...)|举报|收藏

2008年01月01日

原创 经验的软件工程

1，阶段越清晰目标越明确可控制度就越高。软件工程失败的很多原因是公司对工程管理不分阶段，目标不明确。往往是开始设定一个简单的功能，并根据这个功能设定一个较段的开发周期。在随后的开发过程中任意添加功能并天真的认为每一个功能的开发时间是简单相加就可以。在这里1+1 ！= 2 ，比如设定一个功能的开发周期是一个月，在这个开发月中有想到了一个新的功能要添加进去新的功能的开发周期是2个月，那么如果这个工程的第一个开发框架并没有考虑第二个功能的前提下，这个工程就要推倒从新开发，那么加入新功后能的开发周期就不是2个半月（这个工程已经开始了半个月）而是3个月！2，软件的大小和质量与设计人员的水平有关而和数量无关。先不说微软等超大软件团队那是特例！全世界只有一个微软，却有无数个中小软件团队。一个软件产品按技术等级大致可分为核心技术，外围技术，边缘技术三种。能够理解核心技术的程序员很少，能够利用核心技术搭建软件框架的更少。但一个软件盈利和竞争力的部分恰恰是核心技术。当开发一个中型软件时，只有少数的设计人员能够设计核心的框架，接口和每个模块使用的技术等级。并根据个个程序员的水平分配工作，完成一个开发阅读全文>

发表于 @ 2008年01月01日 15:14:00|评论(loading...)|举报|收藏

第1页，共3页
第一页 上一页 下一页 最后一页
Csdn Blog version 3.1a
Copyright © Sur