ATOK2013の誤変換出まくり問題の解決法

ATOK2013にしてから誤変換が多発した。


ATOK2013は、最初はインストール問題から始まり、入れてからもあまりの誤変換の多さに嫌気がさして利用をやめていた。Google日本語入力を使っていたが、辞書登録がやりにくいのでATOK2011に戻していた。

が、ATOK2011と2013の設定を見比べているうちに「ここが原因ではないか？」と思われる部分を見つけ、やってみたら直った（たぶん）。

・・・まずは、誤変換多発時の変換状況・・・

こんな変換をしやがった。

例
「あさおきたらかだらがいたい」　　　「かいけつほう」
ATOK2013　　　　　　「麻生キタラからだが痛い。」　　　　「解穴法」
ATOK2011 　　　　　 「朝起きたら体が痛い」　　　　　　　 「解決法」
Google日本語入力　「朝起きたら体が痛い」　　　　　　　 「解決法」

昔はFEPの誤変換をあげてネタにしたこともあったけど、最近は効率がよくなっておもしろい誤変換にはあまり出会えなくなった。しかし、ATOK2013では「狙っているのではないか？」と思うほど多発した。
どうも名詞を最優先するようだ。「そこはどう考えても名詞が来る場所じゃないだろ」という場所でも名詞単語を出してくる。しかも傾向として、難しい＝あまり使われない単語を優先する感じ。

「使うたびに発見がある」 ではあったが、遊びならまだしも、長文書いているときにこれをやられたら、たまったもんではない。

・・・そして解決法・・・

結局何がいけなかったかというと、辞書設定にて、標準辞書セットには他の変換辞書を入れてはいけないということであった。

 ↑これが正しい設定で、ここに

を入れたら変換がむちゃくちゃになる。
（角川～辞書は入れても問題ない。）

使ってみるとわかるが、この3つの辞書（だけで）変換辞書として使うと正しい変換を全くしない。
じゃあ、標準辞書を優先にして、これらを組み合わせたらどうなるかと言えば、これが私の所で発生してた誤変換出まくりになるわけである。

ゆえに、これらは変換辞書には設定してはいけない。電子辞書検索にのみ設定する、が正解である。

（3つ全部だけがだめなのではなく、どれか1つでも入れたらだめ。）

ATOK2011でもたぶん同様になる。

なお、いったん3つの辞書を入れて誤変換だらけな状態から外した場合は、学習結果をクリアし、省入力変換辞書や、確定履歴も見直すかクリアした方がいい。変な癖が付いてしまっているので。

そもそもの原因は、変換辞書としては使い物にならないものに、変換辞書として設定をできるようにしていることなので、「設定できなく」してほしい。

・・・余談・・・

先日あったJustSystemの一太郎玄アンケートにも「ATOK2013が全く使い物にならねぇ」と書いてしまった。しかし、今回やった設定は別段特異なものではなく、辞書の意義からすると当然考えられる範疇だから、決して間違ったことは書いてない。よって謝罪する気もない。が、ちょっと後味悪い気もしてる。

ちなみに、これで変換が戻ったからといってATOK2013の変換効率が2011に比べて良いかと聞かれると、「特にそうは思わない」というのが正直なところである。統計を取ったわけではないが、2011の方が変換効率が良いような感じもする。
推測変換に関しては、明らかにGoogle日本語入力の方が数段上。

念のため現在は、ATOK2011／2013、 Google日本語入力を共存させてある（MS-IMEも一応あるけど、全く使ってない）。なお、ATOK2013を導入するときATOK2011も残すように設定すると、2011から2013への単語登録や学習内容などの引き継ぎが行われないようである。極めて面倒。

(引き継ぎさせる方法：
(1)ATOK Sync2011でATOK2011の設定を保存
(2)ATOK2013を導入＆2011を削除;ここでATOK2011→2013の引き継ぎが行われる
(3)ATOK Sync2013を導入、2013の設定を保存
(4)ATOK2013/Sync2013を削除
(5)ATOK2011/Sync2011を導入
(6)ATOK Sync2011で設定を戻す
(7)ATOK2013を追加で導入
(8)ATOK Sync2013を導入、設定を戻す；この時点でSync2011は削除される
これで設定を引き継いだ状態で共存環境が出来る。)

ATOKにはさらなる精進を期待したい。


・・・余談・・・
ATOKは「いやがおう」では変換できない。「いやがおうでも」まで入力しないとだめ。
２０１３も２０１１も同じ。
変換できなくても推測表示して欲しい。そうでなくても意味合い的に間違いやすいのだから。
Google日本語入力ではちゃんと出してくれる。
やはり推測変換ではGoogle日本語入力が数段優秀。

・・・やっぱり
学習すればするほど馬鹿になるのはATOKの伝統だけど、2013はいっそうその傾向が強い気が。時々学習結果を消さないと誤変換出しまくりになる。
学習は弱めにするのが良いのかも。

