Title

iOS発売年ごとの最終対応OSバージョン(2016年版)

以前作成した、デバイスごとにサポートするiOSの最終バージョンを一覧を更新しました。

・iOS5以前をサポートすることは、現在困難だと思います。
・iPhone3GSとiPod touch代4世代をサポートしなくて良ければiOS6のサポートをやめられます。
 実質もうOKかと思います。
・iPhone4をサポートしなくてよければiOS7のサポートをやめられます。
・iOS8を最終バージョンとする端末はありませんが、iOS8のiPadはまだ多数あるようなので対応しておいたほうがいいかも。

[3.1.3まで]
(2007)iPhone
(2007)iPod touch 1gen

[4.2.1まで]
(2008)iPhone3G
(2008)iPod touch 2gen

[5.1.1まで]
(2009)iPod touch 3gen
(2010)iPad 1gen

[6.xまで]
(2009)iPhone3GS
(2010)iPod touch 4gen

[7.xまで]
(2010)iPhone4

[8.xまで]
該当なし

[9.xまで]
(2011)iPhone4S
(2012)iPod touch 5gen

(2011)iPad2
(2012)iPad mini
(2012)iPad 3gen

[10対応(最終バージョン未定)]

(2012)iPhone5
(2013)iPhone5C/S
(2013)iPad mini2
(2014)iPhone6/6 Plus
(2015)iPhone6S/6S Plus
(2016)iPhoneSE Plus
(2016)iPhone7/7 Plus

(2015)iPod touch 6gen

(2012)iPad 4gen
(2013)iPad Air
(2014)iPad Air2
(2015)iPad Pro
(2016)iPad Pro(9.7インチ)

(2014)iPad mini3
(2015)iPad mini4

QRコードの誤り訂正レベルの判別方法~アイカツスターズ!のQRコードを分析してみる

(分析ってほどのことはしませんが、既に生成済みのQRコードの誤り訂正レベルはどれなんだろう? って思った時に調べる方法についての記事が意外となかったので)

バンダイにものすごい売上をもたらしたアイカツ!~アイドルカツドウ~ がアニメも終わって、ゲームも稼働終了となり、アイカツスターズ!という新しい展開にするそうです。
アイカツカードといえば裏面のバーコードを読み取る形式だったので、ものすごい種類(2500種類くらい?)を捌ききれるのかと検証してみましたが、全然余裕でしたというのがその時の結論。

ちょうどプロモーションカードを配布していたので、娘のために貰ってきました。

このカードはプロモーション用なので普通の印刷ですが、筐体から排出されるカードはオンデマンド印刷に変わります。
というわけで、裏面にあったバーコードが表面のQRコードに変わりました。
実は今主流の形式ですね。

というか、「妖怪ウォッチともだちウキウキペディア」が既に同じ形式なので新しくもなんともありません。

こうやって写真撮ってしまうと、QRコードも利用できてしまうのが困る。
以前はカードしか挿入できなかったので、一旦紙に印刷しないとスキャンできませんでしたが、今回は筐体のCMOSカメラに見せる形式のようなので写真撮影→スマホ画面でも認識するでしょう。
なので、一応QRコードをボカしました。

前回同様、どのくらいのコードが入っているのか見てみますかね・・・。
別にセル数変えられるからいくらでも拡張できちゃうんだろうけど。

まず、QRコードリーダーで読み込んでみると、「http://dcd.sc/」で始まるURL形式で84文字のデータになっています。カードの固有情報と思われる部分はそのうち65バイトかな?
URLには記号も含まれているのでQRコード的にはバイナリ扱いになります。

セルのサイズから、バージョンは8です。
あと、QRコードには誤り訂正レベルというのが4種類(L,M,Q,H)があり、Hが最も復元しやすく、Lが最もデータ量が多くなります。

誤り訂正レベルは何使ってるんですかね。(84byteは一番誤り生成レベルが高いHでちょうど入るのでおそらくHなんでしょうけど、一応確認します)

