2017年12月 9日 (土)

せめて作業場所節の名前だけでも覚えて帰ってください

Fujitsu Advent Calendar 2017の9日目です。 このエントリは個人の立場で書いております。 なのですが、 せっかくなので業務で開発に携わっているモノを紹介しようと思います。 説明上、特定の製品の話も出てきますが、宣伝の意図はありません。 くどいですが、このエントリは個人的に書いているもので、所属企業の見解を示すものではありません。

さて、 私が開発に携わっているモノとは、COBOL処理系です。 富士通が何かやっているというニュースが出ると、 「どうせCOBOLだろw」みたいな反応が出たりもする、 みんな大好きCOBOLです。

古代の遺物扱いされることも多いのですが、 コードはまだまだあるところには大量にあります。 ぜひ「知っている言語」の一つに入れておいてもらって、 どこかのシステムの奥底からCOBOLコードが出てきた際には、 げえっと叫んで封印するのではなく、 読んで、場合によっては手直しなどしてもらえればなと思います。

ざっと以下の内容。

おかんについて

まずは、わたしらのおかんを紹介したいと思います。 Grace Hopperです。 COBOLの母です。 おかんがCOBOL作りました。

米海軍准将でした。 けっこう偉大な人なので、 その名を付けた駆逐艦があります。

つまり、うちのおかんはリアル艦娘です。 ハイパー婆さんなのに駆逐艦。 「バブみ」などという言葉ではとうてい表現できない歴史の深みです。 ひげのおっさんとかではなく駆逐艦が作った言語と聞くと、 ちょっとやってみようという気になりませんでしょうか。 なりませんか。そうですか。

Grace Hopperといえば、 コンピューターにおける「バグ」語源にからんだり、 「許可を求めるより後で謝った方が簡単だ」という名言を残したり、 逆回りの時計を壁に掛けていたり、 色々エピソードのある人です。 生きていれば、本日101歳の誕生日です🎂。 1992年に亡くなっていますが、 女性技術者の集まりである"Grace Hopper Celebration"に名を冠されていたり、 去年はアメリカ合衆国大統領自由勲章が授与されたり、 今なお存在感があります。

プログラムのスタイルについて

そんなおかんが開発したCOBOLはLispやFortranと並んで最古参の高級言語のひとつです。 記号をあまり使わず、 英語の文章のようにプログラムを記述していくスタイルです。 試しに簡単なプログラムを書いてみましょう。

       IDENTIFICATION DIVISION.
       PROGRAM-ID. MAIN.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WK.
         02 FILLER  PIC X(6) VALUE "Hello".
         02 WK-NAME PIC X(5).
         02 FILLER  PIC X    VALUE "!".
       PROCEDURE DIVISION.
           DISPLAY "? " WITH NO ADVANCING.
           ACCEPT WK-NAME.
           DISPLAY WK.
       END PROGRAM MAIN.

"PROCEDURE DIVISION."と書かれてある行より後ろがプログラム本体になります(『手続き部』)。 この部分はとても文章的です。 まあ、文章的な代わり、 ちょっと複雑な処理を書こうとすると色々書かなきゃならないのが面倒になってくるのですが。 その「本文」の流れに邪魔になる様々な定義はほかの部分、

  • IDENTIFICATION DIVISION(『見出し部』)
  • ENVIRONMENT DIVISION(『環境部』、このプログラムでは省略されている)
  • DATA DIVISION(『データ部』)

に記述するようになっています。

このプログラムは、 例えば"World"を入力すると、"Hello World!"と返すものです。 以下のような感じ。

? World
Hello World!

このユーザー入力を受け取る部分は "ACCEPT WK-NAME."と書かれている行になります。 「"WK-NAME"という『変数』に入力を受け取る」という意味の文です。 この『変数』"WK-NAME"の定義はデータ部にあります。

       WORKING-STORAGE SECTION.
       01 WK.
         02 FILLER  PIC X(6) VALUE "Hello".
         02 WK-NAME PIC X(5).
         02 FILLER  PIC X    VALUE "!".

"PIC X(5)"は、 まあ、ざっくり言えば、「5文字分の領域」という意味になります。 なので、富士通のNetCOBOLの場合、 5文字分入力されるまで入力を待ち続けます。 3文字入力してEnterを押してもあと2文字入力されるまで律義に待ち続けます。 ちなみに、5文字以上を入力すると、余った入力は切り捨てられます。

で、プログラムの最後では、"WK-NAME"を含む"WK"全体を一気に出力しています。

           DISPLAY WK.

今時の感覚からすると、 文字列とかは可変長の「文字列オブジェクト」で扱ってほしいし、 テキストのフォーマットももっと動的に処理すれば使い勝手良いだろうに、 とか思うのです。 まあ、複雑な文字列編集を行うための文とかもあるのですが、 この程度ならばこんなふうに書いてしまうことが多い。

このあたりのデータの取り扱いの感覚が今時の言語との大きな違いではないかと思います。 何と言いますか、発想が帳票的です。 上のデータ定義、 そう思ってみると、 帳票的なイメージがしてきませんか? "WK"という一塊のデータ(レコードと言います)を定義し、 その内部の各欄に6文字、5文字、1文字というサイズを割り当てています ("FILLER"は「名前?名前などどうでもよい」という意味)。

それは構造体のようなものではないのか? 構造体の先祖と言えるかもしれませんが、 今となっては「構造体」で期待するものとかなり違うんじゃないかなあ。 COBOLのレコードは参照が含まれることがほとんどないので、 本当に固定長のべたな領域を区切っていることになります。 領域に余白ができたら自動的に空白を詰めたりします。 ファイルの読み書きもそのレコードをそのままべたに読み書きする感じ。

今の眼からすると、 COBOLはそういった帳票的なデータを加工したり入出力したりするための言語とイメージすると、 分かりやすいんじゃないでしょうか。

「事務作業なんて要するに何かの帳票を読んで別の帳票を作ることだろう」と割り切ったとでも言いますか。 英語の文章的な記述法といい、 おかんは技術者ではない一般の人でも事務作業を自動化できるようなモノを作りたかったのではないかと思います。 今で言えば、Excel的なものでしょうかねえ。 ただ、事務作業向きといっても、 やろうと思えばかなりのことができてしまいます。 それが行き過ぎて、神Excelならぬ神COBOLみたいなコードも大量にあったりします。 適材適所は大事。

ともあれ、 COBOLのデータの取り扱いは今時の言語のデータの取り扱いとは発想がかなり違っています。 この違いが、十進演算と並んで、COBOLの置き換えが結構難しい技術面での原因ではないかと思います。 興味があれば、 COBOLの表の添字付けについても調べてみてください。 COBOLの表は多くの言語での配列に相当するものですが、 多段になっている場合の添字付け方法が今時の言語とまったく異なっています。

ちなみに、 このデータ部の変数を定義する部分(WORKING-STORAGE SECTION)、 日本語では「作業場所節」と言います。 変数は「場所」なのです。 いかにもです。 ここに定義したデータは、C#やJavaなどで言うところのstatic的に割り付けられます。 つまり、もう一回このプログラムを呼び出すと、 "WK-NAME"には前回のデータが残ってます。 いったんプログラムがロードされてしまえば、 メモリ不足やStackOverflowが発生しにくい安心安全設計。 なお、2002年規格以降は、 ローカルなデータも定義できるようになっています。 ローカルなデータは局所記憶節(LOCAL-STORAGE SECTION)という場所に書きます。

いにしえの記法について

上のプログラム、左の余白が目につきます。 実は、この余白(行の先頭6カラム)は行番号領域です。 ですが、今となっては空白にしておくのが吉です。 下手に自動ナンバリングとかしてしまうと、 行を追加/削除した場合に以降の行番号がずれて、 ソース管理上そいつら全部が変更された扱いになってしまいます。

また、7カラム目は標識領域で、 ここに「*」が記述されていたら、その行はコメントです。

こんな調子で、昔のCOBOLのソースにはカラムに意味があります。 古典的な書き方では、73カラム以降はコメント(見出し領域)です。 下手にソースをUTF-8化すると、非ASCII文字を含む行で本文のカラムが増えて、 コード末尾が勝手にコメントになってしまうという事故が起きたりします。 その他、「この要素はこの領域から書き始めないとダメ」みたいな規則もあり、 解析処理を書く際にカラムの考慮が極めてだるいです。 文字コードの問題がからむとなおさら。

なんでこんな書き方をするのか。 今でこそみんなPCを持っていて、 エディタでプログラムを書くわけですが、 昔は一人一台端末を占有しつづけるなどできませんでした。 じゃあ、どうやってプログラムを書いていたかといえば、 こんな紙に書いていました。

コーディング用紙

コーディングシートというやつですね。 この紙に書いたプログラムをコンピューター室に持っていって入力したり、 さらに古くはパンチカードを打ってそれを読み込ませたりしていたそうです。 私自身は経験ないけど。

COBOLの古い書式は、このような昔のやり方に合うようにできていたのでしょう。 今では、カラムを意識しない「自由形式」という書法でも書けるのですが、 デフォルトは互換性のためにこの古い「固定形式」ですし、 なにより大量にある既存のソースが古い形式で書かれています。 カラムの呪縛からはなかなか逃げられない。