使いものにならないので標準を2011に戻した。ソフトウエア は試用ができないので、買ったけど使い物にならなかった時に困る。

ゼンハウザーHD580のイヤーパッド＆ヘッドパッドの交換方法

ヘッドフォンとしてゼンハウザーのHD580を愛用している。しかし購入して10年、さすがに耳当て部分（イヤーパッド）と頭の部分のクッション（ヘッドパッド）がへたってきた。

HD580は装着性も音も非常に気に入っているので、買い換える気は今のところない。 

というか家計的に無理。そこで、それらを交換することにした。 

調べてみると、イヤーパッド自体は楽天のe☆イヤホンという店で購入できた。送料込みで5250円だった。

また、交換方法についてはここに情報があった。基本的にはその通りに行うのだが、若干情報が少ないので、追記も兼ねてここに記述する。

私は、ヘッドパッド部の修繕にはスポンジとクリアファイルを使った。 

・・・

これが10年経過したイヤーパッド。この角度からはわかりにくいが、クッション部の弾力が少なくなり、変色している。また、写真ではユニット部が見えているが、本当はここにも薄いスポンジがあって、見えない。破けてしまっているのだ。

 まずはこのイヤーパッドを取り外す。ちょっと堅いが、力まかせで引き抜くしかない。外れると、下にある薄い「元」スポンジシートが見える。、穴が開いてユニットが見えている。

 そのシートも外すと、このようになる。

スポンジカスをきれいに取り除く。その上にあたらしいスポンジシートを置く。

さらにその上に耳当て部を置く。そして、このあたりを強く押してはめ込む。

これでイヤーパッド部の交換は終わり。交換部品には手順説明が一切なく、かつ上記情報サイトにもその方法に関する記述がない。いろいろと試して解ったのがこれである。

イヤーパッドを自前で修理できないかどうかだが、これはまず無理。
スポンジシートはなんとかなるが、クッション部分がスポンジを布で巻いて接着剤で固定してあるため。よほど腕に覚えがあれば再生できるかもしれないが、極めて難しいといえる。なので、ここは素直に購入したほうが良いかと。

・・・

次はヘッドパッドの交換というか修繕。
こちらは部品は購入しなかった。けちったのではなく、「交換する必要はない」と何故か思い込んでいたためである(同店で買うと2625円)。
実際には、こちらの方が劣化が激しかった。

これがヘッドパッド部分。完全にへたってしまい、膨らみがないのが解る。 まずは、これを取り外す。赤丸の部分の留め具を外せば、ヘッドパッド部分を取り外すことが出来る。

留め具は、隙間にマイナスドライバーを差し込んでひねると外れる。

そうしたら、ヘッドパッド部をスライドして引き抜く。

外したのがこれ。スポンジ部が融けて完全にぺしゃんこになってる。

裏を向けてスポンジ部あたりをカッターで切り抜く。オルファカッターなら、一番浅く刃が出ている状態でちょうどであった。切り抜いた片は再利用しないので破棄してもかまわない。

中はこんな状態。ウレタンスポンジが加水分解と皮脂でどろどろになっている。

これを水と洗剤で洗いながら出来るだけ取り除く。 それだけでは完全には取れないので、あとは古布などでこすりながらきれいにしていく。ウレタンは、普通に家にある洗剤などでは溶かすことが出来ないのでこの方法しかない（と思う）。すると最終的には、布地の袋部が現れる。

乾燥させている間に、その袋部より一回りくらい大きいのスポンジブロックを作る。
私が使ったのは、とある筋から入手してあった導電スポンジであるが、普通のスポンジ、もしくは、弾力性のある布を詰めてもいいと思う。スポンジの場合、穴と同じ大きさではいけない。若干大きめの物を無理矢理入れ込むことで弾力が出る。

スポンジを切り抜いた部分の蓋にはクリアシートを使った。これをヘッドパッドと同じ大きさに切っておく。

ヘッドパッドを元に戻す。まずはクリアシート片をヘッドパッドが入る部分に入れておく。
その上から修理したヘッドパッドを入れる。これでクリアシートが蓋の代わりになる。
そもそも隙間がほとんどないので、ヘッドパッドに対して接着しておく必要はない。
入れ込んだら、留め具を戻す。まずは片側だけをはめ（他方は浮いた状態）、後でぐっと押し込む。

これでヘッドパッド部分も修理完了。結果、これほどふっくらとする。

多少手間はかかるが、これで、購入当時の装着感が戻った。
乾燥時間も含め、1時間見てればいいのはなかろうかと思う。

これを書きながら、PCの排気で乾燥させてた、というのは秘密でもなんでもない。
これもリサイクルの一種。

TimeDomainLightのACアダプタの修理

TimeDomainLightというスピーカーがある。

TimeDomain社(日本)が出している(PC用)アクティブスピーカーである。

