2012年12月4日火曜日

X-BASIC for iOS

長らく開発していた、iPad/iPod touch/iPhone向けBASIC言語、「X-BASIC for iOS」がようやく発売できました。で、その宣伝漫画なども作ってみたので公開。
転載可です。




 

興味の湧いた方は、是非ご購入を<m(__)m>。

追伸(2013/01/01)
最新版V1.50が公開されました。
外部アプリからのファイル取り込み機能、電子メール送信機能などが追加されました。

追伸(2013/01/22)
V1.60が公開されました。
画面描画が大幅に高速化されました。その他機能も追加されています。

追伸(2013/01/24)
V1.70を審査に出しました。
バグ修正と、いくつか機能追加をしています。

追伸(2013/01/31)
V1.70は拒絶されました。
BASICプログラムを外部から入れられるようになってると、やはりはじかれるようです。
インポート機能を削除したV1.71を作成中です。

追伸(2013/02/01)
V1.71を再審査に出しました。

追伸(2013/02/08)
今後X-BASIC for iOSのサポートは専用ページに移行します。

2012年12月2日日曜日

iOSバグ写真集

iOSにはいろいろとバグがいる。
クラスライブラリの中にいて、プログラマーに要らぬ苦労をかける物もいるが、
中には見て「ちょっと楽しくなる」というか、「見つけてやったり!」と愉快になる
物もある。

そういう物の発生現場写真をいくつか紹介。

最初のは、「高温注意」のメッセージ。そもそもこれが出た状況自体が理解できない。
室温20度以下で、筐体を触っても熱い部分などなかった。充電はしていたので、
電池周辺の極狭い範囲で熱を発生していたのだろうか。充電器を外し、電源も完全に切ってしばらく放置したら直った。

「温度検知機能があるのだなあ」と思ったのだけど、それよりおかしいのは警告メッセージ。
文字が多重に表示されていて読めない。 正しくは下のようになる。



次はiCoundのバックアップメッセージの異常。
なぜか2重に表示された。しかもOK押しても動かないハングアップ状態。
このときは、リセット(HOME押しながら電源ボタン長押し)することで解消した。


なんか他にもあったような気がするけど、画面が発掘できたのはこの2つだけだった。
これからもバグハンターしていきたい(^_^;)

2012年12月1日土曜日

iOSシミュレーターの限界2;メモリアクセスの罠(第4版)

メモリアクセスにだいぶ間違いがあったので、テスト結果に基づいて再修正。

以前に「iOSシミュレーターの限界」という題で、実機とシミュレーターの違いに付いて書いたが、その後の開発で、さらに違いを見つけたので書いておく。

・CPUが違う

「当たり前」とか言われそうだが、意外にこれは重要な違いである。

私は、iOSシミュレーターはARMシミュレーター上で動いている物だと思っていたのだが、
シミュレーター上では86のコードでコンパイルされているようである。
(アセンブラコード見て気づけ!というのはなしの方向で。)

これがどんな違いをもたらすかというと、 「メモリ境界アクセスでの挙動が全く違う」のである。

ARMと86のメモリアクセスを考慮するとき、見るべきは・エンディアン;L->HなのかH->Lなのか
・バイト境界からの16bit以上アクセスは可能か
・ワード境界からの32bitアクセスは可能か
・ワード境界からの64bitアクセスは可能か
である。

多くの場合はObjective-Cが隠してくれるので気にする必要はないが、Cのライブラリを使うとき、特に構造体アクセスや、ワークエリアに可変長データを書き込む際に、要注意である。

エンディアンについては、ARMも86もリトルエンディアン、すなわちL->Hのアクセスなので、シミュレーターも実機も変わりない。

しかし、境界アクセスについては全く異なる。

86ではどのようなアドレスからでも16bit/32bit/64bitアクセスが可能である。
奇数アドレスからでも。

がしかし、ARMには制約がある。
1. バイト境界からのshort以上アクセスは不可
2. ワード境界からのlongアクセスは可能な時と不可の時がある
3. ワード境界からのdouble(long long)アクセスは不可
4. ロングワード境界からのdoubleアクセスは可能

どれも「ワード境界からなら行けるだろう」と思っていたら制約があったのでひっかかった。

わけがわからないのが2番めのlongアクセス。トラップを発生するときとしない時があり、 どの時できるの解明できていない。
したがって、現状では「できない」ものとして処理したほうがよさそう。

可変ワーク内に各種サイズのデータを書き込むようなプログラムの場合、そのアドレスによっては例外が発生してしまう。この場合はたとえば、

short *word=アドレス;
*word=0x0001;

という式の場合は、

short dt=0x0001;
memcpy(word,&dt,sizeof(word));

と書き換える必要がある。

Xcode V4.60以降には、memcpy()を、転送サイズが2バイト、4バイトまたは8バイトの倍数の時、それぞれshort、longまたはlong long単位で転送するようにインライン展開するというバグ、というかいらんお世話がいる。したがって、memcpy()では回避できないので、常にバイトまたはワード単位で転送するような関数を作って置き換える必要がある。

構造体では、メンバーはアクセスに問題ないように配置されるため、メンバー間整合のための予備バイトが挿入されることが有る。
したがって、厳密にメンバーのサイズとその配置に依存しているプログラムでは予想する動作をしない。この場合、

    #pragma pack(push,2)    構造体定義
    #pragma pack(pop)

と書くことで境界整合を制御できる。上記式は16ビット境界に配置する場合で、バイト境界にまでする場合は(push,1)とする。ただし、こうすると当然メモリアクセス処理が冗長になるので、速度低下を起こす。従って、可能なら位置やサイズへの依存をなくすようにプログラムを修正する方が良い。


拙作「X-BASIC for iOS」は言語処理部分はCで記述しており、しかも中間コードコンパイルではワークエリアへのデータ書き込みを可変長で行っているためこの問題に引っかかった。

設計上ワード境界アクセスにはしていて、シミュレーター上では全く問題なく動いていたのだが、実機上に持って行ったとたん例外が発生して動かなくなったので調べたらこうだった。

設計を変更して根本的回避ができないかも考えたが、構造があまりに複雑になりすぎるので、メモリアクセス側に対策して回避した。

ということで、「やっぱり実機での確認は欠かしたらあかん」「C言語に慣れている人ほど落とし穴にはまりやすい」という話。

----------2013/05/15更にテスト

以下のプログラムでテスト。これがまた、予想に反して全て正常動作してしまうという、結果になった。ARMの挙動、もしくはXcodeコンパイラの挙動はまったくもって不可解。

    // シミュレーター上=86上では全て問題ない
    // ARM上では?
    long work[32]; // このワークは正しい境界整合で確保されるはず
    char *bp=(char *)work;
    NSLog(@"work=%p",bp);
    unsigned long l=(unsigned long)bp;
    while (l&0xf) l++; // $~0まで移動
    bp=(char *)l;

    NSLog(@"work.0=%p",bp);
    //
    // .bからの.w
    short *wp=(short *)(bp+1);
    *wp=0x1122;
    NSLog(@"[%p]=$%x",wp,*wp);
    //
    // .wからの.l
    long *lp=(long *)(bp+2);
    *lp=0x11223344;
    NSLog(@"[%p]=$%lx",lp,*lp);
    //
    // .w境界から.llアクセス
    long long *llp=(long long *)lp;
    *llp=0x1122334455667788;
    NSLog(@"[%p]=$%llx",llp,*llp);

    // .l境界から.llアクセス
    llp=(long long *)(bp+4);
    *llp=0x1122334455667788;
    NSLog(@"[%p]=$%llx",llp,*llp);

ARM Linuxでは例外をカーネルで受けてうまく処理しているらしいので、iOSでも「ある程度」やってくれているのかもしれない。不十分だけど。

ここも参照のこと↓
http://jr0bak.homelinux.net/~imai/linux/arm_gcc_badknowhow/arm_gcc_badknowhow-4.html#ss4.1

2012年11月30日金曜日

iOS6/568画面対応での要変更点

X-BASIC for iOSの開発を終了、さらに既存アプリも全てiOS6&縦568(*2)対応させることで、その必要変更点がわかったので、ここに要約しておく。

ポイントだけ列記するので、詳細はドキュメント参照のこと。

(0)前に書いた画面回転処理の変更

(1)
[self presentModalViewController:viewCtrl animated:YES];

[self presentViewController:viewCtrl animated:YES completion:NULL];

実はiOS5から変更になっていたらしいが、iOS5では上の記述でも動いた。
でも6では動かない。

(2)
 [self dismissModalViewControllerAnimated:NO];

 [self dismissViewControllerAnimated:YES completion:NULL];

上の記述でもiOS6で動くが、推奨されない(審査は通る)。
iOS5にも対応するときは、バージョンを調べて 双方を切り替える必要がある。

(3)UIWebViewを使って動画再生させた後の挙動が違う
1つ前に指定した動画まで再生されてしまう。
バグだと思う。
MPMoviePlayerControllerに置き換える必要がある。

(4)View*Load/Appearの発生タイミングが違う
なんか並行動作が開始されるタイミングが変わったみたい。
このタイミングに強く依存していると誤動作する。

(5)iTunesArtworkがLarge Icon(だったと思う)という名前になって、1024*1024でしか受け付けなくなった。
 512*512のものは受け付けてくれないので、作り直しが必要。

(6)iPod5/iPhone5の縦長画面(568*2)の画面で「起動」したい時は、Default-568@2x.pngという起動画面を用意する必要がある。
(一応Xcode4上で自動作成させる方法はあるけど。)
これがないと、縦長画面機でもその中央部分だけ使って従来機と同じ画面縦幅で起動する。

568画面への対応は基本的には、UIViewのAutosizingで縦を有効にしておくだけで、自動再配置してくれる。
ちなみに、568画面で異なるUIViewController で表示させることも可能だが、iPodとiPadの切り替えはplistへの追記だけでいけるのに対し、こちらはiOS泥臭くプログラムを書くしかない、と思う。やりかたは画面幅を認識した後modalViewで表示するだけ。

拙作では「プログラマーず電卓 V2.00」で画面を変化させている。


追記。ImagePickerによるカメラ撮影時の画面は、iPod5/iPhone5でも画像部分のサイズは変わっていない。シャッターボタン周りの幅が広がっただけである(撮像素子にそんな縦長の物はないからである)。


(7)iPadでは起動画面に〜@2x.のものを用意したほうが良い。ただし、こちらは
 従来解像度のファイルのファイル名だけそれに変えたら通る。
(これもXcode4上で自動作成させる方法がある。)

以上。
結構細かく多いで手間はかかる。
私は、ビットマップで作っていたiTunesArtworkの大元データを、この際ベクトルデータのものに作りなおした。画像の用意をするのが一番面倒かも。

CGContextSetLineWidth()とCGContextSetLineDash()の関係

X-BASIC for iOS開発の過程で、CGContextSetLineWidth()とCGContextSetLineDash()の関係がどうにもわからないので調べてみた。線幅を1より大きくした時のDashの描かれ方が意図したとおりにならない。

dash=10,20の設定でlineWidth1〜10まで変化させた時、下図のようになった。


width=1の時は設定通りだが、widthが増えるとそうではなくなる。
widthは縦幅だけでなくON部分のみ横幅まで増やしてしまう。
およそではあるが、widthに+1付きon区間が2増え、OFF区間が2減る。

最初iOSのバグかと思ったほど。
意図してこの2つを使いこなせる人間はいるのだろうか?

インターネットで色々調べてもLineWidth=1の時の描き方の例はあってもそれ以上の時は見つけられなかったので、ここに。

ちなみに、X-BASIC for iOSでは意図したとおりに描かれるようパラメーターを自動調整している。

2012年10月20日土曜日

iOSウオッチドッグの存在

今まで全く気にしてなかったが、どうもiOS中にもウォッチドッグタイマーが存在するようである。

ウォッチドッグが何であるか、詳しくは調べてもらうとして、超簡単に書けば、
暴走防止のためのタイマーである。 組み込み機器ではウォッチドッグにひかかったら、
暴走や(周辺デバイス)無反応とみなしリセットをかけるのが普通である。
(正確には、プログラム的に一定時間以内にウォッチドッグタイマーをリセットしないと、ハードウエア的にリセットがかかるようになっている。)

某所の情報によると、iOSでもWebView周りには
  • Watchdog: 20秒(アプリケーション起動時など)
  • DNS: 30秒
  • TCP Connection: 75秒
  • NSURLConnection: 60秒
というウォッチドッグがいるらしい。
"0x8badfood"という例外コードを返してくるとか。"ate bad food"ということらしい。
ateはeatの過去形。発音が8=eightと同じである。

しかし、X-BASIC for iOS開発時の調査の結果、カーネルそのものに関わるタイムアウトも存在ようである。

以下のループをシミュレーター上で実行すると、約256秒でプログラムが落ちる。
while (1) {
#if 0
    NSDate *dt=[[NSDate alloc ]initWithTimeIntervalSinceNow:0.0];
    [[NSRunLoop currentRunLoop]runUntilDate:dt];
    [dt release];
#endif
 }
これで落ちるときはEXC_???(11)(code=0,subcode=0x0)となる。

#ifの中は有効無効どちらにしても変化なし。
また、この中にどれだけ長いCの処理を書いていたとしても、落とされてしまう。
 iOS5.1/6.0とも。

しかもこれ、Xcodeにつないでいる実機上やシミュレーター上でもLeakでトレースしていると発生しない。単独の実機ではHOMEに戻ってしまうし、シミュレーター上で普通に実行している場合は、上記エラーというかトラップを発生して止まる。

2013/11/10追記
iOS7シミュレーターでは発生しない様な気がする。Xcode5で改善された?

・・・

無限ループらしきところを警告しているつもりなのかもしれないが、定期的にcurrentRunLoopに戻しても発生するから、迷惑な事この上ない。
警告ならメッセージで出すべきであって、プログラムを落とすのはやりすぎ。