現状など

さすがに今となっては、世の中の最前線の課題の解決を期待されるようなことはあまりない、と思います。 が、COBOLの特徴は無限のCOBOLプログラムを内包する世界を創り出してしまっていることにあります。 Unlimited COBOL Worksです。 皆さんも日常生活で間接的にCOBOLプログラムを利用しているはずです。 銀行や自治体のシステムとか、表はWebで操作したとしても、 その最深部ではCOBOLプログラムが動いていたりします。 ちょっと古いのですが、2010年頃、 世界で2400億行のCOBOLコードが稼働しているという話がありました。 現在もまだまだコードが書かれています。 こいつらを無事に動かし続けなければなりません。 そのため、 新しいOSや環境で動くようにしたり、 連携できるようにしたり、 やることはまだまだあります。

で、新しいシステムと連携できるようにしたりすると、 「またCOBOLかよw」などと言われたりするわけですね。 数年前にHadoop対応をしたときも「なんでまた」みたいなコメントがありました。 あれ、ビッグデータをやりたいわけではなく(やってもらってもかまわないのですが)、 既存のCOBOLバッチを分割して並行に走らせたいんだけど、 それを独自の基盤を作るのではなく、 よく知られている基盤の上でやろうという話です。 別に流行りだからと何も考えずにやっているわけではないのです。 いや、何も考えずに流行りものをやってみたいとか、思ったりもしていますけど。

ハードや環境が変わっても同じ機能を動かし続けることができる、 というのがソフトウェアに期待される役割のひとつだとすれば、 それをしぶとく勤め続けております。 まだ当分、COBOLは使い続けられることでしょう。 COBOLで「先の規格」といえば応仁の頃に制定されたやつのことですが、 現行は2014年版で、 その次に向けても動きが始まっています。

今時の機能をCOBOLで書いてみる

せっかくなので、COBOLでもう少し書いてみましょう。 富士通の.NET向けCOBOL(NetCOBOL for .NET)を使ってみます。 実は、最古参の高級言語であるところのCOBOLは.NETプラットフォームにおいても最古参のサードパーティ言語だったりします。 2000年の.NET Framework発表直後のPDC 2000で、 ゲイツ先生に「わしも昔はCOBOL書いたがな」と紹介されてデモしたりしてます。 Channel 9でビデオを見れます。 COBOLの紹介は1:27:30頃から。今から見ると実に素朴。

ここで、 .NETとCOBOLのデータ型のマッピングなどを説明して、 「COBOLプログラムを.NETの一般的なデータ型で呼び出せるようにラップしてライブラリ化すれば、任意の.NET言語から利用可能になります」 とか述べればそれなりにお役に立つのでしょうが、 それはマニュアルにも書いてあるし、 せっかくのアドベントカレンダーですので、 ふつうCOBOLで書かないような処理を書いてみましょう。

async処理をCOBOLで書いてみます。

お題としては、 以下のような非同期でWeb上のテキストファイルを取ってくるメソッドがライブラリとして提供されているとして、

public class Downloader: IDisposable {
    private HttpClient httpClient = new HttpClient();

    public async Task<string> DownloadText(string uri) {
        string text;
        using (HttpResponseMessage response = await this.httpClient.GetAsync(uri)) {
            if (!response.IsSuccessStatusCode) {
                throw new Exception($"Error: {response.StatusCode}");
            }
            text = await response.Content.ReadAsStringAsync();
        }

        // 以下の行を入れてわざと待たせるようにすると、
        // 非同期に動作していることがGUI上から分かりやすい。
        await Task.Run(() => { Thread.Sleep(3000); });
        return text;
    }
    ...
}

以下のようなイベント処理をもつWindows FormをCOBOLで書いてみます。

private Downloader downloader = new Downloader();
...
private async void button_Click(object sender, EventArgs e) {
    // 処理中はボタンを無効化し、二度押しを防ぐ。
    this.button.Enabled = false;
    try {
        string message;
        try {
            string text = await this.downloader.DownloadText("http://www.msftncsi.com/ncsi.txt");
            message = $"[{DateTime.Now}] {text}";
        } catch (Exception exception) {
            message = exception.Message;
        }
        this.label.Text = message;
    } finally {
        this.button.Enabled = true;
    }
}

テキストのダウンロードは非同期処理なのですが、 その後、ラベルのテキストを更新してボタンを有効化する処理があります。 awaitを記述することで、 そのあたりがすっきり記述できています。 C#のasync/await機能ですね。

実行して、ウィンドウのボタンを押すと、こんな結果になります。

サンプルのGUI

Visual Studio 2017向けのNetCOBOL for .NETは(国内向けには)まだ出ていないので、 Visual Studio 2015 + NetCOBOL for .NET V7で書きます。

NetCOBOL for .NETはWindows Formsをサポートしています。 NetCOBOLのWindows Formsプロジェクトテンプレートからそのままプロジェクトを起こせます。 なぜWPFでないかと言えば、 残念ながらNetCOBOL for .NETでは諸般の理由によりWPFベースのGUIの作成をサポートしていないからです。 だって死にそうな思いで無理くりCodeDOM実装したのに、WPFではまったく別のコード生成インターフェイス使いよるし。 まあ、今となってはどっちみちRoslyn以前のものだけど。

で、Windows Formsを使うとして、 このasync付きのイベント処理をどうやってCOBOLで書くか。 当然、現在のCOBOLにはasync/await構文とかありません。 が、幸いなことに、.NETの機能の多くは素のクラスを使って記述可能です。 genericsを最後に構文に手を入れる必要があった覚えがありません。 LINQだろうがasyncだろうが、素のクラスとメソッド呼び出しだけで、がんばれば書けます。 がんばれば。

というわけで、 上のイベント処理を素のクラスとメソッドを使った処理に展開します。

  • 非同期処理をTask<string>オブジェクトを使う形で記述します。 非同期処理完了後の後続処理の実行はTask<string>.ContinueWith()メソッドを使ってスケジュールします。 C#のasync/awaitの展開では、ContinueWith()を単純に使わずに内部クラスを生成して色々処理をしています。 おそらくawaitが複数ある場合や例外処理をうまく処理するためでしょう。 が、今回の処理程度であれば、ContinueWith()で十分でしょう。
  • GUIはGUIスレッド上で操作しなければならないことに注意します。 C#のasync/awaitの展開ではよしなに計らってくれますが、 自力で展開する場合は自分で実装する必要があります。 ここでは、FormInvoke()メソッドを使います。
  • COBOLでラムダは書けないので、独立したメソッドに処理を記述します。 クロージャーが必要な場合は、そのためのクラスを新たに作らなければなりませんが、 幸いこのケースではそこまで必要ありません。 このForm内にメソッドを定義するだけで十分です。

いきなりCOBOLで書いても分かりにくいでしょうから、 まずC#で書きます。 以下のようなコードをこの後COBOLで書きます。

private Downloader downloader = new Downloader();
...
private void button_Click(object sender, EventArgs e) {
    this.button.Enabled = false;
    try {
        this.downloader.DownloadText("http://www.msftncsi.com/ncsi.txt").ContinueWith(
            new Action<Task<string>>(this.ContinuedProc)
        );
    } catch {
        FinallyProc();
        throw;
    }
}

private void FinallyProc() {
    this.button.Enabled = true;
}

private void ContinuedProcBody(Task<string> task) {
    try {
        string message;
        if (task.Exception == null) {
            message = $"[{DateTime.Now}] {task.Result}";
        } else {
            message = task.Exception.Message;
        }
        this.label.Text = message;
    } finally {
        FinallyProc();
    }
}

private void ContinuedProc(Task<string> task) {
    // GUIスレッド上で処理を行う。
    this.Invoke(new Action<Task<string>>(this.ContinuedProcBody), task);
}

ではCOBOLで書きます。 こういう場合以外なかなか使ってもらえないオブジェクト指向構文(2002年規格で導入)が炸裂します。 全体を載せると長くなるので、イベント処理関連の部分のみ掲載します。 クラス名の定義とかクラス定義の環境部にあるので、ここだけだと記述が完結しないけど、 まあ雰囲気を見てもらえれば。 ソース全体はGitHubに置いています。

一つおことわりを。 以下のソースでは、 メソッドの『ローカル変数』をWORKING-STORAGE SECTIONに書いています。 規格的にはここはLOCAL-STORAGE SECTIONであるべきですが、 NetCOBOLでは、歴史的な事情により、 メソッドの『ローカル変数』はWORKING-STORAGE SECTIONに書きます。