このスピーカー、音は良い。
サイズがサイズだけに低音とかは無理だが、広がりがあり、かつはっきり聞こえる。
置き場所をほとんど考慮しないでも見事な音場を形成してくれる。

2セット持っていて、内1セットは長らく使うことなく保管してあったが、機会あって取り出して接続したら音が鳴らない。

電源スイッチを入れてもパワーランプが付かない。どうやらACアダプタが壊れているようだった。

純正ACアダプタは、重さや磁石がくっつくところからトランス方式と思われる。
定格銘版がシールでなく印刷であり、また11.5V 700mAという中途半端な定格から、カスタム品の可能性が高い。

それにしても、ほとんど使ってない＆部品点数の少ないトランス式で壊れるなんて、 どんだけ品質悪いねん。さすがMade in china。

スイッチング電源方式のなら12V 1A位のが手持ちであったが、オーディオ製品にスイッチングではノイズが懸念されるので、トランス式を使いたい。
となると、購入しかない。

で、「ACアダプタが壊れたようなので、購入できるか？」とTimeDomain社にメールで問い合わせた。


ただし、高ければ買えない。製品価格から考えて、2000円が妥当な値段だと思われるので、そのあたりが判断基準となる。
（製品原価は多くの場合、販売価格の1/3。今回の場合18000円だから、6000円が原価。
それでスピーカー2本(アンプ内蔵)、とACアダプタが主な構成。当然スピーカーが主体だから価格の7割として残り3割がACアダプタとすると1800円。これが上限。）
メーカーとしてもACアダプタで利益を得るつもりはないはず、と信じたい。

ところが返答がない。
待ってる間に、相当品がないか探してみた。

トランスタイプの安定化なし品は、定格電流を流したときに定格の電圧がかかる仕様なので、同じ電圧が書いてあっても電流値が大幅に異なる物は流用できない。
スイッチング電源タイプを使う手もあるが、オーディオ製品にスイッチングではノイズが懸念されるので、トランス方式は譲らない。
この条件で探すと実はほとんど見つからない。唯一見つけたのがPATOS社のDK072-Bであった。

もう1日待っても返答がこないので発注。 お店はマルツパーツ。
1344円＋送料472円で、合計1816円。上の計算とぴったりである（上記計算式では送料は考慮してないが）。

注文した翌日には物が来た。すばやい。一方、この時点でもまだTimeDomain社からは返答すらない。


比較写真。

左がDK072-B、右が純正品。 見て解るとおり、大きさや重さはほぼ同じである。
ここからも、純正品には安定化回路は入っていないと推測された。

唯一の問題はコネクタ形状の違い。
上がDK072-B、下が純正品。

DK072-B

純正品

全く異なるので、ここは純正品のを切ってDK072-Bに付けるしかないだろう。
久しぶりに半田付けした。電源ラインなので絶縁は慎重に。

ここで1つ注意があって、DK072-Bの配線を見ると赤白の線が見えるが、事もあろうに赤がマイナスで白がプラスとなっている。最初「赤＋」で接続したら負電圧で出たからびっくりした。ちゃんとテスターで計ってよかった。

後で解ったのだけど、実はDK072-Bのコネクタ部分は 差し替えが可能なタイプで、純正品と同じ形状の物も「別売」であるらしい。マルツおよびメーカーにある写真では解らないが、おそらくDK071-E(514円)に入っている「EIAJ4 DC12V用 外径5.50φ センターピン有」が同じものではないかと思われる。加工がいやならそれを買うと言う手もある。

で、ちゃんと接続して、出力電圧も測って確認、TimeDomainLiteに接続してみた。
全く問題ない。エージングしてない状態でも、音質的な違いは感じられない。
→エージングが進んだからか、現在はいい音(2013/05/28追記)。

・・・結局メーカーはどうなった・・・

マルツからDK072-Bが届いた日にやっとTimeDomain社から返答があった。
「購入は可能で3500円(内送料500円)」だと。
もちろんお断り。
遅いし高いし、なめてんじゃねぇか？ Yoshii9売り始めた頃のサポートはまともだったのに。売れて天狗になっている可能性大。

TimeDomain社の製品は、音は良いけどサポートがなってない、ということで決定。メイルも1週間に一度くらいしか見てないんじゃないかと思う。
物にはあからさまに安い部品を使い、しかも中国製造で品質管理も手抜きそうだから原価はかなり安いはず＝儲け分は大きいはず。物に自信があるなら安売りする必要はないが、その分品質やサポートには気を配って欲しい。

・・・だから・・・

TimeDomainLiteのACアダプタが壊れたら、DK072-B＋DK071-Eを買えばよい。
TimeDomain社から買う必要は全くない。というか、「買わないほうが良い」。
マルツの方が安くて早い。店舗もあるので、近くて大急ぎの人は買いにいけるし。

手間を惜しまなければ、適価で修理可能と言うこと。
責任が相手にあっても、自分でそれを解決して突き進むことこそが、脳ある人間の行動。