普通ウォッチドッグタイマーにはそれをリセットする機構があるが、iOSにはない。
ゆえに、iOSは組み込み機器的には使えない。
(iPadやiPod touchが安いから、筐体に組み入れて組み込み機器にしたらいいじゃん、という意見を見たことがあるが、iOSはこの件を含め、組み込み機器向けじゃない。組み込み機器なめんなよってな感じ。)

    ・・・

さらなる調査で、RunLoop内では、如何様にしてもループを回し続けるのはご法度と判明。必ず落ちる。
バッググラウンド内なら回し続けても大丈夫。でもバックグラウンドからからは表示させることができない。というか、表示や入力に関わるすべてのUI要素が使えなくなる。UIWebViewに至ってはレポートまで出力して落ちる。
だが、バックグラウンドからRunLoopに通信する方法が見つからない。
(KVOは同一スレッド内で実行されるのでダメ。 Notificationもおそらく同様。)
これさえあれば何とかならんでもないのだが。

KVOの通知でフラグを立て、先のループ内で表示するという手を考えた。
while (1) {
    NSDate *dt=[[NSDate alloc ]initWithTimeIntervalSinceNow:0.1]; // 0.0はだめ
    [[NSRunLoop currentRunLoop]runUntilDate:dt]
    [dt release];
    if (flag) {
       // 表示
    }
 }
実際にこれで表示が出るには出る。が、秒1回くらいならずっとOKなのだが、秒30回くらいの速度でしばらく回していると表示が出なくなる。どうも、NSRunLoopの行から帰ってこないようだ。RunLoopに入りっぱなしになるという感じ。バグじゃろうこれは。

→アップルのドキュメントの中にRunLoopにスレッドを接続する方法を発見。
何とかUIViewの表示だけは出来るようになった。が、問題はUIViewだけじゃなくUITextFiled等も含む全UI要素に関わるので対応が非常に大変。
→実機で落ちなけりゃそれでOKで無視することにした。


2012年10月12日金曜日

iOS6での画面対応について

iOS6での画面回転対応に非常に苦労したのでここに記録する。
iOS5以前にも対応するなら、従来の回転処理も残しながら、
新たに以下のメソッドを追加する。
細かい話は他のサイトで調べてもらうとして、ここではやり方だけ列記。

(1)基本的に、全てのUIViewControllerに以下の処理を実装する

- (NSUInteger)supportedInterfaceOrientations
// 回転を許可する方向を返す
{
#if 0 // リターン値はこの中から選択
    typedef NS_OPTIONS(NSUInteger, UIInterfaceOrientationMask) {
        UIInterfaceOrientationMaskPortrait,
        UIInterfaceOrientationMaskLandscapeLeft,
        UIInterfaceOrientationMaskLandscapeRight,
        UIInterfaceOrientationMaskPortraitUpsideDown,
        UIInterfaceOrientationMaskLandscape,
        UIInterfaceOrientationMaskAll,
        UIInterfaceOrientationMaskAllButUpsideDown,
    };
#endif
    return UIInterfaceOrientationMaskAll;
}

- (BOOL)shouldAutorotate
// 回転を許可するかどうかを返す
{
    return YES; // NOなら回転させない
}


もし個別のUIViewControllerに実装するのが面倒なら、以下の実装を入れればよい。
(各UIViewControllerの回転時にここが呼び出される。 )

-(NSUInteger)application:(UIApplication *)application supportedInterfaceOrientationsForWindow:(UIWindow *)window
{
    return UIInterfaceOrientationMaskAll;
}



(2)[window addSubview:navigationController.view];
ではなく
    [window setRootViewController:navigationController];
に変更する。

ここまででiPadは回転するようになる。iPhone/iPod touchでもPortraitUpsideDown以外は回転するようになるが、PortraitUpsideDownだけが回転してくれない。



(3)UINavigationControllerの中にも上記回転制御を入れる。そのためにサブクラスを作る。


@interface NavigationControllerForiOS6 : UINavigationController
@end

@implementation NavigationControllerForiOS6
- (NSUInteger)supportedInterfaceOrientations
{

    return UIInterfaceOrientationMaskAll;
}

- (BOOL)shouldAutorotate
{
    return YES;
}
@end

UINavigationControllerを使っているところを全て、このNavigationControllerForiOS6
に変更する。



・・・

となる。
(3)がわかりにくいところ。(2)まででiPadまで動いてしまうので見逃しがち。

しかし、アップルはなんでこんな重要な、しかも非常によく使われている部分の仕様を変えたりするんだろうか。その上、変えてなにか良くなっったりしているとも思えないし。
まったく。

2012年9月21日金曜日

Mac Blu-ray playerのバグ

Mac上で唯一のBlu-rayディスクプレイヤーソフトであるというMacgo社の
「Mac Blu-ray Player」。

「こんな名前いいのん?」というような名前だが、早く出したもん勝ちである。
(Windows版も同じ名前なのはご愛敬?)

それはどうでもいいとして、最新版V2.8.5になっても「BDプレイヤー」としての挙動が全くなってない。「Mac Blu-ray Filer」に変名した方がいいくらい。


その出ているバグ。


*V2.8.5に更新した後はMacの再起動が必要そう
再起動する前はDVDを読ませようとするとハングアップした。
(BDは読めた。)
Windows版では再起動は不要だった。


*V2.8.3以降で出ているバグ
・音声選択名がおかしい
BDでのみ確認した。
Englishで日本語、無効で英語になり、Japaneseは選択できない。
最初、音声選択ができなくなっているのかと思った。
最新のV2.8.4でも治ってない。
V2.8.5では直ってた。

*V2.8.4以降で出ているバグ
・スリープ明けに必ずハングアップする
しかもこのときディスクのアクセス権を握ったままにするので、ディスクが排出できなくなる。
OSでイジェクト命令を発効しても排出されない上に、そうしてしまうとOSからの認識もされなくなるので、強制排出でディスクを入れ替えても認識されない。結果、OSの再起動しかなくなる。
V2.8.5でも直ってない。

・音がおかしくなる
前の音の一部を引きずるような感じになる。

BD:モーレツ宇宙海賊23~26話の内どれか。重低音が効くところ。
V2.8.5で発生。以前のバージョンは不明。


なんでこんなにエンバグするのか、チェックが甘すぎる。

何回かバグレポート出しているけど一向に治す気配がないので、もはやそういう会社だということで。

・・・従来バージョンからずっと出ているバグ

*ディスクによって出たり出なかったりするもの

・複数話が記録されているディスクで、途中の1話しか再生出来ないことがある
   例)BD:Infinite Stratos 1枚目 第2話しか再生されない。
 最新版では治ってた。

・1話再生するごとに再生が止まってしまう
ファイラー的に動作しているので、各話が独立したファイルになっているディスクではこうなってしまう。
次の話を再生するためには、ディスク選択→オープン、その他のタイトルから話数選択をしなければならない。しかも音声選択していたときはそれも選択し直す必要がある。

・宣伝しか再生されない
 BD:シュタインズ・ゲート
 タイトル選択から本編を選べば本編の再生ができる。
 これもファイラー的動作によるものだろう。
 DVD版では、ちゃんとメニューから再生される。

・話の順番がおかしい
 BD:神のみぞ知るセカイII/けいおん!(第2期)
 そもそも連続再生できないが、「その他のタイトル」から選ぶと、第6話が9話目に入ってる(神のみぞ知るセカイ)。
V2.5.4.0994で治った気がする。でもまだ連続再生はできない。

・いきなり途中から再生が始まることがある
 BD:バカとテストと召喚獣
最新版では発生していない。

・字幕設定が1話毎にデフォルトに戻されてしまう

 DVDでも発生。

・全再生が終わると、メニューに戻るのではなく再生そのものが終わってしまう
・BDのメニューが表示できない
 2つはほぼ同じ意味。
 すべてのBDで発生。
 重大なバグ。

・タッチ反応エリアが狭すぎてディスクメニューがほとんど操作できないことがある
 例)DVD: MOONPHASE、タユタマ、シュタインズ・ゲート
 BDはメニューそのものが表示できないので発生し得ない。

・勝手にチャプターが飛ぶ
 例)BD:FINAL FANTASY VII
 最後最後、主人公のセリフが途中で飛んでしまう。しかもその飛び方が絶妙なのでセリフの意味が全く逆になってしまう。だめじゃん。

・チャプタージャンプが単なる時間ジャンプになってる
最新版では更にわけの解らんジャンプの仕方をする。およそ使いものにならない。

  *ディスクにかかわらず発生するもの
・再生中にスリープに入ると、スリープ明けに再生が継続されない事が多い


・再生中に停止すると、次回再生でファイル選択を求められる
最新版では、ここでディスクを選択すると一応前の再生位置から再生が再開される。
が、音声状態はディスクデフォルトに戻されてしまう。


・「最近の視聴履歴」というものがあるが、全く機能してない
 というか、今見ているディスクの名前しか出てこない。
 必要ないと思う。
これはメニューに出るのではなく、Dockの方に出る物だった。
正常動作している。


・AppleRemoteでの操作法が標準アプリの「DVDプレイヤー」とぜんぜん違う。
 ディスクメニューの操作がマウスで出来ないのにリモコンも使えないので操作不能に陥ってしまう。

・ディスクが排出出来ない
 DVDプレイヤーにはEjectボタンもあるし、ツールバーのEjectからでも排出可能だが、
 こいつはEjectボタンがない上に、 ツールバーのEjectを押しても排出できない。
 Finderからディスクをゴミ箱に入れてもダメ。このアプリを終了しないと排出されないのだ。排出のためにいちいちアプリ終了するなんて面倒な事この上ない。
最新版でも治ってない。
→1つ前版では、Eject出来ないだけでなく、再生中にEjectを実行し、その状態で再生を停止すると「ディスクを開く」を選んでもメディアが認識されないというバグも発生する。OSレベルで認識されていないようなので、Ejectされない事が問題の根本。
これをしてしまうとOSの再起動しか手がなくなる。極めて重大なバク。 


ディスクを取り出すだけなら、ドライブの強制排出を行うか、USBケーブルを抜き差ししてEjectボタンを有効化した方が楽だが(BDドライブは外付けしかないのでこの方法が使える)、OSから認識されない状況は変わらない。


・再生速度が微妙に変わる
これはこのソフトだけじゃなくMac上のほとんどのプレイヤーソフトいえるけど、
再生速度が微妙に速くなることがある。VLCでも発生する。

リズムがはっきりしている音楽再生時に音程が狂うのでよく分かる。
同じデータでもWindows上のプレイヤーでは発生したことがない。
Macの省電力に伴うクロック制御などが影響しているのだろうか。
Mac上での音楽再生はこの理由により、正確な意味では「実用的でない」と判断している。
→これはMacOSのバグだったようで、10.8.3で治ったような感じがする。治ってなかった。発生率は下がったけど未だ出ることがある。出たときのひどさは今までの比ではない。

・・・
特にBDでの再生があまりにもひどい。ちゅうか、DVDならMac標準の「DVDプレイヤー」でいけるのだから、ウリのBDでこの状況は「使いもんにならない」。
ディスク内に記録されているいろいろな情報の読み出しそのもの、またはその解釈が正しくないと思われる。もっとDVD/BDの仕様書を読んで正しく実装してほしい。

とりあえずもっとたくさんのディスクを再生して確認しろ。
テストディスク1枚くらいでしかやってないんじゃないか?
本当にデバッグしてるのか?
少なくとも複数枚組作品なんて見てないと思う。そうでなきゃ排出問題は絶対気づくはずだから。なんか、作品を変えるごとに違う不具合が出るんだけど。まともに操作を含む再生が出来る方が少ない。


徐々に良くなってきてはいるが、まだだめ。
フリーウエアじゃないのだから、メーカーには一日も早い全てのバグの修正をしてほしい。クリスマス対応とかしている暇があったらさっさと直せ。どうでもいいような修正でバージョン番号ばっかりあげてんじゃねぇ。


一向に改善されないので、とうとうメーカーに報告。
まあ、治らない可能性が大だけど。
→返答によると、5~6月頃にメニュー対応を初めとした大バージョンアップがあるらしい。

現状では先にも書いたとおりファイラーの域を出てないので、初心者には「全くおすすめできない」し、熟練者でも「なんとか我慢して使える」レベル。
Mac標準のDVDプレイヤーがBDにも対応してくれることを強くかつ、切に願う。

・・・2013/04/23追記
あまりに出来が悪いので、とうとう使用を中止。
来月以降にあるという大バージョンアップが出るまで使わない(当然検証もしない)。(他にモニタが用意できるなら)、専用BDプレイヤーを買った方がよほど精神衛生上良い。
そういうこと。
→ちゅうことでSONYのBDプレイヤーBDP-S190を買った。安いのにとてもいい機種。
HDMI入力に余裕がある人にはおすすめ。

・・・2012/10/24追記
とうとう新型iMacでも光学ドライブがなくなってしまった。
ということは、AppleはPCでのDVD/BD再生はもはやサポートする気が無さそうなので、
BD対応は将来的にもありえないかも。

2012年9月20日木曜日

NSTimerのバグ

NSTimerの時間指定は基本的に秒単位である。

例えば

+(NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)seconds target:(id)target selector:(SEL)aSelector userInfo:(id)userInfo repeats:(BOOL)repeats

のsecondsは秒単位なわけだが、0より大きく1より小さな数を指定すると1秒以下でも指定できる。

ここで、仕様書を読むと「負数を与えるとその負号を取った値を0.1ms単位として使う」と書いてある。これをそのまま理解すると例えば、-1000と指定すると1000*0.1=100msを指定したことになるはずである。

がしかし、実際にはそうはならない。
非常に短い時間でタイマーがかかってしまう。
NSTimerそのもののバグか、仕様書の間違いである。
少なくともiOS5.1まではこのとおりだ。

