x64版 Dependency Walkerがx86アプリケーションで迷子になる
x64版 Dependency Walkerでx86アプリケーションを開くと「なんかおかしーよ！」という旨のダイアログと次のエラーメッセージが表示される:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
拙訳:
エラー: なんか見つかんないエクスポート関数があるから解決できないインポートがあるよ！
エラー: CPUタイプの違うモジュールが混ざってるよ！
たとえばx86版のDependency Walkerを開くとこんな感じ:
x86アプリケーションのはずなのに64bit版のモジュールが表示されてるよ！？ なんで！！？？と思ってF9してみたらこういうことでした:
暗黙的リンクの場合、モジュール名しか記録されていないので順当にWINDIR(ここではC:\windows\system32)にあるものと仮定するっぽい？ 実際にはWOW64環境下ではC:\windows\syswow64からx86バイナリがロードされるのでDependency Walkerのこの挙動にはちょっとビビる。
Forumでもだいぶ前に報告されているけど、別にどーでもいいっちゃどうでもいいことなので対応しないのかもしれない。
これ修正されないのかな？
.idataは.rdataにまとめらることがあるらしい
例えばxeditをdumpbinするとわかるのだけど、このアプリケーションは.idataというセクションを持っていない:
もちろんxeditが何もインポートしていないというわけではなく、ImportDirectoryにはきちんとアドレス・サイズともに格納されている。オフセットからするとインポートディレクトリテーブルは.rdataに所属しているようである（ちょっと長いのでembedするのはやめた。gist参照）。
普通インポートディレクトリテーブルなどの情報は.idataにあるはずで、.rdataが格納するのはRead-only initialized dataであるとされている。不思議に思ってググってみるとこんなQ&Aが:
Imports in .idata instead of .rdata section?
デバッグビルドで/EDITANDCONTINUTEを有効にしているとこういうことが起きるらしい？
SectionHeaderのNameはあんまりアテにならないとは思ってたけど、まとめちゃうようなケースもあるのね…。
.NETな実行ファイルもC#から読んだりする
昨日調べてるときに見つけて書きそびれてたこと。
PERWAPI っていうのがある: http://plas.fit.qut.edu.au/perwapi/
Portable Executable Read/Write API の略らしく、参照追加するだけで使えるようだったので試してみたところ、ほとんどすべての実行ファイルで「うまく読み込めない」的なエラーを出して死ぬ。
よく読んでみたら.NETな実行ファイルをごにょごにょするためのライブラリらしかった。
今のところ使い道ないけど、いつか役に立ちそうなのでメモっときます。ライセンスは “BSD風“(BSD-like License)だそうな。具体的な条項を含む文書は見つからなかった。
C#からPE headerとかを読んだりする
C#からPEファイルを操作するライブラリっていかにもありそうだな～と思って探してみたけど、あんまりそのものずばりなものは見つからなかった。 一応読み込み用のクラスは作って公開してる人がいた:
Reading the Portable Executable (PE) header in C#
コメント欄によれば無保証で使っていいよとのこと。
PeHeaderReader という名前どおり、 NT header 中の Fille header と Optinal header を読み込んでくれる。 NT signature は読み捨てていて、DOS header は読み込んでいるがデフォルトでは accessor は提供されていない。
個人的なニーズとしてセクションヘッダくらいは読んでくれてほしかったので改良した: https://gist.github.com/2633405
ベースの PeHeaderReader に加えて sectionHeaders とかがみれるようになってます。
NOTE: IMAGE_OPTIONAL_HEADER がPE32用とPE32+用で分かれてますが、 PE32+用確認せずに作ったのでもしかしたら間違ってるかも…。
勢いで書いたのでいろいろあれですが勢いで書かなくてもいろいろあれになるのは性格のせいな気がします。 MIT License です。ご自由にお使いください。
参考
tmuxでカレントディレクトリを維持したままペイン分割する
tmuxでsplit-windowによるペイン分割(デフォルトではC-b ” or %)をすると、新しいペインでのカレントディレクトリはtmux起動時のカレントディレクトリに設定されている。new-windowならまだしもペイン分割でのこの挙動は(自然不自然は主観によるとしても)実用上不便に感じることが多い。
そうした意見は多数派のようで、ググるとたくさんの記事が見つかって、設定例の大元はArch Linuxのwikiのようである。この設定例の黒魔術っぷりを見ればわかるのだけど、要するにこれがデフォルトの挙動でないのは思想的なものというよりは実装の難しさによるもので、その面倒くささから僕は設定さえも敬遠していた。
が、ちょっと気が向いたので設定してみようとしてびっくり！ArchのWikiに「最新リビジョンだとこれがデフォルトになってるよん」との記述が…！さっそく試してみたら超快適でおもらししちゃいました
最新リビジョンのビルドといっても普通はそんなに難しくなくて、
$ svn co https://tmux.svn.sourceforge.net/svnroot/tmux tmux
$ cd tmux
$ sh autogen.sh
$ ./configure
$ make && make install
するだけ。libevent2, ncursesをお忘れなく。ちなみに手元のUbuntuでやったらautoconfがコケで悲しくなってきたので後輩さんのGentooでビルドしてもらったバイナリを使ってます！ なんでconfできないの、、、
ちなみにこの機能、Linux, Solaris, FreeBSD, OpenBSDでのみ実装済みのようす。といいつつtrunk/osdep-darwin.cにベースはあるようなので、Macなどで使いたいかたは実装してみてはいかがでしょうか…たぶんosdep_get_cwdとかをプラットフォームに適切なように実装すれば動くんじゃないかなあ…
Obtain vertical substitution of OpenType font
Vertical layout with FreeType seems easy at a first sight, but soon you’ll get trouble that some letter has to be rotated 90 degrees. Like this:
You must feel it strange if you have ever read some Japanese text laid out vertically. It’s because two letters(“～” and “ー”) have not been rotated. Even more, as sensitive one could notify that, one letter “っ” keeps staying too left-bottom. It should be placed right-top of the bounce of letter.
Some sort of fonts provide the way to solve that. They simply provide another glyph to be used vertical layout inside itself. As you know FreeType parse the font and obtain the corresponding glyph index from Unicode index. Like this, if you will use the glyph provided for vertical layout(called substitute glyph), you should substitute glyph index by parsing the relation of them. The relation represented in the file as GSUB table.
Unfortunately, FreeType doesn’t support the parser for GSUB table and has never. But an implementation of this exists as in public domain.
I implement something to show vertical substitute glyph correspond to given UTF8 character. This command line program takes two arguments: path to font file and one UTF8 character you want know glyph index.
$ g++ vertical_substitute.cpp ttgsubtable.cpp utf8decoder.cpp `pkg-config --cflags freetype2 --libs freetype2`
$ ./a.out mplus-1c-heavy.ttf ～
Font specified: mplus-1c-heavy.ttf
Unicode index: 0x301c
Glyph index: 0x09b0
Vertical substitute: 0x189d
You can show vertically optimized glyph by passing above value to FT_Load_Glyph function:
This script is included by my repository so you can build this the command above.
Operating a mailing list
Two existing different points of view, about mailing lists:
- Pros; share what’s going on and what’s done between developers
- Cons; nobody will read what’s sent the list
My current opinion is the latter. Some my teams in previous projects worked well on the mailing list, however, the most didn’t on the other hand.
The reason why every one(includes me, of course) will never read the mails on the list might be because of too many emails sent there. It seems we ignore the list just when we’ve got too many from it.
If it’s true then we can solve that by making the mails on the list fewer. I consider what a mailing list worth is archivability, so it seems possible to get fewer the number of the mails with getting the value of the list together.
The rules to use the list with both of archivability and responsibility.
- Not to discuss on the list. Discussions should be done on personal mails. Just use the list to ask other developers or to notify what you decided.
- Specify a format the mails on list should observe. This will eliminate the impediments to write a mail to send completely newly, and make the mails easy to be read.
- Make the archive easy to be refer. This seems possible by using Google Group or the group feature of the Google Apps.
I’ve never known if the rules work well, I just want to try them from here
Decoding UTF-8 byte sequence to Unicode code points
Some libraries like FreeType will take a Unicode code point(or Unicode character) to render a glyph or something. We usually use UTF-8 to serialize a string, show in a terminal and so on, however, about decoding UTF-8 byte sequence to a Unicode character, I didn’t know how.
To encode Unicode character to byte sequence, we can use some different formats: UTF-8, UTF-16, UTF-32. As you know, by high compatibility with ASCII string, UTF-8 encoding is becoming de-facto standard recently.
To understand the format, the facts listed below will help you:
- Each bytes in a UTF-8 string are classified as head byte of n-byte unicode character or following byte
- Pick up a single byte from UTF-8 string, it is very easy to check if the byte is head byte or following byte
- Extract a chunk of UTF-8 encoded character, it can not be used as Unicode character directly
So then, let’s take a look. We consider the case given a UTF-8 byte sequence “0xE6 0x97 0xA5 0xE6 0x9C 0xAC 0xE8 0xAA 0x9E 0xE3 0x83 0x86 0xE3 0x82 0xB9 0xE3 0x83 0x88”. This represents a six-letter text “日本語テスト” in Japanese language which contains three Kanjis and three Katakana.
The first letter of the text is “日”. This letter is allocated U+65e5 in Unicode table. As you may know, the most of UTF-8 character are represented by two or more bytes except ASCII characters. In this case of “日”, the letter encoded to three byte in UTF-8.
Let’s begin by checking if the first byte is head or following byte. To do this, you just have to compare the first two bits of the byte with ‘10’. If the byte starts with bits ‘10’, it is a following byte. If not, it is head byte of some byte character(you don’t know what following byte is? No problem, I will explain it later).
The UTF-8 byte sequence which given starts with a byte “0xE6”. This shown as a hexadecimal, so show this as a binary: 0b1110 0110.
As you can see, the first two bits is ‘11’, not ‘10’. Then we can decide this is the head byte of n byte characters.
But how can we decide the n? This is also pretty easy, it can be done just by counting how many ‘1’ bit is until the ‘0’ bit appears. In the case of byte ‘0xE6’, or ‘0b1110 0110’, we can see the byte is the head byte of 3 byte character.
If this byte is the head of the 3 byte character, we can estimate the two following bytes are not a head byte. So call themfollowing byte, and check if it is true or not.
0xE6 | 0x97 | 0xA5 => 1110 0010 | 1001 0111 | 1010 0101
0x97 and 0xA5 is starting with two bit ‘10’, so they are following bytes.
So now, we know three byte letter ‘日’ is represented by ‘0xE697A5’. But I still need to convert this to Unicode code point, U+65E5.
Of cause we can do this very easily. In short, all the thing we must do is Remove header bits and join them.
The header bits mean the bits we use them to classify the byte. I wrote a table for explaining it:
Byte(hex) Byte(bin) Header bits Rest bits
----- --------- ----------- ---------
0xE6 1110 0110 1110 0110
0x97 1001 0111 10 010111
0xA5 1010 0101 10 100101
Note that the header bits of the head byte include a zero bit at last of the bits.
Finally, we just have to join each rest bits described above: 0010, 010111, 100101. We got a chunk of bits ‘0110 0101 1110 0101’ by simply joining them. This is just shown in binary. As a hexadecimal, they are shown as ‘65E5’.
The result matches with ‘U+65E5’, which is the code point of ‘日’ in Unicode.
At last, I wrote and gisted a C++ class which decode UTF-8 byte sequence to Unicode character.
File uploader on Rails via Windows Azure
Heroku is a great platform to deploy Rails applications.
Since it is a cloud platform it does not allow us to use local storage. Therefore we must use an external storage service or make our app referential transparent. Heroku recommends to use S3 as storage officially, but this time I tried to use Windows Azure.
Here’s the repository and the working demo.
In Windows Azure, we can use Blob storage as a key-value storage just like Amazon S3 in AWS. Blob storage can be controlled by Ruby with waz-storagegem. If you have Windows Azure account you can deploy it also your own server. Unlike other cloud platforms, it can’t be used through Fog (it seems just not to be supported). So managing assets in models must be implemented by ourselves.
And now, waz-storage includes a bug it fails to change or obtain container publicity. Probably this will be fixed shortly or you can avoid it by a workaround. The solution is also included in whatzup repository.