X68000で記録されたHDD/MO/DVD-RAMの読み出し方(限定的)

X68000で記録したDVD-RAMが見つかった。
DVD-RAMなので、最近のPCでも光学ドライブがそれに対応していれば読めるかと思った。Windows/MacOS/Linuxでは標準でFAT12/16/32で記録されたメディアを読むことが出来るからである。
しかし実際には一部しか読めなかった。
読むために、いろいろやってみた。

ということで、そのあたりの情報を「覚えているうちに」書いておこうと思う。
なお、X68000用のツールなどについては細かい説明をしない。また、ファイルシステムについての若干の知識を要する。

まずは、X68000のファイル/メディアをWindows/MacOS/Linuxで読む場合の問題点を先に列記しておく。

・8+3バイトの文字を超えた部分は切り捨てられる
Windowsの1ファイルシステムであるところFAT、というかMS-DOSのファイル名は8+3バイトであった(+3は拡張子分)。
X68000のOS、Human68Kのファイルシステムは基本的にFAT12またはFAT16準拠でありDOS互換だが、ファイル名部分を18バイトまで記録できる。これは、FATで予備になっていた10バイトをファイル名領域に割り当てたからである。ただし、識別はDOSとの互換性を考慮して8バイトまでとしてあった。TwentyOneを導入していれば18バイト全て識別させる事もできる。

WindowsではVFAT(Windows95で採用された、FATでロングファイル名を使うためのシステム)でその予備領域を使うようになった。従って、X68で記録されたその10バイトの拡張部分に関しては、どうやっても読むことが出来ず、バッサリ切り捨てである。この拡張部分の記録=ファイル名によってはVFATと誤認識して、正しく読めないこともある。
(かなりまれな現象ではあるが、何度か遭遇した。)

TwentyOneでファイル名識別を18+3文字に拡張していた場合、切り捨てによってファイル名が重複する可能性がある。この場合、後から出てきたファイルで上書きされてしまう。

余談だが、VFATとFAT32を混同している説明がたまに見受けられるのでちょっと説明。FAT32は、FATファイルシステムにおける、1File Allocation Table単位を32ビットにしただけのものである(厳密には他にもルートディレクトリの大きさが可変になったとか細かい違いはある)。VFATはFATファイルシステム上でロングファイル名；正確にはunicodeによる256バイトまでのファイル名記録をするのための「やり方」である。したがって、FAT16/12上でも実現される反面、FAT32だけどロングファイル名は使えないシステムもある(というか組み込み機器用に作った。そういう仕事してた)。


・半角カナ、2バイト文字は化ける
Human68Kのファイル名には半角カナ(0xa0〜0xdf)やSHIFT-JISでの2バイト文字も使うことが出来る。SX-Window上のファイル名には特に多い。

Windowsでは今もこれをサポートしてくれているのでそのまま表示もアクセスも可能であるが、MacOSやLinux上に実装されているFATドライバは8+3部分はASCIIのみ(VFATはUnicode)なので、文字化けする。文字化けはするが、アクセスは可能である。

ただしWindowsでは、ファイル名を8バイト目で切り捨てるとき、2バイト文字の1バイト目で切られた場合はアクセス不可となりエラーが発生する。これは結構多発する。
（Linux上には2バイト文字という概念がないので、単に文字化けするだけ。)

・英大文字しか受け付けない
X68→Windowsで一番引っかかるのがこれではないかと思う。WindowsというかDOSではファイル名は全て英大文字である。ロングファイル名で小文字が使えるようになったが、それはVFAT上で記録されているからであって、DOS互換の8+3バイトファイル名では全て英大文字に変換されている。
Human68Kでは小文字ファイル名を使え、そのまま記録する。ただし、ファイル名比較では大文字と区別されない。

小文字ファイル名があると、Windows上ではエントリとしては表示できるが、実体へのアクセスはできない。MacOSではエントリとしても表示されない。ところが、Linuxでは表示もアクセスも出来る。UNIX自体がファイル名に英小文字を許し、また大文字小文字の区別があったからであろう。 それをFAT相手でも有効にしてくれているのである。


TwentyOneを入れ、さらに英大文字小文字区別オプションをつけていると、Windowsから見た時、同一フォルダ内に同名ファイルが存在することになり、どういう結果をもたらすかわからない(うちにはそういう環境はないから)。


このような各OSでのファイル名の互換性を頭に入れた上、ファイルコピーを考える。


・物理的にドライブを認識させる
X68で記録したメディアでそれらが読める可能性があるのはSCSI接続のHDD、MOまたはDVD-RAMドライブに限られる。いや、3.5インチフロッピーも、ドライブさえ用意出来れば読めるだろう。FDS-120のようなUSB-3.5インチドライブも数年前までは入手できたが今はどうだろうか。
→3.5インチFDは、ドライブ自体が1.2Mフォーマット(いわゆる98フォーマット)に対応していれば読めるが、1.44M（IBMフォーマット)専用だと読めない。これは容量だけの違いではなく回転数が異なる。USBタイプのは、私が知るかぎり全てOKだったと思う。
5インチドライブに関しては、現在手に入れることはおよそ不可能だろう。