下の画像は、上のカードのQRコードの左上を拡大したものです。

赤枠の部分は、タイミングパターンというもので、必ず白と黒の交互のパターンになっています。
他の部分のセルを切り出すときのヒントになるマーカーみたいなものですね。

青枠の部分が形式情報を保存している部分です。
15bitあります。なお、この位置以外にも、右上と左下の検出シンボルにも分割して同じ情報が入っています。(汚れや隠れに対応するためと思います)

この0~14の部分を、白を0,黒を1として読み取ると、
001110011100111
になります。(この数字の左端が上位ビットなので=画像の14の位置です)

この15bitのうち、最初の2bitが誤り訂正レベルを示しています。
ただし、同じビットが続くと読み取り精度に悪影響を与えるため、101010000010010でXORをとってあります。
といわけで、もう一度XORをかけて元に戻すと、
100100011110101
になります。

最初の2bitは10ですね。
誤り訂正レベルは以下のように定義されていますので、このコードの誤り訂正レベルはHということになります。

誤り訂正レベル一覧:
L 01
M 00
Q 11
H 10

もう少し、実用的にまとめると、上の画像の14と13の部分を見て、
□□(白,白)だったら、誤り訂正レベルH
□■(白,黒)だったら、誤り訂正レベルQ
■□(黒,白)だったら、誤り訂正レベルM
■■(黒,黒)だったら、誤り訂正レベルL
です。

というわけですので、セルサイズが変わらないという前提で言えば、コーデ(衣装)カードは84byteのURL形式が固有IDとして割当られるようです。

旧アイカツカードにも実はQRコードも併記されているんですが、こちらはもっとコード量が少ないです。
更にURLが「http://aikatsu.com/」になっているので、固有コードはもっと短いです。

旧アイカツカードの裏のQRコードの誤り訂正レベルはL(7%復元)、バージョン4だったのに対して、アイカツスターズのQRコードは最も誤り訂正レベルの高いレベルH(30%復元)、バージョンは8になっていますね。オンデマンド印刷での品質を考慮した結果でしょうか。

ところで、Webにある、QRコード生成サイトで、同じURLのQRコードを同じバージョンと誤り訂正レベルで作ってみても、QRコードが同じになりません。
同じになる場合もあるんですが、QRコード生成時に、いまいち規格上固定されない部分や、規格の年式による微妙な違いがあり、実装により変わるみたいです。

アイカツスターズの筐体が、この部分の違いまで見極めて勝手に作ったQRコードを不正なカードと判断するかするかどうかは・・・まぁ、しないでしょうね。

なお、ライバル機である、プリパラのQRコードは白黒反転されております。
これはデータの保護というよりは、デザイン面での配慮な気がします。

(つづき)Y!mobileはHTTPのプロトコルを監視して帯域制限を行っている

前回の記事のつづきです。

月が変わり、帯域制限の対象ではなくなったはずなのでもう一度測定してみました。
(1MBのファイルを転送)

ファイルタイプ 転送時間 速度
.zip 1.2秒 849KB/s
.bin 0.9秒 1.10MB/s
.exe 1.1秒 966KB/s
.lzh 1.2秒 864KB/s
.pdf 1.2秒 869KB/s
.aikatsu 1.2秒 864KB/s

あ、速い・・・。

帯域制限がかかっていたファイルタイプと、そうでないファイルの速度差がなくなりました。
月末に測定した時の転送時間は、zipファイルは80秒弱、pdfファイルは2秒ちょっとでした。
上記表以外にも複数回測定してみましたが、概ね安定した速度です。

また、帯域制限がかかっていないと思っていたファイルでも転送速度がだいぶ速くなっています。
(同じく平日で、時間帯もほぼ同じですが、違う日ではあるので単なる通信環境の違いかもしれませんが)