では。

       METHOD-ID. button_Click PRIVATE.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WK-CONTINUED-PROC OBJECT REFERENCE DEL-ACTION-TASK.
       01 WK-TASK OBJECT REFERENCE CLASS-TASK-STRING.
       LINKAGE SECTION.
       01 sender OBJECT REFERENCE CLASS-OBJECT.
       01 e OBJECT REFERENCE CLASS-EVENTARGS.
       PROCEDURE DIVISION USING BY VALUE sender e.
      *    前準備
      *    複雑な型パラメータをもつ型によるメソッドオーバーロードの解決に問題があるので、
      *    ここではAction<Task<string>>ではなく、Action<Task>引数で
      *    Task.ContinueWith()を呼び出す。
           INVOKE DEL-ACTION-TASK "NEW" USING SELF N"CONTINUED-PROC" RETURNING WK-CONTINUED-PROC.
      
      *    ボタンを無効化する。
           SET PROP-ENABLED OF button TO B"0".
           TRY
               SET WK-TASK TO WK-DOWNLOADER::"DownloadText" (N"http://www.msftncsi.com/ncsi.txt")
               INVOKE WK-TASK "ContinueWith" USING BY VALUE WK-CONTINUED-PROC
           CATCH
               INVOKE SELF "FINALLY-PROC"
               RAISE
           END-TRY.
       END METHOD button_Click.
      
      *button_Clickで必ず行うべき後処理
       METHOD-ID. FINALLY-PROC PRIVATE.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WK-BUTTON OBJECT REFERENCE CLASS-BUTTON. 
       PROCEDURE DIVISION.
      * ボタンを有効化する。
           SET WK-BUTTON TO PROP-BUTTON OF SELF.
           SET PROP-ENABLED OF WK-BUTTON TO B"1".
       END METHOD FINALLY-PROC.
      
      *ダウンロード終了後に行いたい処理の本体
       METHOD-ID. CONTINUED-PROC-BODY PRIVATE.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WK-TASK OBJECT REFERENCE CLASS-TASK-STRING.
       01 WK-EXCEPTION OBJECT REFERENCE CLASS-EXCEPTION.
       01 WK-MESSAGE OBJECT REFERENCE CLASS-STRING.
       01 WK-TEXT OBJECT REFERENCE CLASS-STRING. 
       01 WK-NOW OBJECT REFERENCE CLASS-DATETIME.
       LINKAGE SECTION.
       01 PARAM-TASK OBJECT REFERENCE CLASS-TASK.
       PROCEDURE DIVISION USING BY VALUE PARAM-TASK.
      *    タスクをTask<string>型にキャストする。
      *    実際のタスクの型はTask<string>だが、インターフェイス上はTaskにしている。
      *    button_Clickメソッドの手続き部のコメントを参照。
           SET WK-TASK TO PARAM-TASK AS CLASS-TASK-STRING.
      
           TRY
      *      ラベルのテキストを更新する。
             SET WK-EXCEPTION TO PROP-EXCEPTION OF WK-TASK
             IF WK-EXCEPTION = NULL THEN
               SET WK-TEXT TO PROP-RESULT OF WK-TASK
               SET WK-NOW TO PROP-NOW OF CLASS-DATETIME
               SET WK-MESSAGE TO CLASS-STRING::"Format" ("[{0}] {1}" WK-NOW WK-TEXT)
             ELSE
               SET WK-MESSAGE TO PROP-MESSAGE OF WK-EXCEPTION
             END-IF
             SET PROP-TEXT OF label1 TO WK-MESSAGE
           FINALLY
      *      ボタンを有効化する。
             INVOKE SELF "FINALLY-PROC"
           END-TRY.
       END METHOD CONTINUED-PROC-BODY.
       
      *「ダウンロード終了後に行いたい処理」をGUIスレッド上で実行するメソッド
       METHOD-ID. CONTINUED-PROC PRIVATE.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WK-PROC OBJECT REFERENCE DEL-ACTION-TASK.
       LINKAGE SECTION.
       01 PARAM-TASK OBJECT REFERENCE CLASS-TASK.
       PROCEDURE DIVISION USING BY VALUE PARAM-TASK.
      *    GUIスレッド上で処理を行う。
           INVOKE DEL-ACTION-TASK "NEW" USING SELF N"CONTINUED-PROC-BODY" RETURNING WK-PROC.
           INVOKE SELF "Invoke" USING WK-PROC PARAM-TASK.
       END METHOD CONTINUED-PROC.

C#のFormが106行(Form1.cs: 38行、Form1.Designer.cs: 68行)なのに対し、 COBOLのForm1.cobは1126行です。 いまどき行数で生産性を計っている方々、 お喜びください。 生産性10倍以上です。

まあ、COBOLのFormにはデザイナが自動生成する特殊コメント等が大量にありまして(しかも事情があってちょっと冗長)、 単純集計だと極端に行数が増えます。 なので、button_Click処理に限定しましょう。 それでも、C#: 16行に対し、COBOL: 83行です。 COBOLのスタイルだとどうしても記述量は増えます。

やはり、言語は適材適所に使っていただいて、 適切な言語で記述された今時のシステムから伝家のCOBOLプログラムを呼び出し、 末永く利用していただければと思います。

謝辞

古来、 COBOL仕様扱う文書はCODASYLへの謝辞を掲載していました。 謝辞を掲載することで、 COBOL仕様書の内容やアイデアを自由に利用することが許可されていました。 せっかくですので、 古式ゆかしく、 CODASYLへの謝辞で終わりたいと思います。 CODASYLはもうないけど。

以下、1984年版の謝辞(「CODASYL COBOL JOURNAL OF DEVELOPMENT 1984」から)。

【謝辞】

COBOLは産業界の言語であり、特定の団体や組織の所有物ではない。 CODASYL COBOL委員会又は仕様変更の提案者は、 このプログラミングシステムと言語の正確性や機能について、 いかなる保証も与えない。 さらに、それに関する責任も負わない。

次に示す著作権表示付きの資料の著作者及び著作権者は、 これら全体又は一部分をCOBOLの原仕様書中に利用することを許可した。 この許可は、COBOL原仕様書をプログラミングマニュアルや類似の刊行物に複製したり、 利用したりする場合にまで拡張される。

  • FLOW-MATIC(Sperry Rand Corporationの商標), Programming for Univac(R) Ⅰ and Ⅱ, Data Automation Systems, Sperry Rand Corporation 著作権表示1958年, 1959年
  • IBM Commercial Translator Form No.F28-8013, IBM 著作権表示1959年
  • FACT, DSI 27A5260-2760, Minneapolis-Honeywell 著作権表示1960年

今後ともよろしくお願い申し上げます。

2017年10月28日 (土)

Docker for Windowsをアップデート/再インストールできない件

今年の春の頃からだったろうか、 家のPCのDocker for Windowsがアップデートできなくなりました。

アップデートを開始すると、 「Do you want to replace your current version of Docker for Windows with this new one 17.09.0-ce-win33(13620)?」というダイアログが出ます。 ここで「はい」を押そうが「いいえ」を押そうが、 次の瞬間「install canceled」と出て先へ進めなくなります。

一回Docker for Windowsをアンインストールして、 最新バージョンのインストーラーで再インストールを試みても同じ結果。

そのうち直るだろうと思って放っていましたが、 一向に直らない。 で、まじめに調べてみました。

対処法

レジストリの以下のキーを削除してからアップデート/再インストールを行います。

HKCR\Installer\UpgradeCodes\9CA3F2E62DBFCA74DB9BD0384695C460

最後の"9CA3F2E62DBFCA74DB9BD0384695C460"の値は、 ひょっとすると環境によって異なるかもしれません。 アップグレードコードの役割からすると、同じ値の場合が多いと思いますが。 確実を期したければ、後述の詳細をみて、確認してください。

詳細

Dockerのコミュニティフォーラムの以下のトピックを参考にしました。

Cannot uninstall Docker for Windows

ここではアンインストール時の問題として取り上げられています。 このトピックは2016年1月に始まっていますが、 長らく進展していませんでした。 キーになるのは、一年半以上も後の投稿です。

2017年10月12日 3:06のdjarvis8さんの投稿

Process MonitorでDocker for Windowsのインストーラーをモニタし、 片っ端からチェックして"HKCR\Installer\UpgradeCodes"下のキーを読んでいるのが問題だと突き止めたらしい。 すげえ。

というわけで、 私もProcess Monitorで問題のレジストリキーを探して、 それを削除したところ、無事Docker for Windowsを再インストールできました。

問題のレジストリキーは同じだとは思いますが、 環境や現在インストールされているバージョンによっては異なる可能性があります。 確実を期すならばProcess Monitorでインストーラーが実際に読もうとしている"HKCR\Installer\UpgradeCodes"下のキーを確認するとよいでしょう。 結構めんどくさいけど。

2017年8月27日 (日)

IS12Tとわたくし

一昨日、auがこんなツイートを。

4年近く愛用してたよ。 ちょっと感慨深くて、何か書きたくなった。

ただ、まあ、IS12Tの発売がどんなに感無量であったかを書くには、 Windows Phoneの前史から語らねばならなくてですね…

Windows Phone 7まで

元々Microsoftは大昔からスマートフォンを作っていました。 それこそiPhoneが出るよりずっと前から。 当時「スマートフォン」と呼ばれていたものは電話回線につながるPDAみたいな感じだったけど。 日本でも2005年のW-ZERO3で知られるようになりました。 残念ながら住んでいる所が当時ウィルコムのサービスエリア外だったので、 私はW-ZERO3は買いませんでしたが、 その後、ソフトバンクから出たWindows Mobile(現行の"Windows 10 Mobile"ではなく、"Windows Mobile 6"ね)を使ってました。 X01TとかX02Tとか。