私が知るかぎり、WindowsXP時代まではPCMCIAのSCSIカードやUSB-SCSI変換器があったので、SCSIドライブを容易に接続できたが。今はどうだろうか。Windows7以降ではドライバが対応しているかどうかもわからない。(シリアルでない)PCMCIAカードスロットを持つノートPC自体が希少価値状態だろう。

・論理的にメデイアを認識させる
物理的にドライブが接続できても、メディアが読めるかどうかはまた別問題である。
Human68KはFATであるが、それより前にドライブとしての認識領域(MBR領域)のフォーマットがあり、ここは互換性がない。
Human68Kでフォーマットされたメディアが読めないのはこのためである。

残念ながらの、この部分を「後から」読めるように変換するツールはないと思う。
少なくとも私は知らない。しかし、「先に」読めるようにしておくツールはある。
GORRYさんのFIMである。現在も↓から入手可能である。
http://download.goo.ne.jp/software/contents/soft/x68/hardware/se036103.html
これでフォーマットしておくとIBMフォーマットとなり、Windows/MacOS/Linuxで読めるメディアが出来上がる。

私はX68を現役で使っていた時にもDOSとファイルやり取りすることがあったので、ファイル名の問題はともかく、ある時期以降FIMだけは必ず掛けていた。

余談であるが、実はFIMにはいくつかバグが居る。
・１セクター256バイトHDDで暴走する（可能性がある）
・FDS-120のようなProcessor Deviceで容量が表示出来ない
・Humanフォーマットのディスクで１パーティションの容量が一定(多分2000M)を越えると表示がおかしくなる
・フォーマットで書き込む値が一部おかしい
・６桁を越えるセクター番号に対応していない
実使用上ほとんど表面化しない/問題ないとは思うが念のため。
修正版も作った(日付から見るに2000年)のだけど、どこにもアップロードしないままだったなぁ。
今となっては検証環境がないので出すことも出来ないけど。


・・・結局

長々と書いたが、結局のところ
・FIMフォーマットされたメディアを認識させる
・Linuxで起動して読ませる
ことが基本となる。

Linuxはどれでもいいかわからないが、私はMacOS上のVMWare Fusion4上にUbuntuを入れて作業した。Windows機ならCD-ROMまたはDVD-ROMから起動できるKnoppixなどを使えばいいだろう。もちろんFATをサポートしている物しか使えないが。

その上でのだいたいの手順。

(1)Ubuntu起動
(2)Macの内蔵ドライブを共有してDVD-RAMを認識させる

(3)ファイルが見えたら、ローカルに圧縮して保存する
直接ファイルとしてコピーすると、エラーが発生するファイル名分をコピーした際、Ubuntu(12)ではカーネルエラーが発生してしまうことがある。圧縮だと圧縮エラーは発生するが、そこまでの圧縮ファイルとができる上、カーネルエラーも出ないので安全である。

(4)圧縮ファイルをWindows等目的のOSへコピーする。
方法はネットワーク経由でもUSBメモリ経由でも適当に。

(5)切り捨てられたファイル名や文字化けしたファイル名を手動で直す
2バイトまたは半角カナフォルダ名だけなら、先にWindowsでコピーして作成させておき、Linuxでコピーした実体をその下に移動すると、幾分楽にはなる。


以上、FIMさえ除けば、X68での操作は一切いらずにファイルの転送が可能になる。


うちではこれでFIMをかけてあるDVD-RAM/MOは(制約はあれ)読めるようになった。
が、やはりFIMでないMOも若干あったりして何とかしたいと思わなくもない。
X68実機環境を作れば一発解決だけど、それが大変だからなぁ。


もしX68エミュレーターの上でサポートしてくれるなら、知りうる限りの情報は提供するけど、あれらもXDF/HDSレベルの互換性であって、物理ドライブを直接接続できるものはないからなぁ。まあ、そのためにはデバイスドライバーを作る必要があって非常に難しいというのは解るが。

Windows95ではDOSレベルファンクションコールでディスクの直読みが出来たので、DOSプログラムとしてX68メディアを読み取るプログラムも作れたんだけど、今は禁止されてるから無理。Windows7が走るPC上でも動くDOS互換OSでもあれば作れる？昔はフリーのDOS互換OSもあったけど、今はどうなんだろうか。


そうそう、拙作FAT32ツールは、X68000上でFAT32+VFAT記録されたディスクを読むためのプログラムであって、Windows上でX68のメディアを読むためのものではない。どこぞで勘違いされているような話を見かけたこともあるので、念のため。

