Windowsで言うところの「スタートアップ」のMacOS MoutainLionでの位置。
システム環境設定〜ユーザーとグループ〜ユーザーを選択〜ログイン項目
で設定する。
2013年3月13日水曜日
2013年3月6日水曜日
Windows7←Macファイル共有が出来ないとき
MacからWindows7側のファイルを共有しようとしてできなかった時に、
Windows側で見るべき項目。
共有対象とするフォルダやファイルの共有設定は当然しているが、それでも共有できないとき。
（１）コントロールパネルから「ネットワークと共有センター」
（２）ネットワーク接続図が出てくるので、左側の「アダプターの設定の変更」
（３）ローカルエリア設定（ネットワーク番号は異なる場合がると思う）
（４）ローカルエリアの接続の状況から「プロパティ」
（５）共有のタブ
（６）共有の設定をチェックしてOK。上側は必須、下側は随意で。
これでうまく行けば治る。
これでもダメなら、ウイルス駆除ソフトを一時的にOFFしてどうなるか調べる。
ちなみに、ウイルスバスタークラウド（2012）はONにしてても大丈夫。
まあ、今時のそれらでファイル共有設定も通せないようなダメなのはないと思うけど。
（昔はあった。）
Windows側で見るべき項目。
共有対象とするフォルダやファイルの共有設定は当然しているが、それでも共有できないとき。
（１）コントロールパネルから「ネットワークと共有センター」
これでうまく行けば治る。
これでもダメなら、ウイルス駆除ソフトを一時的にOFFしてどうなるか調べる。
ちなみに、ウイルスバスタークラウド（2012）はONにしてても大丈夫。
まあ、今時のそれらでファイル共有設定も通せないようなダメなのはないと思うけど。
（昔はあった。）
2013年2月27日水曜日
「手習い君」が「Appliv」にて紹介されました。
「手習い君」が「Appliv」にて紹介されました。
「手習いくん」は、手本の文字をなぞって練習するアプリです。
般若心経の写経から小学生の漢字やアルファベットの練習も出来ます。
内蔵手本だけでなく、ユーザーが作成した手本も入れることが出来ます。
手書きの内容は、メールで送ったり、AirPrintで印刷することが出来ます。
・・・
「手習い君」へのご意見ご要望は、これにコメントでどうぞ。
「手習いくん」は、手本の文字をなぞって練習するアプリです。
般若心経の写経から小学生の漢字やアルファベットの練習も出来ます。
内蔵手本だけでなく、ユーザーが作成した手本も入れることが出来ます。
手書きの内容は、メールで送ったり、AirPrintで印刷することが出来ます。
 |