そんなこんなしているうちに2007年にiPhoneが出て(日本発売は2008年)、 「スマートフォン」のイメージを塗り替えてしまいました。 Microsoftも「これはいかん」ということで、 スマートフォンOSを刷新することになります。 確か、新しいやつは従来のWindows Mobileじゃなくて、 Zune(Microsoftのメディアプレーヤー)を元に作り直したんじゃなかったっけ。 あのタイルUI(メトロ)もZune起源だったような。 今や本家Windowsにもメトロの後継が入っていますね。

開発は順風満帆とはいかなかったようで、 Windows Mobile 6.5を繋ぎで出さざるを得なくなったり、 Kinという別系統のスマホを発売してたった2カ月でディスコンにするというわけの分からんサイドストーリーがあったり、 なんだかんだで、 2010年にやっとこさ"Windows Mobile 7"改め"Windows Phone 7"が登場しました。

が、今度はなかなか日本で発売されない。

技適の問題もありますが、 当時はまだSIMロック端末が一般的だったので、 キャリアがちゃんと対応機を出してくれないと国内で使い物にならないのです。

IS12T!

で、うーうー唸っているうちに、2011年7月27日、 突然auから「IS12Tを8月25日から発売する」との発表があり、 色めき立つのです。 しかも世界初のWindows Phone 7.5機です。 「Windows Mobileを現代風に作り直すやで」と聞いてからはや3年です。 まさかこの後、国内で次のWindows Phoneが出るのが4年後になるとは思わなかったけど。

開発は東芝ですけど、 直前に東芝と富士通のケータイ部門が事業統合したため、 富士通機種のような扱いになっていました。 でもロゴは"TOSHIBA"だったな。 発売直前に社内割引きで買えるとのアナウンスがあり、 速攻で予約しました。 色はシトロンを選びましたが、 シトロンは入荷待ちで発売当日には入手できないといわれた。 でも、発売翌日に入荷したとの連絡をうけ、 次の日、窓口のある武蔵小杉へ沼津から受け取りに行きました。 契約書を掘り出して確認しましたが、 ちょうど六年前、2011年8月27日でしたね。

感無量でしたねえ。 ぬるぬる動くし、 従来のWindows Mobileからずいぶん「現代的」になってたし。 カラーも気に入ったし。

当時、 スマホではまだあまりカラフルなモデルは出ていなかったように思います。 とくに海外では。 Lumiaが青や群青のWindows Phoneを出してなかなかカッコよかった記憶がありますが、 それでも青系で、 派手な色のスマホはIS12Tが先駆けのように思うけど、どうかな。 Lumiaが黄色とかを出したのはその後じゃなかったっけ。

ただ、機能は仕上がっていない部分もありました。 始めの頃は二三日ごとに再起動していたし、 冬まではSMSの受信はできても送信はできてなかったりして、 妻からのSMSにメールで返信するというはめになり、 iPhone使いの妻に「それは便利なのか?」と煽られたりしてました。 アップデートしているうちに色々直って安定してきましたが。

空白の4年間

というわけで、 機嫌よくIS12Tを使っていたわけですが、 これに続くWindows Phoneが国内でまったく出てこない。 「Microsoft側の都合」ということでしたが、 具体的な理由は公式に出たことはなかったんじゃないかな。 ストアなどの環境を日本向けに整備するのが追いついていないのではなかろうか、 とか言われていました。 この少し後にWindows Phoneの公式マップとして採用したNokiaのマップとか、 日本の領域はスカスカだったし。

一方、海外ではそれなりにWindows Phoneが出ていました。 Nokiaの力もあったのでしょう。 特に2012-13年頃はヨーロッパでわりとシェアがあったような。 イタリアとかiPhoneよりシェアが多かったはず。

IS12Tにはその後Windows Phone 7.8が配信されましたが、 それが最後。 ハードの世代的にWindows Phone 8にはできない。 主にNokiaがWindows Phone 8機を海外で出すのを横目で見ながら 再びうーうー唸る日々が続きました。

そして、ついに、2014年10月にWindows Phone 7.8のサポートも終了します。 でも、しばらく使い続けてたけど。

復活

2015年早春、マウスコンピューターとかFREETELとかがWindows Phone機の開発を表明します。 まあ、今までの経緯があるので「実物を手にするまで信じひんのやー」という思いでしたが。

ところが、6月、思ったより早くマウスからMADOSMA Q501が発売されました。 もちろん、すぐに入手しました。 またまた感無量です。 4年近くぶりですよ。 IS12Tと比べて、手に取った時あっけらかんと軽いので驚いた覚えがある。

この年、 Windows Phone OSもWindows 10ベースになり、 それに伴いブランドも"Windows 10 Mobile"に変わりました。 このMobile版のWindows 10のリリースに合わせて、 翌年にかけてWindows 10 Mobile機が国内でいくつか出ました。 11月には、Windows 10 Mobileの「日本最速提供」競争が発生していました。

  • 11/24: FREETEL Windows 10 Mobileスマホ「KATANA 01」を発表。
    • 11/25 受付開始
    • 11/30 発売(この時点で最速と思われた)
  • 11/26: ヤマダ電機 Windows 10 Mobileスマホ「Every Phone」を発表。
    • 11/28 発売(この時点で最速と思われた)
  • 11/27: マウスコンピュータ 既存のWindows Phoneスマホ「MADOSMA」へのWindows 10 Mobile搭載を発表。
    • 11/27 既存機の有償アップデート代行を開始。3000円。ダイレクトショップに持込んでアップデート可。
    • 12/04 Windows 10 Mobile搭載MADOSMA発売
    • 12月 既存機へのアップデート配信開始

結局、11/27に既存のMADOSMAをダイレクトショップに持ち込んでアップデートしてもらうと、 一般提供の公式版を「日本最速」で入手することができたようです。

まあともかく、日本では妙に盛り上がっていました。 逆に世界では失速ぎみでしたが。 このあたり、うまく波が噛み合わない。

で、現在

また微妙な空白期に入ってしまいました。 Microsoftはスマートフォンをあきらめていないようですが、 次の動きは2018年以降になりそうです。 Fall Creators UpdateのARM対応に合わせてなにか動きがあるんじゃないかと思っていましたが、 これは外れたようです。 また、どうやら現行の機種は「次のWindows 10 Mobile」にはアップデートできないっぽい。 あらあらという感じですが、 スマホはハードの制約が厳しかろうし。

まあ、またひたすら待つ局面です。 待つけど。 でも、Microsoftももうちょっとロードマップというか、どうするつもりなのか言った方がいいんじゃなかろうか。 おっちゃんは待つけど、パートナーは愛想つかさずに付き合ってくれるんだろうか心配。

再びIS12Tについて

結局、IS12Tは四年近く使い続けました。 その間に妻のiPhoneは3回ほど変わって、 回線もLTEになったりしましたが、 その激動の時代をあまり不満なく使っていたなあ。 スマホに関してはタイルUIが気に入っているし、 タイルのシトロンのカラースキームも好きだった。 さすがに最後の方は回線速度とか色々重かったけど。 電源はもう入れませんが、まだ手元に置いています。

というわけで、 IS12Tに感謝しつつ、 Windows 10 Mobileの存続を切に祈念しております。

2017年8月 9日 (水)

「認証プロキシ爆発しろ!」が自動構成スクリプトに対応しました

認証プロキシをなんとかするためのツールであるところの「認証プロキシ爆発しろ!」ですが、 プロキシ設定の自動構成スクリプトに対応しました。 自動構成スクリプト(.pacファイル)によって複数のプロキシを使い分けているような環境では、 「認証プロキシ爆発しろ!」は自動構成スクリプトの内容に応じた適切なプロキシに対して中継を行うようになりました。

今回のバージョンアップに伴って、設定の変更が必要になります。 以下、それも含めた説明など。

  • ユーザーへの影響
  • 従来の動きと問題点
  • 新しい動き
  • 設定変更の必要性
  • 問題など

ユーザーへの影響

現在「認証プロキシ爆発しろ!」をお使いの方のうち、 以下の条件に該当する方は設定変更の必要があります。

  • コントロールパネルの「インターネットオプション」-「接続」-「LANの設定」の「自動構成」 (Windows 10の「設定」で言えば「ネットワークとインターネット」-「プロキシ」の「自動プロキシセットアップ」)が 有効になっている環境下で「認証プロキシ爆発しろ!」をお使いの方。

と言っても、 ver 1.0.17.0以降のGUI版「認証プロキシ爆発しろ!」を起動すると、 変更の必要のある場合は「設定を推奨値にするか?」という画面が出ますので、 「はい」を押せばほとんどの場合大丈夫です。

設定変更の必要性の詳細を知りたい方は、 以下の説明をお読みください。

従来の動きと問題点

従来の「認証プロキシ爆発しろ!」において、 通信の中継先となるプロキシ(「実際のプロキシ」)はひとつだけでした。 通信の中継を開始する際に、 「実際のプロキシ」のアドレスを自動検出し、 そのアドレスに対して中継を行っていました。

