Blog my life

下载0day的5.2.1的破解（地址网上找哈），得到lic_gen.exe用于生成文件。

下载最新的5.4.0，安装，将gDEBuggerAppCode.dll中的RSA字符串（字串）：

C4DD47CE9C8B14AD4993751B8E92598765868B23653DF74B06EF9131EFAEE53013760709FF932832C244AED24E1371673BA091BF5D04CE1A6ADA20378F81CDC912200FD6ADB517BA4CD32164D6D905E9B713406A1416295D4DEB8BFE769A3E46A2A20F1B36BBA06D17D3C2118A25A134EBC7B5A0412308422724BBE81635F9BB

替换成

CB64B8141DA2441B39902D0C890BE6C6C668B7D0C69275EC4DC55BC0583BF89FCB1B978F5F11558A0FA0910D19EF8ACE6E074CAF31DE7DADF768878CE2EF456FF9A1967F7F594E6D0B6AEF92CB73B7534ADE8383BD537698419E9F1CFC21D873FB1F6D5038603D1E68A8ADF3CB9511475D865454421FAEFB723A9C6BDA1DF0A9

并保存。这是代替key_replacer的作用（这个程序只针对5.2.1）

覆盖原文件后，按照5.2.1破解操作进行。用lic_gen生成Licence。注意生成Licence的时候选择第一个。
进入后不会提示需要注册的窗口，看似完全破解了。按“播放键”进行调试会没有反应，不清楚为啥。
退出程序，打开OllyDbg，选择File->Open，选择gDebugger.exe，然后按F9，就可以用了。注意将OllyDbg的Debugging Options中的Exceptions的Ignore (pass to program) following exceptions所有选项勾上。防止在pause程序的时候被OllyDbg中断。

这时就是真正的完全破解版。目前5.2.1和5.4.0均可以使用此方法破解。

另外，如果达人有能力会破解的帮忙看看为什么用OllyDbg载入后他的限制就消失了，应该会有一个检测调试器的函数怎么的，把这个函数破解了就好办了。

如需要原版和破解的压缩文件，请留下你的联系方式。

Enjoy!

最近遇到个奇怪的现象，在调试我的C#程序时，如果VS不打开“启动非托管代码调试”的话，序列化我的一个ApplicationConfig类就会报告“Unable to cast object of type 'X' to type 'X'”的问题，打开后万事大吉，但是无法进行暂停后编辑运行。

遇到这个问题后第一反应就是VS出问题了，重装系统后无法解决问题。

后GOOGLE到：http://www.google.cn/search?hl=zh-CN&source=hp&q=Can%27t+cast+type+X+to+X&btnG=Google+%E6%90%9C%E7%B4%A2&aq=f&oq=

发现其他人也遇到相同的问题，但具体问题不太一样。但大体看来是程序集出了问题。我选择清空项目然后重新编译，问题依旧，这就奇怪了。

最后偶然之间到我的编译目录下一看，清空后竟然dll文件还在。手动删除后，一切问题解决。

最后看来，还是DLL没有被正确删除造成的。那位什么没有被删除的DLL会影响随后的编译和调试呢？神奇了。

自从操作系统升级到Win 7以后，SVN Commit就经常出现类似错误：

Commit
G:\doc\projects\estar\trunk\vs\EstarSharp\EstarSharp\Data\WorkData.cs
G:\doc\projects\estar\trunk\vs\EstarSharp\EstarSharpGUI\Forms\About.cs
G:\doc\projects\estar\trunk\vs\EstarSharp\EstarSharpGUI\Forms\MainForm.cs
G:\doc\projects\estar\trunk\vs\EstarSharp\EstarSharpGUI\Forms\MainForm.cs
G:\doc\projects\estar\trunk\vs\EstarSharp\EstarSharp\Data\WorkData.cs
G:\doc\projects\estar\trunk\vs\EstarSharp\EstarSharpGUI\Forms\About.cs
Commit succeeded, but other errors follow:
Error bumping revisions post-commit (details follow):
Can't move
'G:\doc\projects\estar\trunk\vs\EstarSharp\EstarSharp\Data\.svn\tmp\entries' to
'G:\doc\projects\estar\trunk\vs\EstarSharp\EstarSharp\Data\.svn\entries': The
file or directory is corrupted and unreadable.

说文件损坏或者无法读取。这是一个很令人费解的问题，到底commit是成功还是失败了？网上查询一番后找到有朋友遇到相同的问题并且给出了解决方案（见：http://schleichermann.wordpress.com/2009/12/09/svn-tortoisesvn-cant-move-the-file-or-directory-is-corrupted-and-unreadable-windows-7/）

原因是Win7启动了索引服务和SVN Commit时候移动文件冲突了。解决方法是关闭Win 7的对SVN仓库的索引服务。

打开Win7的控制面选，选择“索引选项”，然后选择“修改”，将G:\doc\projects\estar全部反选即可

