首先依据网上的说法，到C:\Windows\Resources\Ease of Access Themes下找是找不到standard配色方案的，这原因我也不清楚。只能说假专家比假货还多。

我检查事件记录器的时候发现，我的色深不对，是16位的。所以没有办法启动桌面窗口管理器。

修改成32位，再去看配色设置，可以见到有standard了

有一些程序在写好了以后需要做修改，但是由于源代码缺失。

并且修改点可能很简单，也就是修改某一个函数的跳转地址之类的。直接用ollydbg修改即可。但前提是要知道指令的地址，以及要修改到的位置。

对于win api就很简单了，直接通过加载模块的地址一查询，就可以跳转到对应的反汇编地址上。

但对于内部自己做的一些函数，那就需要做汇编代码的分析了。

所谓的消息嵌套，说白了，就类似函数递归。下面存在这样一种场景，会导致所谓的嵌套发生。

需要解决一种使用场景，例如主线程post一个任务到MessageLoop的队列中，然后调用MessageLoop::Run。
这是进入消息处理，而这个抛入的任务实际上做的也是调用MessageLoop::Run。
那这就陷入了2个问题
1，要么出现多次“嵌套”，直到最后一个待处理的任务被执行完，然后再逐级返回，以至于最后一个任务被处理完。
2，要么直接死循环或者说是饿死。因为有可能抛入的任务都是调用同一个线程的MessageLoop::Run，然后最后被处理的任务被停在了事件等待上面，这个事件是用于等待有新MessageLoop任务抛入的。

因此nestable_tasks_allowed_ 标记就成了关键，这个标记控制着不允许任务会被嵌套的情况发生。

代码如下

  MessageLoop* task_run_on = NULL;
  MessageLoop* task_deleted_on = NULL;
  int task_delete_order = -1;
  MessageLoop* reply_run_on = NULL;
  MessageLoop* reply_deleted_on = NULL;
  int reply_delete_order = -1;

  scoped_refptr task_recoder =
      new LoopRecorder(&task_run_on, &task_deleted_on, &task_delete_order);
  scoped_refptr reply_recoder =
      new LoopRecorder(&reply_run_on, &reply_deleted_on, &reply_delete_order);

  ASSERT_TRUE(task_thread_.message_loop_proxy()->PostTaskAndReply(
      FROM_HERE,
      Bind(&RecordLoop, task_recoder),
      Bind(&RecordLoopAndQuit, reply_recoder)));

  // Die if base::Bind doesn't retain a reference to the recorders.
  task_recoder = NULL;
  reply_recoder = NULL;
  ASSERT_FALSE(task_deleted_on);
  ASSERT_FALSE(reply_deleted_on);

  //--- 这里将是比较关键的一个问题 begin ---
  UnblockTaskThread();
  current_loop_->Run();
  //--- 这里将是比较关键的一个问题 end ---

  EXPECT_EQ(task_thread_.message_loop(), task_run_on);
  EXPECT_EQ(current_loop_.get(), task_deleted_on);
  EXPECT_EQ(current_loop_.get(), reply_run_on);
  EXPECT_EQ(current_loop_.get(), reply_deleted_on);
  EXPECT_LT(task_delete_order, reply_delete_order);

readmore

有某种数据类型需要满足如下需求：

1，单一线程内部使用

2，生命周期与线程一致

3，便于管理

一般的做法如下:

unsigned int ThreadMain(LPVOID p)
{
    unsigned int g_ThreadVar = 0;    //这个作为线程自身的共享变量
    ...
    return 0;
}

这样做的坏处，主要是在代码里面可维护性和可管理性变差了。
所以就干脆采取tls来进行管理

unsigned int ThreadMain(LPVOID p)
{
    unsigned int* var1 = new unsigned int;
    tlsset(id, var)
    ...
    return 0;
}

win 2k时代开始，微软用的中文系统编码均是unicode，而unicode编码被微软使用固定的2个字节来存放（也许这就是和unicode字符集的编码长度有关）。