一方、 多くの環境では自動構成スクリプト(.pacファイル)によるプロキシの自動構成が行われています。 この自動構成スクリプトでは、 通信元のアドレスや通信先のURLに応じて複数のプロキシを使い分けるということができます。 「認証プロキシ爆発しろ!」はこのような環境で複数存在する「実際のプロキシ」を使い分けて中継を行うことができませんでした。

というか、 私がこのツールをふだん使っている環境で、 近々複数のプロキシの使い分けが必須になりそうな状況でして、 そのために真面目に対応する気になったんですけれどもね。

新しい動き

PCのユーザー環境でプロキシ設定の自動検出や自動構成スクリプトが有効になっており、 かつ、 「認証プロキシ爆発しろ!」の「認証プロキシ」設定が「自動検出する」になっている場合、 「認証プロキシ爆発しろ!」は自動構成スクリプトが返す「実際のプロキシ」に対して中継を行うようになりました。

新旧比較

設定変更の必要性

変更が必要になる設定は、 「認証プロキシ爆発しろ!」の設定の「プロキシ」-「システム設定書換え」-「中継時の設定」にある以下の二つの項目です。

  • ローカルアドレスにはプロキシサーバーを使用しない
  • 次で始まるアドレスにはプロキシを使用しない

従来は「認証プロキシ爆発しろ!」を通す必要のないアドレスをここに指定していました。

今後、自動構成スクリプトが有効な環境においては、 いったんすべてのhttp通信は「認証プロキシ爆発しろ!」が中継し、 その内部で自動構成スクリプトの結果に応じて切り分けを行います。 その切り分けには「プロキシを通さない」という判断も含まれます。

なので、この場合、 上の「中継時の設定」は原則不要になります。 ぜんぶ「認証プロキシ爆発しろ!」を通せばよい。 まあ、全通信を中継するオーバーヘッドを考えると、 「プロキシを通さないことが確実なアドレス」は指定してもよいかもしれません。 「ローカルアドレスにはプロキシサーバーを使用しない」ぐらいが実用的ではないでしょうか。 ということで、新しい設定の推奨値は『「ローカルアドレスにはプロキシサーバーを使用しない」のみ有効』にしています。

問題など

「認証プロキシ爆発しろ!」による中継下で、 IEやChromeでは問題がないのに、 Edgeで「プロキシサーバーに接続できません」というエラーが出ることがあります。 現在気づいているケースとしては以下があります。

  • 新しいタブを開いた際の「新しいタブ」ページの「マイ フィード」の項
  • プロキシの内側にあるサイトのページ(外部ページは問題ない)

後者の正確な条件はよくわかりません。 ひょっとしたら、Active Directoryのドメインが関係しているのかも。

この問題の原因は分かりません。 このケースではそもそも「認証プロキシ爆発しろ!」に接続が来ていません。 Edgeが内部でプロキシの要不要をどう判定しているのかが謎。

あと、 ほとんどのhttp通信を「認証プロキシ爆発しろ!」に通すことになるので、 以前よりオーバーヘッドがかかるようになります。

現状、(httpsではない)普通のhttpではレスポンスを返す際にチャンク転送をサポートしていない(まとめて返している)ので、 体感的に遅く感じる場合があります。 これは以前からの問題なんだけど、今回の変更でより目立ちやすくなったかも。

そのうちなんとかしたい。

2017年5月14日 (日)

Windows 10 Mobileユーザーを一時的に増やした話

上の娘の機種変更時のつなぎにWindows 10 Mobileを使った話。 と、おまけで、Windows 10 Mobileをめぐる最近の状況についてちょっと思うところなど。

経緯など

うちには子供が三人います。 下の二人にはエントリーモデルのWindows 10 Mobileを持たせています。 このあたりの経緯は過去に書きました。

子供らの「つなぎ携帯」をWindows 10 Mobileにしてみた話

一方、 上の娘はiPhoneを使っています。 このiPhoneの契約が二年縛りの更新月を迎えました。 で、今になってみると、 うちの他の回線はすべてMVNOにしてしまったし、 こいつもMVNOにして通信料を節約したい。 ところが、都合の悪いことに、このiPhoneはSIMロック解除対応前のものです。

どうしたもんかと、色々費用をシミュレーションしたり娘と話し合ったりして、 「SIMフリーのiPhone SEに乗り換えよう」という結論に達しました。

AppleのiPhone下取りキャンペーン使って乗り換えるぞー。 なに?Apple Storeだとその場で下取分を割引するけど、 オンラインだとApple Storeギフトカードになる? ギフトカードなぞいらん、キャッシュよこせー。 よーし、ゴールデンウィーク中に一家で東京に行く機会があるから、 その時Apple Storeに押し掛けるぞー。 ということで、機種切り替えがゴールデンウィーク中にスケジュールされたのでした。

で、四月の終わり近くにキャリアにMNPの申し込み電話をしました。 例によって転出を思いとどまらせようとするような会話にテキトーに対応していたのですが、 一つ気になる指摘がありました。 予定では切り替えは5月上旬になるのですが、 となると、数日の利用のために5月分の基本料が丸ごと取られてしまうらしい。 「なので、切替えは月のなるべく遅くにした方が...」などとお勧めしてくれるのですが、 こちらは別のことを思いつくわけです。

ピコーン

回線は4月中に切り替え、 iPhone SEを入手するまではWindows 10 Mobileでつなごう。

娘に打診したところ、「一週間ぐらいなら」とOKが出ました。 妹と弟が使っていることもあり、多少の興味はあるようで、まんざらでもなさげ。

機種

機種はMADOSMA Q501を使います。 私がInsider Program入れて遊んでいるやつです。 ちょうど、Creators Updateに相当する10.0.15063.251が降ってきたところでした。 これに対して「電話のリセット」したところ、 都合よいことにOSバージョンは巻き戻らず、 ProductionなCreators Update機ができあがりました。 当時まだ国内のほとんどのProductionな電話にCreators Update降ってきてなかったのに。

MNPしたMVNOのnano SIMをmicro SIMアダプタかませてMADOSMA Q501に載せ、 娘のMicrosoftアカウントを指定し、 OutlookをiCloudのメールアカウントと接続。 あとは好きに設定せいや、 と渡したら、 次の朝にはあっさり実運用しとりました。 この時点でCreators UpdateのWindows 10 Mobile機使っている女子高生って、 日本に数人いるかどうかじゃないか?

というわけで、 わが家におけるWindows 10 Mobileシェアは80%に達しました。

我が家のスマホシェア

圧倒的ではないか、Windows 10 Mobileは。 こまるわー、寡占が進んでこまるわー。

あとは妻だけだけど、 妻は私がX01T時代にメール一本打つのに苦労してたの見てあきれてたからなあ。 今回も上の娘に「Windows Phoneにしたらメール打つのも苦労するで」とか言ってたし(もう今はあまりメール使っていないくせに)、 なかなか手ごわそう。

感想など

娘に一週間ほど使ってみた感想を聞きました。 良い点。

  • タイルのGUIはわかりやすい。
  • 一通りのことは問題なくできる。

悪い点。

  • アプリが少ない。今ゲームとかしてないからいいけど、ゲーム好きな人は困るんじゃないか?(まあねえ)
  • 一部アプリの動きがもっさりしている(まあ、元々そんなに高スペックでもないし)
  • カメラがあんまりきれいじゃない(これはW10Mというよりこの機種の弱い点だな)

その後

予定通り、一週間ぐらいでiPhone SEに移行しました。 家庭内シェアも元に戻ってしまった。

まあ、上の娘もWindows 10 Mobile使ってみてくれたから、よしとするのです。

ちなみに、四月中のMNP切り替えは失敗しました。 元iPhoneのバックアップ等に手間取って、 「当日中の切り替え締め切り」刻限に間に合わず、 5月1日切り替えになってしまった。 あかんやん。

(おまけ)最近のWindows 10 Mobileの話題について

Microsoftの最近の四半期決算にからんで、 「MicrosoftがPhoneビジネスを6月までに終わらせると言った」とか「証券取引委員会に提出した書類で投資項目からWindows Phoneが消えている」といった話が出ており、 またぞろ「Windows Phoneは終わった」みたいに言われています。

Microsoft’s 10Q SEC filing confirms investment in Windows Phone has ended (MSPoweruser)

ざっと見てみたけど、 記述対象となる期間からして、これらは多分Lumiaビジネスを畳んだことを指しているんじゃないかな。 実際、Microsoftの2017会計年度(2017年6月迄)を越えて作業予定があるように見える。 現状、秋のFall Creators Updateに向けてWindows 10 MobileのInsider Preview配信も進んでいるし、 つい最近もSurface Phoneの生存も確認されたし。

Nadella: “We’ll make more phones, but they will not look like phones that are there today.” (MSPoweruser)

今後、Mobileは"Windows 10"の一部分(おそらくはARM版の一部)として活動するんじゃないかな。 Intelがモバイル向けSoCやめちゃったから、 ARM版Windowsを是が非でも何とかしなければならなくなっているしねえ。