最近事情多哦，抓紧时间把弯管机工艺申请的专利说明书写完叫了，又花了两个小时把中期检查的PPT做了，然后随时当接线员，软件的BUG一个一个的出来，接下来又一个一个的消灭了，再后就研究OpenCASCADE用在五轴五联动仿真上的可行度。
一件事情一件事情的理清楚好了。
弯管机工艺专利其实不是我做的，写专利说明书还是按照以前遗留的一些文档复制粘贴，改改格式，重新做作图，就OK。核心的东西写不来，一个函数上5000行的程序看不懂，也没有必要看懂。更悬的学术派的什么说法我弄不懂，胡扯罢了。
中期检查的事情让我想起我们的开题报告，开什么题哦，检查也是敷衍，本来认认真真做的PPT就让检查的给敷衍了。
软件的BUG是最近比较头痛的事情。还好早就有大量的准备。
首先是软件的LOG系统发挥了很大作用，在设计之初就采用了自己写的一个LOG系统。虽然说功能很简单，但比没有强多了。
其二是指导厂商去客户那儿了解客户出问题的具体原因，不要就是说“软件卡死了，软件有问题”这种根本无法确定原因的问题。要得到故障发生的具体时间，越精确越好，方便定位时间。另外要保证是电脑上的时钟，而不是客户手上的时间，搞不好今年2009年电脑还是2008年呢。
第三是要有解决问题的耐心。因为客户在温州，我在成都，而且我手上没有现成的设备供调试。所以所有的程序修改工作都是“瞎蒙”的。但这个“瞎蒙”不是指随便乱猜，这样只会使程序越改越糊涂，厂商和用户会越来越没有信心。力求做到解决一个问题就不再会出现了。关键就是如何正确的分析LOG文件了。最开初设计的LOG文件加工后会变得异常的大，经常加工一天就几个G，中间有些大量垃圾信息是在while循环中生成的，将这些去除，再优化和规范LOG的格式，便容易分析多了。
对于LOG的添加也是在不断地测试、不断地试用当中逐步添加的。起初根本不知道哪儿需要LOG、LOG记录的密度等等。在后面看LOG的时候会逐步明朗的。
那么离线情况下如何进行调试呢，有些时候是没办法的。还好我这里在前期设计的时候就做了一个简单的虚拟机床模块，可以模拟运动控制卡、IO卡的动作。当时用了两三天的时间制作，并在后期进行了维护。现在看来这个模块起了很好的作用，一些简单的流程上的问题就直接在虚拟机床上测试即可。对于一些疑难杂症，就只有靠更透彻的分析日志，特别是多线程的时候，更要仔细的检查GUI、底层线程、和状态机的配合。
最后就是要认真的记录出错的原因。因为软件越到后期出的问题就更是稀奇古怪，没有良好的注释和版本管理，肯定会修正了一个问题又带来N多的其它问题。总结了一下整个软件的设计，还是有不太满意的地方，但目前修改的话已经不太现实。所谓吃一堑长一智，下个系统开发的时候会更关注于整个框架的结构，毕竟，这些都不是靠书本就能学来，实战才能让你理解为什么书里面说的是对的，为什么是错的。
OpenCASCADE目前还没有找到合适的路子去仿真五轴数控，恐怕还需要学点数学的东西，刀具的包络面能够出来了，大部分事情就解决了。

最近眼睛很不舒服，到了晚上就红，看东西也恼火，今天去看了一下，原来不是疲劳的问题而是结膜炎惹的祸。后来吃饭的时候谈论到传染的问题，才忽然想起前段时间在外面酒店住的，很有可能是洗脸帕上面的细菌传染的。晚上点了两次“加替沙星滴眼液”以后明显好多了，眼睛也舒服多了。看来以后出去的时候一定要用自己的洗脸帕比较安全。

OpenCASCADE的QT例子过于复杂了，不突出核心。经过几个小时的钻研终于把它搞定了。编译环境是Ubuntu 9.10+Eclipse+QT4.5，有兴趣的可以看看。很简单的例子，可以突出核心。

  qtCASCADE.tar.gz (37.4 KiB, 123 hits)

花了些时间终于在MINI2440上把enlightenment运行起来了，速度还行，比XFCE和GNOME快多了。XFCE和GNOME的X的CPU占用率高达50%，难怪很慢。Englithenment没有这个问题，不用的时候CPU占用率很低。

编译Enlightenment仅需要使用Openembedded就可以构建，详细步骤今天没时间写了，以后有空补上。

看看截图吧，解解馋。

我是才接触OpenEmbedded不久，也算是个菜鸟。看到这么方便的东西以为bitbake xxxx就可以了，结果哪知道这个才是唐僧刚刚上马，遇到的妖魔鬼怪还多着呢。这里总结一下我最近bitbake console-image所历经的磨难。

1、准备