というわけで、Y!mobile LTEプランの帯域制限中の挙動はおそらく以下のような挙動かなと思われます。

・全体的に帯域制限される(3Mbpsくらい?)
・HTTP転送において、レスポンスヘッダに含まれるContent-Type: が特定のタイプと一致すると更に帯域制限される(96Kbpsくらい?)

ただし、帯域制限の目安の通信量をどの程度超えたかや、基地局の混雑具合によって制限値が変わるという書き込みも見られるので、数値は環境によって変わるかもしれません。

Y!mobileはHTTPのプロトコルを監視して帯域制限を行っている

旧EMOBILE LTEの回線でアプリのテストをしているときに謎の不具合として発見しました。
スピードテストや、普通のブラウジングは快適に行えているのに何故かzipファイルの転送時のみものすごく遅くなり、最初は自分のアプリの不具合を疑いましたがHTTP通信全般で発生するようです。

契約回線は旧EMOBILE LTEで、「当月のご利用通信量が10GB以上」で帯域制限を行うと公表されています。
テストした日までの通信量は10.588GBで、目安の通信量を超過している状態です。

この状態でHTTPによるリクエストを出すと、ファイル種類によって挙動が変わります。
月初めはどのような挙動になるか不明なので来月になったらやってみます。
以下実験結果です。

以下コマンドで1MBのダミーファイルを生成。
% dd if=/dev/zero of=test.zip bs=1M count=1

ファイルの中身はそのままで、拡張子のみを色々変えてwgetで転送してみた結果が以下です。

ファイルタイプ 転送時間 速度
.zip 95秒 9.68KB/s
.bin 72秒 13.1KB/s
.exe 74秒 12.6KB/s
.lzh 73秒 12.8KB/s
.7z 78秒 12.1KB/s
.rar 77秒 12.7KB/s
.jpg 2.1秒 480KB/s
.png 2.3秒 436KB/s
.pdf 2.6秒 388KB/s
.cbz 2.1秒 495KB/s
.pptx 3.1秒 335KB/s
.aikatsu 2.0秒 502KB/s

1回づつしか測定していないので誤差は大きいと思いますが、ファイルタイプによって明確な差がついていることは明らかです。10倍どころか30倍違う・・・!
1MB転送するのに1分以上もかかっているようでは、実用的にはかなりキツイ状態です。

なお、HTTPSにした場合は帯域制限かからなくなります。
(どれでも変わらないはずなのでzipのみ実験)

ファイルタイプ 転送時間 速度
zip
(HTTPS)
2.8秒 371KB/s

この結果から、Y!mobile(のEMOBILE LTEプラン)では、HTTP通信の内容を見て帯域制限を実施していることがわかります。
また、.aikatsuは制限がかかっていないので、「JPEGは制限しない」のようなホワイトリストでなく、「zipは制限する」といったブラックリスト方式みたいですね。
僕が発見したのはzip,bin,exe,lzh,7z,rarですが、他にもあるかもしれません。

次にファイルタイプの判別方法ですが、ファイルの拡張子ではなくMIMEタイプを見て判別しているようです。

.htaccess ファイルに以下を以下のようにしてMIMEタイプを変更して同じRARファイルをダウンロードした場合です。

AddType image/jpeg rar

MIME 転送時間 速度
application/x-rar-compressed 93秒 9.25KB/s
image/jpeg 2.1秒 491KB/s
www/unknown 2.7秒 376KB/s

その他、いくつかオレオレMIMEを指定してみましたが帯域制限はうけませんでした。

よって、HTTPサーバの設定を変更してMIMEタイプを変えてしまえば帯域制限を免れることができますね…。
というか最近のWebサーバはRARとかまでMIMEが正しく設定されているのか・・・。

サーバ管理者側の対策

スピードテストで測定すると速いのに、お前のサイトからダウンロードすると遅ぇよ! と、どうしていいか分からない苦情が来ることに備えるには以下の対策が考えられます。
(実際これが原因で帯域制限の仕様を知った・・・)