で、まあ、Surface Phoneは2017年中に出るのか、2018年になるのか分からないけど、 ハイエンドになるんだろうなあ、と思っています。 一方、あまり具体的な根拠はないんだけど、 Fall Creators Update世代では久々にサードベンダーからハードが出るんじゃないかという気がしています。 関係者のタイムラインとか眺めていると、 なにか動いているんじゃないかなあ、という気がしている。 もちろん、はっきり書いたりしていないんだけど。

なんにせよ、Windows 10ベースのスマホが存続してくれることを切に祈念いたしております。

2017年4月 6日 (木)

PCの時計が1時間進む問題が完全に解決した

前回の続き。 PCの時計が1時間進んでいる問題ですが、 私のPCに関しては問題は完全に解決しました。 わーい。

  • 前回のあらすじ
  • 現状の確認
  • PCメーカーのサポートに問い合わせた→解決
  • 考察など
  • まとめ

前回のあらすじ

  • 自分のPCの時計が1時間進んでいた
  • 原因はPCのファームウェアの設定のせいと確信(thanks to 「「PCの時計が1時間ずれている」の原因 」)。 要するに、四半世紀前ならともかく、現在においてはまったく意味のない"Daylight Savings Enable"がなぜか有効になっているPCがあるということですね。
  • 突如、Microsoftが「修正した」とのニュースが→「えっ?」

現状の確認

Microsoftが修正したとのニュースに「ほんまかいな」と思いつつ、 1日ほど様子を見てました。 しかし、修正は落ちてきませんし、 ツールで覗くとReal-Time Clockの"Daylight Savings Enable"のビットは立ったままです。

念のため、以下の手順で実験をしてみました。

  1. PCのLANから切り離す。WiFiも無効にする(タイムサーバーとの同期を防ぐため)。
  2. Windows上で現在時刻を2017年4月3日午前1:55にセットする。
  3. PC電源を電源を切り、10分放置する。
  4. (10分後に)電源を入れる。
  5. Windows上で時刻を見る。

この結果、時刻は午前2:05頃になっているはずですが、実際には午前3:05頃になっていました。 "Daylight Savings Enable"の仕様通り、午前2時がスキップされています。

(あれ、4月2日だったっけな。 手元に残したメモには4月3日ってあるけど、 "Daylight Savings Enable"の仕様を厳密に解釈すると4月2日が正しいような気がする。 でも、もう直ってしまったので再現させて検証できない… まあ、午前2時がすっ飛ぶ現象が起きたのは確か。)

つまり、時計がずれる問題は直っていない。

PCメーカーのサポートに問い合わせた→解決

ここで意を決して、 PCメーカー(富士通)のサポートに問い合わせを投げました。 問題のPCは富士通 LIFEBOOK WA3/Wです。 これが昨日の夜。

で、今日返事がきました。

(意訳)BIOSアップデートしなはれ。

あー、確かに。 サポートに問い合わせる前に確認するべきでした。 最近、ドライバもほとんどWindows Updateで更新されるので忘れてたよ。

で、サポートページでBIOSを探すと新しいものがありました。 Readmeを見ると、ちゃんと載っているじゃないですか。

■ 5.改版履歴(修正項目)

...略...

(1.20)

  • パソコンの安定性を改善しました。
  • ごく稀に、4月と10月にパソコン内蔵の時計が1時間ずれることがある問題を修正しました。

わーい。 さすがFMVサポート。 こんなくそ面倒くさい問い合わせ分かってもらえるんだろうかと思って、 こんなツイートしてたんですけど、

えらそうなこと言ってほんますいませんでした。

BIOSアップデート後、"Daylight Savings Enable"はちゃんとDisableになっているし、 上記実験をしたら、ちゃんと再起動後の時間が午前2:05になってました。

直った。

考察など

Microsoftが修正したってのは何?

何でしょうねえ… どこかにコミュニケーションミスがあったのかも。 英語サイトを色々検索したんだけど、「修正した」ってニュースは他に無さげだし。 「PCの時計が1時間ずれている」の原因 を書いた人は、 その続編(「PCの時計が1時間ずれている」の原因の解説)で Microsoftのタイムサーバーのマシンでこの現象が発生したんじゃないか、と言ってます。 うーん。 でも、そうだとすると、Windowsの時刻の同期間隔はデフォルトで一週間と聞いているので、 「影響を受けたPCの時計は、日本時間4日未明までに自動で直っているという。」(「PCの時計が1時間ずれる」グローバルで発生「修正した」とMS)なんて言えないんじゃないかな。 よくわからない。

どうして今回だけ騒ぎになった?

これも分からない。 ただ、検索してみると、過去にも時間がずれたという声はあるし、 私も、前に時間がずれて「あれー」と思いながら直したことをぼんやり思い出したし、 実は以前から結構発生してたのではなかろうか。 今回、声が目立ってニュースにも取り上げられたということかも。

あと、最近広く採用されたBIOSにそういう設定のものがあったのかも知れない。

メーカーはもっと広く知らせるべきでは

と思うんだけど、 BIOSアップデートだとするとあんまり安易に勧められないしなあ。 Windows Updateでなんとかならんのだろうか。 ボードのファームウェアとなるとWindows Updateレベルでは難しいのかな。

結局、PC側の原因で問題が発生するのはどういう場合?

  • RTCの"Daylight Savings Enable"がEnableで、
  • RTCがずれるタイミングでPCが動いておらず(停止 or スリープ)、
  • その後PCを起動した場合(電源投入 or スリープ解除)

は確実に起こるかな。 OSがRTCと同期するとずれた時刻がOSに伝わる。

PCが稼働中にRTCがずれた場合はよくわからない。 OSがRTCに書き込む機会があるかどうかに依存するでしょう。

Windowsだけの問題?

いや、違うと思う。 ボード上のRTCがずれるんだから、 ずれた後に起動すれば例えばLinuxでも時間がずれるでしょう。

ただ、Linuxとかの場合、 どういうタイミング・方法でntpサーバーと同期しているのか知らないので、 その影響はよくわからない。 Windowsより短い期間で同期しているマシンが多いような気がする。 知らんけど。

まとめ

PCの時計がずれて直っていない人は、 PCメーカーからBIOSの更新が出ていないか確認してはどうでしょうか。

ただ、 BIOSアップデートは無条件にお勧めできるものでもないので、 アップデートするかどうかは注意事項をよく読んでからお決めください。

2017年4月 4日 (火)

PCの時計が1時間進む問題が発生したので調べてみた(もう答は出た、と思ったけどなんか混迷している)

昨日(4月3日)、私のPCの時計が1時間進んでいるのに気が付きました。 どうやら、同じ目にあっている人が多数いたようです。

「PCの時計が1時間ずれている」報告多数 (ITMedia)

気持ち悪いので少し調べてみました。 なんですけれど、今日タイムライン上で以下の記事を知りました。 答はこれで決まりでしょう。 (と思ったんだけど、今ちょっとわけわからん状態になっている。「で、どうするよ」の項で後述)

「PCの時計が1時間ずれている」の原因 (Tactful Answer)

ですが、せっかく簡単な実験などしていたので、 書き残しておきます。

  • 観察
  • 実験
  • で、どうするよ

観察

4月3日夜、家の帰ってPCをスリープから復帰させてしばらくして、時計が1時間ずれていることに気づきました。 家にPCが数台ありますが、自分のノートPC1台のみ時計が進んでました。

で、イベントログの「システム」でスリープ前後を見ると、 以下のようなログが残っていました。

時刻 ログ
2017/04/03 0:32:53
システムがスリープ状態になります。

スリープの理由: アプリケーション API
2017/04/03 0:32:54
システムがスリープ状態から再開されました。
2017/04/03 20:57:35
システム時刻は ‎2017‎-‎04‎-‎02T15:32:54.726613700Z から ‎2017‎-‎04‎-‎03T11:57:35.500000000Z に変更されました。

変更の理由: システム時刻がハードウェア クロックと同期されました。

時刻はUTCで出ていますが、 日本時間に直すと、 4/03 0:32にスリープしています。 その後、スリープから復帰し、直後にハードウェアクロックと同期しています。 この際のハードウェアクロックの時刻は20:57です。 「再開しました」ログのタイムスタンプが0:32:54なのは、クロック同期前なので、スリープ時点の時刻が出てしまっているのでしょう。

記録されたスリープ時の時刻は前夜の記憶通りで正しいものです。 一方、PCを再開したのは20時前でした。 つまり、復帰時にハードウェアクロックが1時間進んでいる。

復帰時のハードウェアクロックが進んでいるので、 OSではなくPCのクロックの問題なんだろうと思って、 以下のようなツイートをしました。

実験

で、今朝(4/04)、ちょっと実験をしてみました。 出勤前に、PCに以下の操作をしました。

  1. PCをLANから切り離す(WiFiも無効にする)
  2. PCを再起動し、Windowsは起動させず、BIOS画面で時間を4/02 23:30にする
  3. 電源を切る

夜、帰宅後に電源を投入し、そのままBIOS画面を出して時間を確認しました。 すると、予想通り、朝ずらした時間から予期される時間よりも1時間進んでいました。

LANに繋がず、OSも動かしていない状態で時計が進んだので、 OSもタイムサーバーも無関係。

この結果は、 冒頭に紹介した記事(「PCの時計が1時間ずれている」の原因 )の説明と整合します。