仕方ないので、0.??の値を使っている。

早々に正しい仕様を公開して欲しいところ。というか、仕様書通りに動くように直してくれ、Apple。

MountainLion v10.8.2での不具合ほか

iOS6にあわせてMoutainLionも10.8.2にバージョンアップされた。

V10.8.1にあったバグの修正具合を確認。update2でも変化なし。

(1)自動スリープ後、Ethernetが切れてしまうバグは修正された模様
   IPv6では接続できるがv4では接続できない状況になる。
  未完全な修正だったということで。
(2)画面共有のログイン画面のスリープでスリープできないバグは修正された模様

が、また例によって新しいバグがいる。

 (3)スリープ明け後最初の受信で、メールが高確率で落ちる
メール側の対応漏れかOS側の問題かはわからないが、落ちたらあかん。

どうもスリープ明けの最初の受信メール有り時に高確率で落ちる様子。


(4)DVDプレイヤーで、話の切り替わり目で数秒〜数分が飛んでしまうことがあるバグは治っていない。
 やはりMac go社のMac Blu-ray Playerでは発生しないのでDVDプレイヤーのバグ。
(Mac Blu-ray Player自体もバグだらけなので使いものにならないが。)

(5)スリープ中にリマインダーの通知が来ると、スリープ明けに通知の「閉じる」を押しても閉じない。しかも二度と通知が操作できなくなる。
ユーティリティのアクティビティモニタで「通知センター」を選んで「プロセスを強制終了」すると一応治る。

アップルは少なくとも、まだ5倍はデバッグ要員を増やせ。

Xcode4.5およびiOS6の動作状況はこれから確認。
iOS5/5.1のバグは今回のアプリ開発でだいぶ見つけたのだけど、それらが治っているかどうか。

・・・ついでのXcode4.5の確認・・・

Xcode V4.4.1であったバグが4.5でどうなっているかの確認ちょっとだけ。

(1)Separate Assistant Editorの右側で補完候補がすぐに消えてしまうバグ
やっぱり治ってない。更に悪いことに、Google日本語入力では日本語入力がまともにできなくなった(ことえりでは未確認)。

(2)ソースファイルの改行コードが0x0d+0x0aのとき(Windowsで作っていたファイルを持ってきた時など)、エディターでDelete To End Of Lineを実行すると行末までを削除すると、次の行が接続されてしまう
これは前のバージョンから治ってない。

他は再現させるのが面倒なので省略。今のところ、ファイルの認識間違いは発生していない模様。

後バグじゃないけど、iPhone5対応のため、Launch ImageにRetina(4-inch)が追加されてる。
そのままでは黒画面画像(Default-586@2x.png)を入れられるので、何らかの置き換えが必要。私は、面倒だったので、従来のRetina(3.5-inch)の画像そのまま入れておいた。おいおい書き換えると言うことで。

2012年9月14日金曜日

NSString UIKit Additions のバグ

NSString UIKit AdditionsにあるsizeWithFont:は、文字列を指定フォントで表示した時の表示サイズを求めるメソッドとされている。


ところがこれ、横幅は正しいのだが、縦幅は正しくないことがある。
表示幅が取得値(size.height)より大きいことがあるのだ。

どのような場合にそうなるか。


指定フォントが英字フォントで、文字列に日本語を含む場合がそれに当たる。

この場合、英字部分は指定フォントが使われるが、日本語に関しては代替フォントが使われる。
例えば、標準的フォントとしてよく使われるHelveticaは英字フォントであり、実は日本語は含まない。それでも日本語も表示できるのは、この代替機能があるからだ。絵文字もこの機能によって、どのフォントでも表示できるようになっている。
(フォントが実際のところどの文字コードに相当するフォントを持っているかは、FontBookで情報を見ると分る。)

そして、殆どの場合その代替フォントのほうが大きいので、高さがそちらに合わせられる。
このため、実表示サイズが取得値と合わなくなる。

 sizeWithFontが返してくるのは指定したフォントのlineHeightであり、文字列に含まれるすべての文字を考慮した高さではないのだ。

その代替となっている日本語フォントのlineHeightを得ておけばいいと思うかもしれないが、それがそう単純ではなく、実際に表示される文字だけのフォント幅に合わせられる。
よって、表示文字列が固定ならいいが、文字列が可変なら高さも可変になる。

ということで、現在出来る回避策は、実際に表示させてみるしかない。
例えばUITextView.textに「改行付きで」代入し、その前後でcontentSize.heightの
差分を取る。これなら正確に取得できる。
ただし、.textへの代入の処理はかなり重いので、すべての行の高さを得ようと思うなら、ちょっと工夫が必要である。


アップルは英語圏なので、こういう日英文字混在の条件下ではデバッグされていないのだろう。iOS5.1でも治っていない。iOS6でどうかは未検証。


2012/09/25追記
drawAtPointの返してくる高さも同様と判明。横幅はなぜかちょっと違う。
sizeWithFontの方が小数点以下を切り上げた幅を返してきている感じ。

あと、ひょっとしたらこの問題はUITextView内に表示した時だけに発生するのかもしれない。UITextViewないならフォントの高さなんて気にしなくていいのではないかと思われるかもしれないが、外部表示との同期をかけようとすると問題になる。
それがどういうことかは、次回アプリを見てもらえばわかるかと。

2013/09/29追記
1年ぶりの追記。実はiOS7では contentSize.heightの返す値が全く意味不明になっておりこの方法が使えなくなってしまった。現状回避策は見つかってない。

2012年9月1日土曜日

Macのゴミ箱の中の消えないファイルの消し方

Macで「ゴミ箱を空にする」を実行しても消せないファイルが残ることがある。

(不要になった)TimeMachineのフォルダを削除したときなど、boot.efiというファイルにロックがかかっていて、情報からアクセス権を変更してロックを外そうにも外せず、
この状態になる。

こういう時は、Optionキーを押しながら「ゴミ箱を空にする」を実行すればよい。

たったこれだけで綺麗サッパリ消してくれる。

2012年8月18日土曜日

Xcode 4.4.1とMoutainLion V10.8.1のバグ

MacOSがMountainLionになってXcodeもV4.4.1が出た。

が、いつものごとく幾つものバグがあった。

(1)Finderからのドロップでプロジェクトにファイルを追加すると、コンパイル対象にならない

ファイルはあるはずなのにリンクが通らないという謎の現象が発生し、調査の結果がこれ。

プロジェクトのところでマウス右クリックのAdd File Toを使った場合はこうはならない。
ファイルがあるのにリンクが通らないとエラーが出る場合はこれが原因。
一旦Delete→Remove ReferenceしてからAdd File Toをやり直せばよい。

コンパイル対象でないファイルの追加にはドロップも使える(画像とか)。


(2)エディタで「Open in eparate Assistant Editor」で分割表示しているとき、
右側(Assistant Editor側)で単語補完候補がすぐ消えてしまう

入力がかなり面倒になる。
入力を続けていると、一時的に治ることもある。


(3)リアルタイムエラー検出で使うソースを間違える
例えば
proj-+--a.m,a.h
       +-lib--a.m,a.h
と同じファイル名のソース(.m/.h)が2箇所にあり、proj直下のファイルをプロジェクトにAddしていて、libはフォルダごと登録しているが、この2つのファイルは登録してないとする。
この時、本来lib下のファイルは無視されなければならないが、これがエラー検出に使われる。ソースを見ても絶対にあってるのに警告が出るときは、同一ファイルが複数箇所にないか確認したほうがいい。
これで一体どれだけ無駄なデバッグさせられたか。

同じファイル名のソースが複数出来てしまうのもバグ(に近い仕様)で、プロジェクトにAddするときコピーを作ってしまうとか、グループ間移動をした時ときに発生すると考えられる。


(4)iOS4.x用シミュレーターがないのはバグに近い仕様だと思う。
Device Debugging SupportはiOS3/4用ともまだあるが、シミュレーターは消えている。

まだあるじゃろうiOS4機。それとももう無視していいというお達しなのか?

仕方ないので、うちではVMware Fusion上にLionを構築してXcode4.3.2を復旧させた。
まさかこういう使い出があるとは。->だめ。一旦プロジェクトをXcode4.4用にしてしまうと4.3.2ではエラーが出てしまう。4.3.3にしたら通った。


(5)同名のグループが複数作れてしまう
多分、New Groupで作成したものとドラッグでフォルダごと入れた場合に出来るのだと思う。

(6)IBでClassを変更しても内部的に更新されないことがある。
サブクラスを作ってそれに変更したのに、正しく動作しない。
Cleanかけてもだめ。
結局そのViewを一旦削除して再度貼り付けたら直った。
参照するファイルを間違えるのと同じ原因ではないかと推察中。

(7)ソースコードを修正してもそれをコンパイラが認識しないことがある
発生させる一例。
1.あるメソッドの引数を変更する
2.それを使っている部分で警告が出るようになる
3.その部分を引数付きに書き換える。ただし、エラーが出るようする(間違えておく)
4.メソッドの引数を元に戻す
5.エラーが出ている行も引数を削除し、エラーが出ないようにする
としても、エラーが消えない。コンパイルしなおしてもダメ。
Cleanをかけたら消えた。
別の条件で発生したときはCleanをかけてもダメで、プロジェクトを一旦閉じて再度開いて、更に再ビルドでようやく直った。

幾つかの現象から、どうも、4.4.1にはソースの修正を正しく認識できないバグがいる模様。どうしてもおかしいと思ったら、Cleanをかけてみるか、プロジェクトを一旦閉じて再度読み直すか、IBなら一旦削除して貼り付け直しするのが吉。

(8)Settings.bundle内を編集し続けているとハングアップすることがある
2回発生したから確実かと。

(9)日本語名ファイルがGitで通らない
コミット時にエラーが出る。
コンソールからgitのコマンドを発行するとちゃんといけるので、
Xcode内のgit処理のバグだと思われる。ずっと前のバージョンから治ってない。

(10)gitの管理下にあるファイルで、編集していないのに「M」マークが付くことがある。
しかも、しばらくすると勝手に消えるという謎付き。
実害はない。

・・・

V4.3台で存在した「実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けする」バグは「ほぼ」修正された模様。一度に大量に表示させると、まだときおり/???というUnicode形式で表示されることがある。




アップルは、毎度のことながらデバッグが全く足りてない。
この分だと、もうすぐ出てくるiOS6もすぐには対応作業しないほうが吉かも。
どうせバグだらけだろうから。
「アップルのソフトはバージョンアップがあってから入れるのが正解」。
・・・

ついでに、MountainLion(v10.8/10.8.1)のバグも少々。

・省エネルギー設定でコンピューターのスリープを「しない」にしっていしても
勝手にスリープしてしまう。スリープと言うより、アプリを終了してスタンバイ状態に
入ろうとする。

2時間くらいで落ちる気がする。
このため、一晩中処理を走らせ続けたいと思っても出来ない。
(スタンバイになる前にアプリの終了を確認しており、ここで処理が停止してしまうから。)
->これは、「使用しない状態が?分間続いたらログアウト」の設定によると判明。「セキュリティーとプライバシー」〜「一般」〜「詳細」の内にあり。


・画面共有で接続されているとき、ホスト側からスリープに入るよう操作してもスリープしない
要するに遠隔からスリープさせられないということ。だめじゃん。
10.8.1では治っていた。
やっぱり治ってない。
ログイン画面のスリープを押してもスリープしない。
その後ログインしてスリープをかけてもスリープしない。
どうも、ログイン画面でスリープを押すとおなしくなる様子。

・ネット先のドライブが応答しない時、リセットがかかってしまう
 エラーも出ずに急に再起動した。

・USBディスプレイドライバのDIsplayLinkDriver V1.8を入れているとスリープできなくなる=スリープ時にシステムが落ちてしまう

→調査の結果、メーカーサイトの中の http://www.displaylink.com/support/ticket.php?id=331 に情報を発見。
要約すると「スリープ中にBluetoothデバイスの電源を切ると落ちる」らしい。
うちの場合、マウスがそれに相当している(手動で電源を切るだけでなく、デバイスが自動的に電源を切る場合も同様)。
これはOS X v10.8のバグで、10.8.1で修正される予定らしい。

「DisplayLinkを入れると露呈する」とある。
ということで、暫く待つしかなさそう。
→10.8.1では治っていることを確認。

・共有にしているフォルダの内容が更新されないことがある
ファイル削除したらそうなる感じなので、ファイル削除後のディレクトリエントリ作成周りにバグがいると思われる。

・Windows(7)とのファイル共有ができなくなった

今のところ、Win←Macはできているが、逆はできない。
画面共有はLion時はできなくなっていたが、MountainLionでは出来るようになったのに、
更に利用頻度が高いファイル共有ができなくなってどうするよ。
→出来る機体と出来ない機体が存在する。ということで、何かの設定だと思うのだけど、原因は不明。Mac間のファイル共有は出来てる。
→ようやく原因が判明。セキュリティとプライバシー」の設定で「ファイヤーウォール」〜「ファイヤーウォールオプション」〜「smbd」〜「外部からの接続をブロック」を「許可」に直したら治った。
こんなところいじった覚えはないので、10.8.1で勝手に設定されたと思う。

・スリープ明けにEthernetでつないでいるネットワークが切れてしまうことがある
省エネ設定の時間を過ぎて自動スリープに入った時に発生する。
ケーブルの抜き差しでは復旧せず、再起動するしかない。かなり致命的なバグ。
V10.8.3では発生頻度がかなり下がったが、まだ出る。

手動でスリープに入れたときは発生しにくいが、長時間スリープした後だと別症状で発生する。ただし、再度手動スリープして再起動すると治ったこともある。
V10.8.2で直った模様。まだ2回だけでの結果なので、もう少し様子見。
V10.8.2でも発生。IPv6では接続できているがV4では接続できない。
うちのプロバイダはv6を通さないのでインターネット接続ができなくなる。
WiFiでは発生しない。