• 一个超级好的网络是必不可少的，否则当你什么都下载不了的时候你就知道什么是痛苦了。
• 一个4核的CPU是很有必要的，当然如果有钱可以买个core i7更好
• 如果想在编译的时候能够打发一下时光，建议安装vmware。特别建议用7.0的技术预览版（网上找找看有没有，我是vmware邀请测试的），因为可以支持大于2个CPU。
• 留至少80G连续的硬盘空间。
• 选一个比较吉祥的日子，准备好耐心

2、下载和建立好local.conf

从OE的官方git源clone一个副本，这个步骤我就省略了，但是记得经常git pull。我的local.conf的MACHINE定义为mini2440，DISTRO定义为openmoko。想编译一个openmoko出来玩。

3、bitbake console-image

然后bitbake就会工作了，期间肯定会遇上小的妖魔鬼怪，什么preferred version not found之类的，只需要改变一下conf/distro/conf文件里面的preferredxxxxx.inc文件就可以了。具体是什么文件可以用grep xxxx -r .来搜索，当然这你得有一些基本的linux尝试。

其他的问题比较多的是：

1、编译出错。我想这不是我的错，如果在recipes的相应组件中找到了更新的版本，可以使用另外的版本来替换。替换的方法是修改PREFERRED_VERSION_xxxxx的值即可。一般使用高点的版本就会OK。

2、没有本地的工具支持。有些编译项目需要本地支持。上次编译mtd-utils就遇到了本地有一个工具没有安装。如果看到了有些错误位于i686目录（有这个字样的），就可以怀疑是本地有些工具或者库没有安装，从而不能正常编译。懂点脑子把东西装上应该就会对。

3、版本不兼容。有时候包与包之间有可能不兼容，方法是把出错的包在网上搜一下，例如这个编译mtd-native的错误就是由包之间不兼容引起的：http://projects.linuxtogo.org/pipermail/openembedded-devel/2009-January/007571.html

4、其它问题。有时候编译中途出了问题（例如电脑死机、意外重启、停电等）会造成一些莫名其妙的温长天，把tmp文件夹删除了再编译，看会不会OK。当然删除tmp文件夹要有点耐心，文件太多了。

如果想在晚上通宵运行，那么加一个-k参数就好，这样第二天早上再来处理那些莫名其妙的问题。

写这篇文章的时候我只记得这么几个问题了，还有一些另外的小问题，但也都是很容易解决的。多多搜索，或者利用邮件列表来解决。

现在开始另一站了，编译bitbake x11-office-image。

外面下雨了，这个国庆真是恼火~

April 21th, I got an email saying I was registered for ERC 2009 and the conference would be hold at April 23th. I remembered I haven't registered any conference yet. Is that a fake one? I searched the web just to find that there was really a conference here in Chengdu. I was confused but I guess it could be a mistake or I forget I've registered. Though it may be fake, it's not bad see if it is real. By the way, that day was my birthday! If it was true, I would have meals for free. A big gift! Read more

我在开发WinForm应用程序的时候很少使用数据绑定，以前也没有怎么用过。今天在做一个参数设置面板的时候用到了他。然而很令我失望，它不仅没有解决问题，而且还带来了严重的问题，让我找了好半天，最后确认是BUG。当然也不是我一个人遇到了，看看这篇文章，他们也遇到了相同问题。

问题描述起来是这样的：

我有一个这么样一个Class：

[csharp]
public class BindTest
{
private int number = 5;

private int anotherNumber = 10;

public int Number
{
get { return number; }
set { number = value; }
}

public int AnotherNumber
{
get { return anotherNumber; }
set { anotherNumber = value; }
}
}
[/csharp]

窗体上有两个控件，一个是textBox1，绑定Number属性，另一个是textBox2，绑定AnotherNumber属性。由于我需要“确认”和“取消”按钮，所以我在高级绑定里面将两个控件的绑定行为改为Never，也就是不更新它的值。

按照MSDN里面阐述的，使用Binding的WriteValue()方法就可以将数据更新。在我的程序里面可以这样写：textBox1.DataBinding[0].WriteValue();

textBox2类似的做法。

后来一运行，问题就出来了，仅仅能够将textBox1的值更新，而textBox2的值还原了！！！

一番搜索以后又回到了刚开始的那篇讨论中，有人这么说道：

As to the problem above this comment, it is a common malfunction of databinding. Simply, if you attempt to control the writing/reading behavior of Binding class, it will --REVERT-- changes of all other non-bound fields/properties. Therefore, only first bound control gets updated due to the fact it is the only one which has access to CHANGED data, after its done with the update, it reverts the changes back thus canceling them, so other bindings are useless.

大意是“这是数据绑定的一个故障。简而言之，试图操作绑定类的写入和读取行为，它回将所有的未绑定的字段和属性还原。因此，仅仅只有第一个被绑定的对象能够得到修改了的数据，在它完成刷新操作之后，它将所有的修改还原因此就取消了其他控件的修改，因此绑定是无用的”

理解了以后，就明白了，我得重新手动写了，哎，数据绑定真是讨厌啊。