で、どうするよ

先の記事の説明に従って自分のPCを調べたところ、 確かにPCの"Daylight Savings Enable"設定が有効になっていました。 これが有効だと、4月と10月にPCのクロックがずれます。 つまり、この先も半年ごとに時間がずれることになります。 自分はツールで設定を変更するとして、 一般ユーザーとかどうするんだろうか。 これは多分工場出荷時の設定がこうなっているんだろうから、 メーカーのサポートに連絡した方がいいんだろうか、 とか思っていたところ、 Microsoftが修正(!)したとのニュースが。

「PCの時計が1時間ずれる」グローバルで発生「修正した」とMS (ITMedia)

いったい、どうやって? Windowsから"Daylight Savings Enable"を無効化してくれるのか? まさか、強制的に時刻同期させて終わりじゃないよな? 半年後またずれるし。

疑いをもちつつWindows Updateを試みましたが、 なにも落ちてきません。 念のため、先のツールで再チェックしましたが、 "Daylight Savings Enable"は有効のままです。

謎。しばらく様子見。

あともう一つ疑問があって、 なんで今回のみ騒ぎに? そういえば、このPCにしてから時計がずれていたことが以前にもあって、 「あれー」と思いながら時計を合わせたような覚えがぼんやりとあるんだけど、 今回これほど騒ぎになったのはなんでだろう? 最近よくPCに採用されているボードがこの設定になっているとか?

2017年3月26日 (日)

Windows Mobileしんでしまうん?

最近、 Windows 10 Mobileを採用していたスマホが、 新モデルではAndroidに鞍替えしていた、 ということが立て続けに2件ありました。

で、「やっぱりねー」みたいな雰囲気を感じるので、 私の見るところなど書こうと思います。 状況は厳しいけど、まだ終わる状況じゃないと思ってます。 ただ、結果的に「空白期間」が生じてしまっているので、 もっとうまく立ち回れないもんですかねえ、 というような話。

なお、これは私がニュース等を見てて個人的に思ったことを書いています。 勤務先はスマートフォンに関連している部署もありますが、 私はそことはほとんど関係ないし(というか関係あったら勝手なこと書けない)。

話は2016年始めの頃から。

2016年始めの時点

あれは2016年の始めだったか。 「Microsoftはスマホを諦めている。はやくそれを公式に認めるべき」みたいな記事が海外で出てました(ちょっと検索してみたけど、探し出せなかった)。 まあ、苦戦しているのは確かだけど、 現在進行形で戦略遂行中で、 次の施策もまだある状況で「諦めてる」と決めつけるのはひどいなあ、と思った憶えがあります。

この頃、 前の年にリリースしたWindows 10をやっとこさでスマホにもロールアウトしたところでした。 これにより、 PCもスマホもその他デバイスも、 Windows系デバイスは「Windows 10」というプラットフォームで統一され、 同じプログラミングモデル(UWP)アプリを書けるようになりました。

で、次の施策は以下だと見られていました。

  • アプリの拡充支援
  • Surface Phone

アプリの拡充支援策としては、例えばAndroidやiOS向けアプリを簡単に向けに移植する「ブリッジ」を提供しようとしていました。 が、結果としてはあまりうまくいっているように見えません。 「Windows Bridge for Android」はキャンセルされました。 「Windows Bridge for iOS」(現在v0.2)は開発が続いていますが、「使った!」という話をまだあまり聞きません。 まあ、アプリ拡充は今となってはWindows 10 MobileだけでなくUWP全体の問題になるので、 この点についてはWindows 10 Mobileの動向がどうあろうともMicrosoftは頑張ってくれるでしょう。

一方、Surface Phoneは、公式にはMicrosoftは発表していません(開発していることは認めているんだっけ?)。 この時点では、PCにおけるSurfaceのように、 新しいコンセプトを提案するようなモデルになると期待されていました。 いや、まあ、今でもそれは同じなんですけど、 登場時期が当初予想されていたより大幅に遅れており、 遅れた結果、もっと切実な問題が起こっていると思います。 これについては次の項で。

2016年夏-秋

2016年夏、MicrosoftはLumiaを作っている元Nokia部門をリストラしました。 また、Lumiaブランドのデバイスの販売を2016年末で終わらせてしまいました。 これは結構衝撃だった。 日本ではLumiaを販売していませんが、 世界的には出荷されているWindows Phone/Windows 10 Mobile機の大多数はLumiaであり、 その「大多数」の供給が無くなるわけだから。

私は、本来この時期にSurface Phoneを出す予定だったのではないかと思っています。 ここでLumiaからSurfaceへのブランド切り替えをする予定だった。 ところが、Surface Phoneが大きく遅れた一方、 Lumiaは次の計画が無いのでラインを継続させておくわけにもいかず、予定通り終了。 おかげで、Windows 10 Mobileは主流となる機種が不在になってしまった。

なぜSurface Phoneが遅れたかは、外部からは知りようがないです。 ただ、以前にわりと信じられていた噂には、 Surface PhoneはIntelのCPUを採用している、というものがありました。 そのため、2016年春のIntelのモバイル向けSoCからの撤退決断はSurface Phoneを直撃し、計画変更を余儀なくされるのでは、 と見る向きもありました。 そう言われてみれば、 冒頭のAndroidに鞍替えした件に関連して、 「今年のSnapDragon 600番台はMicrosoftのWindows 10 Mobileのサポート対象から外れていた」という証言があり、 素人目には「Intelを主力CPUにしようとしてリソースつぎ込み、一方SnapDragonのサポートは絞ってて、あてが外れたんじゃないのかよ」とか疑ったりもするのです。 知らんけど。

で、(再企画したかもしれない)Surface Phoneは(早くとも)2017年秋になるといわれています。 2017年秋といえば、Windows 10のRedstone 3のタイミングです。 Redstone 3といえば、 大きめのアップデートと言われており、 Redstone 2 and Redstone 3 are going to be heavily focused on "innovation around mobile phones."といわれるやつでもあり(ただし、この記事ではSurface Phoneは2017年4月リリースになっている)、 ARM版Windowsの復活であり、 x86エミュレーターが載るわけであり、 このあたりが次のキモだと思うのです。 Surface Phoneにx86エミュレーターが載るかどうかはわからんけど。 素のWindows 10にARM版が復活することで、 よりPC/タブレットとの差が無くなっていく方向に進んでいくんじゃないかな。 ひょっとすると、その先は「Mobile」カテゴリは無くなって、 「Windows 10」でスマホもカバーすることになるかも知れない。

今後の見込み

というわけで、まだ次の計画があるんだから、「諦めた」状況ではないだろう、と思っています。 つい最近もWindows Mobileのプログラムマネージャーの求人しているし

とりあえず、Surface Phone待ちかなあ。 私的には、もうSurface Phoneは「新しいコンセプトを提案してくれるデバイス」ではなく、 「Microsoftがスマホにコミットしていることを宣言するデバイス」として期待を一身に集めております。 本家が主力ブランド(Lumia)を止めて次をどうするか明らかにしていない現状では、 周りもコミットできないでしょう。 でも今年の秋だから、まだ遠い。

何にせよ、 今後の計画の説明なしにLumiaを販売停止すると、「撤退だ!」と思う人もいるでしょうし、 シェアが小さい状況でこんな空白期間ができてしまったらただでさえ心もとないエコシステムが消えてしまいそうで気が気ではありません。 もしSurface Phoneがずるずると伸びると、空白期間はさらに広がっていくことになります。 なんかもうちょっとうまくメッセージとか出せないもんでしょうか。 Microsoftがデバイス出せない状況なのだからパートナー頼みなのに、 パートナーさんに「梯子を外された」とか感じさせてはあかんだろう、と思うのです。 本当にたのんます。

Windows 10 Mobileに将来性はある?

まあ、現状苦しいのは確かだけど、 ぼちぼちスマホ市場の状況も変わりつつあり、 まったく目が無いわけではないと思ってます。

iOSとか、そろそろMacとの関係をどうするんだということが問題になってくるんじゃないかな。 新しいモノを世に出す際には、その目的のために鋭く割り切ったようなモノでなければ認知されることはないでしょうが、 いったんブレイクして色々な人が使い始めると、色々な要求に対応せざるを得なくなり、どんどん肥大化していきます。 iPod/iPhoneはその目的を実現するために後にiOSとなるシステムを作ってそれを活用したわけですが、 iPhoneがブレイクして成長した結果、いいかげんiOSも巨大になっているように見えます。 一方、少なくとも先進国ではスマホが飽和しつつあるようです。 成長が鈍ってくると、iOSとOS Xが「二重投資」に見えてきてきつくなるんじゃないかな。

で、iOSに限らず、 PC的なものとスマホやその他デバイスと、少なくともOSは統合しようぜ、 という流れが出てくるんじゃないかと思っています。 となると、Windows 10で各種デバイスのコード統合が済んでいるWindowsは、システム的には一周回って半歩先んじている状況にならないかな。

まあ、それでもアプリ不足をなんとかする必要はあるし、 優位点が生きる状況にするにはマーケティングが必要だし、 そもそも続けていなければ優位点もへったくれもありませんが。