・DVDプレイヤーで、話の切り替わり目で数秒〜数分が飛んでしまうことがある。
 例えば1話目が終わり、2話目が始まるとき、2話目の最初しばらくが飛ぶ。
 すべてのディスクではないが、かなり高い確率で発生する。
 SnowLeopard/Lionでは発生していなかったので、MoutainLion版のみのバグ。
 10.8.1で確認しているが、10.8.0がどうだったかは不明。
 ちなみに、Mac go社のMac Bru-ray Playerでは発生しない。
 (それはそれで他の問題が多すぎて常用しづらいのだけど。)
10.8.3では発生していないような気がする。

・フリーウエアのMacFaceが動かない
 対応版は出そうにない。まあ、必須ソフトではないけど。

・同muCommander v0.9.0が「ファイルが壊れてる」と出て実行できない(Lionでは動く)
10.8.1でも変わらず。
→「セキュリティーとプライバシー」〜ダウンロードしたアプリケーションの実行許可を「すべてのアプリケーションを許可」にすると実行可能と判明。
しかし、「実行できません」ならわかるけど「ファイルが壊れてる」というのはエラーメッセージが間違っているとしか思えない。


・ロジクールマウスの特殊ボタンが効かなくなった
ドライバーを更新しようにも、日本サイトにあるドライバはMountainLionには対応してない。米国サイト http://www.logitech.com/en-us/home で検索するとMountainLion対応の最新版がある。メッセージ英語のみになってしまうが、まあ、簡単だから問題ないかと。とありあえず日本語版が出てくるまでのつなぎはこれでOK。

・落ちる頻度はLion(10.7.4)より多い
まだ不安定な部分がある様子。
1ファイルへの多重アクセスをすると落ちやすいような気がする。
落ちるというか、無反応になってしまう。
Xcodeでタグ上に残っているファイルをDelete-Move trashとかすると一発。


とにかく、デバッグ要員を10倍くらい増やせ、アップル。新機能より安定性重視。
特に企業に入って行く気ならそれは非常に重要(その気はないのかもしれないが)。

2012年8月9日木曜日

UTF8とSHIFT-JISの判別し方

UTF8はUTF16を算術演算して一定のコード範囲に収めるようにした文字コードである、らしい。

 実際のところ、以下の5つパターンに収束する。

   (1)c2~df+80~bf                                                2バイト
   (2)e0~ef+80~bf+80~bf                                    3バイト
   (3)f0~f7+80~bf +80~bf +80~bf                             4バイト
   (4)f8~fb+80~bf +80~bf +80~bf +80~bf                5バイト
   (5)fc~fd+80~bf +80~bf +80~bf +80~bf +80~bf   6バイト

UTF8データ群中では、先頭のバイトで長さがわかる。
逆に後ろからでも順次読んでいけばその文字の先頭がわかるのは、ASCIIコードは0x00~0x7eなので、重複部がないからである。

SHIFT-JISは
  第1バイトは
    (あ)0x80~0x9f
    (い)0xe0~0xef (JISのどの水準までサポートするかで変化することがある)
  第2バイトは
    (A)0x40~0x7e
    (B)0x80~0xfc
なので、2バイト目がASCIIと重複する部分がある。
このため、逆側からの読み出しでは正しく文字を認識できない。

また、SHIFT-JISのファイルには1バイト半角カタカナも入っている可能性も高いので、
  0xa0(0xa1)~0xdf
のコードも存在する。UTF8中には1バイト半角カタカナはない

そういう状況でのUTF8とSHIFT-JISの識別の仕方。

前から順に読んでいって、上記(3)~(5)のパターン、すなわち0xf0~0xfdが出てきたらUTF8で即確定できる。


逆に、(あ)が出てきたらSHIFT-JIS。UTF8では(あ)のコードはいきなり出てこないから。
0xa0~0xc1が出てきたときは、半角カタカナなのでSHIFT-JIS。
ここまでの識別でもまだわからないのが
 (1)と(2)
である。この部分の完全な判別はできない。

しかし、確率論的には推測できる。
(2)のコードはSHIFT-JISでも存在しうるが、その範囲は第二水準であり、
しかも次の1バイトが第1水準及び半角カタカナとなるため、事実上その並びが
普通のファイルで出てくることはほとんどありえないと考えていいだろう。
だからここはUTF8。

残りは(1)。
0xc2~0xdfは半角カタカナと重複するからここだけでは判別できない。

2バイト目が0x80~0x9fならSHIFT-JISの第1バイトかもしれない。
したがって、この先を更に読み続け、どちらかの文字コード範囲として矛盾が
出てきた時点でその可能性を排除する、という方法しかない。
ただし、場合によっては、UTF8とSHIFT-JISの双方でありえる可能性もある。

ということで、完全自動の文字コード認識は不可能という話。
基本自動、読めなかったら手動で、という風にしておく必要があるわけである。

X−BASIC for iOSではコード範囲を限定しているので、全自動。

2012年8月1日水曜日

UTF8とSHIFT-JISコードの特徴

UTF8<->16の変換関数を書いたので、UTF<->SHIFT-JISの変換関数も公開したいところだが、それは出来ない。

なぜかというと、出し惜しみじゃなくて、文字コードにおいて、UTFとSHIFT-JISの間に算術的相関関係がないからである。

(一部のコード範囲を除き)基本的には、1:1で変換テーブルを作るしかないのだ。

だから、変換処理を公開すると言うことはそのテーブルを公開することに等しく、
SHIFT-JISの文字数を考えたら、それは現実的ではない。高速化を考慮するなら、
交互の変換にはそれぞれ別テーブルが必要となるのでなおさらである。

実際に、全ての対応表を載せているHPがあったりするが、その表示はかなり重い。


・・・

さて、X-BASIC for iOSの開発でUTF-8の文字コード(正確には文字エンコード、らしいけど)についてかなりだいぶ理解できたと思う。
SHIFT-JISに関してはその誕生時から見ていて、X1-turboからX68000、さらには
多くの組み込み機器にも処理を実装してきた。日本でもトップクラスの理解者である、と自負してたりする(^_^;)。
なもんで、両方のコードを理解した今となっては、怖いもん無しである(^_^;;)

いや、それは冗談として、 UTF-8の特徴を少し説明。

UTF-8は、JISコードに対するSHIFT-JISのような物で、UTF16に対して算術演算をかけることでコード範囲を限定している。

双方の特徴をまとめると以下のようになる。


SHIFT-JIS
・前から読まないと正しいコードが得られない
・しかしそれさえ守れば、ASCIIコードと混在可能
・ASCII用に書かれた処理の多くは、簡単な2バイトコード判定の追加するだけで流用可能
・基本的に見た目のバイト数と文字コードのバイト数が一致する
X68000の1/2角・1/4角文字など、例外も存在した(まあその範囲はそもそもJIS規定外だが)。
・第2水準漢字までが2バイトで収まる(第3水準以降は知らない)
・JISコード(=連続コード)と算術演算による交互変換が可能なため、漢字フォントの位置を求めるのが楽。
JISコード並びの文字フォントはフリーで多数出回っているため、 無償で漢字を表示できるシステムを構築できる(読みやすさは別にして)。
・JISコード第1水準漢字は音読みで並べられているため、音読み漢字変換なら比較的簡単に実装できる



UTF8
・前からだけでなく後ろからでも正しい文字コードを得られる
・そのままASCIIコードとの混在が可能
・しかもASCII用に書かれた処理の多くがそのまま使える
・見た目のバイト数と文字コードのバイト数が一致しない
・第2水準漢字まででも3バイト以上になることがある(というか2バイトで収まる範囲は少ない)


どちらがいいというのではなく、目的さえ間違えなければ、どちらもよく考えられたコードだと言える。が、SHIFT-JISは組み込み機器で使うに有益な特徴を持ったコードで、UTF8はOS上で英語圏発祥の処理を多国語化するに良いコードだと言えよう。

UTF8については次回もう少し解説。

2012年7月25日水曜日

UTF8-16変換処理の抜け

先に発表したUTF8-16変換処理でdefine関数の部分の定義が抜けていたので公開。

#define b32(w)  (((w)&0xff000000)>>24)
#define b24(w)  (((w)&0x00ff0000)>>16)
#define b16(w)  (((w)&0x0000ff00)>> 8)
#define b8(w)  ( (w)&0x000000ff)
#define w16(h,l)   (((h)<<8 data-blogger-escaped-define="define" data-blogger-escaped-hh="hh" data-blogger-escaped-hl="hl" data-blogger-escaped-l="l" data-blogger-escaped-lh="lh" data-blogger-escaped-ll="ll" data-blogger-escaped-pre="pre" data-blogger-escaped-w16="w16" data-blogger-escaped-w24="w24" data-blogger-escaped-w32="w32">







2012年7月20日金曜日

UTF16をUTF8に変換する処理

今度はUTF16をUTF8に変換する処理。

実を言うと、UTF16はあまり使い道がない。と思う。
->とか書いてたけど、実はiOSの中の文字コードはUTF16だと判明。
characterAtIndexで返ってくるコードはUTF16である。
UTF8だと思って処理を書いてたらうまく動かないので調べたらそうだった。
(後日アップルのドキュメントを読み返したら、UTF16だとちゃんと書いてあった。
でも、あんなところに1行だけでは気が付く人少ないのでは?)
ただし、ソースコード(その中に記述する文字列)そのものはUTF8でなくてはならない。
ここは少しややこしいところ。

SHIFT-JISは、組み込み機器ではプログラムもデータも小さくなるので非常に使いやすい。
表示幅とバイト数が一致するのもいい点である。
UTF8はASCIIコードとの互換性が高く、ASCII用のプログラムを移植するに都合がいいことが、X-BASIC for iOSの開発でよくわかった。

SHIFT-JISとの変換に関してはUTF16の方が行いやすい。

ulong Utf16ToUtf8(ulong n)
// http://ja.wikipedia.org/wiki/UTF-8 参照
// Unicodeは文字コードの総称で、UTF-16やUTF-8はその表現方法の種類、である。
{
 if (n<=0x7f) return(n); // ASCII互換
 if (n<=0x7ff) {
  // 8421 8421   8421 8421
  // 110x_xxxx | 10xx_xxxx
  return  w16(             (0xc0|(n>>6))   , (0x80|(n&0x3f)) );
 }
 if (n<=0xffff) {
  // 8421 8421   8421 8421   8421 8421
  // 1110_xxxx | 10xx_xxxx | 10xx_xxxx
  return w24(       (0xe0|((n>>12)&0x0f)) , (0x80|((n>>6)&0x3f)) , (0x80|(n&0x3f)) );
  
 }
 // n<=0x1fffff
 // 8421 8421   8421 8421   8421 8421   8421 8421
 // 1111_0xxx | 10xx_xxxx | 10xx xxxx | 10xx xxxx
 return w32( (0xf0|((n>>18)&0x07)) , (0x80|((n>>12)&0x3f)) , (0x80|((n>>6)&0x3f)) , (0x80|(n&0x3f)) );
 
 // 定義上はこれ以上もあるが、実在しないので省略
} 
 

2012年7月14日土曜日

UTF8の文字コードをUTF16に変換する処理

しばらく忙しすぎて更新できてなかった。
理由は、どスランプとか開発作業とか。
中核の処理は動くようになったが、まだiOSへの対応については手つかず。
ずっとWindowsのCygwin上で開発してたので、Xcodeも忘れてしまった(^_^)。
まずはその思い出しから始めないと。

ということで、超久しぶりの更新は、そのプログラム中で使っている処理を1つ。
UTF8の文字コードをUTF16に変換する処理。
ただし、UTF8で32ビットの範囲に収まるコードのみ。

UTFまわりの処理はインターネットで探しても 意外と見つからない。
最近はOSや言語レベルでサポートされているようで、
Cでの記述、というかフローが正確にわかる物が無かった。
ということで、公開。

ulong Utf8ToUtf16(ulong b)
{
 if (b<=0xff) return(b); // ASCII
 if (b<=0xffff) {
  return (        (b16(b) & 0x1f) << 6) + (b8(b) & 0x3f);
 }
 return ( ((b24(b) & 0xf) << 12) + ((b16(b) & 0x3f) << 6) + (b8(b) & 0x3f) );
}


2012年4月30日月曜日

C言語;ポインターの増減

C言語のポインターに対する演算の結果について。
しばらく使わないと忘れてしまうので覚え書き。

long  *lp=0;
short *wp=0;
char *cp=0;

としたとき、それぞれを++した時の実アドレスは、
lp++ == 4
wp++== 2
cw++== 1
である。

同様に、
&lp[1]のアドレスは4
&wp[1]のアドレスは2
&bp[1]のアドレスは1
である。




同じ演算子でも、ポインターの型によって得られる実アドレスが異なる。

アセンブラーでアドレスを演算する場合にも変化が伴うことがあるが、
Cとは結果が違う。

たとえば680x0MPUでは、
a0.l=0のとき、
move.l d0,(a0)+   → a0=4
move.w d0,(a0)+   → a0=2
move.b d0,(a0)+   →   a0=1
であるが、

move.l d0,4(a0)
move.w d0,4(a0)
move.b d0,4(a0)
はいずれも4番地からにデータを書き込む。
自動インクリメント(またはデクリメント)は大きさを考慮するが、オフセット指定は
大きさは関係ないと言うことである。

通常加算は大きさを考慮しないので、
addq.l #1,a0
addq.w #1.a0
はいずれもa0=1となる。

アセンブラとC言語の両方に精通していると、C言語におけるポインターの演算結果を
迷うことがあったりするので、注意。

2012年4月11日水曜日

Windows7のデスクトップガジェットの強制的な削除仕方

