AppleのUSBに関するMailing Listで、Appleの技術者による以下のような記述を見つけました。
----------------------- snip -----------------------
The arg0 parameter of the IOAsyncCallBack1 contains the # of bytes that were transferred.
We are improving the documentation and examples so that this is clear.
----------------------- snip -----------------------
実際、IOAsyncCallBack1の引数の解説は不親切で、いくつかのサンプルコードを元に実際にいろいろと試さないと引数の意味は分かりません。
IOKitLib.h
つまり、上記の説明は以下のように書くべきでしょう(笑)
We are improving the documentation and examples now. So that, this will be, may be, or hope to be clear.
2007年8月31日金曜日
2007年8月19日日曜日
USB装置のMac OS Xへの移植
Windowsで動いているUSB装置のMac OS Xへの移植を考えている人は多いと思います。通常であればKEXTドライバかアプリケーションを書けば、全てのUSB装置はMac OS Xでも動作する「はず」です。しかし「動かない」ことがあります。
例えば、SonyのGPS ユニットキットGPS-CS1はUSBのマスストレージとして作られていてWindowsでは問題なくマスストレージとして認識されます。一方、Mac OS Xではマスストレージ用のKEXTドライバが標準装備されているので、USBマスストレージとして作られた装置であれば動く「はず」です。しかし、Sony GPS-CS1はMacintoshではタイムアウト・エラーになりマウントできません。ちなみに、Intel MacをBoot CampとWindows XPで起動してGPS-CS1を接続すると正常に動作します。このようにWindowsで問題なく動作するのに、Macintoshだと動かないUSB装置がときどき見られます。
昨年の末に私からAppleが主催するUSBのMailing Listで上記の問題に関して質問したことがあります。その時にはIntel MacとMac OS X 10.4.9の組み合わせではマスストレージとして認識されることが分かりました。しかし、具体的に何が悪いのかは不明のままです。他にも似たような症状を一部の「製造元不明」のUSBメモリで見ています。
さて、昨日に上記のUSBのMailing ListにWindowsに関して興味深い書き込みがありました。
質問した人はCypressのUSBチップFX2を使用した装置用にMac OS Xのアプリケーションを書いていますが、Windowsでは正常に動作するのにMac OS Xでは動きません。Appleを始め多くの技術者が討論した末に、質問した人から以下のような報告がありました。
まず、USB装置メーカが書いたCypress FX2用ファームウェアに以下の二つの問題がありました。
1.endpoint descriptorのBULK IN lengthが1024になっていた。
本来は512
2.ファームウェアのendpoint autoin lengthが1024になっていた。
本来のサイズ以上のデータを送ろうとしている。
上記の二つの問題はCypressやCypress FX2の問題ではなく、Cypressのユーザである装置メーカが書いたファームウェアの問題(バグ)です。繰り返しますが、CypressやCypress FX2の問題ではありません。
面白いことに、この二つのバグ持を持ったUEB装置はWindows XPとVistaでは動作「します」ただし、全てで動作するわけではなく、一部のマザーボードやUSB拡張カードではWindowsでも誤動作するようです。
装置メーカがファームウェアをプログラマに開示しないために厳密に何が起きているのかは不明としています。
Mac OS Xは今回のような設計ミスや故障による「エラー処理が弱い」という欠点を持っています。たとえば故障したUSB装置を接続した場合に、Windows XPなら直ちに「故障している」とのダイアログが表示されます。この時にUSB装置はソフトウェア的に切り離され、Windowsは動作を続けます。しかし、上記の故障している装置をMac OS Xに接続すると、ダイアログは表示されず、フリーズしないまでも処理能力が極端に落ちて、再起動せざるを得なくなります。
例えば、SonyのGPS ユニットキットGPS-CS1はUSBのマスストレージとして作られていてWindowsでは問題なくマスストレージとして認識されます。一方、Mac OS Xではマスストレージ用のKEXTドライバが標準装備されているので、USBマスストレージとして作られた装置であれば動く「はず」です。しかし、Sony GPS-CS1はMacintoshではタイムアウト・エラーになりマウントできません。ちなみに、Intel MacをBoot CampとWindows XPで起動してGPS-CS1を接続すると正常に動作します。このようにWindowsで問題なく動作するのに、Macintoshだと動かないUSB装置がときどき見られます。
昨年の末に私からAppleが主催するUSBのMailing Listで上記の問題に関して質問したことがあります。その時にはIntel MacとMac OS X 10.4.9の組み合わせではマスストレージとして認識されることが分かりました。しかし、具体的に何が悪いのかは不明のままです。他にも似たような症状を一部の「製造元不明」のUSBメモリで見ています。
さて、昨日に上記のUSBのMailing ListにWindowsに関して興味深い書き込みがありました。
質問した人はCypressのUSBチップFX2を使用した装置用にMac OS Xのアプリケーションを書いていますが、Windowsでは正常に動作するのにMac OS Xでは動きません。Appleを始め多くの技術者が討論した末に、質問した人から以下のような報告がありました。
まず、USB装置メーカが書いたCypress FX2用ファームウェアに以下の二つの問題がありました。
1.endpoint descriptorのBULK IN lengthが1024になっていた。
本来は512
2.ファームウェアのendpoint autoin lengthが1024になっていた。
本来のサイズ以上のデータを送ろうとしている。
上記の二つの問題はCypressやCypress FX2の問題ではなく、Cypressのユーザである装置メーカが書いたファームウェアの問題(バグ)です。繰り返しますが、CypressやCypress FX2の問題ではありません。
面白いことに、この二つのバグ持を持ったUEB装置はWindows XPとVistaでは動作「します」ただし、全てで動作するわけではなく、一部のマザーボードやUSB拡張カードではWindowsでも誤動作するようです。
装置メーカがファームウェアをプログラマに開示しないために厳密に何が起きているのかは不明としています。
Mac OS Xは今回のような設計ミスや故障による「エラー処理が弱い」という欠点を持っています。たとえば故障したUSB装置を接続した場合に、Windows XPなら直ちに「故障している」とのダイアログが表示されます。この時にUSB装置はソフトウェア的に切り離され、Windowsは動作を続けます。しかし、上記の故障している装置をMac OS Xに接続すると、ダイアログは表示されず、フリーズしないまでも処理能力が極端に落ちて、再起動せざるを得なくなります。
2007年8月12日日曜日
Javaの文字化け、その後2
考えてみれば当然であるが、javadocもjarも文字化けする。当面の対策は例によって~/.bash_profilに追記である。
alias javac='javac -J-Dfile.encoding=UTF-8'
alias java='java -Dfile.encoding=UTF-8'
alias javadoc='javadoc -J-Dfile.encoding=UTF-8 -encoding UTF-8 -docencoding UTF-8'
alias jar='jar -J-Dfile.encoding=UTF-8'
ただし、javadocで出力されたhtmlファイルはエンコードの指定がないためSafariでは文字化けする。
システムプロパティを参照するPropertiesで調べると以下のような出力がある。
sun.jnu.encoding=SJIS
おそらくはこれを変更するかなにかするのであろうが、Shift JISのまま設定を変えないAppleの意図が分からない。
alias javac='javac -J-Dfile.encoding=UTF-8'
alias java='java -Dfile.encoding=UTF-8'
alias javadoc='javadoc -J-Dfile.encoding=UTF-8 -encoding UTF-8 -docencoding UTF-8'
alias jar='jar -J-Dfile.encoding=UTF-8'
ただし、javadocで出力されたhtmlファイルはエンコードの指定がないためSafariでは文字化けする。
システムプロパティを参照するPropertiesで調べると以下のような出力がある。
sun.jnu.encoding=SJIS
おそらくはこれを変更するかなにかするのであろうが、Shift JISのまま設定を変えないAppleの意図が分からない。
2007年8月9日木曜日
偽札
日経のサイトに偽札に関する記事が連載されています。その中に偽札の見分け方の一部が紹介されていました。
北朝鮮だけではなかった偽ドル札づくり / SAFETY JAPAN [松村 喜秀氏] / 日経BP社
そこで米国カリフォルニア州のCitibankから引き出した$100札を調べてみました。分かりやすそうな時計の針を調べてみたのですが、虫眼鏡程度の拡大率では偽札のように見えます。そこでScannerで約80倍に拡大スキャンすると、何となく分かりました。
しかし、書かれている内容から受けるイメージとは少々異なります。針が長いと言うよりは、時計の目盛りと長針が重なっていると言った方が近い感じです。もし、彼が言うように針が長いとすれば、その針先は曲がっています。
ところで、偽札を扱っている人達は、$100札を受け取ると一枚一枚顕微鏡で調べているのでしょうか?一般に流通していまえば、それが元に戻ったとしてももう一度使うだけのように思います。
それとも、偽札が見分けられる事で偽札が流通していることを世界に知らせ、米ドルに対する不安をあおることが目的なのでしょうか?そうだとすると、この記事を書いている人や日経の立場は危うくなります。どうも素人には分かりません。
北朝鮮だけではなかった偽ドル札づくり / SAFETY JAPAN [松村 喜秀氏] / 日経BP社
そこで米国カリフォルニア州のCitibankから引き出した$100札を調べてみました。分かりやすそうな時計の針を調べてみたのですが、虫眼鏡程度の拡大率では偽札のように見えます。そこでScannerで約80倍に拡大スキャンすると、何となく分かりました。
しかし、書かれている内容から受けるイメージとは少々異なります。針が長いと言うよりは、時計の目盛りと長針が重なっていると言った方が近い感じです。もし、彼が言うように針が長いとすれば、その針先は曲がっています。
ところで、偽札を扱っている人達は、$100札を受け取ると一枚一枚顕微鏡で調べているのでしょうか?一般に流通していまえば、それが元に戻ったとしてももう一度使うだけのように思います。
それとも、偽札が見分けられる事で偽札が流通していることを世界に知らせ、米ドルに対する不安をあおることが目的なのでしょうか?そうだとすると、この記事を書いている人や日経の立場は危うくなります。どうも素人には分かりません。
2007年8月3日金曜日
Javaの文字化け、その後
先の「Javaの文字化け」記述に問題があった。javacのエラー出力にShift JISとUnicodeが混合されて出力されることが分かる。環境設定ファイルを以下のようにすると全てUnicodeで表示される。
alias javac='javac -J-Dfile.encoding=UTF-8'
alias java='java -Dfile.encoding=UTF-8'
alias javac='javac -J-Dfile.encoding=UTF-8'
alias java='java -Dfile.encoding=UTF-8'
2007年8月2日木曜日
Javaの文字化け
Mac OS XでJavaを利用すると文字化けする。
信じられない話しであるがMac OS X 10.4.10の"javac"も"java"もその日本語出力はShift JISである。なぜこのような時代錯誤が発生したのか詳細は不明であるが、これでは実用に問題がある。
結果から言えば以下のように~/.bash_profilに追記すれば一時的に回避できることが分かる。
alias javac='javac -encoding UTF-8'
alias java='java -Dfile.encoding=UTF-8'
"-encoding"はmanに解説があるが設定する変数の定義がなく、どこを参照するべきかも書かれていない。これはIANAという規格を前提にしているらしいが、ここで定義しているUFT-8だけでなくutf-8でもUTF8でも機能する・・・いやはや。
http://www.iana.org/assignments/character-sets
"-Dfile.encoding=utf-8"に関してはmanとSun Microsystemsのサイトに以下のような記述がある。
manより
-Dproperty=value
Sets a system property value.
Sun Microsystemsのサイトより
-Dproperty=value
システムプロパティの値を設定します。value が、スペースを含む文字列である場合は、文字列を次のように二重引用符で囲む必要があります。
java -Dfoo="some string" SomeClass
ここで言うシステムプロパティとはJavaが実行されるときに、システムから得た情報を格納するSystemクラスのプロパティーとキーの組み合わせのことらしい。今回のfile.encodeingというプロパティはファイルのエンコードを指定している。
信じられない話しであるがMac OS X 10.4.10の"javac"も"java"もその日本語出力はShift JISである。なぜこのような時代錯誤が発生したのか詳細は不明であるが、これでは実用に問題がある。
結果から言えば以下のように~/.bash_profilに追記すれば一時的に回避できることが分かる。
alias javac='javac -encoding UTF-8'
alias java='java -Dfile.encoding=UTF-8'
"-encoding"はmanに解説があるが設定する変数の定義がなく、どこを参照するべきかも書かれていない。これはIANAという規格を前提にしているらしいが、ここで定義しているUFT-8だけでなくutf-8でもUTF8でも機能する・・・いやはや。
http://www.iana.org/assignments/character-sets
"-Dfile.encoding=utf-8"に関してはmanとSun Microsystemsのサイトに以下のような記述がある。
manより
-Dproperty=value
Sets a system property value.
Sun Microsystemsのサイトより
-Dproperty=value
システムプロパティの値を設定します。value が、スペースを含む文字列である場合は、文字列を次のように二重引用符で囲む必要があります。
java -Dfoo="some string" SomeClass
ここで言うシステムプロパティとはJavaが実行されるときに、システムから得た情報を格納するSystemクラスのプロパティーとキーの組み合わせのことらしい。今回のfile.encodeingというプロパティはファイルのエンコードを指定している。
登録:
投稿 (Atom)