まとめ

使い続けたいので、なんとか存続してください。 まあ、IS12Tの後、4年放置されたのに比べるとまだ何てことないけど(強がり)。

あと、MADOSMA信じてます。

2017年3月 7日 (火)

OAナガシマのおっさんの話(Visual Studio 20周年記念)

Visual Studioは今年で20周年だそうで、 #MyVSStory などというハッシュタグもできていました。

おおっと思ったので、こんなことを書きました。

で、OAナガシマのおっさんのことをちょっと思い出したので、書き残しておこうかなと思います。 実はそんなによく知らないし、 人柄を表すようなエピソードとかも無いんだけど、 大昔、おっさんを店頭で見かけていた頃の話。

OAナガシマとは

私が沼津に来たのは90年代始めの頃です。 地元の人に「沼津のパソコンショップならここ」と教えてもらったのがOAナガシマでした。 「OAナガシマ」という店名からして、 OA事務機器屋が出自なのでしょう。 (そういえば、当時DOS/V雑誌に怪しげな広告を載せていた「大西ジム」も高砂の商店街の文房具屋(ジム = 事務)でした。何回か行ったことある。今検索したら、まだ元気でやっているらしい)

その頃の店は沢田のバイパス沿いにあり、まあ、いわゆるDOS/Vショップでした。 世界的には、ちょうどPC/AT互換機上でWindowsがブレイクした頃です。 日本ではNECやら富士通やら東芝やらが独自規格のパソコンを出しており、 それらは結局PC/AT互換(いわゆる「DOS/V機」)になっていくのですが、 その時点ではDOS/Vはまだ立ち上がりかけの頃でした。 Windowsが盛り上がっており、海外で面白そうな機器やソフトが出るのに、 日本は独自規格のせいでなかなか利用できない。 Windows 3.1とか、USで発売されてから国内発売されるまで1年以上かかったなあ。 各社版の対応に手間取っている、とかの噂でした(本当かどうかは知らない)。 「鎖国状態」とか言われたりしてましたね。今ならガラパゴスか。 お好きな方はPC/AT互換機を個人輸入したりしてましたが、 そういう「DOS/V」世界の窓口がDOS/Vショップでした。 秋葉原ならたくさん店もあるんでしょうが、 地方なもんで、 近所にOAナガシマがあるのはとてもありがたかった。

なんか、DR-DOS買ったこととか思い出した。 冷やかしのつもりで店番してたおっさんに声をかけたら、 勢いに乗せられて気づいたら買ってて、 しばらくDR-DOS使ってたよ。

さて、時は1992年

Windowsはまだ16-bitの3.xの時代。 ちょうどアメリカでVisual Basic 1.0(これがまたちょっとした衝撃だった)が出た翌年。 私は「某言語でVisual Basicみたいのを作ろう」というプロジェクトに配属されました。 当時のWindows開発環境は、コマンドラインベースのMicrosoft C 6.0 + Windows SDK。 デバッガ(Code View)はこんな感じ。 (Microsoftのフォーラムの質問にCode Viewの画面イメージがあったので引用)

Code Viewの画面

せっかくWindowsがGUIを導入したのに、開発環境はキャラクタベースです。 ついでに言うと、会社支給のパソコンはFMRという独自規格。 それに富士通が出しているFMR用のDOSとWindowsとWindows SDKを入れて頑張るわけです。 (ちなみに、富士通の「DOS/V機」であるFMVは翌年秋の発売でした)

そんな中、 このプロジェクトが調査用に購入していたソフトウェアの中にQuick C for Windowsがあって、 これを動かしてみて私は衝撃を受けました。 フルGUIだし、「統合」されていて、ビルドからデバッグまでその上ですべてできる。 Windowsが普及し始めたころで、当時はWebとかもまだ広がってないためググるわけにもいかず、 Petzold本とかを頼りにプログラムを書いて色々挙動を確認するんですが、 この「ちょっと書いて動かしてデバッガで状況を見る」ということがGUI上で一目瞭然にストレスなくがんがん回せる。 生産性、という言葉では気が済まない、なにかパラダイムシフトのようなものが頭の中で起こりました。 目から鱗。

巧みな操作で計算機リソースを効率的に使う、 というのがスマートだと思っていました(まわりの達人的な人はほとんど共用ワークステーションとかにぶら下がってたし)。 しかし、考えたらこれは「パーソナル」なコンピュータなので、 CPUを自分の都合のためにぶん回すのは大正義である、 いや、自分が仕事を遂行するためにぶんぶんぶん回すべきである。 能天気にカーソルキー押しっぱなしてスクロールするのはCPUを無駄に使う頭悪そうなやり方だけど、 それで簡単に目的の場所に行けるならいいじゃないか。 「パーソナル」用機械を好きに使ってさっさと仕事しろよ、ということに思い至ったのでした。

人によってはVisual Basicが目から鱗だったりするようですが、 私はQuick C for Windowsだったなあ(いやまあ、Visual Basicも凄かったけど)。

ということで、 同じく調査用に海外から購入してたGateway 2000のマシン(鉄の筐体、純白の4DX2-66V)を占有し、 DOS/VとWindowsを入れ、Quick Cでごりごりプログラムを書いていました。

そんなこんなしているうちに

アメリカでVisual C++ 1.0が出ました。 「むっちゃ欲しい」と思うわけです。 IDEも進化しているみたいだし、CもC++になっているし。 でも日本では発売していない。

で、とある日曜日にOAナガシマに行ったら、 なんということでしょう。 置いてあるんですね。 でかい箱がでーんと置いてある。 おっさん、どこからモノを引っ張ってきたんだと思いました。 しかも、US価格から想定した値段よりかなり安い。 バッタもんじゃなかろうかとも疑ってまじまじと見てみましたが、どう見ても本物。 結局買いました。 両手でないと持てない大きさで、重かった。 開けてみると、中にはみっしりとWindows APIのマニュアルが入ってた。

当時の写真を探したら、箱が写っているものが一枚ありました。 あまりに部屋が乱雑で全景を出すのはアレなので、一部切り出しますが、箱の奥行をお察しください。

Visual C++の箱

探してみたら、フロッピーディスクまだありましたよ。

Visual C++のインストールフロッピーディスク

安かった理由は謎です。 仕入れ経路で誰か何か間違えてたか。 実はアップグレード版か何かだったりして。

ともかく、 Visual C++というアイテムを手に入れた私は絶好調でぶいぶいいわせながら開発したのでした。 当時まだ私物ソフトの使用禁止とかルール化される前でしたね。 まあ、仕上げには会社設備のMSCでコンパイルするようにはしてたけど。

その後

Visual C++はVisual Basicと統合されてVisual Studioになりました。

一方、 OAナガシマの方は、どんどん店が増えていきました。 本店は沢田から今ある大諏訪に移り、 ZOAという名前で静岡県以外にも店を出すようになりました。 今の正式な社名は「株式会社ZOA」のようですね。 その頃にはもうおっさんを店頭で見ることはなくなりました。 そういえば、Windows 2000の発表時には、 マイクロソフトの発表資料に他のメーカーやショップに並んで、 おっさんのコメントが載っていたなあ。 今検索して探し出したプレスリリースには社名しか出ていないけど、 当時のリリースではこのコメントがおっさんの名前入りで出てて、Webニュース経由で見てのけぞった記憶がある。

そして、一、二年前、 店の営業時間を確認するためにOAナガシマのサイトを見に行って、 間違って「会社概要」を開いてしまったら、 代表者の名前がおっさんじゃなくなっていました。 引退したのかな、とも思ったのですが、 気になったのでIRを見てみたら、 2013年の夏におっさんが亡くなったとの知らせが出ていました。

昔の沢田の店も、 去年更地になり、 ポルシェの店になりました。

その頃(もう四半世紀前)からすると、 PCをめぐる状況も、 OSやソフトや開発環境のあり方もずいぶん変わりました。 一方、その頃作っていたそのソフトは、 幸運にも気に入ってくれた人が結構おり、 バージョンを重ね、 まだ稼働しているものもあります。 ソフトウェアが世に出るのはいろんな人の仕事やら偶然やらが積み重なった結果なのですが、 あのソフトには「おっさんがVisual C++をどっかから引っ張ってきてくれた」という要素も入っているのです。

ということで、 おっさんのご冥福をお祈りします。 と同時に、Visual Studio 20周年おめでとうございます。

2017年3月 4日 (土)

SourceTreeでGit LSFを使うには

【要約】「リポジトリ」-「Git LFS」メニュー

分かれば簡単だけど、しばらく迷ってうろうろしたので覚え書き。

SourceTreeはGit LFSに対応していると聞いたのに、 どうやればリポジトリの扱いをGit LFSモードにできるのかが分かりませんでした。 「リポジトリ設定」の画面にも設定ないし。 ヘルプとか検索かけても出てこないし。

が、まあ、気づけば簡単で、 メニューに「リポジトリ」-「Git LFS」という項目がありました。 そのサブメニューの「Initialize Repository」から始めれば、 あとはだいたい見当ついた。

それだけ。

«認証プロキシをなんとかするためにツールを作っている話