Windows7でデスクトップガジェットを使っているとき、まれにその起動が出来なくなることがある。

ガジェット内部でエラーを発生してしまうと、そのエラーを起こしたガジェットだけでなく、登録している全てが落ちてしまうようだ。うちでは、IO-DATAのDrive Centerがこの状態になって往生した。

いったんこうなってしまうと、コントロールパネルのデスクトップガジェットも開けなくなり、通常ではどうしようもなくなる。
この場合、

c:\Users\ユーザー名\AppData\Local\Microsoft\Windows Sidebar

にあるSettings.iniをテキストエディタで開き、エラーを起こしていると思われるガジェットの設定を削除する。

削除対象は、[Root]タグ内にある
  Section?="?"
というセクション名の登録、
[Hashes]タグ内にあるプログラムの登録と、
[Section?]タグの内容そのものである。

念のため、編集前にはバックアップをとっておいた方が良いであろう。

また、同\Gadgets\の下にガジェットのプログラム本体(のフォルダ)があるので、場合によってはそのフォルダも削除する。

いや、ガジェットが落ちるようになってしまったけど、解決に関する情報がどこにもなくて、
いろいろやっている内に発見した。同様なことで困ったいる人がいたら、どうぞ。

2012年3月22日木曜日

Xcode4.3.2のバグ修正のチェック結果

ようやく公開されたので、現在調査中。

・・・

なんかうまく動かない。
V4.3.2自体が正常動作しない上に、V4.2.1までも動かなくなってしまった。

ということで、全部再インストールする羽目に。

アップルはいったいどういうチェックをしているのだ?
クリーンインストールの機体だけしかチェックしていないのではなかろうか?

→なんかまたインストールされ方が変わってる。

・・・
再インストール後チェック。

(1)iPadシミュレーターの枠がない(HOMEボタンが表示されない)のは仕様
(2)[[UIDevice currentDevice]systemVersion]が@"Unknown”を返してくるバグは修正された
(3) ビルトインマクロ__VERSION__は"4.2.1~"のまま。
"4.2.1 Compatible Apple Clang 3.1~"になってる

(4)実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けするバグは修正されていない。

(5)日本語ファイル名があるとgitでcommit出来ないバグは修正されていない

(6)OrganizerのArchivesでアプリのアイコンが表示されないバグは修正された
(7)DistributionのCodeSigningが外れるバグは修正された

(8)シミュレーター上のUITextView/UITextFieldで落ちるバグは修正された

(9)WiFi接続のデバイスの検出機構(iOS Device DiscoverryのSupport Wirelessly Connected Devices)がなくなった
問題が多かったから?


ということで、重大なバグは修正された模様。一応開発に使えるレベルには戻った。

でも全てのバグは直ってない。

早よ直してくれ。

2012年3月17日土曜日

methods named 'xxx' found

プログラムを組んでいると、「methods named 'xxx' found」という警告がいくつか出た。

直訳すると「xxxという名前のメソッドが複数見つかった」となろうが、
それならエラーになるはずではないか。


よくよく調べると、id型のクラスインスタンスに対してメソッドを発行しようとすると
発生する(ことがある)とわかった。

「例」
タッチイベントを処理する
-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
 NSTimeInterval tm=[[touches anyObject]timestamp]; // ここでmethods named 'timestamp' foundが発生する


}

touchesに実際に格納されるのはUITouchであるが、[touches anyobject]はid型で返す。
timestampという名前のメソッドは複数のクラスが持つので、
どれか解決できずに警告が出てしまう。

実行時にはNSSetの内容は決定しているので、[touches anyobject]のidが実際は何であるか、
この場合UITouchであることがわかっているのでtimestampを呼び出す先もわかる=実行時エラーはでないのである。

警告を回避するには
 NSTimeInterval tm=[(UITouch *)[touches anyObject]timestamp];
として型を確定してやればよい。ポインター型でキャストすることに注意。

Xcodeのエラーコードはわかりにくい(その上ドキュメントがない)ので困る。

2012年3月16日金曜日

The new iPad

「The new iPad」が届いたのでちょいと感想など。

Xcodeでつなぐと「iPad (3rd generation)」と表示される。
なら「iPad3」でいいじゃん、と思ったりもするのだが、
まあ、こだわりがあるのだろう。

で、ちょっと触ってみた感じのiPad2との違い。

  • 文字がきれい。これは今回の一番の売りのRetinaDisplay(解像度倍)だから当然だけど、目に優しく感じる。
  • iPhoneモードの2倍表示がきれい。従来のiPadにもiPhoneモード2倍表示はあったけど、単純拡大で文字はがたがただった。これが改良されたのか非常にきれいになった。iOS5の改良項目かと思ったが、iPad2では今まで通りだったので、3の特徴と言える。
  • 音が良く聞こえるようになった。スピーカーの位置は同じだけど、音ははっきりしている。スピーカーそのものが良い物になったか。
  • グラフィックを使う処理にもたつきがなくなった。iPad用のゲームで少々もたつきがあったゲームが、3では全くもたつかない。3はCPUの能力はほぼ同じだが、解像度倍に合わせてグラフィックの能力があげられているので、iPad解像度のゲームは恩恵を受けてこうなっているようだ。3専用ゲームではそうはいかんだろうけど。
  • 背面カメラの画像が格段に良くなった。PCの画面を撮影しても今までは文字が読めなかったが、3でははっきり読める。ただ、モアレの発生はかなりきつい。
  • 重さは、カタログ上は初代iPadと同じに戻ったらしいが、手に持った感じではiPad2と変わらなく思う。
    多分に、厚みが変わっていないからだと思う。
  • 外観上の違いはほとんどない(だからここにも写真を載せなかった)。あえて言うなら、背面カメラのレンズ径が倍くらい大きくなったのと、規格適合マークが大きく変わったことくらいか(iPad2はVCCIなど国内規格マークだったが、3はFCCやCEなど海外規格のみになっている)。両方持っている人は、自分でわかりやすいようにシールでも貼った方が良いかもしれない。

そんなところ。

2012年3月11日日曜日

開発用実機の接続について

Xcodeで開発用実機を「USBケーブルで」接続する場合、
本体のUSB端子もしくはそこに差したUSBハブからでなければならない。

USBハブにさらにハブをつなぎ、そこに差したケーブルで実機を接続すると認識してくれない「ことがある」。してくれることもあるが、不安定。
USBハブの種類というか構造にもよると思うけど。

Xcode4.2ではWiFi接続も出来るけど、また使ったことがない。
どんなもんだろうか?
→Xcode4.3.2ではWiFi接続機能は削除された。

Lionの壁紙が起動毎に初期化されてしまう・・・ように見える

Lionにしてから、壁紙が起動(またはログイン)毎に初期化されてしまう(Andromeda Galaxyになる)という問題が発生した。

調査の結果、以下のようにすれば解消されると判明。

(1)システム環境設定~デスクトップを開き、各画面に違う壁紙を設定する
そのときの各画面の壁紙名を控えておく

(2)Fiderからライブラリ~Preferences~com.apple.desktop.plistを開く
(3)BackGroundの下にある、0以外の数字だけの項目が画面別壁紙設定 なので、全てを開き、
  (1)で 設定した壁紙名「以外」の設定の入っている項目を全て削除(Cut)する
    spaces/default/0は消さないこと。

これで直る。

・・・修正。
初期化されたのではなく、表示されるページが変わっていたと判明。
デスクトップを複数用意している場合、背景(バックグラウンド)はデスクトップ毎に設定できる。
そのため、別のページが表示されると背景がおかしくなったように感じる。

上の処理をすると壁紙は戻るが、消したデスクトップに配置していたアプリの画面情報も消えるので注意。

なお、デスクトップの追加はMissionControl表示中、物理画面の右上あたりにマウスカーソルを持って行くと「+」が出るので、これで行う。
MissionControlは本当にわかりにくいし、操作しにくい。

ExposeとSpacesに戻して欲しい(可能なら切り替えでも良いので両方使えるようにして欲しい)。
ちゃんとユーザーの声を聞け、アップル。

2012年3月9日金曜日

Xcode4.3.1のバグ

iOS5.1の公開に合わせてXcodeも4.3.1(Lion専用)が公開された。

が、早速問題が多数出ている。
太字は重大なバグ。

(1)iPadシミュレーターでHOMEボタンが表示されない。
Retinaだと50%表示にしても縦1080でも枠付き表示しきれないからだと思われる。
外枠自体表示されないので、仕様変更であろう。
iOS4.x/5.xどちらも同じになってる。
メニューバーのハードウエア~ホームで押下をシミュレートできるが、
ホームダブルタップによるアプリ切り替えが出来なくて困る。
アプリの削除もやりにくい。
iPhoneシミュレーターはHOMEありで変更なし。

(2)シミュレーター上で[[UIDevice currentDevice]systemVersion]が@"Unknown”を返してくる。
実機では問題ないが、シミュレーターではデバイスまたはOSバージョンを変えても変化なし。
4.2.0まではちゃんとシミュレーターに設定したOSバージョンが返ってきてた。
バージョンチェックして動作を変えている場合、シミュレーター上では問題が出る。
なんかおかしいから調べてみて気がついた。
今のところ回避策が見当たらないので非常に困ってる。
→info.plistに独自キーを追加してそこにバージョンを「毎回打ち込んで」読み込ませることで、
当面回避。
なんていう手間。 やり方は1つ前の記事を参照のこと。早速役立った。

(3)ビルトインマクロ__VERSION__が"4.2.1~"になっている。
だめじゃん。

(4)シミュレーター上動作中でアプリがハングアップして落ちた場合、二度とシミュレーター上でアプリが実行できなくなることがある。
その状態でも実機ではデバッグできた。
シミュレーターのiPhone/iPadおよびバージョンを変えても改善しない。
シミュレーターおよびXcodeを再起動しても だめ。Mac自体を再起動してようやく復帰。
新しいデバッガーlldbのバグかも知れない。
1回だけ発生した。


(5)エディタで編集内容表示が消えてしまうことがある
スクロールすると戻る(ソースそのものには影響なし)。
2~3回発生。

(6)Xcode4.0.xほどではないが、遅くなった。
検索前とかビルド前にマウスカーソルが回る。
(Snapshotはとってないのに。)
せっかくv4.2.0で速くなったのに(4.1.0からだったかも) 。
→Lion自体の問題だと判明。

(7)writeToFileがエラーを発生することがある
これはXcodeのバグではないが、LionではSnowLeopardとファイルアクセス権限の設定が異なっているため、これが出る。
デバッグ中の中間ファイルが書き出されなくて調べてたらこれとわかった。writeToFile:@"ファイル名だけ"という書き方をしているとまずだめ。
フォルダを厳密に指定し、そこのアクセス権限を読み書き可能に設定していなければならない。

(8)シミュレーターでiOS5.0以上を選択したとき、UITextFieldおよびUITextViewをタップするとEXC_BAD_ACCESSで落ちる
自分のプログラムの問題かと思って調べ、その後Apple提供のサンプル「HelloWorld」で試したらこれも落ちる。そのくせ実機で動作させたらあっさり動いた。丸1日調査してたのがばからしい結果。100%再現する。
重大なバグ。これらを使っている場合、実機でしか動作確認できない状況。
なお、iOS4.xのシミュレーターではINVARID dictionaryというのが出てるが、一応動作には問題ない。
Xcode4.2.0まででは発生していない。

(9)実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けする。
シミュレーターでは問題ない。環境設定のフォント設定の間違い、なんてこともない。
これは実機OSが4.3でも5.1でも同じに発生する。

(10)日本語ファイル名があるとgitでcommit出来ない
V4.2.0でも有ったバグ。直されてない。
最初からわかってれば全て英語ファイル名にしたんだけど、後からgit管理下に入れたもんで。 フリーのGitXを使えばOK。

(11)OrganizerのArchivesでアプリのアイコンが表示されない

(12)DistributionのCodeSigningが外れる
ファイルそのものが消えていた。再設定が必要。
しかも、それがArchiveを作るときにはわからず、アップロードするときにわかる。
さらに、そのアップロード時のエラーメッセージも変更されたのでわかりにくい。

(13)[UIColor colorWithPatternImage:]にもバグがあるらしい(未確認)


V4.2.0にあった他のバグの内、大問題だったSettingBundleが編集できないバグはさすがに修正されてるが、他は未確認。


とにもかくにも問題が多すぎて困る。問題が出るたびに調査に時間がかかってしまう。
V4.2.0に戻そうとしたが、Xcode4.2.0(Build 4C199)/4.1.0はLion上では動かない。

仕方ないので、もう1台有るMacのSnowLeopard上に4.2.0で開発環境を再構築することにしたが、メインマシンではないのでいつもそちらで開発するのはつらい。

Appleには猛省をして欲しい。
毎度のことながら、とにかくデバッグが足りなすぎ。いじる理由がないのに、
前のバージョンまで正常に動いてたところが動かなくなるのも多い。
儲かってるんだから、デバッグ要員を増やせ。