Macのスクリーンキャプチャーの保存位置の変更

Macには標準で画面のキャプチャーを取る(スクリーンショットを取る)機能がある。

キーの設定は、システム環境設定〜キーボード〜スクリーンショット〜 でわかるし、変更もできる。

標準ではShift+Ctrl+3で全画面、Shift+Ctrl+4ではキャプチャー範囲指定をしてそこを読み取る。

便利であるが、その保存位置を変更することが、システム環境設定では出来ない。


その変更方法。

(1)MagicianToolを使う方法
MagicianToolとは、Macの各種設定を簡単に変更したり、(簡易的に)ウイルスチェックをするツールである。無料。同種のものではOnyxが有名だが、それがちょっと敷居が高いのに対し、こちらはかなり簡単ではあるが私の使う限りでは必要十分である。

MagicianToolを導入し、最適化〜パラメータのスクリーンキャプチャ〜パスで記録フォルダでパスを入れた後、「適用」で設定できる。

(2)ターミナルで変更する
以下の2コマンドを連続で実行する
defaults write com.apple.screencapture location 保存パス名
killall SystemUIServer

どちらにも共通して気をつける点がある。
・保存フォルダ名に'('を入れてはいけない

例えば、~/Pictures/ScreenCapture(temp)とか書くと、MagicianToolでは一見設定できるようでいて、実は変更されない。ターミナルで実行するとエラーが出るのでわかる。
MagicianToolで何度設定してもうまくいかないので、ターミナルでやってみて気がついた。

他にも使えない文字があるかもしれない。MagicianToolでどうしてもうまくいかないときは、そのあたりに注意。


2013/05/10補足
iOSシミュレーターのスクリーンショットの保存位置はこれでは変更されない。
デスクトップ固定の様子。

MacでCPU利用率が乱高下/高止まりするとき

OS X Serverを導入したMacでCPU利用率が乱高下するという現象が発生した。

1桁台かと思えば100％になったりで、平均的に50％を超えていることが多くなった。
VNCで画面共有先から操作していると、操作とそれに伴う画面更新が途切れ途切れになってしまい 、ほとんど使い物にならなくなる。そのままOSが落ちることも何回かあった。

ところが、アクティビティモニタで原因を探ってもそれらしいタスクが見つからない。
全て多くても数％なのだ。

OS X Serverを入れた後に発生したので真っ先に疑ったのはそれだったが、それを外しても元に戻らない。
iTunes、外部からのアクセス、 ウイルスチェックなど思いつく項目は全て止めてみたが改善しなかった。

・・・

OS X Serverを導入したときにSpotlightでインデックスを作る対象のフォルダを限定的にするように変更した。 システム環境設定～Spotlight～プライバシーでサーバー用HDDを全て対象外にして、内蔵HDDも多くを対象外にした。接続するPCから検索することはあっても、サーバー自体のMac上では検索しないと思ったからだ。
事実、これで、つないでいるPCからのファイルコピーは速くなった。
が、その後にCPU利用率の乱高下が発生した。

Windowsでは検索用インデックスを付けているとCPUパワーをかなり持って行かれる上にHDD上にも大きないデックス情報を作るので、インデックスは付けない方がいい。
付けなくても通常のファイル処理には全く問題ないし、インデックスがなくても 高速検索可能なフリーウエアもあるので問題ない。


ところが、MacOSではSpotlightが作るインデックス情報をいろんな場所で使っているらしく、作らないと不具合が起こることもある。その１つがこのCPU利用率の乱高下である。

どうもファイルアクセスのたびにインデックスを作るのと同じ処理を走らせるらしく、これが非常に重い。しかもこの処理はOSのカーネル内部で行われているのか、アクティビティモニタには出てこない。

だから、乱高下を防ぐには、Spotlightのプライバシーに何も指定しない＝全てにインデックスを付ける、が正解である。

・・・

Spotlight用インデックスを付ける処理はmdworkerというプロセスとして見える。インデックス作成中はこれが高いCPU利用率を示すが、できあがれば自動的に止まる。

Windowsのインデックス作成処理は高いCPUパワーを持っていく上、非常に時間がかかる。丸1日おいても終了しないこともある。
一方Spotlightのそれは比較的短い時間で終了する。実利用500GBで3時間くらいであった。


これで乱高下問題は治った。VNCでの遠隔操作も快適である。

・・・

アクティビティモニタに表示されない理由は、ウインドウ右上にあるプロセスの選択リストで、「すべてのプロセス」を選択してなかったことによると判明。
デフォルトではここが「自分のプロセス」になっている。

・・・
 CPU占有率が高止まりするときで、iCoreServiceというのが動いていれば、これは「ウイルスバスター for Mac」の検索処理である。