・HTTPSを利用する

昨今色々あるので、もう全部HTTPSにできればそれが良いかもしれません。。。

・MIMEタイプを変更する

これを変えてしまうのは反則かもしれませんが、現実的にはzipなどのMIMEが間違っていてもダウンロードさえされれば別に困りません。
ただimage/jpegなどにするとブラウザ側が困るので、www/unknownあたりにしておくのが無難かと思います。

AddType www/unknown zip
AddType www/unknown rar
AddType www/unknown exe
AddType www/unknown lzh
AddType www/unknown 7z
AddType www/unknown bin

のような感じで.htaccessファイルに書いておくだけで転送速度が30倍に! すげえ!
とりあえず、ComicGlassのサンプルファイル置き場はこの対策で乗り切ります。

もちろんブラックリストに入っているMIMEは今日現在の挙動なので今後は変わるかもしれません。
自分で薦めておいて何ですが、みんながこんなことやり始めたらHTTP崩壊だな・・・。

利用者側の対策

できることは少ないですが、HTTP通信の内容がわからなければいいわけなので、VPN接続してトンネル経由でアクセスすれば制限はかかりません。

ただ、帯域制限としては良心的な気もします。

実際に公表された通信量を超えても、HTML,JPEGやPDFなど通常のブラウジングには制限がかからないので通常の利用に弊害がありません。
また、HTTP以外の通信は特に制限されている様子はありません。

僕のようなzipをHTTP転送するのに特化されている特殊なアプリ開発者にとっては罠もいいところですが・・・。

補足

上に書いた通信速度はByte/秒です。
通信速度はbit/秒で書いてあることも多いので注意してください。

12KB/sは96kbpsになります。
400KB/sは約3.1Mbpsになります。

よって、今回のテストでも制限を受けないファイルタイプであれば3Mbps程度は出ており、たぶん制限なくてもこんなもんです。

追記(15/07/22)

いくつか補足と訂正を。

・「最近のWebサーバはRARとかまでMIMEが正しく設定されているのか・・」と書きましたが、正確には(Apacheが)/etc/mime.typesを参照してるだけですね。すみません。

・測定は平日昼間(正午ころ)行っています。夜間はプロトコル関係なく帯域制限がかかります。こちらは「24時間ごとのご利用通信量が約366MB以上の場合当日21時から翌日2時まで制限」という方にひっかかっているものと思われます。
 測定が1回づつしかやってない件については、面倒だからなんですが、数値見てもらえばわかるように1回で十分に誤差ではない有意な差が出ているので問題ないかと思います。実際体感してみればわかりますけどとんでもない差なので・・・。2秒or1分の差ですからね・・・。

・上記挙動は、記事中にも書きましたが公表された帯域制限にひっかかっている状態の話です。
 プロトコルによって帯域制限かけるのは、古くはP2Pなどで遮断はダメだけど帯域制限ならOKという方向で概ね世の中落ち着いているようなので、キャリアは真っ当な対応をしていると個人的には思ってます(ただ、帯域制限は僕の契約時には存在せず、後から導入されたものなのでキャリアとしてもあまり強く制限できない事情もあるのかもしれません)。
 一方でサービス提供者やアプリ開発者の立場からはすごく迷惑なので仕様を明確にしてユーザーに分かるようにしておいてほしいですね。

・MIMEタイプの変更は本当にやるひとはあまり居ないと思いますが、普通のWebサイトだったらやっぱ止めたほうがいいと思います。
 一方で、スマホなどのアプリ内でzipでアーカイブしたアプリ内データをHTTP使ってダウンロードするなんて仕様にしていると、「このアプリだけクソ遅いので星ひとつです。金返せ」とか書かれかねないので本当に注意が必要です。
 アプリ側を変更しないで今すぐできる対策としてはやっぱMIMEタイプ変更は、けっこういいアイデアかと思ったんですけど。
 どちらにしても、これからは「IPネットワークもはや透過的ではない」と思ってアプリケーション開発をしないといけないってことですね。崖に負けるな!