一応(10)まではAppleのフィードバック(http://www.apple.com/jp/feedback/)で報告はしておいたが、フィードバックの項目にXcodeがないのはどういうもんだか(OSで報告した)。Xcodeのバグ報告は受け付けないってか?
それともXcodeは全く別の場所にフィードバックがある?→developperのXcodeダウンロードの一番下にあったのね(Submit Bugs to Apple)。出し直した方が良いのか?


また、Xcodeの最新版はまだSnowLopard上でもサポートして欲しい。
Lionには画面共有とかまだ不具合があるから。せめてMountainLionが出て安定するまで。

OSのサポート、およびOS間のアプリ動作互換性はMicrosoftを大いに見習って欲しい。(ほぼ)無意味な下位互換切り捨てはやめてくれ。

2012年3月6日火曜日

info.plistの読み出し方

プログラム名-info.plistの内容は、通常プログラムから明示的に読み出す必要はないが、
ごくまれに必要になることがある。

その全体の読み出しは、
[[NSBundle mainBundle]infoDictionary]
で行える。


個別キーに対応する値の読み出しは、
[[[NSBundle mainBundle]infoDictionary]objectForKey:@"CFBundleDisplayName"];
のように行う。

ただし、InfoPlist.stringsの内容によるローカライズは反映されていない。
 
キー名は、Xcodeでinfo.plistを表示して、Keyの桁で右クリック~Show Raw Keys/Vakuesにチェックして表示されるKey名を使う。

2012年3月1日木曜日

Windows7 64bitで正常動作するソフト

Windows7 64ビットで動作するソフトについても一応記録。
現行版ではないもののみ。

  • XM6 v2.06
    X68000エミュレーター。意外にも(失礼?)一発動作。
  • 楽々はがき2009(JustSystem)
  • アレンジOK!素材集(JustSystem)
  • はがき さくっとファイリング(コクヨ)
  •  

・・・2013/04/12追記
WindowsXPの公式サポートがあと1年ということで、これから7もしくは8への移行を考える人も多いと思う。
8はおそらくVista同様MSの黒歴史OSになると思うので全くおすすめしない。
操作性が変わりすぎており、混乱を招くこと必死だ。

意外にもXPのソフトが7の64ビット環境下でもそのまま動く。
ハードウエアドライバーはダメなことも多いが、すでに多くのソフトが対応版を出しているので、
入れ替えだけでいけることが多い。
万が一動かなければ、7のPro以上なら仮想XP環境を構築できるので、その上で走らせればよい。

ではあっても、異なるOS、というより別のPCに環境を移行することは、かなり難しい。
特にアプリケーションのライセンスや設定を移行するのは手間がかかる。
引っ越しツールというのもあるが、私はそれで成功した試しがない。
移行後に何かしらの問題が発生するため、手動でやったほうがよほどまし、という結果になったことがほとんど。

専門家に任せるか、時間をかけて、手動で徐々に行うのが吉。

2012年2月29日水曜日

UIKitの隠れた仕様

UIFontの情報を得ようと次のようなプログラムを書いた。

NSLog(@"smallSystemFontSize=%f" ,[UIFont smallSystemFontSize]);
NSLog(@"systemFontSize=%f"  ,[UIFont systemFontSize]);
NSLog(@"buttonFontSize=%f"  ,[UIFont buttonFontSize]);
NSLog(@"labelFontSize =%f"  ,[UIFont labelFontSize]);
// この処理をmain()に置くと、なぜか↓がエラーを発生する
//  UIFont *font = [UIFont systemFontOfSize:96];
UIFont *font = [UIFont fontWithName:@"Times New Roman" size:96];
NSLog(@"capHeight =%f",font.capHeight);
NSLog(@"ascender  =%f",font.ascender);
NSLog(@"descender =%f",font.descender);
NSLog(@"lineHeight=%f",font.lineHeight);
NSLog(@"pointSize =%f",font.pointSize);
NSLog(@"xHeight   =%f",font.xHeight);

が、これが実行時にエラーを出す。
調べると、main()の中に書いているとfontWithNameまたはsystemFontOfSizeでエラーを発生する。
UIApplicationMain()以降に呼び出されるメソッド内、たとえばapplication:didFinishLaunchingWithOptions:の中だと問題ない。

main()中ではインスタンスを作ることそのものがだめなのかと思いきや、NS*では問題ない。
UIKitのインスタンスメソッドはだめなのかも知れない。

まあ、通常main()内に記述することはないはずだが、念のため。







2012年2月26日日曜日

MacとWindowsのフォルダの違い

MacでもWindowsでも、ファイルシステムにおける階層化構造のことを「フォルダ」と呼ぶ。
もともとWindows、というかDOSでは「ディレクトリ」と読んでいたが、いつの頃からか「フォルダ」と呼ばせるようになった。Windows95からだったか。
この呼び名の変更は明らかにMacを意識したものだと思われる。
GUI化するとき、「アイコンがフォルダの方が作りやすい」とも、まことしやかに囁かれているが、多分それはこじつけ。

しかし、この2つのOSにおける「フォルダ」の意味合いは大きく異なる。

Windowsにおけるフォルダは単に「ディレクト」の名称変更に過ぎず、機能的差異は全くない。フォルダを1つのファイルとして扱うことはできない。

ところが、Macではフォルダは1つのファイルとして扱うことも出来る。まさしくファイルを束ねる「フォルダ」である。OSまたはアプリによって認識されている特殊フォルダに関しては、通常の方法ではその下のファイルを見ることができなくも出来る。

例えば、Macのアプリケーション実行ファイル名は*.appだと思われがちだが、
実はこれはファイル名ではなくフォルダ名である。CTRL+クリックまたはマウスの右クリックで「パッケージの内容」を選ぶと、その中に入っている実際のファイルが見える。
Macではアプリケーションの削除は.appの削除だけでいいと言われるが、それは実はフォルダごと消せるからである。

このように、1ファイルのように見えるフォルダはXcodeのSettings.bundleなどを初め、いくつも存在する。

Windowsでは既存フォルダと同名フォルダをコピーした場合、フォルダ内のファイルは両方が交じって存在するようになる。
Macでは同じ事をすると、古いフォルダの内容は全て消え、新しいフォルダの内容のみになる。これは、WindowsからMacに移ってきた人が、かならず一度はハマる罠だと思う。

これもフォルダの性格の違いから来ることである。Macにとってはフォルダは複数のファイルを束ねて出来た新しいファイルとほぼ同等であり、上書きはその内容の改変ではなく、フォルダそのものの置き換えを意味するからである。

ということで、どちらかというとWindows側の名称がその実態に合っていないのが問題なので、ここは1つ「ディレクトリ」に戻して欲しいと思う今日この頃。

WindowsとMacではファイルに対する認識も大きく異なると思っているが、それについては後日またまとまったら。

・・・2012/03/09追記
Lionでは「フォルダの結合」と「両方のファイルを保持する」というのが加わった。Windowsと同等になるのは前者。大迷惑OS Lionでの数少ない「改良」と言える項目かと。

2012年2月18日土曜日

Windows7 ネットワークの高速化

Windows7 64bitのネットワークアクセスが異常に遅い。

インターネットでは気がつかなかったが、ネットワーク先にあるドライブ、WindowsHomeServer(WHS)やネットワーク共有ドライブへのアクセスが今までより10倍どころかもっともっと落ちている感じ。

調べてみると情報あり。Mac mini 2011/2014にWindows7を入れている場合、以下の通りに設定する。
  1. コントロールパネル~ネットワークと共有センター~(左側から)アダプターの設定の変更
  2. ローカルエリア接続の右クリックメニュー~プロパティ
  3. 構成~詳細設定
  4. TCP/UDP Checksum Offload(IPv6)をDisable
  5. Large Send Offload v2(IPv6)をDisable
  6. [OK]
EpsonDirect NP25Sの場合
  4. TCPチェックサムオフロード(IPv6)を無効
  5. 一括送信オフロードv2(IPv6)を無効
 
これで速度がほぼ戻った感じ。IPv6プロトコル自体は外してない。
本来はこれらの機能はEnableにするとネットワークカード上で処理されるようになるのでCPU処理が減って速くなるはずなんだがなぁ。

さらに調べると、ネットワークのTCPウィンドウサイズの自動調整機能を高速回線用にするとよいという情報もあり。
コマンドプロンプトを管理者権限で起動してから、下記コマンドを実行する。
(「プログラムとファイルの検索」に次のコマンドを入れて実行した場合、管理者権限で弾かれる。)

netsh interface tcp set global autotuninglevel=highlyrestricted

元に戻す場合は最後をnormalにする。(上記設定を変更するときは、基本的にネットワーク越しのファイルアクセスをしていない状態で行うこと。していると、そのアクセスに失敗することがある。特にVNCでの遠隔設定時に注意。)

さらに速くなったような感じ。特にインターネット接続が劇的に速くなった。
他にもいろんな設定を変えている人が見受けられるが、うちの場合はこれでOKとしておく。


2012/04/11追記
ファイルコピーを高速化するフリーウエア「TeraCopy」は、ネットワーク越しコピーでは無効どころか、場合によってはかえって遅くなるようである。あまりに遅い場合は、それを一時的に無効にするか、他のファイルコピープログラムを試してみると良いかもしれない。
「SotaさんのBackupが意外に早い」とも書いておこう。

2013/02/10変更
WindowsHomeServer相手のコピーならBackupが結構早い。
Macをサーバーにしている場合はTeraCopyの方が速い。
Backupは、Mac相手のコピー時に限り、ファイル名の扱いに問題があるらしく、コピーに失敗することが多い。日本語を含むフォルダおよびファイル名が怪しい(でも全てではない)。
なので、Mac相手は基本TeraCopy。
ただし、TeraCopyでのコピー中にMacとの接続が切れることが多い。コピー動作が止まったらほぼ確実。その場合、一旦中止して、再度やり直し。
2以上のコピーを同時に走らせると切れる確率が上昇するのでやらないこと。
なぜだろう?

2013/3/23変更
Backupはネットワーク越しだと異常に遅くなると判明。

→遅くなるのはどうやらWindows7側の問題のような感じ。他のコピーツールでも同様な現象が発生する。
→2つ(以上)の別ネットワークドライブに同時にコピーするとものすごく高速化されるという変な現象も起きる(Backupは多重起動可能)。でも、Mac相手ではコピーに失敗しまくるようになるのでやってはいけない。

2012年2月14日火曜日

Windows7 32ビット版で不具合を起こすソフト

ついでなので、Windows7の32ビット版で不具合を起こすソフトについても少し。
XPでは動いてたけど、というもの。

・Zwei!!(Falcom)
全くだめ。ついでに言えば、仮想XPモードでも完全ではない。
Zwei2は全く問題ない。

・PanoramaMaker4
写真をつなぎ合わせてパノラマ写真にする物。
対応版は出ているが有償だし、MicrosoftのICEという無料アプリでも同じことが出来るので、今はそちらを使っている。
→最近はPhotoShopElementsに移行。

・Logicoolウェッブカムソフトウエア
USBカメラの制御ソフト。カメラ自身が認識されない。
USBカメラデバイスの仕様が策定される以前に発売された古いUSBカメラは軒並みアウトかもしれない。

・inksaver2
インクジェットプリンターのインク量を削減してコストダウンを計るツール。
対応版はinksaver4(以降)。

・MFC-6490CN付属CDのドライバー
ブラザーの複合機。メーカーサイトに有る最新版は対応されている。


最初はもっとたくさん動かなくなる物が出ると思ったけど、純然たるソフト物もデバイス関係も意外に動く物が多くて驚いた。
というか、まともな会社の製品は全て対応版ドライバーが出ている。

ただ、My Documentをはじめ主要ディレクトリの位置(名前?)が変わったことには大弱りで、その対応にどえらく時間がかかった。
うちではMSが用意してた移行ツールではうまく移行できなくて、自前でファイルコピーをしたから。
というか、MSの移行ツールは、よほど単純な環境以外では成功しないと思うので、使わないほうがいいと思う。
時間の無駄。

あと、先にアンインストールしてライセンスなどを解放しないといけないアプリをしてなくて困った。今からXP→7移行する人は要注意。

・AdobeAcrobat9(readerではない)
・LookFONT ver2
・らくらくファイリング9
・ウイルスセキュリティーZERO
・iTunes(PCの承認解除と共有解除。意外に盲点)

1台のPC上でXP→7移行は絶対に「やめた方がいい」と思う。ものごっつう苦労するから。
うちはWindowsHomeServerがあるから、失敗したと思ったら復旧させてやり直しを何度もやったけど、普通は無理だから。

経験者からの忠告。

Bluetoothファイル共有 on Fusion

Fusion上のWindowsでBluetoothを使ったファイルの送受信する場合の問題点。

Fusion上Windows(送信)→別Windows(受信)の転送は問題ない。

ところが、逆は出来ない。

MacOSが先に受信してしまうからである。
(Macでファイルを受信するには「共有」でBluetoothの共有をONにしておく必要がある。)
Macで受信して共有フォルダ経由でWindowsに渡してもいいけど、一手間増える。

DVDドライブのように、Fusion起動中はWindowsに制御権を渡せばいいのに。
(Windows起動中はMacからはDVDドライブがアクセスできなくなっている。)

これが出来れば、LAN接続なしでもファイルの送受信が楽に出来ると思ったんだがなぁ。

遅いけど。

2012年2月11日土曜日

Windows7 BootCampとFusion4の違い

で、多大な苦労の結果BootCampによるWindows7環境も構築できたわけだが、
Fusion4上との違いが気になるかもしれない。

まず速度差。
ほぼ同一のCPU/グラフィック性能を持つと思うiMac(Mid2011)上のFusion4とMac mini(Mid2011)上のBootCampでの対比。
Windows7のパフォーマンス評価の結果は以下の通り。

コンポーネントBootCamp Fusion4 
プロセッサ7.04.7
メモリ(RAM)7.45.5
グラフィックス5.76.0
ゲーム用グラフィックス6.56.0
プライマリハードディスク 5.76.6

CPUとRAMの速度には当然大きな開きがあるが、他は同等もしくはFusion4の方が上回っている。
HDDの差はiMacとMac miniのハード差が出ている。
iMacは3.5インチHDD、Mac miniは2.5インチHDDで、そもそも速度差がかなりある。

Mac mini上のWindowsは、電源ONからの起動も、プログラムの起動もかなり遅い。
HDDの遅さが直撃している感じ。
速度をできるだけカバーするため、RAMDISKやディスクキャッシュソフト(うちで使っているのはIO-DATAのマッハドライブ)を入れた。特にディスクキャッシュはけちらず出来るだけ大きく確保した方が良い。2回目以降のアクセス速度がRAMDISKに近い速度まで劇的に上がる。
ここで8GBにしたメモリが活きている。

ただ、再起動時の速度差は圧倒的で、Fusion4はWindowsを再起動しても
本当に一瞬で立ち上がってくるが、BootCampでは数分かかる。
FusionではMacOSのメモリ上にWindowsがキャッシュされているためである。
SSDとはこういう物だろうか、と一瞬思ったが、まだ高くて今の私には手が出ない。
(誰かください^_^;。)

起動してしまえば、やはりBootCampでの方が速い。
ハード性能をフルに活かせる。
2画面構成なども楽に出来る。

でも、WindowsとMac間のデータのやりとりがあるならFusion4の方が楽なのは言うまでもない。
画面以外のハードウエアも多くはそのまま使うことが出来る。
Mac上からWindowsのアプリを、見かけ上とはいえそのまま起動できるのも便利だ。
従って、双方を有効に使い分ければいいと思う。

・・・

FusionではBootCamp下にあるWindowsをMac上から起動できるようにすることも出来る。
Fusion上に別に仮想Windows環境を作るには、Windowsがもう1ライセンス別に必要となるが、BootCamp環境を起動する分にはそれは必要ない。

が、これはあまりおすすめできない。
簡単に言えば、BootCamp Windowsでフル性能を活かす設定にしていると、Fusion上では不具合が出るからである。

それは単に速度差だけではなく、以下のような問題を起こす。
  • メモリ不足になることがある。特にキャッシュディスクやRAMディスクを設定していると出やすい。そうなるとスワップが起こりまくって、ほとんど実用にならない速度にまで落ちる。
  • 画面解像度が変わるし2画面にも出来ない。1画面に納めようとするのでデスクトップがおかしくなる。
  • さらに悪いことに、Fusion上で設定を変えてしまうとBootCamp上にも影響してしまう。Fusion上で起動したそれは、BootCamp上のWindowsそのものだからである(ややこしい)。
このほか、BootCamp WindowsをFusion上で実行したときはリジューム機能が使えないという制約もある。
これは取説に書いてある。

ということで、BootCampとFusionのどちらを選ぶかは、Windowsに求めることによって決まると言うことである。
両立はあまり考えない方がいい。
私の場合は、「安価なWindows機」ということで今回選んだので、FusionではなくBootCampを選んだのである。


・・・2012/03/29、04/12追記

一部ソフトはFusion上Windowsでは正常動作しないことが判明。
手元にある物で確認したのは以下の通り。

COREL WinDVD7/9/11仮想PC上での動作を禁止している。これが動けばMac上でCPRMのかかったDVD-RAMが再生できるのに。
一太郎2011上の詠太行最後の1文字の発声が途中で切れてしまう

なお、完全なWindows機になるBootCamp上ではどちらも正常動作する。

Windows7 64ビット版で不具合を起こすソフト(一部解決策あり)

今回導入したのはWindows7 Proの64bit版であるが、やはりというか想像通り、一部に
不具合を起こすソフトがあった。うちでわかったものを列記しておく。
すべて元はXP対応の物で、32bitのWindows7では問題なかった物である。

  • B's FileGuard/DiskGuard(v1.06)
    これが一番やっかいだった。Windowsの起動すら出来なくなる(2つのうちどちらがぶつかっているかまでは未確認)。
    対応版も発売されてない。フリーでファイルの暗号化ツールはあるので、それを使うことになる。
    アタッシェケース」がおすすめ。
  • IO-DATA USB2-NFC
    nanacoやICOCCAカードを読むためのカードリーダー。インストールできない。
    当然、これの動作を前提としているアプリは動かすことが出来なくなる。
    EdyViewer v2.1(v3.0はこのカードリーダー非対応)とか精算快速とか。
  • ROXIO EASY CREATOR7
    インストール不可。CD/DVD作成系アプリが動かないのはちょいとつらい。
    最新版は出てるけどちょいと高い(1.5万)。
  • Core Temp v0.99.8
    起動せず。最新版(v1.0 RC3以降)にすることでOK。
  • あふw x64 v1.53
設定でフォントサイズ変更が効かない。.iniを直接書き換えて対応。
64bit対応不足と言うより、単にバグな気もする。

→仕様通りだそうですm(_ _)m。
64ビット版ではアーカイブ関係のDLLも64ビット版を入れないと展開できないのかも知れず。
うちでは↓理由によりExplzhは32ビット版なのでLZHが展開できない状態。
ということで、現在は32ビット版を利用中。機能差なしなので問題なし。


  • ExpLzh 64ビット版
    別途7-ZIP64/TAR64.DLLを入れろと言ってくるが、指定されたwindows\system32にコピーしても、なぜかsyswow64に入ってしまう。OSが勝手に入れ替えているらしい。回避策が見つけられなかったので、32bit版を入れた。機能差なしなので問題なし。
    →エクスプローラーなどによるファイルのコピーではうまくいかず、ファイルをいったんクリップボードにコピーしてペーストするとうまくいくらしい。(情報感謝!)
  • JustSystem 三四郎2009
    ウインドウサイズを変更すると、広がった部分が再描画されない。

    →治ったみたい。が、三四郎2009は日本語入力システムとしてATOKしか受け付けない問題がある。可能なら、早いうちにLibreOfficeやMS-Officeなどに移行したほうが良い。
  • Ztop v1.72
    マウスカーソルが飛んだり、ホイールスクロールで変にスクロールしたりする。
    V1.73にして、これをうまく使う情報がここにあった。
    一応不具合は出なくなった模様。
  • コントロールパネル~管理ツール~サービス
    ウインドウを右側広げると描画されない。標準同梱ツールがバグっててどうするよ。→治ったみたい。
  • WindowsXP/7-32bitまでで動いていたスクリーンセーバープログラムは、軒並みアウト。
    画面復帰時にタスクバーが消えてしまう。パスワードをかけていれば大丈夫らしいが、基本的に64bit 7対応とうたっている物以外は使わない方がよさそう。
    32ビット 7では問題なかったので、64ビット 7のバグのような気もする。
  • e-TAXで使うカードリーダーSHARP RW5100
    ドライバーが64ビットに対応してない。
    SHARPのサイトでは未対応と書いてあったが、OEMのサンワサプライの製品では「対応」となっていた。
    実際、オンラインでドライバを探すとインストールできた。
    e-TAXのソフト自体は64ビットでも動く。
  • IO-DATA USBGPS2
    メーカーではWindows7は32bit版も含め一切サポートしていない。
    FT232R USB UARTというドライバが×と出る。 このドライバは、その大本のメーカーFTDI社のサポートページから64ビット対応版がダウンロードできる。
    executable版を選んだ方が楽だと思ったが、困ったことにこれを実行してもドライバは正常にインストールされない。
    仕方ないので、zip版を適当な場所(デスクトップとか)に展開する。デバイスマネージャーからFT232R USB UARTを選択してプロパティ~ドライバーの更新~コンピューターを参照してドライバーソフトウエアを検索します~場所はc:\からで、サブフォルダも検索させる。すると「証明書がない」とか言ってくるが一応見つかるので、インストール。
    これでFTR232Rは動くようになるが、まだ「USB Serial Port」が動かないと言ってくる。
    もう一度同じようにUSB Serial Portでも検索してインストール。
    これで必要なドライバがすべてインストールされ、COMポートも確定するのでUSBGPS2 Utilityを起動、 COMポートを指定して動作確認する(最初は初期化した方がいいと思う)。初期測位までに5分くらいかかる。
    他のポータブルGPS(2台)では速攻なので、このIOのが性能が低いと思われる。
    なお、付属のSuperMapple8は問題なく動作する。が、GPS機種設定は「IO-DATA社製GPS」ではなく、「NMEA TOKYO Datum出力タイプ」に設定しなければならない。なお、このGPSはカシミール3Dでは対応されていない。
  • Unlocker v1.9.1
    32ビット版ではシェル拡張でunlockが出てこないので、64ビット版を入れること。
  • 確実にWindows7をBootCampで導入する方法;Mac mini 2011および2014、MoutainLion/Yosemite版(Mac mini 2014では注意点あり)

    Windows7をMac mini2011および2014にBootCampで導入した。
    BootCamp上でインストールするのは、ハードの性能を最大限引き出すWindows環境がほしかったからである。Fusion上との差などは後述。

    Fusion4上に導入したときはキーボード以外では苦労しなかったが、このBootCampでは非常に苦労したので記録しておく。

    細かい経緯は省略するとして、まず1つ言えるのは「AppleのBootCampに関する説明は重要な点が抜けてる」ということである。あの説明書通りにやってうまくいくのはまぐれだと思う(2014/11/15追記;今上がっているのは良くなっている)。

    で、まずはわかったことのまとめ。
    1. インストールに必要な物。Mac mini2011では8GB以上のUSBメモリと2GB以上のUSBメモリ。Mac mini2014では8GBメモリ1本だけで良い。USB-DVDドライブまたは、DVDドライブを持ったMac(Windows機でも出来るとは思う)。
      Windows7のインストールディスクは当然。
    2. Mac mini2011のBootデバイス順序は、USB1→内蔵HDDである。
      また、MacにはこのBoot順を変える手段がない(少なくとも公開されていない)。
    3. USBは、本体裏面左(中央側)から1~4になっている。
      2011では2~4はBoot対象にはなっていない様子。2014では他のポートからもBoot可能になっている(でもこれが悪さをする原因になっている)。
    4. Option(またはAlt)キーを押しているとHDDから強制起動してMacOS/Windows/ネットワークからの起動選択は出来るが、USB1とHDDの起動順を入れ替えられない。
    5. そのため、USB1にUSBメモリが刺さっていると、必ずそこから起動しようとし、起動できない場合はエラーを表示する。
      「Non-system disk press any key」と表示する割に、キーボードが効かないのでどうしようもなくなる。
    6. USB1にUSB接続のDVDドライブを接続している場合も起動できない。
      DVDの内容が、Windows7のインストールディスクであっても(起動できるはずなのに)。
      「no bootable device -- insert boot disk and press any key」と表示する割に、やはりキーボードが効かないのでどうしようもない。2014では起動はできるが、その後キーボードもマウスも一切効かず操作できない。
    (余談。Macは、一旦ブート元を設定すると、そこから起動できない場合でも他からブートするということはしない。Windowsから起動するにして、実際にはWindowsから起動できなかった場合にもOS Xで起動したりしない。 優先順位という考え方がないからだが、実にお馬鹿さんといえよう。この辺りはWindows機の方が圧倒的に優れている。)

    ということを前提に、実際にWindows7を「確実に」インストールする手順は以下のようになる。
    1. MacをTimeMachineでバックアップしておく。BOOTCAMP導入中に失敗するとMacOS側もパーになることがあるので、その時もすぐに復旧できるようにするため。自信があれば取らなくてもいいが、私は一度失敗したので、2回目以降は必ず取るようにしている。
    2. USBメモリにWindows7のディスクイメージを入れ込む。以下MacOS上での作業方法。
      1. DVDドライブにWinows7のインストールディスクを挿入
      2. ディスクユーティリティを起動
      3. Windows7のディスクを選択状態にして、ファイル~新規~(Win7の名前)からディスクイメージを選択。
        名前そのまま
        場所適当(デスクトップなど)
        イメージフォーマット~DVD/CDマスター
        暗号化なし
        で保存する。
      4. *.cdrというファイルが出来るので、拡張子を.isoに変更
      5. BootCampアシスタントを起動。「Windows7のインストールディスクを作成」のみを選択。「続ける」でISOイメージに今作ったファイルを指定・・・と言うか、勝手に指定されてる。
        このファイル指定を自動化するため実機上での作成が望ましいが、別の機械で作って実機へコピーしても良い。ちなみに、iMacで作ったら非常に遅かった。MacはDVDドライブの性能が低いからである。USBで接続するDVDドライブのほうが圧倒的に速い。
      6. 内容がすべて入る容量のUSBメモリをUSB1に接続する。Windows7Pro64bitは4GBもあれば入る。さらに、YosemiteのBootCampではこの中にドライバも一緒にコピーするので、+2GBくらいあったほうが良い。8〜16GBあれば問題ない。
        メモリは自動フォーマットにより内容が消去されたあとコピーが始まる。時間は結構かかる(ISOイメージを作る以上に)。
      このUSBメモリが(インストール用)ブートデバイスになる。
    3. 2011ではBOOTCAMPでWindows用ドライバをダウンロードして、別のUSBメモリに保存する。同じメモリだとブートできなくなる。2014/Yosemiteでは(選択する必要はなく)自動的に同じメモリにドライバも入れる。故に、Marvericksまでで作ったisoイメージUSBメモリはYosemiteでは使えない。作りなおす必要がある。BootCampのメニュー上には別USBメモリにドライバを入れる選択項目があるが、それを使って別メモリにドライバを入れ、それをUSBのほかポートに指しているとWindowsのインストールが出来ないという罠である。
    4. BOOTCAMPで「Windows7をインストール」を選択する。これもYosemiteでは不要で、自動的に起動される。
    5. 最新版のBootCamp(5.1.5759)はWindows7に対応できていないので、Windows起動後の初期設定中に「Windows\system32\drivers\AppleSSD.sys このファイルのデジタル署名を検証できません」と出て先に進まない。なので、以下の対策が必要。
      (5-1)1つ前のバージョン(5.1.5640)のBootCampをここからダウンロードしてくる。
      (5-2)USBメモリをFilderで開き、$WinPEDriver$フォルダを削除する。
      (5-3)ダウロードしてきたBootCampを展開する
      (5-4)その中の$WinPEDriver$をUSBメモリにコピーする
      ここで、BootCampフォルダはコピーしない。5640はMacMini2014に対応してないから。2011ならBootCampフォルダも置き換えたほうが良いのかもしれないが、未検証。
    6. Windows用パーティションサイズを設定し、「インストール」を押す
    7. (パーティション設定が終わったら)自動的に再起動がかかる
      このとき、キーボードを差し込んでおかないとWindowsインストーラーが起動しないかもしれない(うちではそうだった)。
    USBからWindowsのインストーラーが起動して、無事インストール画面になる。


    とにかく、2011ではUSBに起動順があることを知ってないとはまる。
    USB-DVDからでも起動できないのが事態をさらにややこしくしている。
    (USB-DVDドライブの中にはMacのUSBバスパワーでは動かずインストールには使えない物があるらしいが、今回の件にはそれは関係ない。ACコンセント付きの物で試したから。)
    2014では、2011までと同じやり方でやると失敗するので要注意。これがわかるのに2週間も無駄にしてしまった。
    さらに、最新版のBootCampではWindows7対応にバグがあるというお粗末さ。Appleは検証が絶対的に甘すぎる。

    ・・・
    この先はWindows7のインストール。
    基本的には普通通りなのだが、Macで作業する上で注意する点がある。
    1. 2014ではキーボードとマウスは有線の物が必須。BluetoothはWindows側でドライバがインストールされるまで使えなくなるから。マウスはなくてもキーボードで操作できるが(それがWindowsの良い所)、キーボードが効かないとどうしようもなくなる。
    2. Windowsの入ったUSBメモリはポート1に指す。2011でも、Windowsドライバの入ったUSBメモリはこの時点ではどのポートにも刺していてはいけない。HDDや光学ドライブも同様。要するに、この時点でUSBポートに指していいのは、1にWindowsの入ったメモリ、他はキーボードとマウスのみとなる。
    3. Windows上で新規インストールをすると、まずは「どこのパーティションに入れるか」聞いてくるので、「ディスク0:パーティション4:BootCamp」を選ぶ。すると、「ここにはインストール出来ない」と言ってくるので、「ドライブオプション(詳細)」からフォーマットを選択する。このパーティションを再フォーマットしてインストール可能にする。
    4. フォーマットはすぐ終了するので「次へ」を押す。この時点で「新しいシステムパーティションを作成できなかったか、既存のシステムパーティションが見つかりませんでした」エラーが出るときは、USBにドライバの入ったメモリやHDDなどが刺さってないか確認する。Windowsは、インストール時に(物理的な)複数ドライブを発見するとこのエラーを発生させる。なので、インストール時には絶対に1ドライブしか接続していてはいけない(インストールディスクの入ったドライブは除く)。Mac mini 2011ではこんなことなかった気がするのだが、2014では発生するので要注意。
    5. インストールが終わり、Windowsが正常起動したら初期設定を行う。此処から先、Windowsが起動してドライバの設定が終わるまではBluetooth機器が使えない。ドライバが入ってないからである。Bluetoothマウスやキーボードが使えない理由はこれ。
    6. 2014(というかYosemiteで作ったメモリ)では初期設定が終わると自動的にBootCampインストーラーが起動しドライバ群がインストールされ、その後再起動する。2011ではドライバをSETUPする。終わったら、USBメモリを外し、再起動する。
      これをしないとディスプレイドライバが標準のままなので、画面の解像度変更とか2画面とかが出来ないし、 ネットワークも繋がらない。このあたりがWindows純正メーカー品との違い。こういう作業に慣れてないと出来ないと思う。
      Bluetooth機器はペアリングが切れるので、コントロールパネルから再ペアリングが必要(2014ではそうだった)。
    7. ここでも注意すべきは、2011では、USB1にはUSBメモリ/DVDドライブ/HDDをつながないことである。起動しなくなる。USB2~4につないでいる状態では起動するので、基本的に、USB1にはキーボードやマウスなど、起動に関係ないデバイスをつなぎ、USB2~4にHDDや光学ドライブを接続することになる。当然、Windows上でReadyBoostをUSBメモリに作る場合もUSB1に接続してはいけない。なお、HUBをつないでいても状況は同じである。2014では問題ない。
    なお、インストールを途中で中断すると、以後Macが全く起動できなくなる。Command+Rでの復元起動も効かない。この場合は、Option+Command+P+RでNVRAMクリアすれば起動できるようになる。ただし、MacOS部分が破壊されている場合はやはり起動に失敗するので、Command+Rで復元する。このとき、TimeMachineバックアップがあれば、復元がとても楽になる。

    ・・・

    以上のことを知っていれば、Mac mini 2011でも2014でもBootCampによるWindows7環境を作成できる。なんにしても、Appleの説明は情報が足りない。

    ここで言えることは、「MacをWindows機にして使おうなんて、普通の人は思わないほうがいい」である。 価格対性能比(およびデザイン)では決して悪くないが、やはりWindows機とは異なるので壁が高い。
    この最初のWindows環境の構築だけでなく、他にもいろいろと問題がある。それについては別の記事にする。「労多くして益少なし」まさにこのことを言う。反省。
    Appleにしてみれば、BootCampはおまけであって、完全ではなくても文句は言わないで、というところだろう。

    以下は2011での話。
    ・・・2013/02/16
    MountainLion用に更新Mac mini(mid2011) EFIファーム v1.6のアップデートで、「USB記憶装置がホットプラグされている時の起動装置の選択の問題が解決される」は、本当に解決されたようである。

    コメントにも頂いたとおり、Option(Windowsキーボードの場合はAlt)を押したまま再起動すると、起動メディア選択ができる(事を確認した)。たぶんファームアップデートで改善されたというのがこれのことだと思う。この時はUSB-DVDドライブに入っているWindowsインストールディスクからの起動もできた。USB1でなくてもOKだった(USB1以外につないでいる場合)。

    ただし、 USB-DVDにWindowsディスク、USBメモリにWindowsを入れたものを挿していると、どちらかを起動選択しても、なぜか両方とも起動できないので注意。

    2012年2月5日日曜日

    Windows7 on VMware Fusion4

    VMware Fusion4には「キーボードの認識が常にUSになる」というバグがいる。
    このため、Fusion4上でWindows7を動かす場合も、日本語キーボードだと配置が合わないという問題が発生する。

    それを解消する方法。
    1. VMwareを完全に終了しておく
    2. SpotLightで「仮想マシン」で検索
    3. Windows 7 x64.vmwarevmというファイルで右クリック、パッケージの内容を表示(32bit版の時はx64は「ない」)
    4. Windows 7 x64.vmxでこのアプリケーションで開く~適当なテキストエディタで開く
    5. 一番最後の行にkeyboard.vusb.idProduct = "0x222"と追加し、改行、ファイルを保存
    6. VMWare~Windows7を再起動
    7. Windows上で、コントロールパネル~キーボード~ハードウエア~プロパティ~ドライバー~ドライバーの更新
    8. コンピューターを参照してドライバーソフトウエアを検索します~コンピューター上のデバイスドライバー一覧から選択します
    9. 「互換性のあるハードウエアを表示」のチェックを外す
    10. (標準キーボード)の中から「日本語PS/2キーボード 106/109 Ctrl+英数」を選択、次へ
    11. 警告メッセージが出るが「はい」でインストール続行
    12. Windowsを再起動

    これで日本語キーとして正しく認識されるようになる。Lionと違い「|\」と「_ろ」も正しく入力できる。

    ・・・

    さて、うちではMacにもWindowsのキーボードをつなぎ、Mac上ではCommandとControlの位置をKeyRemap4で入れ替えている。また、Windows上ではCapsLockとCtrlを入れ替えている。
    CommandとControlの位置入れ替えだけなら、キーボード~修飾キーの設定で入れ替えられるが、他のキーも変更しようと思うとKeyRemap4が必須であり、またKeyRemap4を入れているとこの修飾キーの設定は無視される。

    こういうことをしていると、Windows上でCtrlとWinのキーが入れ替わってしまう問題が発生する。
    調べてみると、CTRL+←/→を押すと正しくCTRL+←/→と返すのに、CTRL+アルファベットを押すとWin+アルファベットと返してくるという変な現象が発生している。

    これを回避するには、KeyRemap4で、Fusionには入れ替えてない状態のキーを渡すようにすればよい。

    private.xmlに次の内容相当を追記してReloadする。
    <?xml version="1.0"?>
    <root>
      <appdef>
        <appname>VMware</appname>
        <equal>com.vmware.fusion</equal>
      </appdef>
      <item>
        <name>Control_R to Command_R (except VMware)</name>
        <identifier>private.app_vmware_control_r_to_command_r</identifier>
        <not>VMware</not>
        <autogen>--KeyToKey-- KeyCode::CONTROL_R, KeyCode::COMMAND_R</autogen>
      </item>
      <item>
        <name>Control_L to Command_L (except VMware)</name>
        <identifier>private.app_vmware_control_l_to_command_l</identifier>
        <not>VMware</not>
        <autogen>--KeyToKey-- KeyCode::CONTROL_L, KeyCode::COMMAND_L</autogen>
      </item>
      <item>
        <name>Command_L to Control_L(except VMware)</name>
        <identifier>private.app_vmware_command_l_to_control_l</identifier>
        <not>VMware</not>
        <autogen>--KeyToKey-- KeyCode::COMMAND_L, KeyCode::CONTROL_L</autogen>
      </item>
    </root>
    

    これで、思惑通りのキー操作ができるようになる。
    なお、Fusion上に複数のWindows環境を入れている場合、これ1つですべてに有効である。

    Command-L/Control-Lに関してはKeyRemap4に元からexcept Virtual Machineという似たような設定があるが、それを設定してもうまく動かなかった。Fusion4には対応していないのかもしれない。

    実はこの状態でも「全角/半角」を押しても日本語入力できないという問題が残る。
    これに関しては、Windows上のキー配置変更ツール(chgkeyなど)で、「カタカナ・ひらがな→全角/半角」(逆ではないので注意)の変更を入れる。

    ただし、この変更をしても、Mac側が日本語入力モードになっているとWindowsで「全角/半角」が効かない。
    キーが効かないときは、Macの日本語入力モードを確認のこと。

    これで、WindowsとMacでほぼ同じキー操作ができるようになった。

    「そもそもWindows上でキーCtrlとWinを入れ替えればいいんじゃないか」と思われるかもしれないが、先に書いたとおり、返されてくるCtrlとWinのキーコードが場合によって異なるのでうまくいかない。
    だからホストとなるMac側で変更しなければならない。このあたりはさんざんやったから間違いなし。

    CTRL+←/→や一部ファンクションキーはデフォルトではMac側にとられる場合があり、Windowsに渡すことができない。
    この場合、環境設定~キーボード~キーボードショートカットを変更する。
    private.xmlにさらに書き加えれば両立出来るかもしれないが、そこまでは必要を感じてないので省略。

    いや、KeyRemap4MacBookは本当によく出来ている。
    英語だけなのでちょっとわかりにくいけど。











    Lion on VMware Fusion4

    VMware Fusion4には「キーボードの認識が常にUSになる」というバグがいる。
    このため、Fusion4上でLionを動かす場合、日本語キーボードだと配置が合わないという問題が発生する。

    それを改善する方法。

    1. VMwareを完全に終了しておく
    2. SpotLightで「仮想マシン」で検索
    3. OS X 10.7(64ビット).vmwarevmというファイルで右クリック、パッケージの内容を表示
    4. OS X 10.7(64ビット).vmxでこのアプリケーションで開く~適当なテキストエディタで開く
    5. 一番最後の行にkeyboard.vusb.idProduct = "0x222"と追加し、改行、ファイルを保存
    6. Lion Xを再起動

    これで、「|\」と「_ろ」以外のキーは全て正しい配置になる。
    しかし、この2つだけは入力が出来ない。
    KeyRemap4MacBookを使ってこれを強引に入力できるようにする。

    private.xmlに次の内容相当を追記してReloadする。
    <?xml version="1.0"?>
    <root>
     <item>
        <name>Swap F14 and BackSlash</name>
        <identifier>private.swap_F14_and_BackSlash</identifier>
        <autogen>--KeyToKey-- KeyCode::F14, KeyCode::VK_JIS_BACKSLASH</autogen>
     </item>
     <item>
        <name>Shift(L)+0=Underscore</name>
        <identifier>private.shift0L_to_Underscore</identifier>
        <autogen>--KeyToKey--
      KeyCode::KEY_0, ModifierFlag::SHIFT_R,
      KeyCode::JIS_UNDERSCORE
        </autogen>
     </item>
     <item>
        <name>Shift(R)+0=Underscore</name>
        <identifier>private.shift0R_to_Underscore</identifier>
        <autogen>--KeyToKey--
      KeyCode::KEY_0, ModifierFlag::SHIFT_L,
      KeyCode::JIS_UNDERSCORE
        </autogen>
     </item>
    </root>
    

    これを読み込ませてチェックすることにより、「\」でバックスラッシュ、SHIFT+0で「_」を入力できるようにする。
    バックスラッシュでなく「\」そのものを入力したいときは、VK_JIS_YENにすればよい。
    これで、Lion上でのプログラム開発も「できなくはない」状態になる。

    しかしまだ、Lion上ではファンクションキーの設定ができない。
    キーボードショートカット設定でファンクションキーに設定しても一切効いてない。
    KeyRemap4でもキーを認識してくれないので再設定しようがない。
    VMware Fusion~環境設定~キーボードとマウス~キーマッピングでも設定できない。

    あとはVMWareFusion側で正式に対応されるのを待つしかない。
    が、私も前にサポートに連絡を入れたが、いっこうに改善される気配がない。
    開発元はUSなので、気がつかないのかもしれない。
    (ひょっとしたらBluetoothキーボードでは大丈夫?)
    だったら日本の窓口act2が何とかしろ!と思うのだが。

    Fusion4によって、Lion対応というのは表面上の宣伝文句に過ぎず、現状では使い物にならない。
    と、言われても仕方ないと思うのだが。