これ、環境設定〜検索に設定しているタイミングで自動的に走り始める。
デフォルトでは月に1回、予約検索が有効で、推奨ファイルを検索する。
この検索処理が何をどうやっているのかわからないが、推奨ファイルとやらだけでも非常に数が多いことに加え、1ファイルあたりの処理も非常に遅く、1日かけても終わらないことがある。Windows版ではそんなに遅くないMac版は異常に遅い。

ウイルスチェックは基本的にファイルダウンロードとかメイルの閲覧時にだけ動いてくれればいいものなので、予約検索なんぞほぼ無意味。

ということで、さっさと止めてしまった方が吉。

そうでなくても「ウイルスバスター for Mac」は「とりあえず作ってみました」程度の出来で（Windows版より1世代古い)、機能的にも性能的にも最低限という感がある。
私はWindows版に付属されているからMac版を使っているけど、あまりおすすめはしない。

 ・・・

backupdというのが動いていたら、それはTimeMachineである。
こいつも結構CPUパワーを食う。
まあ、これは止めないほうが良い。バックアップするファイル(正確には除外するファイル)をこまめに設定すれば早くなると思う。

なお、TimeMachine中にもmdworkerが走る。バックアップしたファイルにもインデックスをつけている模様。 なので、バックアップ中はかなりCPU占有率が高くなる。

・・・
 
これをしても、OS X Serverを走らせていると、まだ時々利用率がちょっと上がることがある。OS X Serverは裏でいろんな、しかも機能をOFFしているはずの処理が走ることがあるが原因。ファイル共有するだけなら、OS X Serverは必要時だけ起動し、常時は止めておくのが吉。

ファイル/フォルダのアクセス権を一括変更(内包する項目に適用)するとLocumというプロセスが走り、これが高いCPU利用率を示す。ゴミ箱を削除するときにも走ることがあるらしいが、おそらくはアクセス権を変更して削除できるようにしているのだろう。
当然ファイル数が多いほど時間がかかる。ファイル数はわからないが、800GB強で10分はかかることがある。遅い処理なので時間はかかるが終わると引っ込む。30分も待って終わらないようなら異常なのでアクテビティモニタで停止させる。


そのOS X Server(v2.2.1)の問題については、他にもいろいろと書きたいことはあるが、それは別の機会に。

BOOTCAMPパーティションサイズの変更仕方

BOOTCAMPの問題について書いたが、そういえば「そのパーティションサイズの変更仕方」について書くと言いながら書いてなかった。

BOOTCAMPでWindows領域を作るときパーティションを切るが、そのサイズを後々変更したい場合があるだろう。私の場合、最初Mac領域を余裕を持って大きめにしていたが、結局(ほぼ)Windows専用機とするためMac領域を最小限にしてWindows領域を広げようとした。

ここで前述の通りいろいろな問題が発生したわけだが、ちゃんと正しい方法をとっていれば、それほど苦労なく変更できる。

・一番確実なのはWincloneを使う方法
Wincloneとは、BOOTCAMPのWindows領域をMacOS上でバックアップするプログラムである。
昔は無償だったらしいが、現在は有償である。ただし高くはないし、その分日本語にも対応しているし、格段に安定している（らしい）。無料であった旧バージョンを使った方法を乗せているサイトもあるが、面倒な上失敗する可能性も高いので、ここは有償でも最新版を入手するのが吉である。

これを使うパーティションサイズの変更手順。

0.念のため、MacOS部分はTimeMachineでバックアップしておく

1.WincloneでWindows領域をイメージ化する
ベタでイメージ化するのではなく利用されている領域のみZIP圧縮して保存される。
しかし、それなりの大きさにはなるので、それを保存できる外部HDDが必要である。
Mac領域内に入りきれば内蔵HDDでも行けるが、難しい場合が多いと思う。
当然、Mac領域を小さくしたいなら内蔵HDDに保存するのはだめ。
なお、NTFSでフォーマットされたHDDには、Paragon NTFSを導入していたとしても保存できない(必ず途中でエラーが発生する)。ネットワークで共有された他のMac上のHDDには保存できる。また、USB-HDDでNTFSとHFS+のパーティションを持っている場合、HFS+領域には保存可能。

また、サイズがサイズだけにそれなりの時間もかかる。夜中に走らすのが良いかもしれない。




2．ディスクユーティリティでパーティションサイズを変更する。
MacOSとWindowsの各領域の配分を変えると言った方がわかりやすいかも知れない。
Mac側にせよWindows側にせよ、元より小さくなる方は、元の領域内で実際に使われていたサイズより小さくはできない（だから、内蔵HDDにイメージを保存するべきではない)。

この作業をしてもパーティション0のMacOS領域は残るが、Windows領域は消えることになる。

3.Wincloneでイメージを戻す
パーティションサイズの変更ができたら、再度Wincloneを起動して、今度はイメージを戻す。
このときパーティションサイズが変更されていることを検知すると、 イメージ展開後にパーティション情報を書き換えてうまく合わせこんでくれる。ここがWincloneのえらいところである。