Windowsのファイル名ソート順の再現が難しい件(StrCmpLogicalW)

最近「ComicGlassのソートがWindowsの並びと違う」とご意見を頂きました。

WindowsXP以降ではファイル名のソート順が数値などを解釈する自然な並びになるようになっています。
よって単純なコードの比較とは違う結果になります。

よく説明されるのは、
20string
2string
3string
というソート順だったのが
2string
3string
20string
という感じになることでしょうか。

WindowsであればStrCmpLogicalW()というAPIを呼び出すとこのソートが行われます。
Windows以外の環境でこのソートを再現する方法は、検索するといくつか提案されていますが、どうも結果が違います。
公式な仕様が見つかればいいんですが、どうも見つかりません。

そこで、それを再現すべくそもそもWindowsがどのようにソートしているか実験してみました。
(特に海外のサイトの情報はUnicode文字に関する配慮がほとんどされてない事が多いので)

結論から言うと、StrCmpLogicalWを再現するのって無理ゲーなんじゃないかと・・・。
いい方法あったら是非教えてください。

とりあえず、以下調査結果でございます。

・StrCmpLogicalWは記号、数値、その他文字の順で並ぶ

ASCIIやUnicodeでは「!」は「0~9」より前にあるが「;」などは数値より後です。
しかしながらWindowsでは「;」などの記号も数値より前に並びます。

(Unicodeコード順)
!test.txt
0test.txt
;test.txt

(Windows)
!test.txt
;test.txt
0test.txt

というわけで、その文字が「記号」であるか「数値」であるか「その他文字」であるかを区別しているようです。

そこで問題になるのが、何が記号で何が記号でないか。

(記号になる例)
!
;
®
µ
§
»

(記号にならない一例)
¼
À

うーん。規則性がわからん。
プログラムを組んでStrCmpLogicalWで実際に試してみたのですが、かなり後ろの方のコードまで記号扱いになるものとと文字扱いになるものが入り乱れています。
どうもUnicodeコンソーシアムが規定するUNICOD文字一覧表に記号かどうかの情報があるようです。
つまりUnicodeとして記号かどうかで判断されており、それは規則性などなく全一覧を知らないとどうにもならない。
まぁ、それだけなら全コードの情報を持っておけばいいのですが・・・

・・・しかし!
Windowsが知らない新しいUnicodeは正しく解釈していないような気がします・・・。

例えばU+2639(☹)、U+263A(☺)、U+263B(☻)は記号扱いですが、その他顔文字は記号になりません。
もしかしたらWindowsではサロゲートペアが正しく処理されていないだけかもしれません・・・。

これは心が折れますね・・・!

・StrCmpLogicalWは全角の記号も半角と記号と同じ扱いになる

同じ記号の場合は全角の方が後になる。
・・・ってことは正準等価性を使った正規化してるんでしょうかね?
その説を支持する結果として「»」が「§」よりも前に並ぶんですよね。コードは後ろなのに。

しかし後述しますが、数値で混在すると別々に評価されるっぽい。つまり単純に先に正規化しても駄目と・・・。

・StrCmpLogicalWは数字が並んでいる場合はまとめて1つの意味付けがされる

0001.txt
2.txt
003.txt

これはファイルに0から順に名前つけて桁が増えた時に変な順番になるのを防げます。

・StrCmpLogicalWは20桁以上の数値は数値として扱わない

符号なし64bitで表せる値の最大値は18,446,744,073,709,551,616で20桁なので、20桁目からオーバーフローします。
よって、Windowsも64bit演算で扱える最大値の19桁まで取り扱うようになっていると思われます。
これは実装が楽で助かります。

