很简单的一个插件，现在支持汉化Sublime Text2，Sublime Text3。全部系统Win64、Win32，Linux64，Linux32，OSX等，可以随意来回切换简体中文、繁体中文、日语、英语，无需重启SublimeText。

• 版本号
• mzscheme_base.c
• scheme_register_tls_space
• 自己编译Racket
• 我的修改
• 后记

在VS编译的64位gvim支持了Python2/3,ruby，perl，tcl，lua之后(参考在Visual Studio编译gvim和ycmd)，发现配置里面还有一个叫做MzScheme，而且是在Make_mvc.mak里面，就是说原生是支持VS编译的。那么开启吧。

Build from source code.

• 1.shobj.h present but cannot be compiled
• 2.cc1plus.exe has stopped working
• 3.localtime_r gmtime_r相关的错误
• 4.cygwin posix环境影响process.h

在自己编译FileZilla Client中编译过3.9，但是对于最近的3.10却一直编译不出来。

换了多个编译器，其中发现个新环境msys2中提到过的基本都试了一遍(实际上主要在实验有4.9的，因为Filezilla3.10.x似乎用到了4.9的一些特性或者头文件)。

• MSVC
  • 返回double
  • 返回 long long
• gcc
  • double
  • long long
• clang
  • double
  • long long

我们学过汇编的都应该知道C语言的返回值，在x86机器上面都是用eax来实现的。而eax是32位的，所以返回值只能是int/long类型或者指针类型，在汇编里面都是dword。可是突然想到怎么实现返回64位值呢？难道会是指针？显然不太可能这样做。

• MinGW/msys 1.0:
• MingW
• MinGW-w64
• MinGW-builds
• Win-builds
• tdm-gcc
• Cygwin
• msys2
• 结束语

好久没写，发生种种暂且不表。

最近注意到了一个新的Windows上面的模拟Linux的项目。一般来说两大主流阵营MingW与Cygwin，这两个思路各不相同。相对来说MingW性能比较好，尽可能用WinAPI替代实现。Cygwin则是添加了一个层，利用很多dll来模拟Linux的那些syscall(典型的如fork)。所以cygwin程序一般都是需要有cygwin的dll在path里面才可以运行。MingW缺点是很多程序没法编译，如果没有专门为MingW设计的程序，基本上MingW是编译不出来的。Cygwin缺点是会比较慢。

午后无聊整理了下大体上的语言关系图谱，有一些个人观点在里面如有不对之处欢迎指正。本来是一副横向的，但是我发现HTML那里刚好可以断开，所以就分成两幅了，对排版正好有好处。

电脑的日常使用中总是会感觉一些需求不能满足，比如希望批量重命名1000多个分布在不同文件夹的图片，希望在十多个文件夹中的txt文件中找一个含有某一字符串的文件等。

最近Adobe更新比较频繁，然后下载下来12个1G分卷的是用的Total Command的win-sfv32生成的一个sfv校验文件。因为以前好像都是MD5的校验和，所以直接用md5sum,sha1sum和type命令，直接在cmd里面就可以把问题解决(我的path里面带了cygwin的bin目录)。突然来个CRC32还真没办法。

最近一次升级cygwin后(cygwin升级基本上和Ubuntu差不多频繁，个人感觉仅仅次于Arch的升级频率，这说明开发社区异常活跃)，对图形界面比较惊喜。而国内的几个有影响的mirror都加入了cygwin的源，所以网速没问题的(实际上kernel.org的源也是非常稳定的)。