「FlashAir / WiFiSD8 がWiFi接続している間に写真が追加されたら写真を自動的にDLする」機能に今トライしているところです。
部屋に籠ってフィギュアなり何かブツ撮りをひたすら続けるときに少し便利かもしれません。
2014年2月21日金曜日
2014年2月18日火曜日
futa8 Release 21
futa8 Release 21 が Windows ストアからインストール出来るようになりました。
インストールに成功すると、futa8 のバージョンは 1.1.0.129 になります( チャーム→ 設定→アクセス許可、で確認できます）。
 |
| クリックでストアに移動 |
インストールに成功すると、futa8 のバージョンは 1.1.0.129 になります( チャーム→ 設定→アクセス許可、で確認できます）。
変更点
futa8 再起動時にスレッドが表示出来なくなる場合がある不具合の修正
画像表示モードでアプリ表示領域が変更された場合、領域サイズに合わせて画像の表示倍率を変更するよう修正
2014年2月14日金曜日
futa8 Release 20
futa8 Release 20 が Windows ストアからインストール出来るようになりました。
|
| クリックでストアに移動 |
インストールに成功すると、futa8 のバージョンは 1.1.0.128 になります( チャーム→ 設定→アクセス許可、で確認できます）。
変更点
futa8 がOS に終了された場合、futa8 再起動時に状態を復元するよう変更
futa8 が他のアプリの背面に回っている間、メモリ状況等によりOSがfuta8 を終了する事があります。複数のストアアプリ・デスクトップアプリを同時に使っている場合、そこそこ頻繁に発生します。この状態でfuta8 を起動…スタート画面でタップ・クリック、画面左端のタスクリストから選択等…を行うと、
これまでのReleaseでは、
futa8 は起動後、初期状態の板画面を表示していました。
今回のRelease 20 からは、
futa8 は（なるべく）OS に終了された時点の状態に復帰します。スレ画面を表示していたならばそのスレ画面、板のカタログ画面ならばその板のカタログ画面に復帰します。
ただし、場合によっては復帰できない場合があります（スレがもう無い、カタログから見つけられない場合等）。
また、手動でfuta8 を終了した場合・OS の再起動後等、通常の終了が行われた場合は、これまで通り初期状態…板画面から起動します。
………
この機能、ストアアプリは本来対応しているべきものなのですが、futa8 は再起動後にスレが残っている保証も無いブラウザなので…サボっておりました。すみません。
最近は便利なストアアプリも増えたためアプリを同時に使う事も多く、それにつれfuta8 がいつの間にかOS に終了されてしまっている事が増えてきました。これはまずい、ということで今更ですが対応しました。
Changes - futa8 Release 20
futa8 release 20 is available at Windows Store.
Restore app state when the app was terminated by OS.
2014年2月2日日曜日
Desktop App が動く Windows RT 機の謎
この記事のまとめ
ご存じの通り、Windows RT で動作する ユーザー アプリケーションはWindows ストア からインストールするストアアプリだけで、デスクトップ アプリケーション…Win32ベースのアプリケーションは動作しません(*1)。
ですが、.NET 以降のWindows にはOSの中に.NET Frameworkのビルド環境が一通り入っていることが知られています。Windows RT も例外ではなく、.NET v1, 2, 4の参照DLLと、.NET 4用のcsc.exe, csharpのコンパイラが入っています。
何に使っているのかは僕は知らないのですが…使うんだから入ってるのでは？NGEN用？ そして、動くのなら案外ユーザーアプリもビルドしたら動いちゃったりして？
と、なんとなく考えました（この先を読むと判りますが、この仮定はほぼ間違いでした が、話の進行上「そうかも？」という体で読んで頂けると幸いです）。
(*1) Microsoft 製の「Windows RT向けDesktop アプリ」は動作します。OS付属のメモ帳やエクスプローラー、加えて、VisualStudio 用のRemote Debug Tools（MSのサイトからDL可能）等がそれです。MS製だけ許すための署名＋ハッシュ付きバイナリなのかなーと想像しますが確認はしていません。
確認は簡単で、超単純なC# のプログラムを OS組み込みの.NET Frameworkでビルドしてみます。
Windows RT 機上でCommand Prompt を開き、
これを手持ちのASUS VivoTabRT で試すと、
おお。あっさり動きました。これは楽しい。ARM版VisualStudio なんてものは存在しないので本格的な開発は無理ですが、出先でC#の簡単なプログラム組んで遊ぶくらいは出来そうです。
ただ、上にも書いたようにWindows は署名を使ってプログラム実行許可・不許可を判断している（はず）ですが… 今ビルドしたこのプログラムはどういう扱いになるのだろう？謎です。
なので、今ビルドしたプログラムを、手持ちのSurface RT （色々あってRT二台持ちなのです）にCopyして実行してみると、ダメでした。…実行PC上でコンパイルしないとダメなのかな？とSurfaceRT 上でも全く同じ事をしてみても、
「このバージョンのfoobar.exe は、実行中のWindows のバージョンと互換性がありません。コンピュータのシステム情報を確認してから、ソフトウェアの発行元に問い合わせてください」
ビルドは通るのですが、実行しようとすると同じエラーが表示されます。？？？？？ ちなみにこれ、x86用のDesktopApp をWindows RT で実行しようとした時に表示されるエラーメッセージと同じです。
？？？？何で？ 一応二台のセキュリティ ポリシーを比較してみたのですが設定は同じでした。というか、そもそもセキュリティポリシーの変更だけでDesktop Appが動くのならWindows RT 発売と同時に誰かが即発見してお祭りになるでしょう。
段々意味が分からなくなってきました。
ビルドしたバイナリと実行の可否を確認すると、
確認してみます。
Windows 8.1 機 （x64 の普通のWin8.1PCです）上のVisualStudio で.NET Application をターゲット「Any CPU」でビルドし、件のVivoTabRT で動かしてみます。
Oh... ビルド環境云々では無く、「この」VivoTabRT は何故かDesktop App がノーチェックで動いてしまう、かなり妙な状態になっていることが確認できました。
また、上でSurfaceRT 上でビルドしたテストプログラムが動かないのも、それが（MSが）意図する正しい動作であろうことも判ります。
「この」VivoTabRTが何故こんな状態になっているのか？方法が判れば楽しいのですが、残念ながら今のところ判りません。グループポリシー上はSurfaceRTと同じ設定ですから、SurfaceRT や別のRT機でこの状態に入れる方法も判りません。
ただ、思い当たるというか、ひょっとして？という点が一つあります。
去年 Windows8.1 / 8.1RT がリリースされ、VivoTabRT をアップデートしたのですが…その際、以下のような不具合がありました。
「SecureBootが正しく構成されていません」というWarningが、スタート画面・デスクトップの右下に表示される、という不具合でした。
なお、手持ちのSurfaceRTではこの不具合は発生していません。
この不具合、結構多くのVivoTabRT (TF600T)で発生していたようで、当時MSのSupport Forumで報告が多く寄せられていました（私も文句書きましたし、ASUS サポートに連絡もしました。その後返事無いですが…）。
その後、「Warning Messageを表示しなくする」というPatch がWindows Updateで配布され、上のWarning Messageは表示されなくなりました。
問題の根本、「SecureBootが使えてない状態」そのものは直らず、放置されたことになります。
このSecureBoot、EFI System+Win8では必須で、これがOnになっているとWin8以外のOSは動作しない、というもので・・・あーつまりLinuxも入れたら動くのかな俺のVivoTabRT、くらいにしか考えていなかったのですが。
ですが、今回のVivoTabRTのザル動作と、SecureBootが結局直っていない事を合わせて考えると…
「SecureBoot がDisable になっていると Windows RT は UserAppの実行時チェックを行わなくなる」
という動作をしているのでは？という推測が出来るのではと考えています(*3)。
しかし、何分にも実例が私のVivoTabRT １台だけで、自信を持って言える話では全く無いのも確かです。
もしあなたがASUS VivoTabRT TF600T や SurfaceRT / Surface2 のようなWindows RT機をお持ちで、また、上に書いたようなSecureBootエラーを経験されていたら…本記事で書いた手順でUser Appが実行できるか試してみると面白い結果が出るかもしれませんよ。
(*3) なお、一般的なx86/64 PC では PC起動時の EFI 設定で SecureBoot の設定を変更できるオプションが用意されているのですが、 ARM機の Windows RT ではそもそもSecureBootの設定項目自体がありません。
- 我が家のVivoTabRT - ASUS TF600T ではAnyCpuでビルドしたDesktop Appが動く事が判明した
- 理由は判らないが、思い当たる節が無くも無い
- 動作例は今のところ私の持ってる1台だけですが、同じ環境の人は試してみると動くかもですよ
事の起こり
ご存じの通り、Windows RT で動作する ユーザー アプリケーションはWindows ストア からインストールするストアアプリだけで、デスクトップ アプリケーション…Win32ベースのアプリケーションは動作しません(*1)。
ですが、.NET 以降のWindows にはOSの中に.NET Frameworkのビルド環境が一通り入っていることが知られています。Windows RT も例外ではなく、.NET v1, 2, 4の参照DLLと、.NET 4用のcsc.exe, csharpのコンパイラが入っています。
何に使っているのかは僕は知らないのですが…使うんだから入ってるのでは？NGEN用？ そして、動くのなら案外ユーザーアプリもビルドしたら動いちゃったりして？
と、なんとなく考えました（この先を読むと判りますが、この仮定はほぼ間違いでした が、話の進行上「そうかも？」という体で読んで頂けると幸いです）。
(*1) Microsoft 製の「Windows RT向けDesktop アプリ」は動作します。OS付属のメモ帳やエクスプローラー、加えて、VisualStudio 用のRemote Debug Tools（MSのサイトからDL可能）等がそれです。MS製だけ許すための署名＋ハッシュ付きバイナリなのかなーと想像しますが確認はしていません。
やってみる
確認は簡単で、超単純なC# のプログラムを OS組み込みの.NET Frameworkでビルドしてみます。
Windows RT 機上でCommand Prompt を開き、
- OS組み込みの.NET Framework にパスを通す set path=%path%;C:\Windows\Microsoft.NET\Framework\v4.0.30319
- cscを叩いてビルド(*2) csc.exe test.cs /noconfig
これを手持ちのASUS VivoTabRT で試すと、
 |
| 「私の」VivoTabRT でのテスト |
おお。あっさり動きました。これは楽しい。ARM版VisualStudio なんてものは存在しないので本格的な開発は無理ですが、出先でC#の簡単なプログラム組んで遊ぶくらいは出来そうです。
ただ、上にも書いたようにWindows は署名を使ってプログラム実行許可・不許可を判断している（はず）ですが… 今ビルドしたこのプログラムはどういう扱いになるのだろう？謎です。
なので、今ビルドしたプログラムを、手持ちのSurface RT （色々あってRT二台持ちなのです）にCopyして実行してみると、ダメでした。…実行PC上でコンパイルしないとダメなのかな？とSurfaceRT 上でも全く同じ事をしてみても、
 |
| SurfaceRT でのテスト |
「このバージョンのfoobar.exe は、実行中のWindows のバージョンと互換性がありません。コンピュータのシステム情報を確認してから、ソフトウェアの発行元に問い合わせてください」
ビルドは通るのですが、実行しようとすると同じエラーが表示されます。？？？？？ ちなみにこれ、x86用のDesktopApp をWindows RT で実行しようとした時に表示されるエラーメッセージと同じです。
？？？？何で？ 一応二台のセキュリティ ポリシーを比較してみたのですが設定は同じでした。というか、そもそもセキュリティポリシーの変更だけでDesktop Appが動くのならWindows RT 発売と同時に誰かが即発見してお祭りになるでしょう。
段々意味が分からなくなってきました。
ビルドしたバイナリと実行の可否を確認すると、
- VivoTabRT でビルドしたバイナリ は VivoTabRT 上で動作する。
- VivoTabRT でビルドしたバイナリ は SurfaceRT 上で動作しない。
- SurfaceRT でビルドしたバイナリ は SurfaceRT 上で動作しない。
- SurfaceRT でビルドしたバイナリ は VivoTabRT 上で動作する。
確認してみます。
Windows 8.1 機 （x64 の普通のWin8.1PCです）上のVisualStudio で.NET Application をターゲット「Any CPU」でビルドし、件のVivoTabRT で動かしてみます。
 |
| 正直、目を疑う光景ではあります |
Oh... ビルド環境云々では無く、「この」VivoTabRT は何故かDesktop App がノーチェックで動いてしまう、かなり妙な状態になっていることが確認できました。
また、上でSurfaceRT 上でビルドしたテストプログラムが動かないのも、それが（MSが）意図する正しい動作であろうことも判ります。
考察
「この」VivoTabRTが何故こんな状態になっているのか？方法が判れば楽しいのですが、残念ながら今のところ判りません。グループポリシー上はSurfaceRTと同じ設定ですから、SurfaceRT や別のRT機でこの状態に入れる方法も判りません。
ただ、思い当たるというか、ひょっとして？という点が一つあります。
去年 Windows8.1 / 8.1RT がリリースされ、VivoTabRT をアップデートしたのですが…その際、以下のような不具合がありました。
 |
| VivoTabRT を 8.1RT に更新した当時のスタート画面 |
「SecureBootが正しく構成されていません」というWarningが、スタート画面・デスクトップの右下に表示される、という不具合でした。
なお、手持ちのSurfaceRTではこの不具合は発生していません。
この不具合、結構多くのVivoTabRT (TF600T)で発生していたようで、当時MSのSupport Forumで報告が多く寄せられていました（私も文句書きましたし、ASUS サポートに連絡もしました。その後返事無いですが…）。
その後、「Warning Messageを表示しなくする」というPatch がWindows Updateで配布され、上のWarning Messageは表示されなくなりました。
問題の根本、「SecureBootが使えてない状態」そのものは直らず、放置されたことになります。
このSecureBoot、EFI System+Win8では必須で、これがOnになっているとWin8以外のOSは動作しない、というもので・・・あーつまりLinuxも入れたら動くのかな俺のVivoTabRT、くらいにしか考えていなかったのですが。
ですが、今回のVivoTabRTのザル動作と、SecureBootが結局直っていない事を合わせて考えると…
「SecureBoot がDisable になっていると Windows RT は UserAppの実行時チェックを行わなくなる」
という動作をしているのでは？という推測が出来るのではと考えています(*3)。
しかし、何分にも実例が私のVivoTabRT １台だけで、自信を持って言える話では全く無いのも確かです。
もしあなたがASUS VivoTabRT TF600T や SurfaceRT / Surface2 のようなWindows RT機をお持ちで、また、上に書いたようなSecureBootエラーを経験されていたら…本記事で書いた手順でUser Appが実行できるか試してみると面白い結果が出るかもしれませんよ。
(*3) なお、一般的なx86/64 PC では PC起動時の EFI 設定で SecureBoot の設定を変更できるオプションが用意されているのですが、 ARM機の Windows RT ではそもそもSecureBootの設定項目自体がありません。
登録:
投稿 (Atom)