Wincloneを使う方法は、時間こそかかるが複雑な手順があるわけではなく簡単である。



もう1つ方法を思いついたが、これは試していない。
こちらは、うまくいけば無料でできる。
一応書いておく。

1．ディスクユーティリティを起動
2．Windows領域を「新規イメージ」で書き出す
3．パーティションを変更
4．復元でイメージを戻す
5．TestDiskでディスクを走査し、パーティション情報を再構築させる
　TestDiskについては「WindowsHomeServerのPC復元ディスクの重大バグ」のネタに書いたので、参照あれ。ただし、その動作の仕組み上、パーティションの変更を繰り返してるHDDでは誤動作する可能性も高い。

誰か試してうまくいったら、ご報告いただけるとありがたい。
自分ではもう二度とこんな面倒なことする気はないので。

Macのスタートアップ

Windowsで言うところの「スタートアップ」のMacOS MoutainLionでの位置。

システム環境設定〜ユーザーとグループ〜ユーザーを選択〜ログイン項目

で設定する。

Windows7←Macファイル共有が出来ないとき

MacからWindows7側のファイルを共有しようとしてできなかった時に、
Windows側で見るべき項目。

共有対象とするフォルダやファイルの共有設定は当然しているが、それでも共有できないとき。

（１）コントロールパネルから「ネットワークと共有センター」

 （２）ネットワーク接続図が出てくるので、左側の「アダプターの設定の変更」

 （３）ローカルエリア設定（ネットワーク番号は異なる場合がると思う）

 （４）ローカルエリアの接続の状況から「プロパティ」

 （５）共有のタブ

 （６）共有の設定をチェックしてOK。上側は必須、下側は随意で。

これでうまく行けば治る。
これでもダメなら、ウイルス駆除ソフトを一時的にOFFしてどうなるか調べる。
ちなみに、ウイルスバスタークラウド（2012）はONにしてても大丈夫。
まあ、今時のそれらでファイル共有設定も通せないようなダメなのはないと思うけど。
（昔はあった。）

「手習い君」が「Appliv」にて紹介されました。

「手習い君」が「Appliv」にて紹介されました。




「手習いくん」は、手本の文字をなぞって練習するアプリです。
般若心経の写経から小学生の漢字やアルファベットの練習も出来ます。
内蔵手本だけでなく、ユーザーが作成した手本も入れることが出来ます。

手書きの内容は、メールで送ったり、AirPrintで印刷することが出来ます。

手習い君

・・・



「手習い君」へのご意見ご要望は、これにコメントでどうぞ。

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で行うから。）

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

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領域の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へ保存すると初期段階でエラーが発生する(しかもフォルダーにカスが残る)。

・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で戻したWindows領域はMac側から起動対象ディスクとして認識されないことがある。
具体的には、システム環境設定の起動ディスクの一覧に出てこない。
そのため、Option（またはAlt）キー押し起動で起動デバイスとしてWindowsを選択し、Windows内のBootCamp設定で「Windowsから起動する」に設定する必要がある。
これをしないと、毎回Option(alt)押し起動するハメになる。
これはWincloneの問題ではなく、Paragon NTFSの所業と判明。

・途中でエラーが出て止まってしまう時は、ディスクユーティリティで「ディスクの修復」および「アクセス権の修復」をかけると治る事がある

・Windows7のファイル暗号化は使わない
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を使うと。

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にはこのツールは絶対いれておけか、
実はパーティション情報だけなら復旧方法があったとか、
そういう情報も追って公開したいと思う。

Xcodeでリンクエラーが出るとき

Xcodeでリンクのエラーが出る。

"_OBJC_CLASS_$_オブジェクト",referenced from:
～

オブジェクトが見つからないと言っている。

でも、プロジェクトにソースはちゃんと入ってる。

悩んだ末にやっと思い出した。
「ターゲットになってない」。

Xcode4から、ここにターゲットに入れるかどうか、
単純に言えば実コンパイルするかどうかのチェックが付いた。ここにチェックがないとコンパイル対象から外れる。

ソースコードをAddしただけではここのチェックが入らないので要注意。

正確には、外部にあるソースをAddするとき、.m単体で入れたときはチェックが付き、.hと同時に入れると付かないようだ。ヘッダーはコンパイル対象ではないからだ(オブジェクト生成対象ではないと言うべきか)。

Xcodeが4になった当時からある、バグに限りなく近い仕様で、未だ直っていない。

自分でも何回か引っかかってるだけど、都度忘れてしまうので、今回はここに書いておこうかと。

ひょっとしたら前にも書いたかも知れないけど、そのときは「ぼけ中年ゆえ仕方ない」とお目こぼしを。

ATOK2013インストール時の問題→解決

今日発売の一太郎２０１３「玄」。
早速インストールしてみる。
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の開発中です。
ただし、本業としての開発ではありませんので、いつ完成するかは解りません。