| 手習い君 |
・・・
「手習い君」へのご意見ご要望は、これにコメントでどうぞ。
2013年2月26日火曜日
MacでWindows用テンキーを使う
MacOS X MoutainLionでWindows用テンキーを使ってみた。
本体は、iMac 2011とMac mini2011。
テンキーは、ELECOMのTK-UFHとTK-TCM003。
結論から言えば「ほぼ使える」。ただし、少し注意がある。
（１）NumLockは解除しておく
WindowsではNumLockをONにしておかないと数字入力できないが（OFFだとカーソルキーなどになる）、Macで使うにはNumLockをOFFにしておかないと正常に数字入力できない（OnだとClear＋数字が入力されてくるので）。
MacにはNumLockという考え方がないからだろう。
（２）「００」は入力できない
まあこれは仕方ないと諦めるしかない。
キーコードが分からないので、KeyRemap4MacBookを使っての変換もできない。
なお、他のキーはすべて有効である。
（３）BootCampでWindowsとMacで共有する場合、先にMacで認識させ、あとでWindowsで認識させる。
というか、挿した後はMac→Windowsの順で起動する。そうしないと、Windowsが起動しなくなることがある。Bluetoothマウスとは逆。
というところ。(1)のNumLock解除が肝。
当然のことであるが、BootCampのWindows上では、NumLockはONしないと数字入力できないし、「００」は入力できる。
Mac用テンキーは（処分品以外）2000円を超えてたりするので、実売500円程度で手に入る事もできるWindows用のテンキーが使えるなら、ありがたい。
もっとも私の場合、Macでテンキーが必要になるようなことはほとんど無いのだけど。
（そういう処理はWindowsで行うから。）
本体は、iMac 2011とMac mini2011。
テンキーは、ELECOMのTK-UFHとTK-TCM003。
結論から言えば「ほぼ使える」。ただし、少し注意がある。
（１）NumLockは解除しておく
WindowsではNumLockをONにしておかないと数字入力できないが（OFFだとカーソルキーなどになる）、Macで使うにはNumLockをOFFにしておかないと正常に数字入力できない（OnだとClear＋数字が入力されてくるので）。
MacにはNumLockという考え方がないからだろう。
（２）「００」は入力できない
まあこれは仕方ないと諦めるしかない。
キーコードが分からないので、KeyRemap4MacBookを使っての変換もできない。
なお、他のキーはすべて有効である。
（３）BootCampでWindowsとMacで共有する場合、先にMacで認識させ、あとでWindowsで認識させる。
というか、挿した後はMac→Windowsの順で起動する。そうしないと、Windowsが起動しなくなることがある。Bluetoothマウスとは逆。
というところ。(1)のNumLock解除が肝。
当然のことであるが、BootCampのWindows上では、NumLockはONしないと数字入力できないし、「００」は入力できる。
Mac用テンキーは（処分品以外）2000円を超えてたりするので、実売500円程度で手に入る事もできるWindows用のテンキーが使えるなら、ありがたい。
もっとも私の場合、Macでテンキーが必要になるようなことはほとんど無いのだけど。
（そういう処理はWindowsで行うから。）
2013年2月24日日曜日
Macの「メモ」のバグ
Macの「メモ」はiCloudで同期していてなかなかに使い手があるのだけど、
バグがいる。
・メモを独立したウインドウで開いている時にそれをメインウインドウのリストから削除しようとするとハングアップする
メモはリストでダブルクリックすると別ウインドウで開くけど、この状態で削除しようとすると落ちるわけである。意図的にダブルクリックをしないでも、リスト中から選択した時にそうなる場合も多いので、まれではなく結構陥りがちな現象である。
アップルは、もう少し各アプリのデバッグをした方がいいと思われる。
いつものことだけど。
バグがいる。
・メモを独立したウインドウで開いている時にそれをメインウインドウのリストから削除しようとするとハングアップする
メモはリストでダブルクリックすると別ウインドウで開くけど、この状態で削除しようとすると落ちるわけである。意図的にダブルクリックをしないでも、リスト中から選択した時にそうなる場合も多いので、まれではなく結構陥りがちな現象である。
アップルは、もう少し各アプリのデバッグをした方がいいと思われる。
いつものことだけど。
Apple-KeyboardのUSBハブの問題
Apple純正のUSBキーボードにはUSBポートが付いている。
左右各１つ。
ところが、こいつの電流許容量が極めて低い。
左右に、光学マウスとUSBメモリを挿しただけでも「電流許容量を超える」と警告が出る。
また、ここはWHSの復旧ディスクでは検索対象にならない。
特殊なハブなのかもしれない。
いくらおまけのUSBポートでも、これはいくらなんでもダメだと思うので、
アップルにはちゃんとした製品づくりをしてほしいものである。
まあ、それなら「取っ払う」が正解なのだろうけど。
・・・追記
Mac mini2011に接続しての話だったんだけど、そもそもそれのUSBポート自体の給電能力が、USB2の規格に反して低いような気もする。本来バスパワーで動くはずのDVDドライブが動かなかったりするし。
ちなみにUSBの給電能力規格はUSB2.0では5Vの500mAで、キーボードはだいたいの機種が１００ｍＡと結構電流を食っている。 自分で電源を入れているＨＤＤなどは5mA程度しか流れない。USBカードリーダーは400mAと予想以上に食っている。あくまでデバイスドライバレベルで検出できる電流量なので、実際はどうかわからないけど。
Windows7のドライバーのプロパティーでは各USBデバイスの消費電力まで見えるので、
細かく見ていけばもっと詳細、というか原因デバイスの特定も出来るかもしれないけど面倒。
このフリーウエアを使えばもう少し楽に調べられるかも。
USBDeview
http://www.nirsoft.net/utils/usb_devices_view.html
左右各１つ。
ところが、こいつの電流許容量が極めて低い。
左右に、光学マウスとUSBメモリを挿しただけでも「電流許容量を超える」と警告が出る。
また、ここはWHSの復旧ディスクでは検索対象にならない。
特殊なハブなのかもしれない。
いくらおまけのUSBポートでも、これはいくらなんでもダメだと思うので、
アップルにはちゃんとした製品づくりをしてほしいものである。
まあ、それなら「取っ払う」が正解なのだろうけど。
・・・追記
Mac mini2011に接続しての話だったんだけど、そもそもそれのUSBポート自体の給電能力が、USB2の規格に反して低いような気もする。本来バスパワーで動くはずのDVDドライブが動かなかったりするし。
ちなみにUSBの給電能力規格はUSB2.0では5Vの500mAで、キーボードはだいたいの機種が１００ｍＡと結構電流を食っている。 自分で電源を入れているＨＤＤなどは5mA程度しか流れない。USBカードリーダーは400mAと予想以上に食っている。あくまでデバイスドライバレベルで検出できる電流量なので、実際はどうかわからないけど。
Windows7のドライバーのプロパティーでは各USBデバイスの消費電力まで見えるので、
細かく見ていけばもっと詳細、というか原因デバイスの特定も出来るかもしれないけど面倒。
このフリーウエアを使えばもう少し楽に調べられるかも。
USBDeview
http://www.nirsoft.net/utils/usb_devices_view.html
MacからWindowsのHDDへ書き込む方法
MacOS(MoutainLion)は、WindowsのNTFSでフォーマットされたHDDの内容を読むことができる。
しかし、書き込みはできない。
異なるファイルシステムなので、安全策なのかもしれない。
しかし、せっかくBootCampでWindwosとシステム共有しているのにファイルのやり取りが直に出来ないのは、いかにも面倒である。
それを解決するソフトに「Paragon NTFS for Mac OS」というのがある。
Paragon NTFS for Mac OS X 10 [ダウンロード]
現在はバージョン１０。
同社のサイトでも購入できるが、Amazonのダウンロードで購入するのが一番安い。
これを入れると、Mac側からWindowsのNTFS領域にも自由に読み書きできる。
しかも、MacのHDD領域に読み書きするより多分に速い。
MacのファイルシステムHFS+はNTFSより堅牢ではあるけど、だいぶ遅い。
速度を求めるなら、積極的にNTFS領域を使うのも良いと思う。
安いので、導入しておいて損はない。
なお1つ注意があって、これを導入すると、MacOSシステム環境〜起動ディスクの設定からWindowsが消えてしまう。Windowsから起動するときは、Paragon NTFS for Mac OS X 10の設定〜詳細で起動ディスクとしてBOOTCAMP（＝Windows）を選択しなければならない。
ひょっとしたら、TimeMachineによるバックアップ対象にも出来るかもしれないのだけど、それはまだ未検証。
前にも書いたが、Wincloneでディスクイメージを作る際の保存先にNTFS領域を指定すると必ずエラーが出る。
それはこのドライバーを入れても解決できないので、Wincloneがなにか特別なことをやっているのだと思う。
・・・
逆のWindowsからMacのHDD領域の書き込みはどうかというと、これも読み込みは出来るが書き込みできない。
これを可能にするのに、同社のParagon HFS+ for Windows 9というのがある。こっちのほうがちょっと高い。
Paragon HFS+ for Windows 9 (NTFS for Mac OS X 10 試用版付き) [ダウンロード]
こちらは導入していない。Win→Macで書き込まなくても、Win側にあるのをMacで読みだしてやればいいじゃんという考えである。
・・・補足
FATでフォーマットしているHDDに関しては、多分ドライバー無しにアクセスできる。
SDで可能だったから。
しかし、書き込みはできない。
異なるファイルシステムなので、安全策なのかもしれない。
しかし、せっかくBootCampでWindwosとシステム共有しているのにファイルのやり取りが直に出来ないのは、いかにも面倒である。
それを解決するソフトに「Paragon NTFS for Mac OS」というのがある。
Paragon NTFS for Mac OS X 10 [ダウンロード]
現在はバージョン１０。
同社のサイトでも購入できるが、Amazonのダウンロードで購入するのが一番安い。
これを入れると、Mac側からWindowsのNTFS領域にも自由に読み書きできる。
しかも、MacのHDD領域に読み書きするより多分に速い。
MacのファイルシステムHFS+はNTFSより堅牢ではあるけど、だいぶ遅い。
速度を求めるなら、積極的にNTFS領域を使うのも良いと思う。
安いので、導入しておいて損はない。
なお1つ注意があって、これを導入すると、MacOSシステム環境〜起動ディスクの設定からWindowsが消えてしまう。Windowsから起動するときは、Paragon NTFS for Mac OS X 10の設定〜詳細で起動ディスクとしてBOOTCAMP（＝Windows）を選択しなければならない。
ひょっとしたら、TimeMachineによるバックアップ対象にも出来るかもしれないのだけど、それはまだ未検証。
前にも書いたが、Wincloneでディスクイメージを作る際の保存先にNTFS領域を指定すると必ずエラーが出る。
それはこのドライバーを入れても解決できないので、Wincloneがなにか特別なことをやっているのだと思う。
・・・
逆のWindowsからMacのHDD領域の書き込みはどうかというと、これも読み込みは出来るが書き込みできない。
これを可能にするのに、同社のParagon HFS+ for Windows 9というのがある。こっちのほうがちょっと高い。
Paragon HFS+ for Windows 9 (NTFS for Mac OS X 10 試用版付き) [ダウンロード]
こちらは導入していない。Win→Macで書き込まなくても、Win側にあるのをMacで読みだしてやればいいじゃんという考えである。
・・・補足
FATでフォーマットしているHDDに関しては、多分ドライバー無しにアクセスできる。
SDで可能だったから。
BootCamp領域のWindowsのバックアップ仕方
先の記事で述べたとおり、BootCampのWindows領域はWHSのバックアップでは復旧できない。
ではどうやってそのまるごとバックアップを取っておいたらいいか。
(ファイル単位のバックアップはいくらでも方法があるので書かない。)
まず最初に、すぐに考えられそうな方法について、その結果を述べておく。
・Windows7の持つバックアップ機能は非常に遅く、実用できない。
400GBで2時間かけて3％ってありえない速度。
MSもとりあえず付けただけで、絶対に実験とか社内で実用してないと思う。
一応パッチファイルも見つけたが、当てられなかった。だめじゃん。
・Windows領域（NTFS領域)はTimeMachineバックアップできない
という状況である。
そこで私がとったのは、「Winclone」というアプリを使う方法である。
WincloneとはMac上でBootCampのWindows領域をまるごとバックアップできるプログラムである。
以前は無償だったらしいが、現在は有償になっている。ただしその分安定し、日本語にも対応している。個人で使うには「Indivisual」で$19.99である。
これを使えば、BootCamp領域のWindowsをまるごとバックアップでき、そのイメージファイルを使えば、他のHDDやパーティションを拡大・（入るなら）縮小してもそれに合わせて再構築してくれる。
ただし、利用上にはいくつか注意もある。
・バックアップを保存する先はHFS+でフォーマットされたHDDかネットワーク先のドライブに限る。
MacOSからNTFSのHDDに書き込みできるドライバーを導入していても、NTFS-HDDへ保存すると初期段階でエラーが発生する(しかもフォルダーにカスが残る)。
・なにせ最低でも10GB単位なのでかなり時間が掛かる。しかも、この間その書き出し対象ディスクに対して(数多い)読み書きをすると途中でエラーを発生することがあるので、基本、夜中など他の作業をしない時間帯に走らせたほうが良い
・バックアップから戻すときも、戻すドライブに対して読み書きを余りしないほうが良い。していると、展開直後にエラーを発生したりすることがある。こちらも当然ながら、非常に時間が掛かる。
・まるごとバックアップのみなので、差分記録はできない。
そのため、毎日とか定期保存には向かない。
・Wincloneで戻したWindows領域はMac側から起動対象ディスクとして認識されないことがある。
具体的には、システム環境設定の起動ディスクの一覧に出てこない。
そのため、Option（またはAlt）キー押し起動で起動デバイスとしてWindowsを選択し、Windows内のBootCamp設定で「Windowsから起動する」に設定する必要がある。
これをしないと、毎回Option(alt)押し起動するハメになる。
これはWincloneの問題ではなく、Paragon NTFSの所業と判明。
・途中でエラーが出て止まってしまう時は、ディスクユーティリティで「ディスクの修復」および「アクセス権の修復」をかけると治る事がある
Windows７のPro以上のモデルではファイルやフォルダの暗号化が出来るが、これを設定していると、戻したディスク上で読めなくなる可能性がある。設定時に解除キーを確実な場所に保存し、それを覚えておけばいいが、それを忘れた場合、全く戻す手法がなくなってしまう。
アタッシェケースなど、どこでも復号できるソフト暗号化のほうが良い。
私は今回これで３日無駄にした。
とにかく、Windowsの構築が終わったらWincloneでまるごとバックアップを取る、
ユーザーファイルは別途Windows上でバックアップしておくがが重要である。
・・・とは書いたものの、Windows上にもまるごとバックアップを取ることが出来るアプリケーションがあるのではないか、という気はせんではない。いやあるだろう。フリーウエアでもあるかもしれない(^_^;)。
ではどうやってそのまるごとバックアップを取っておいたらいいか。
(ファイル単位のバックアップはいくらでも方法があるので書かない。)
まず最初に、すぐに考えられそうな方法について、その結果を述べておく。
・Windows7の持つバックアップ機能は非常に遅く、実用できない。
400GBで2時間かけて3％ってありえない速度。
MSもとりあえず付けただけで、絶対に実験とか社内で実用してないと思う。
一応パッチファイルも見つけたが、当てられなかった。だめじゃん。
・Windows領域（NTFS領域)はTimeMachineバックアップできない
という状況である。
そこで私がとったのは、「Winclone」というアプリを使う方法である。
WincloneとはMac上でBootCampのWindows領域をまるごとバックアップできるプログラムである。
以前は無償だったらしいが、現在は有償になっている。ただしその分安定し、日本語にも対応している。個人で使うには「Indivisual」で$19.99である。
これを使えば、BootCamp領域のWindowsをまるごとバックアップでき、そのイメージファイルを使えば、他のHDDやパーティションを拡大・（入るなら）縮小してもそれに合わせて再構築してくれる。
ただし、利用上にはいくつか注意もある。
・バックアップを保存する先はHFS+でフォーマットされたHDDかネットワーク先のドライブに限る。
MacOSからNTFSのHDDに書き込みできるドライバーを導入していても、NTFS-HDDへ保存すると初期段階でエラーが発生する(しかもフォルダーにカスが残る)。
・Winclone(４まで)には致命的とも言える問題があって、対象とするBootcamp領域のNTFSにエラーがあってはいけない＝chkdskでエラーがない状態でなければならない。NTFS領域もMacのディスクユーティリティのディスクの修復で多くの場合修復可能であるが、一部見逃されるものがあり、それはWindows上でchkdskして修復するしかない。しかし、Bootcamp領域は以下の理由により殆どの場合かけられない。
１．Bootcamp領域はC:ドライブ(システムドライブ)である
２．chkdskは、システムドライブに対しては修復付きの実行はできないため、再起動時に実行されるよう予約される(チェックだけならできる)
３．ところが、その予約実行時に「An unspecified error occurred (766f6c756d652e63 3f1)と表示されて止まってしまう
４．これはパーティション情報が異常になっている(とWindowsが判断した)時に発生するものらしい。１パーティションしかないHDDでは発生しないと思われるが、Bootcamp環境では必ず２パーティション(以上)存在するので発生しやすい
５．バックアップを取り、パーティションを切り直して復元すれば治るらしいが、そもそもそのバックアップが取れないのでどうしようもない
そのエラーが出たままでもWindowsとしての動作にはなんの問題もない。
ということで、このエラーが出た場合はWincloneは使えなくなる。
ひょっとしたら、Linux上にあるNTFSのパーティション情報修復ツールを使えば治るのかもしれないが、今のところMac上で起動できるLinuxをうまく構築できてないので未検証。
・なにせ最低でも10GB単位なのでかなり時間が掛かる。しかも、この間その書き出し対象ディスクに対して(数多い)読み書きをすると途中でエラーを発生することがあるので、基本、夜中など他の作業をしない時間帯に走らせたほうが良い
・バックアップから戻すときも、戻すドライブに対して読み書きを余りしないほうが良い。していると、展開直後にエラーを発生したりすることがある。こちらも当然ながら、非常に時間が掛かる。
・まるごとバックアップのみなので、差分記録はできない。
そのため、毎日とか定期保存には向かない。
これはWincloneの問題ではなく、Paragon NTFSの所業と判明。
・途中でエラーが出て止まってしまう時は、ディスクユーティリティで「ディスクの修復」および「アクセス権の修復」をかけると治る事がある
Windows７のPro以上のモデルではファイルやフォルダの暗号化が出来るが、これを設定していると、戻したディスク上で読めなくなる可能性がある。設定時に解除キーを確実な場所に保存し、それを覚えておけばいいが、それを忘れた場合、全く戻す手法がなくなってしまう。
アタッシェケースなど、どこでも復号できるソフト暗号化のほうが良い。
私は今回これで３日無駄にした。
とにかく、Windowsの構築が終わったらWincloneでまるごとバックアップを取る、
ユーザーファイルは別途Windows上でバックアップしておくがが重要である。
・・・とは書いたものの、Windows上にもまるごとバックアップを取ることが出来るアプリケーションがあるのではないか、という気はせんではない。いやあるだろう。フリーウエアでもあるかもしれない(^_^;)。
BootCampでWindows環境を構築するときの問題と解決方法
Mac上にBOOTCAMPで構築していたWindows領域のパーティションを変更して容量を増やそうとした。その過程でWindows領域だけでなくMac領域まで破壊されてしまい、復旧に約1週間もかかる羽目になった。
Windows領域のパーティション変更方法については別途書くとして、ここではまず
「BootCampでWindows環境を構築するときの問題」を書いておきたい。
結論から言えば、やはり「普通の人は素直にWindows機を買ったほうがいい」。
BootCampによるWindows環境の構築は、導入からして大変だし、いざというときの復旧にも非常に苦労が必要となる。AppleにすればBootCampはおまけにすぎないし、Microsoftにしてもそんな特殊な環境知ったこっちゃないわけ（とは書いたが、実際にはマイクロソフト日本のサイトにはBootCampへのWindows7のインストール方法が詳しく説明されている。アップルよりよほど親切。）で、どちらからもサポートは期待できない。
で、その問題点。
・WindowsHomeServerによる、まるごと復旧が使えない
WindowsHomeServer(以下WHS)にはWindows領域をまるごとバックアップし、万が一PCが壊れても簡単に復旧できる機能がある。純正Windows機ではこれのお世話になりだいぶ楽ができた。が、BootCamp環境に対してはこれは使えない。
使えないどころか「MacOS領域も含め全て読めなくしてしまう」ので絶対に使ってはいけない。
WHSの PC復元は、どうやら常にHDDの先頭からにWindowsがあると想定しているらしく、BootCampのようにパーティションを切ってWindowsを入れている場合を想定していない。
しかも、パーティションがあるかどうかの判断を全くせず書き込んでしまう。そのため、HDD先頭にあるパーティション情報を破壊して、MacOS/Windows領域共に起動できなくしてしまう。
MacのHDD内には復元領域が用意されているが、これまで見えなくなる。
ではあるがMacの偉いところは、この状態になってもネットワークさえつながれば、アップルに接続してOSをダウンロードして復旧できることにある。
このネットワークリカバリーを使えばMacOSはかろうじて復旧できるので、あとはTimeMachineから戻せばMac領域は復元できる。
でもWindows領域は復元できないので、BootCampで一から再構築する必要がある。
WHSで自動バックアップをしていればユーザーファイルは（知識があれば）復旧可能だが、アプリケーションに関してはそれでは戻らない。フォルダのコピーだけで戻せるMacOSとは大違いで、この辺り、WindowsはDOS時代から何も変わっていない、というかむしろひどくなっている。
・起動HDDはCHKDSK出来ない
Windowsにはディスクの問題を検知・修復するCHKDSKコマンドがあるが、BootCampを入れているディスクでは必ずエラーが出てしまい、実行されない。
このエラーはMacOSとの同居によるものなので無視して良いが、他に本当にファイルの問題が発生していた場合、例えばファイル書込み中に電源が切れてディレクトリエントリが破壊された場合なども復旧ができないことになる。フリーウエアも探してみたが、Bootドライブに対するチェックには皆制限がついており、解決できるものは見つけられなかった。
一部のエラーに関しては、MacOS上のディスクユーティリティーで「ディスクの修復」もしくは「アクセス権の修復」をかけることで復旧できる。まさかNTFS領域まで対応しているとは思ってなかった。
（うちではParagon NTFS for Mac OSを導入しているからかもしれない。）
・Bluetoothマウスの共有には手順がある
BootCamp環境であれば、当然周辺機器はMacとWindowsで共有することになるが、
Bluetooth機器の共有には手順がある。
Macで解除、Winで登録、Macで再登録
である。Macで登録されているBluetooth機器はなぜかWindowsで登録できない。
Windowsインストール中は使えるのだが、一旦Windowsが正常起動するようになると、機器としては見つかるのに登録できないという状態になる。
この場合、先にMacOS上での登録を解除すると、Windows側で登録できるようになる。
それでまたMacに戻って再登録すると、双方で使える状態になる。
この作業中は有線USBマウスが必要である。Bluetoothマウスしかないときはどうにも出来ない。
・USB光学ドライブにメディアを入れっぱなしにしていると、Windows側で排出できなくなる
BootCampにしてから、Windows側でUSB光学ドライブ の排出ができなくなった。
入っているメディアはちゃんと読めるだが、「取り出し」しても排出されない。
どうも、「メディアを入れたままMacOSを終了すると、OSによってメディアがロックされていることをドライブが記憶してしまい、Windowsに移動しても排出命令を拒否する」ようである。
回避するには、
1. MacOS、終了時には必ずメディアを排出しておく
2. そもそもメディアを入れっぱなしにしない
しかない。もしなってしまったら、
1.強引にピンで排出するか、
2.一旦光学ドライブをUSBから抜いてまた挿し直す
をする。ピンで強制排出した場合は排出禁止そのものは解除されないので、
また排出するならピンを使う必要がある。
面倒。
→Windows終了時に光学ドライブを排出するフリーウエアを発見。
Removables Eject and Mount Intelligence
これを使えば、Windows上でしか使わないメディアであれば、Macで認識されて排出出来なくなることを一応防げる。本当はMac終了時に排出できるのがあれば良かったんだけど、見つけられなかった。
・同一USBハブ上に、キーボードとテンキーをさしていると、Windowsが起動しないことがある
Windows起動前の黒画面で止まってしまう。
まさかテンキーごときで引っかかると思ってなかったので、原因発見にえらく時間がかかった。別Hub（ポート）に指していると問題ないが、USB-HDDが USB1.1で接続されてしまうという別問題が発生することがある。こうなってしまう場合は、Windows起動後にテンキーを刺すしかない。
→USBキーボード/テンキーは先にMac→Windowsの順で認識させなければならないかもしれない。なんとなくそれで回避できたような気が。
→現在は、スイッチ付きUSBハブにテンキーを指すことで回避。面倒だし、OFFのまま起動し、そのままの状態でスリープすると、テンキーからスリープ解除できなくなるのが欠点（テンキーのドライバーがインストールされないから認識されない）。
・毎回Windowsで起動させるには、WindowsのBOOTCAMP設定でWindowsで起動を選択しておかなければならない。
Macは基本的にMacOSから起動しようとする。OptionまたはAltキーを押しながら起動すると起動OSが選択できるが、これはその時だけの設定であり、次回起動時にはまた戻ってしまう。毎回Windowsで起動できるようにするには、Windowsのコントロールパネル内にあるBootCamp設定で、「Windowsからの起動」を設定しておかなければならない。Mac側にも起動ディスクの設定はあるのだが、なぜかWindowsからの起動という項目がない。→この問題は、MacOSからNTFSへ書き込みを可能にする「Paragon NTFS for Mac OS」を導入していると発生すると判明。その設定〜概要でBOOTCAMP領域を起動ディスクとして指定、しなければならない。ただ、指定してもどこにもなんの印もつかないのでわかりにくい。ここは改善して欲しいところ。
・MacのUSB1（本体中央側）にはUSBメモリ、光学ドライブ、HDDをつないではいけない
そこから起動しようとし、必ず失敗する（キーも効かないので電源ボタン長押ししかない）。
これはBOOTCAMP導入のネタに書いたこと。
ということで、BootCampでWindows環境を構築した場合色々と問題があるので、
普通の人、と言うか、そのあたりを全て自己責任で解決できる心構えのある人以外は
絶対に手を出すべきではない、と言いたい。
ちなみに、VMwareFusion等でMacOS上にWindows環境を構築したほうがよほど楽。
というか、別記事のバックアップも含め、全ての問題が解決される。
ただし、それはかなり遅いので常用するには難がある。
やはり、Windowsを使いたいなら素直にWindows機を買うのが一番である、という結論に達した。費用や置き場の問題でどうしてもしょうがないのなら、覚悟の上でBOOTCAMPを使うと。
Windows領域のパーティション変更方法については別途書くとして、ここではまず
「BootCampでWindows環境を構築するときの問題」を書いておきたい。
結論から言えば、やはり「普通の人は素直にWindows機を買ったほうがいい」。
BootCampによるWindows環境の構築は、導入からして大変だし、いざというときの復旧にも非常に苦労が必要となる。AppleにすればBootCampはおまけにすぎないし、Microsoftにしてもそんな特殊な環境知ったこっちゃないわけ（とは書いたが、実際にはマイクロソフト日本のサイトにはBootCampへのWindows7のインストール方法が詳しく説明されている。アップルよりよほど親切。）で、どちらからもサポートは期待できない。
で、その問題点。
・WindowsHomeServerによる、まるごと復旧が使えない
WindowsHomeServer(以下WHS)にはWindows領域をまるごとバックアップし、万が一PCが壊れても簡単に復旧できる機能がある。純正Windows機ではこれのお世話になりだいぶ楽ができた。が、BootCamp環境に対してはこれは使えない。
使えないどころか「MacOS領域も含め全て読めなくしてしまう」ので絶対に使ってはいけない。
WHSの PC復元は、どうやら常にHDDの先頭からにWindowsがあると想定しているらしく、BootCampのようにパーティションを切ってWindowsを入れている場合を想定していない。
しかも、パーティションがあるかどうかの判断を全くせず書き込んでしまう。そのため、HDD先頭にあるパーティション情報を破壊して、MacOS/Windows領域共に起動できなくしてしまう。
MacのHDD内には復元領域が用意されているが、これまで見えなくなる。
ではあるがMacの偉いところは、この状態になってもネットワークさえつながれば、アップルに接続してOSをダウンロードして復旧できることにある。
このネットワークリカバリーを使えばMacOSはかろうじて復旧できるので、あとはTimeMachineから戻せばMac領域は復元できる。
でもWindows領域は復元できないので、BootCampで一から再構築する必要がある。
WHSで自動バックアップをしていればユーザーファイルは（知識があれば）復旧可能だが、アプリケーションに関してはそれでは戻らない。フォルダのコピーだけで戻せるMacOSとは大違いで、この辺り、WindowsはDOS時代から何も変わっていない、というかむしろひどくなっている。
・起動HDDはCHKDSK出来ない
Windowsにはディスクの問題を検知・修復するCHKDSKコマンドがあるが、BootCampを入れているディスクでは必ずエラーが出てしまい、実行されない。
このエラーはMacOSとの同居によるものなので無視して良いが、他に本当にファイルの問題が発生していた場合、例えばファイル書込み中に電源が切れてディレクトリエントリが破壊された場合なども復旧ができないことになる。フリーウエアも探してみたが、Bootドライブに対するチェックには皆制限がついており、解決できるものは見つけられなかった。
一部のエラーに関しては、MacOS上のディスクユーティリティーで「ディスクの修復」もしくは「アクセス権の修復」をかけることで復旧できる。まさかNTFS領域まで対応しているとは思ってなかった。
（うちではParagon NTFS for Mac OSを導入しているからかもしれない。）
・Bluetoothマウスの共有には手順がある
BootCamp環境であれば、当然周辺機器はMacとWindowsで共有することになるが、
Bluetooth機器の共有には手順がある。
Macで解除、Winで登録、Macで再登録
である。Macで登録されているBluetooth機器はなぜかWindowsで登録できない。
Windowsインストール中は使えるのだが、一旦Windowsが正常起動するようになると、機器としては見つかるのに登録できないという状態になる。
この場合、先にMacOS上での登録を解除すると、Windows側で登録できるようになる。
それでまたMacに戻って再登録すると、双方で使える状態になる。
この作業中は有線USBマウスが必要である。Bluetoothマウスしかないときはどうにも出来ない。
・USB光学ドライブにメディアを入れっぱなしにしていると、Windows側で排出できなくなる
BootCampにしてから、Windows側でUSB光学ドライブ の排出ができなくなった。
入っているメディアはちゃんと読めるだが、「取り出し」しても排出されない。
どうも、「メディアを入れたままMacOSを終了すると、OSによってメディアがロックされていることをドライブが記憶してしまい、Windowsに移動しても排出命令を拒否する」ようである。
回避するには、
1. MacOS、終了時には必ずメディアを排出しておく
2. そもそもメディアを入れっぱなしにしない
しかない。もしなってしまったら、
1.強引にピンで排出するか、
2.一旦光学ドライブをUSBから抜いてまた挿し直す
をする。ピンで強制排出した場合は排出禁止そのものは解除されないので、
また排出するならピンを使う必要がある。
面倒。
→Windows終了時に光学ドライブを排出するフリーウエアを発見。
Removables Eject and Mount Intelligence
これを使えば、Windows上でしか使わないメディアであれば、Macで認識されて排出出来なくなることを一応防げる。本当はMac終了時に排出できるのがあれば良かったんだけど、見つけられなかった。
・同一USBハブ上に、キーボードとテンキーをさしていると、Windowsが起動しないことがある
Windows起動前の黒画面で止まってしまう。
まさかテンキーごときで引っかかると思ってなかったので、原因発見にえらく時間がかかった。別Hub（ポート）に指していると問題ないが、USB-HDDが USB1.1で接続されてしまうという別問題が発生することがある。こうなってしまう場合は、Windows起動後にテンキーを刺すしかない。
→USBキーボード/テンキーは先にMac→Windowsの順で認識させなければならないかもしれない。なんとなくそれで回避できたような気が。
→現在は、スイッチ付きUSBハブにテンキーを指すことで回避。面倒だし、OFFのまま起動し、そのままの状態でスリープすると、テンキーからスリープ解除できなくなるのが欠点（テンキーのドライバーがインストールされないから認識されない）。
・
・MacのUSB1（本体中央側）にはUSBメモリ、光学ドライブ、HDDをつないではいけない
そこから起動しようとし、必ず失敗する（キーも効かないので電源ボタン長押ししかない）。
これはBOOTCAMP導入のネタに書いたこと。
ということで、BootCampでWindows環境を構築した場合色々と問題があるので、
普通の人、と言うか、そのあたりを全て自己責任で解決できる心構えのある人以外は
絶対に手を出すべきではない、と言いたい。
ちなみに、VMwareFusion等でMacOS上にWindows環境を構築したほうがよほど楽。
というか、別記事のバックアップも含め、全ての問題が解決される。
ただし、それはかなり遅いので常用するには難がある。
やはり、Windowsを使いたいなら素直にWindows機を買うのが一番である、という結論に達した。費用や置き場の問題でどうしてもしょうがないのなら、覚悟の上でBOOTCAMPを使うと。
2013年2月16日土曜日
WindowsHomeServerのPC復元ディスクの重大バグ
WindowsHomeServerのPC復元ディスクには極めて重大なバグがいる。
「パーティションを切っている場合、最初のパーティション以外は復旧出来ない」
「復旧出来ない」だけならまだ良いのだが、「パーティション情報を破壊してHDD全体をアクセス不可にしてしまう」。
MacにBootCampでWindowsを導入している場合、パーティション０がMacOS、１にWindowsが入るが、このWindowsを復元しようとした場合、HDDのパーティション情報を破壊して、Mac OSも含めも全てのデータが消えてしまう。
どうやら、常にHDDの先頭からに入れようとするようだ。
PC復元ディスクで復元データを選んで復元先を選んだ直後にエラーが出て、この状態になる。
パーティション情報がなくなると、HDD内に何もない状態になってしまう。
HDD内のMacOS復元領域も読めなくなるので、ネットワークに繋がらない場合、全く復旧のしようがなくなる。
2013/03/04補足：
ここで諦める前に、1つ手がある。
パーティション情報の復旧を行えるツールとしてTestDiskというのが存在する。
HDD内を走査し、かなり正確に復旧してくれる「こともある」（出来ないことも当然ある）。
WHSの全復旧をやってしまった直後なら復活できるかもしれない。
うちでも作業の途中に何回か使って、正しく復活できたこともあった。
英語版しかないし、HDDの専門用語が出てくるので多少知識が必要だが、
日本語で説明しているサイトもここを始めたくさんある。
Linuxを使って起動CDまたはUSBを作るか、Macの場合外部HDD上にMacOSを構築してそこからOSを起動、コンソール上からTestDiskを実行するという手もある。私がとったのは後者。
いずれにせよ、他のPCが必要になる。
・・・
ネットワークに繋がる場合は、インターネットRecoveryなるものを開始される。
Appleに接続してOSをダウンロードしてきて復旧する。MacOSとして起動できるようになるまで30分以上かかる。
しかもLion。でも出来るだけまだマシといえる。
ということで、
「WindowsHomeServerのPC復元ディスクは、BootCampのWindowsでは絶対に使ってはいけない。」
である。
こういう時に限って外の問題もどんどん出てきて、結局復旧に丸１週間もかかってしまった。
今回は兎にも角にもいろいろな状況に遭遇した。
じゃあ、BootCampのWindowsはどうやってバックアップを取ったらいいのかとか、
BootCampでWindowsも使うMacにはこのツールは絶対いれておけか、
実はパーティション情報だけなら復旧方法があったとか、
そういう情報も追って公開したいと思う。
「パーティションを切っている場合、最初のパーティション以外は復旧出来ない」
「復旧出来ない」だけならまだ良いのだが、「パーティション情報を破壊してHDD全体をアクセス不可にしてしまう」。
MacにBootCampでWindowsを導入している場合、パーティション０がMacOS、１にWindowsが入るが、このWindowsを復元しようとした場合、HDDのパーティション情報を破壊して、Mac OSも含めも全てのデータが消えてしまう。
どうやら、常にHDDの先頭からに入れようとするようだ。
PC復元ディスクで復元データを選んで復元先を選んだ直後にエラーが出て、この状態になる。
パーティション情報がなくなると、HDD内に何もない状態になってしまう。
HDD内のMacOS復元領域も読めなくなるので、ネットワークに繋がらない場合、全く復旧のしようがなくなる。
2013/03/04補足：
ここで諦める前に、1つ手がある。
パーティション情報の復旧を行えるツールとしてTestDiskというのが存在する。
HDD内を走査し、かなり正確に復旧してくれる「こともある」（出来ないことも当然ある）。
WHSの全復旧をやってしまった直後なら復活できるかもしれない。
うちでも作業の途中に何回か使って、正しく復活できたこともあった。
英語版しかないし、HDDの専門用語が出てくるので多少知識が必要だが、
日本語で説明しているサイトもここを始めたくさんある。
Linuxを使って起動CDまたはUSBを作るか、Macの場合外部HDD上にMacOSを構築してそこからOSを起動、コンソール上からTestDiskを実行するという手もある。私がとったのは後者。
いずれにせよ、他のPCが必要になる。
・・・
ネットワークに繋がる場合は、インターネットRecoveryなるものを開始される。
Appleに接続してOSをダウンロードしてきて復旧する。MacOSとして起動できるようになるまで30分以上かかる。
しかもLion。でも出来るだけまだマシといえる。
ということで、
「WindowsHomeServerのPC復元ディスクは、BootCampのWindowsでは絶対に使ってはいけない。」
である。
こういう時に限って外の問題もどんどん出てきて、結局復旧に丸１週間もかかってしまった。
今回は兎にも角にもいろいろな状況に遭遇した。
じゃあ、BootCampのWindowsはどうやってバックアップを取ったらいいのかとか、
BootCampでWindowsも使うMacにはこのツールは絶対いれておけか、
実はパーティション情報だけなら復旧方法があったとか、
そういう情報も追って公開したいと思う。
2013年2月14日木曜日
Xcodeでリンクエラーが出るとき
Xcodeでリンクのエラーが出る。
"_OBJC_CLASS_$_オブジェクト",referenced from:
～
オブジェクトが見つからないと言っている。
でも、プロジェクトにソースはちゃんと入ってる。
悩んだ末にやっと思い出した。
「ターゲットになってない」。
Xcode4から、ここにターゲットに入れるかどうか、
単純に言えば実コンパイルするかどうかのチェックが付いた。ここにチェックがないとコンパイル対象から外れる。
ソースコードをAddしただけではここのチェックが入らないので要注意。
正確には、外部にあるソースをAddするとき、.m単体で入れたときはチェックが付き、.hと同時に入れると付かないようだ。ヘッダーはコンパイル対象ではないからだ(オブジェクト生成対象ではないと言うべきか)。
Xcodeが4になった当時からある、バグに限りなく近い仕様で、未だ直っていない。
自分でも何回か引っかかってるだけど、都度忘れてしまうので、今回はここに書いておこうかと。
ひょっとしたら前にも書いたかも知れないけど、そのときは「ぼけ中年ゆえ仕方ない」とお目こぼしを。
"_OBJC_CLASS_$_オブジェクト",referenced from:
～
オブジェクトが見つからないと言っている。
でも、プロジェクトにソースはちゃんと入ってる。
悩んだ末にやっと思い出した。
「ターゲットになってない」。
単純に言えば実コンパイルするかどうかのチェックが付いた。ここにチェックがないとコンパイル対象から外れる。
ソースコードをAddしただけではここのチェックが入らないので要注意。
正確には、外部にあるソースをAddするとき、.m単体で入れたときはチェックが付き、.hと同時に入れると付かないようだ。ヘッダーはコンパイル対象ではないからだ(オブジェクト生成対象ではないと言うべきか)。
Xcodeが4になった当時からある、バグに限りなく近い仕様で、未だ直っていない。
自分でも何回か引っかかってるだけど、都度忘れてしまうので、今回はここに書いておこうかと。
ひょっとしたら前にも書いたかも知れないけど、そのときは「ぼけ中年ゆえ仕方ない」とお目こぼしを。
2013年2月8日金曜日
ATOK2013インストール時の問題→解決
今日発売の一太郎２０１３「玄」。
早速インストールしてみる。
Windows7PRO ６４ビット。
ところが、ATOK2013がどうにも変換モードに入れない。
「テキストサービスと入力言語」でみると「ATOK(６４ビットのみ）」と表示されている。
調べてみると、手持ちの数少ない６４ビットアプリであるところの「秀丸エディタ」と「ExpLzh」の６４ビット版上でのみ変換モードに入ることが出来るとわかった。それとエクスプローラー上（当然これも６４ビットアプリである)。
３２ビットアプリ上では全滅。一太郎も含めて。だめじゃん。
ATOK2013プレビュー版ではそんなことなかったのに、いきなり製品版でバグか？
電話しようにも大混雑でつながらない。
みんなこの件で電話してるんじゃないか？
ちゅうことで、とりあえず一報。
ちなみにGoogle日本語入力が使えたので、仕事はなんとか終えられたが、
それがなかったらどえらいことだった。
この文章はMac上からなので関係なし。
・・・そして解決・・・
一度ATOK2013を完全削除して、再インストール。このときインストール先が
ProgramFiles(x86)になっていることを確認して進めると直った。
一太郎もいけるし、６４ビットアプリ上もOK。
完全削除しないで、上書き再インストールではだめ。
(完全削除にはフリーウエアのGeekUninstallerを利用。「プログラムと機能」から削除した場合どうなるかは不明。)
前に入れてたプレビュー版を先にアンインストールしておかないとダメだったのかもしれない。設定引き継ぐためにはそのままで入れないとあかんのかと思ったのだが。
早速インストールしてみる。
Windows7PRO ６４ビット。
ところが、ATOK2013がどうにも変換モードに入れない。
「テキストサービスと入力言語」でみると「ATOK(６４ビットのみ）」と表示されている。
調べてみると、手持ちの数少ない６４ビットアプリであるところの「秀丸エディタ」と「ExpLzh」の６４ビット版上でのみ変換モードに入ることが出来るとわかった。それとエクスプローラー上（当然これも６４ビットアプリである)。
３２ビットアプリ上では全滅。一太郎も含めて。だめじゃん。
ATOK2013プレビュー版ではそんなことなかったのに、いきなり製品版でバグか？
電話しようにも大混雑でつながらない。
みんなこの件で電話してるんじゃないか？
ちゅうことで、とりあえず一報。
ちなみにGoogle日本語入力が使えたので、仕事はなんとか終えられたが、
それがなかったらどえらいことだった。
この文章はMac上からなので関係なし。
・・・そして解決・・・
一度ATOK2013を完全削除して、再インストール。このときインストール先が
ProgramFiles(x86)になっていることを確認して進めると直った。
一太郎もいけるし、６４ビットアプリ上もOK。
完全削除しないで、上書き再インストールではだめ。
(完全削除にはフリーウエアのGeekUninstallerを利用。「プログラムと機能」から削除した場合どうなるかは不明。)
前に入れてたプレビュー版を先にアンインストールしておかないとダメだったのかもしれない。設定引き継ぐためにはそのままで入れないとあかんのかと思ったのだが。
X−BASIC for iOS紹介記事
X-BASIC for iOSが「Appliv」および「日刊Appliv」にて紹介されました。
よろしければご覧ください。
なお、記事ではV1.60が最新となっておりますが、2/12にV1.71が公開になっています。
m(_ _)m
・・・2013/04/07追記
収益上の問題から、3月をもってiOS用アプリ開発の仕事を辞めました。
そのため、今後X-BASIC for iOSのサポート及びバージョンアップなどは全て「趣味」として、空き時間に行うしかなくなりました。
なお、現在はショックにより、開発作業は全く行えておりません。
あしからず、ご了承ください。
・・・2013/04/20追記
V1.80の開発を再開＆終了。
現在V2.00の開発中です。
ただし、本業としての開発ではありませんので、いつ完成するかは解りません。
よろしければご覧ください。
なお、記事ではV1.60が最新となっておりますが、2/12にV1.71が公開になっています。
m(_ _)m
・・・2013/04/07追記
収益上の問題から、3月をもってiOS用アプリ開発の仕事を辞めました。
そのため、今後X-BASIC for iOSのサポート及びバージョンアップなどは全て「趣味」として、空き時間に行うしかなくなりました。
なお、現在はショックにより、開発作業は全く行えておりません。
あしからず、ご了承ください。
・・・2013/04/20追記
V1.80の開発を再開＆終了。
現在V2.00の開発中です。
ただし、本業としての開発ではありませんので、いつ完成するかは解りません。
2013年1月31日木曜日
Xcode4.6のバグ
Xcode4.6が出た。
「おっ、今回はバグが出ないじゃん」と思ってたら、やっぱりというか案の定というか
バグがいた。
・memcpyで転送サイズがlongサイズの定数倍の時、インライン展開がいらんお世話をする
・double変数のくせに８バイト境界から確保されない
正確にはXcodeのバグというよりコンパイラのバグ。
ARM実機でのみ発現する。
ARMではlongでは４バイト境界、doubleでは８バイト境界から始まっていなければならない。そうしないとアクセス時にCPUが例外を発生してしまう。ところが、Xcode4.6のコンパイラでは事もあろうにそれらをワード境界から確保することがある。
さらに、それを見越してmemcpy()で内容をコピーするようにしたのに、全く要らんことにmemcpy()がインライン展開する際に、サイズが定数(相当)で指定されている場合、常にバイト単位転送ではなく、サイズが４で割り切れる時は４バイト単位転送にしてしまいやがる。これじゃ意味無いじゃん。
定数相当と書いたのは、定数＊変数で定数が4バイトの倍数の時も同じということ。
コンパイルオプションに-fno-inline-functionsを入れてみたけど変わらず。これはユーザー関数のインライン展開のみを制御するのかもしれない。
シミュレーター上では８６のコードが出力され、８６はどの位置からでもいかなるサイズでもアクセス可能なため発現しない。
ARMと８６で同じ最適化というか境界配置にしてるんじゃないか？
実機でしか発現しないし、実機でも同じコードでも出る場所と出ない場所があったりして
非常に厄介なバグである。
ということで、バイト単位コピーを所望する場合は、自前で相当関数を実装しなければならないようである。
・・・補足
同じようにインライン展開される関数でも、memcmp()は1バイトづつ比較するしかないから多分大丈夫だろうし、strcpy()も1バイトコピーが必須なので大丈夫だと思う。
引っかかる可能性があるのはmemcpy(相当)の定数サイズ時だけだと思う。
ちなみに、GCCにも同じバグがいるらしい。XcodeはGCCじゃなくなったけど同じということで。
「おっ、今回はバグが出ないじゃん」と思ってたら、やっぱりというか案の定というか
バグがいた。
・memcpyで転送サイズがlongサイズの定数倍の時、インライン展開がいらんお世話をする
・double変数のくせに８バイト境界から確保されない
正確にはXcodeのバグというよりコンパイラのバグ。
ARM実機でのみ発現する。
ARMではlongでは４バイト境界、doubleでは８バイト境界から始まっていなければならない。そうしないとアクセス時にCPUが例外を発生してしまう。ところが、Xcode4.6のコンパイラでは事もあろうにそれらをワード境界から確保することがある。
さらに、それを見越してmemcpy()で内容をコピーするようにしたのに、全く要らんことにmemcpy()がインライン展開する際に、サイズが定数(相当)で指定されている場合、常にバイト単位転送ではなく、サイズが４で割り切れる時は４バイト単位転送にしてしまいやがる。これじゃ意味無いじゃん。
定数相当と書いたのは、定数＊変数で定数が4バイトの倍数の時も同じということ。
コンパイルオプションに-fno-inline-functionsを入れてみたけど変わらず。これはユーザー関数のインライン展開のみを制御するのかもしれない。
シミュレーター上では８６のコードが出力され、８６はどの位置からでもいかなるサイズでもアクセス可能なため発現しない。
ARMと８６で同じ最適化というか境界配置にしてるんじゃないか？
実機でしか発現しないし、実機でも同じコードでも出る場所と出ない場所があったりして
非常に厄介なバグである。
ということで、バイト単位コピーを所望する場合は、自前で相当関数を実装しなければならないようである。
・・・補足
同じようにインライン展開される関数でも、memcmp()は1バイトづつ比較するしかないから多分大丈夫だろうし、strcpy()も1バイトコピーが必須なので大丈夫だと思う。
引っかかる可能性があるのはmemcpy(相当)の定数サイズ時だけだと思う。
ちなみに、GCCにも同じバグがいるらしい。XcodeはGCCじゃなくなったけど同じということで。
2013年1月8日火曜日
X-BASIC for iOS 次バージョン開発状況
「X-BASIC for iOS」の次バージョンの開発状況などをお知らせします。
今後X-BASIC for iOSのサポートは専用ページに移行します。
・・・
バージョン V1.60->発売中
・指定時間待ち関数
・テキストおよびグラフィック色の合成RGBでの指定
・pset()
・bitmap関数群
・picLoader
X68での事実上標準画像フォーマットであった.PICを表示出来る
・cutLoader
電脳倶楽部で使われていたCUTファイルを表示出来る
・最新取説への更新
・いくつかのバグ修正
エラー発生行番号がずれる/キーリピートが止まらなくなることがある/bingo.basのバグ他
・描画高速化(50倍位)
・・・
バージョン V1.70→拒絶
・PCM/M44/M30/P16音声ファイルサポート
a_play()で直接再生可能
・files()で正規表現を使えるようにした
・(プログラム実行開始時を含む)cls()直後のprint表示が抜けることがあるのを修正
・ビットマップにline/box/fill/circle/paint/get/put関数を追加・エラー番号とメッセージが一致していないのを修正
・エラー表示発生行が実発生行と一致しないことがあるのを修正
・キー表示画面の優先順位が一番高くないのを修正
プログラムのインポート機能が「やっぱりだめ」と言われてしまいました。
V1.60では通ったのに。
現在対策を検討中ですが、場合によっては、プログラムを外部から入れる機能は
Webサイト等からのCopy&Pasteのみになるかもしれません。
・・・ということで
バージョン V1.71→発売中(2013/2/11)
・プログラムのインポート機能を削除
単独ファイルだけでなく、ZIP内も禁止。
テキストでのCopy&Pasteしか仕方ない様子。このことも取説には書けない。なんてこったい。
・Xcode4.6コンパイラのバグを回避するコードを実装
今後X-BASIC for iOSのサポートは専用ページに移行します。
・・・
バージョン V1.60->発売中
・指定時間待ち関数
・テキストおよびグラフィック色の合成RGBでの指定
・pset()
・bitmap関数群
・picLoader
X68での事実上標準画像フォーマットであった.PICを表示出来る
・cutLoader
電脳倶楽部で使われていたCUTファイルを表示出来る
・最新取説への更新
・いくつかのバグ修正
エラー発生行番号がずれる/キーリピートが止まらなくなることがある/bingo.basのバグ他
・描画高速化(50倍位)
・・・
バージョン V1.70→拒絶
・PCM/M44/M30/P16音声ファイルサポート
a_play()で直接再生可能
・files()で正規表現を使えるようにした
・(プログラム実行開始時を含む)cls()直後のprint表示が抜けることがあるのを修正
・ビットマップにline/box/fill/circle/paint/get/put関数を追加・エラー番号とメッセージが一致していないのを修正
・エラー表示発生行が実発生行と一致しないことがあるのを修正
・キー表示画面の優先順位が一番高くないのを修正
プログラムのインポート機能が「やっぱりだめ」と言われてしまいました。
V1.60では通ったのに。
現在対策を検討中ですが、場合によっては、プログラムを外部から入れる機能は
Webサイト等からのCopy&Pasteのみになるかもしれません。
・・・ということで
バージョン V1.71→発売中(2013/2/11)
・プログラムのインポート機能を削除
単独ファイルだけでなく、ZIP内も禁止。
テキストでのCopy&Pasteしか仕方ない様子。このことも取説には書けない。なんてこったい。
・Xcode4.6コンパイラのバグを回避するコードを実装
2012年12月23日日曜日
編集できなくなったMacの連絡先の再構築仕方(10.8.3対応）
いつの頃からか、Mac上の連絡先.appで編集ができなくなった。
正確には、追加や既存分の修正は出来るが、削除ができない。
なぜだか連絡帳内に同じ人のデータが複数存在し、それが消せないのだ。
色々やった結果、ようやく修正方法、というかそのデータベースの再構築方法がわかったので記しておく。
これで重複がなくなり、そうすると削除もできるようになる。
どうも、重複あると削除できなくなるようである。
(どちらを削除して良いかわからなくなるからか？)
それにしてもどうして重複が発生したのか。
自分でそうした覚えはないので、OSのバージョンアップ時に新旧が結合されたのか、iOSデバイスとの同期時に結合されてしまったのか、まあ、そんなところだろう。
アップルの製品は、よくできているところがある反面、ツメが甘いところも多々見受けられるので、回避策を知っておくこと、それを共有しておくことは重要だ、と思う今日この頃である。
正確には、追加や既存分の修正は出来るが、削除ができない。
なぜだか連絡帳内に同じ人のデータが複数存在し、それが消せないのだ。
色々やった結果、ようやく修正方法、というかそのデータベースの再構築方法がわかったので記しておく。
連絡先を起動する。編集〜すべてを選択。マウス右クリック(1ボタンマウスならシフト＋クリック？)〜vCardを書き出す。
なんとか.vcfというファイルが出来る。内容はテキストである。連絡先を閉じる。Finderで/Users/ユーザー名/Library/Application Support/AddressBookフォルダを削除する。
必要ならどこかへコピーしておく。テキストエディタなどで先ほど書きだしたvcfファイルを開く。その中の重複している部分を探し削除する。
1人分は、BEGIN:VCARDからEND:VCARDまでである。
写真を入れてると結構長くなる(テキストにエンコードされてるのでそのまま読める)。保存。連絡先を再起動する。
自分とアップルの連絡先だけ入った状態で開くはず。ファイル〜読み込むでvcfを読む。
それにしてもどうして重複が発生したのか。
自分でそうした覚えはないので、OSのバージョンアップ時に新旧が結合されたのか、iOSデバイスとの同期時に結合されてしまったのか、まあ、そんなところだろう。
アップルの製品は、よくできているところがある反面、ツメが甘いところも多々見受けられるので、回避策を知っておくこと、それを共有しておくことは重要だ、と思う今日この頃である。
2012年12月21日金曜日
iOSの色々なバグや仕様
X−BASIC for iOSの開発中に発見したiOSのバグや隠れ仕様をあげておく。
発生するバージョンを特定できてないものもあるが、今後の開発時に注意すれば良いということで。
・横画面において、キーボードwidthとheightが逆になってる
（というか、縦画面時のサイズのまま返ってきている）
0,0,1024,352のはずが、0,0,352,1024になってる。
画面方向を認識して、読み替える必要がある。
・MFMailComposeViewControllerで送信するとメモリーリークが発生する
下書き〜削除・保存すると発生しない
宛先をメニューを選ぶだけでは発生しない
シミュレーター上だけかもしれない
・バックグラウンドでUIGraphicsGetImageFromCurrentImageContext()が取得できない
常にリターン値がNULLになる
・ナビゲーションバーのボタンのタッチ有効範囲はかなり広く、かつnaviが最優先されるため、それに隣接する領域ではタッチが検出できない。
ナビゲーションバーのすぐ下のあたりなど。
[lblBasicFile becomeFirstResponder];してもだめ
・[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(keyboardWillShow:) name:UIKeyboardWillShowNotification object:nil];が2回連続でかかることがある
キーボードを閉じてないにもかかわらず「開く」が連続で通知されるため、順番に依存する処理で異常が起こる。
iOS5.0のみ発生。iOS5.1では発生しない。
日本語環境だけかもしれないが、英語環境では未検証。
・デジタルコンパスはメインスレッドで初期化しないと取得できない。
locationManager=[[CLLocationManager alloc]init];
をメインスレッド内で実行しないと、デリゲートが発生しない。
・CGContextRefで宣言したメンバーにはKVOが設定できない
設定しても発生しない。
・実行時に Unknown class ??? in Interface Builder file.と出るときは、そのクラスの.mファイルのTarget Membershipにチェックを入れる
Xcode右上のViewの一番右から
・[s drawAtPoint:point withFont:[UIFont fontWithName:fontName size:pointSize]];
で、pointSize=0だと<Error>: CGAffineTransformInvert: singular matrix.というエラーが出る。
エラーと内容があってない。
・UIWebViewへloadHTMLした場合、webViewDidFinishLoad以降でないと操作してはいけない
・ステータスバーのタップで先頭にスクロール
editor.scrollsToTop =YES;
スクロールさせたいもののみYESにし、他はNOにしなければならない
・UIView.transform=CGAffineTransformMakeTranslation(0, -fontWy);
で 平行移動がかかるのはUIViewのframeそのものであり、内容が移動するわけではない。
描画範囲も変わらない。
したがって、スクロール処理には使えない。
・HTMLの表示され方いろいろ
Chrome <pre>内にフォント指定は無効
UIWebViewとChrome <pre>と<table>内の改行の扱いが異なる
Chromeは<table>内は<pre>が無効になっている。
改行には<br>が必要で、スペースは無視される。
UIWebViewはSafariとも異なる
そのため、HTML表示確認は必ずUIWebView上で行わなければならない。
・UIGraphicsGetImageFromCurrentImageContext()はそれが含まれるコンテキストの内容だけを出力するのではなく、現在有効になっているすべてのコンテキストの内容を合成して出力してしまう。
多分、呼び出し時点までにUIGraphicsBeginImageContextされている全てのコンテキストだと思われる。
・CGBitmapContextCreateImage()にCGImageRetain()を付けたら画面がおかしくなる＝メモリーリークする
・複数のコンテキストを使う場合、その切替には
UIGraphicsPushContext(context);
UIGraphicsPopContext();
が重要。これがないとコンテキストの切替後にエラーが出る。
ドキュメントではメインスレッド内で呼び出せとあるが、サブスレッド内でも問題ない。
・アプリケーション内フォントを追加する場合
必ずルート直下のサブディレクトリに置く必要がある
サブディレクトリの中のサブディレクトリ内は不可
これは他のリソースでも同じ。
・AirPrintはメインスレッドからしか実行できない
ポップアップを伴うので仕方ない様子。UIを持つものは全てメインスレッドで実行するのが慣わし。
おまけ
・Xcodeのsnapshotは過去に消したファイルも戻してしまうので、事実上使いものにならない。
えらい目にあった。
全保存したいなら、自分でzip圧縮化フォルダごとコピーするのが吉。
発生するバージョンを特定できてないものもあるが、今後の開発時に注意すれば良いということで。
・横画面において、キーボードwidthとheightが逆になってる
（というか、縦画面時のサイズのまま返ってきている）
0,0,1024,352のはずが、0,0,352,1024になってる。
画面方向を認識して、読み替える必要がある。
・MFMailComposeViewControllerで送信するとメモリーリークが発生する
下書き〜削除・保存すると発生しない
宛先をメニューを選ぶだけでは発生しない
シミュレーター上だけかもしれない
・バックグラウンドでUIGraphicsGetImageFromCurrentImageContext()が取得できない
常にリターン値がNULLになる
・ナビゲーションバーのボタンのタッチ有効範囲はかなり広く、かつnaviが最優先されるため、それに隣接する領域ではタッチが検出できない。
ナビゲーションバーのすぐ下のあたりなど。
[lblBasicFile becomeFirstResponder];してもだめ
・[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(keyboardWillShow:) name:UIKeyboardWillShowNotification object:nil];が2回連続でかかることがある
キーボードを閉じてないにもかかわらず「開く」が連続で通知されるため、順番に依存する処理で異常が起こる。
iOS5.0のみ発生。iOS5.1では発生しない。
日本語環境だけかもしれないが、英語環境では未検証。
・デジタルコンパスはメインスレッドで初期化しないと取得できない。
locationManager=[[CLLocationManager alloc]init];
をメインスレッド内で実行しないと、デリゲートが発生しない。
・CGContextRefで宣言したメンバーにはKVOが設定できない
設定しても発生しない。
・実行時に Unknown class ??? in Interface Builder file.と出るときは、そのクラスの.mファイルのTarget Membershipにチェックを入れる
Xcode右上のViewの一番右から
・[s drawAtPoint:point withFont:[UIFont fontWithName:fontName size:pointSize]];
で、pointSize=0だと<Error>: CGAffineTransformInvert: singular matrix.というエラーが出る。
エラーと内容があってない。
・UIWebViewへloadHTMLした場合、webViewDidFinishLoad以降でないと操作してはいけない
・ステータスバーのタップで先頭にスクロール
editor.scrollsToTop =YES;
スクロールさせたいもののみYESにし、他はNOにしなければならない
・UIView.transform=CGAffineTransformMakeTranslation(0, -fontWy);
で 平行移動がかかるのはUIViewのframeそのものであり、内容が移動するわけではない。
描画範囲も変わらない。
したがって、スクロール処理には使えない。
・HTMLの表示され方いろいろ
Chrome <pre>内にフォント指定は無効
UIWebViewとChrome <pre>と<table>内の改行の扱いが異なる
Chromeは<table>内は<pre>が無効になっている。
改行には<br>が必要で、スペースは無視される。
UIWebViewはSafariとも異なる
そのため、HTML表示確認は必ずUIWebView上で行わなければならない。
・UIGraphicsGetImageFromCurrentImageContext()はそれが含まれるコンテキストの内容だけを出力するのではなく、現在有効になっているすべてのコンテキストの内容を合成して出力してしまう。
多分、呼び出し時点までにUIGraphicsBeginImageContextされている全てのコンテキストだと思われる。
・CGBitmapContextCreateImage()にCGImageRetain()を付けたら画面がおかしくなる＝メモリーリークする
・複数のコンテキストを使う場合、その切替には
UIGraphicsPushContext(context);
UIGraphicsPopContext();
が重要。これがないとコンテキストの切替後にエラーが出る。
ドキュメントではメインスレッド内で呼び出せとあるが、サブスレッド内でも問題ない。
・アプリケーション内フォントを追加する場合
必ずルート直下のサブディレクトリに置く必要がある
サブディレクトリの中のサブディレクトリ内は不可
これは他のリソースでも同じ。
・AirPrintはメインスレッドからしか実行できない
ポップアップを伴うので仕方ない様子。UIを持つものは全てメインスレッドで実行するのが慣わし。
おまけ
・Xcodeのsnapshotは過去に消したファイルも戻してしまうので、事実上使いものにならない。
えらい目にあった。
全保存したいなら、自分でzip圧縮化フォルダごとコピーするのが吉。
2012年12月11日火曜日
Objective-Cでの文字列系オブジェクト変換
Objective-Cでの文字列系オブジェクト変換。
X-BASIC for iOSの開発中にいろいろ出てきたのでまとめておく。
NSString*からchar*への変換
NSString* str = @"AAA";
char* cp = [str UTF8String];
char*からNSString*への変換
char* cp = "AAA";
NSString* str = [NSString stringWithCString: cp encoding:NSUTF8StringEncoding];
NSStringからCFStringRefに変換
CFStringRef aCFString = (CFStringRef)aNSString;
CFStringRefからNSStringに変換
NSString *aNSString = (NSString *)aCFString;
Cでの記述部分とObjective-Cでの記述をリンクするときにはこのあたりの変換が必須となる。
追記：
stringWithFormat@"%s"ではCの文字列("〜")を受けられるが、
UTF8には対応していないので、ASCIIでない文字は化ける。
UTF8対応するにはstringWithCString:encoding:が必要となる。
X-BASIC for iOSの開発中にいろいろ出てきたのでまとめておく。
NSString*からchar*への変換
NSString* str = @"AAA";
char* cp = [str UTF8String];
char*からNSString*への変換
char* cp = "AAA";
NSString* str = [NSString stringWithCString: cp encoding:NSUTF8StringEncoding];
NSStringからCFStringRefに変換
CFStringRef aCFString = (CFStringRef)aNSString;
CFStringRefからNSStringに変換
NSString *aNSString = (NSString *)aCFString;
Cでの記述部分とObjective-Cでの記述をリンクするときにはこのあたりの変換が必須となる。
追記：
stringWithFormat@"%s"ではCの文字列("〜")を受けられるが、
UTF8には対応していないので、ASCIIでない文字は化ける。
UTF8対応するにはstringWithCString:encoding:が必要となる。
2012年12月8日土曜日
2012年12月5日水曜日
iOSでのいろんな画面(1)
iOS上で見られる、いろいろな場面での画面を集めておこうかと。
もちろん、いつでも見られるものではなく、ちょっと特殊な状況での物。
取説で使うかも知れないので。
 |
| 電池残り20％(英語) |
 |
| 充電機能なし(英語) |
 |
| Bluetooth有効確認(英語) |
 |
| Bluetooth有効確認(日本語) |
 | |
| 電池がもう少しで切れる(日本語) |
 | |||||
電池が切れる直前(日本語のようだけど実は英語)
|
登録:
投稿 (Atom)