・StrCmpLogicalWは全角の0~9も数字として扱われる
 ・ただし半角全角混在の場合はそうならない。何故だ・・。

情報求む・・・・!

とりあえずASCIIコードにある記号だけ記号として解釈し、数値は19桁まで数値として認識する、という方法でだいたい近い結果にはなります。一致はしませんが。

円柱を横から見ても四角ではない

娘が小学校1年生になりました。
どうも「算数」って苦手・・

娘が納得しなかった問題で、

”(これを)よこから みると しかくに みえるね!”という男の子が出てくるのですが娘はこれに納得しないのです。

「四角にはならない」と言うのですが・・・うん、僕にも四角には見えない。

円柱は立体物で、「四角に見える」とか「円に見える」と言うには平面に投影した結果を言っています。

3次元の形状を2次元に投影する方法はいくつかありますが、目でみる場合には「透視投影」を行うことになります。
要するに遠くのものは小さく見えるし、近くのものは大きく見えます。

つまり、、、

円柱を描いてみます。

視点を変換して横から見てみます。

四角じゃない。

これが四角に見えるためには無限の距離から見なければなりません。もちろん無限の距離にあるものなんて大きさが限りなく0なので見えません。
図面のように平行射影すれば円柱の側面は四角に見えるかもしれませんが、目で見たら絶対四角にはならないんですよね。

おそらく問題の意図としては正射影したらどんな形かと言いたいんだとは思いますが、正射影を説明するのも難しいし・・と思ったけど、「遠くから見たら四角っぽくなるでしょ」というファジーな説明でなんとなく理解してくれたみたいです。。
うーん。算数やっぱり難しい。。

アイカツ! カードの固有番号は枯渇しないのか

カードダスといえば、1998年から展開しているバンダイのトレーディングカードで、ちょうど僕が小学生くらいの時に出てきた覚えがあります。

2005年からはバーコードが印刷され、お店の筐体(ゲーム機じゃなくてカード販売機という事で風営法を逃れているらしい・・)でゲームと連動するデータカードダスが展開されています。
最初のタイトルはドラゴンボールだったような気がします。

プリキュアシリーズやアイカツはだいぶカード種類が多いと聞きます。
想定外に売れて、妖怪メダルのように割り当て固有番号が不足するんじゃないかと不安になります。

玩具のコードって徹底的に省略されてるじゃないですか。

さて、頑張ってシンボルを解読するぞー!
と思ったんですが、どうもコレCODE128の既存の規格そのままですね。

シンボルを読んでみます。
以下のようになります。

数値でいうと、103,33,43,20,18,17,55,43,40,46,53になります。

103はCODE Aの開始、つまり英数+制御コードでキャラクタが構成されることを示します。(小文字含まず)
53はチェックサムですね。
計算すると確かに53になります。
最後のシンボルはSTOPシンボルです。

というわけで、このカードの固有IDはAK421WKHNです。
ちなみにカード名称は「ピンクトルテシューズ」(星宮いちご)

本当に固有記号としての意味しかないようです。ただし最初のAKはアイカツを表しているようです。

iPhoneでバーコードを読み取るプログラムを書いてみました。
結果はこんな感じ。

実はorg.iso.Code128をセットすると、iOS標準のライブラリで認識可能。数行で実装できます。。

CODE128には、コードA~Cまでの文字セットがあります。
コードAは英数字+制御文字、コードBはASCIIのみ、コードCは数字のみ。

というわけで、DCDではコードAで記録しているようです。
データ領域は英数字で9文字分ということになります。

最初の2文字はコンテンツの種類を表しているようで、アイカツ!の場合は”AK”から始まります。
ちなみにプリキュアは”PR”のようです。まぁ、なんとなく理解できる記号ですね。

バーコードのデータ9文字から”AK”の2文字を引くと残りは7文字です。
このあたりで、もう表題に書いたことは無かったことにしたい感じですが、、