因此，在中文windows平台中可以直接等同这么看：

unicode便编译的代码，并且和unicode版本的微软库打交道的代码。在判断字符串时是否含有中文时，只要循环遍历字符串中的每一个字节，判断对应的 uint8 是否 大于 0x7F。如果大于，说明有中文一类的，非ascii字符。将对应的字符串buff，转换成wchar即可。否则直接按照char方式来用即可

在windows shell program中讲到。

这里不定期的更新一些《算法导论》中的一些属于。

1，lg n: 是log 以2为底 n的对数，并不是数学中的  log 以10为底 n的对数

cn实际上就是Θ(n)

2，f(n) = O(g(n))的实际含义是是说 f(n)是O(g(n))的一个集合

我是一个很能吃的人，平时都靠食欲来蒙蔽自己对营养不良的认知。

这次得了一场比较严重的感冒，整个人一下子就瘦了下来。

最近几天一直都吃不进东西去，也算是生病历史上少有的几次。今天去沙县喝了一碗当归汤，发现自己顿时越发收敛不住。更想起了以前小时候喝到一些山药之类的中药鸡汤。

以后对待自己决不能再使用暴饮暴食，过度饮食来麻痹自己。要吃的科学有用。

首先，这个笔记本的散热设计就很差。并且用了intel和英伟达的过度方案。

整个机器就相当的不成熟，不过从性能上来看，目前的游戏或者一些大一点的工具（vs 2008, vs2010） 之类的都可以应付得过来。所以2+3吧，用个5年，不追求最新的游戏和画面，应该是可以的。

2年了，没有怎么加过散热硅。最多就是清理过风扇那块，把堵塞物清理掉而已 。到了今年春节过来以后，发现电脑温度不正常。常常出现死机，而且散热口异常的烫。清理了堵塞物以后有所改善，不死机了。但玩一些游戏和开一些比较消耗性能的虚拟机的时候。死机还是照常的有。底部温度也很高。 readmore

我在杭州生活了6年，大学4年。工作2年。看法可能稍加偏见。

到了南京以后，第一感觉发现和杭州差别太大了。尤其是街道马路上的混乱局面。

坐在公交车上，查了一下杭州和南京的差别。发现一大堆口水战。一天的南京生活体现下来看，差不多有点感觉了。

readmore

第一次在火车官网上订火车表。

本来打算订一张20号到南京的火车票。由于订的车子是凌晨开车，时间算错了，倒是订票时下单的时间比计划出行时间早了一天。刚才准备上车时被列车员发现，没上成车又灰溜溜的去购票厅看了一下，凌晨是没有希望了。所以打道回府又花了好多钱。

订票时没有注意，确实是自己的错。但话又说回来，乘车人没有上车，铁路部门没有电话咨询，这一点确实做得不好。花了100多大洋送了铁老大。算是又一次在铁老大的霸气上吃了一亏。

出门比较衰。还没有出门就无缘无故的花了，好几百。真是一个不好的开始，不过也罢。摆正心态。睡一觉，明天起来去做汽车。发现还是汽车性价比最高。坐着是否舒服就不知道了。

是的，我也不例外，我也同样在逃避着某些事情。

逃避究竟是好是还是坏事？记得曾经一个电视上讲过，逃避其实是人的本能反应。

其实有些事情我已经忘的差不多了，并且也没有多少闲工夫去理会了。但是就是不想提起来，要说为何会去逃避。我也说不上来，但至少确实不太情愿提及起来。承认逃避，面对逃避我觉得现在应该这才是比较正确的做法。

感冒难受，最近要进行下去的事情也没有做。很是懊恼

偶尔听到这首歌，不错的。

现在收集了部分不错的轻快英语，乐队如 yuck , sky sailing, acid house kings。

生活需要逐步的找回来，目标的实现不能停止，不管最后是否能够达到目标，一定要继续努力!