とりあえず英数字のみで割り当てるとします。
そうすると、アルファベット26文字+数字10文字の36通り×7桁なので、78,364,164,096 種類のカードを発行できることになります。

つまり780億種類以上なので、カード側の固有記号が枯渇することは全く持ってありませんね…。
AKの部分に新たな記号を追加することだって出来るわけですし。

そういえば前期プリキュアのプリカードは、パッと見ても嫌な予感のする変な切り込みがありますね。
これはたぶん玩具で読み取りを意識した、本当に省略されたコードだったと思われます。

妖怪ウォッチ ともだちウキウキペディアはどうやらQRコードに変わってるようですね。

NBNS(NetBIOS名の解決)に失敗する

タイトルのとおり。

どうも、Windows相手にNetBIOSの名前解決を試みると失敗することがあるようです。
ネットワーク・アナライザで見ると、リクエストは飛んでるのに応答が来ない。
発生条件は不明ですが、テストで変なリクエスト送ったあとに起きやすい気がするけど、何もしてなくても起きる時もある。

理由は不明ですが、一旦失敗するようになると、特定のIPアドレスから発信したものに対して応答が返らなくなる模様・・・。

全くそのままでIPアドレス変えると動くようになります。

このあたりエラーメッセージを簡略化してたので(接続できませんでしたくらいに)、次からメッセージ入れようと思います。
基本ここで失敗はしないと思っていたので。

どうもSMB/CIFS周りはロバスト性に欠けてやっかいですわー。
Windows同士でも調子わるいときありますもんね。

無駄にSMB/CIFS周り(のバッドノウハウ)に詳しくなっていく・・・。

socket()の戻り値0は正常値である!!!

ネットワークプログラミングの基本中の基本。socket()関数があります。
(基本すぎて今ではもう直接使う人はいないのかもしれませんが僕は使います。。)

socket()関数は戻り値としてソケットのファイル・ディスクリプタを返します。
このソケットのファイル・ディスクリプタが何故か現代人には勘違いしやすいようで、うっかり0をエラー値だと思い込んでしまいます。socket()はエラーが発生したときには-1を返します。
これがうっかり間違えます。実際0が返ってくることがありますのでたまに動かないという分かりにくい不具合の原因になります。

わかっているのにうっかり間違えた例が以下のような感じです。本当に良く見かけます。自分も間違えますが・・・。

int fd = socket(AF_INET, SOCK_STREAM, 0);
if (fd <= 0) {
	// COV_NF_START - we'd need to use up *all* sockets to test this?
	startFailureCode = kGTMHTTPServerSocketCreateFailedError;
	goto startFailed;
	// COV_NF_END
}

おそらくポインタを返す時の失敗はNULLだろう、ハンドルを返すときのエラーは0だろう的な思い込みがあるせいではないかと思います。
WindowsのAPIは成功すると非ゼロを返すという仕様のものが多いので、そういう普段使っている環境での慣れもあるのかも・・・。

ちなみに上記のコードはGoogle Toolbox for Macの一部にありました。

同様に

if(soc){
	close(soc);
}

みたいなミスもうっかりやりがちなのでお気をつけください。

WindowsのソフトウエアRAIDを監視してメールで通知するソフト

・・・タイトルのようなソフトをリリースしましたのでお知らせします。

リリースしたのは少し前ですが、記事にしていませんでしたので。

最近のWindowsではソフトウエアでボリュームのミラーが作れるようになり、HDDの故障に備えることができるようになりました。
Windowsのミラーの良いところは何より扱いやすいことです。BIOS画面一切さわる必要ありませんし。

しかし、いざ障害が起きた時にそれを知る手段がイマイチないのが問題でした。

というわけでステータスが変わったらメールするソフト作ってみました。

こちらでございます。
http://arinkosoft.com/download/asvolumestatuschecker/

カレンダー

2016年12月
« 11月    
 1234
567891011
12131415161718
19202122232425
262728293031  

▲Pagetop