2018-12-10

RIP EdgeHTML. Software lifecycle is difficult

丁度USへ行っている最中にMicrosoft EdgeがChromiumベースになるというニュースが入ってきた。とにかく残念というしかない。

個人的な感覚で言えば、BillGだったらもう少し違ったやり方を行っているだろう。おそらく今止めるって判断をしない (EdgeHTMLを作る前に止めるか、そもそももっとリソースを投入して製品としての品質を上げる。今のEdgeはUXがちょっと中途半端だと思うんだ) 、ナデラはサーバーサイドの人だからそういう判断もするだろうなと。

Internet Explorer / Microsoft Edgeに対していろいろ怨念なことを書いている人は多いけど、この怨念って (Microsoftの強みでもある) プロダクトライフサイクルが原因としか思えないのだよねと思うことが多々あって、ちょっと書きたくなった。

プロダクト・ソフトウェアライフサイクル


従来 (1990年代) のMicrosoftのプロダクトサポートポリシー (≒Hotfixの提供、セキュリティ修正プログラムの提供) はN-1だった (現在のメジャーバージョンと一つ前のバージョンという意味)。これだと一つ前のバージョンのサポートがいつ終わるが明確ではないということで2000年代にちゃんと正確な日付を設定するようになった。Windows 2000以降上に乗るInternet Explorerというのはこのポリシーとはちょっと異なっており、OSに乗ってるバージョン (Windows 2000の場合はInternet Explorer 5.01) と最新バージョンがサポート対象という考えだった。それをみんな (≒社内も含む) 理解しておらずN-1ルールだと思い込んでいて、5.01はサポート終了するから5.5にアップグレードしてれば安全とか顧客に言ってた人たちが「どうにかならないか?」と私とかに交渉しにくるのは多かった。(Sustained Teamと一緒に働いていた関係上) 日本における最終的に泣きつく先が私だったので。なぜこうなっているかはソースコードが誰のオーナーなのかとかビルドラボとかいろんな事情があるんだけど。

またWindows XPも結果として2014年までサポートすることになったが、そもそもリリースされた最初の段階ではそこまでライフサイクルが長い製品になるなんて誰も思ってなかった。次のWindows Vistaのリリースが2006年になったのはLongHornが失敗したのが原因なのだが (LongHornはBuild 4xxxだったのだが、Build 5000を入れたときにWindows XPまんまの画面が出たのは記憶に残ってる)、リリース期間が開いてしまった結果、より多くの環境でWindows XPが使われることになった。またVistaのリリースの頃くらいに、エンタープライズ系の顧客からの要望の結果、サポート期間がWindows XPのEOL (End Of Life。サポート期間の終了) が2014年になるという話になる (このメールを見たときに殺気を覚えたのはいうまでもない。自分のハードディスクからこのソースコード消せないのかと。それよりも先に会社を退職したけど)。

Windows XPのサポート期間の延長の決定がInternet Explorer 6のサポートが2014年になってしまうということに。Webブラウザが13年間サポートされるというこがいかにクレイジーなのか (GNOME 2.0でさえ2002年のリリースだよ!)。もしサポートがWindows 7のリリースと同時に終了してれば、Web開発者はそこまで不満を持たなかっただろう。

Internet Explorer 6に対して標準準拠のことをよく言われるが、1990年代というのは標準化というのは後で付いてくるようなもので、NetscapeやMicrosoftはその相互運用性なんてそこまで考えてはなかった (自分はよくIntranet Explorerという言葉を使ってた。イントラネット環境においての最高なブラウザである意味)。Internet Explorer 6なんてその頃に生まれたような産物で、Netscape/MozillaだってGeckoベースになるまでは標準化なんてそれほど考えてなかった。Internet Explorer 7でいろいろ軌道修正を行っていろんな問題を解決し始めて (7の開発時に本社のInternet Client All Handsに行った時はその話がメインだった)、Internet Explorer 9では非常にトレンドにのった実装になったし、さすがMicrosoftだなと (Internet Explorer 8を作ってる最中に9も同時進行だったんだろうなと推測される)。

また、Webの進化を進めるため、Chromeが仕掛けたラピッドリリースモデルも彼らへの不満を増幅させた要因になった。リリースから2年経過したブラウザの対応が辛い状況を作られれば、Microsoftの従来のやり方だと不満しか残らなくなる。

結果として、Microsoft製ブラウザへの対応をすることへの不満に持つ人が増える。これは完全にプロダクトライフサイクルのせいだろう。

その後、OSに付随するバージョンのInternet ExplorerのサポートはOSと同時に終わるのをやめて最新バージョンのみになったが、決断が遅かった。

EdgeHTML


個人的にEdgeHTMLの一番の判断のミスは、古いOSへのサポートがなかったことだろう。WinRTのサブセットをWindows 7に持ってくるか、二つのOS対応のコードを作ればよかったのでは (MainsoftがInternet Explorer 5に対して行ったようにshimレイヤー作ればよかった。Tridentだって抽象化レイヤーあったのに)。EdgeがWindows 7で動かない以上、Internet Explorer 11へ対応することが求められる。Internet Explorer 11だって2013年のリリースだから5年前。そりゃつらい。

まとめ

Windows 7上でEdgeHTMLが動いて、半年サイクルでMicrosoft Edgeが全OS向けにリリースされていれば、EdgeHTMLをやめるというニュースを喜ぶ人も少なかったのだろうなと思う。Windows Phoneみたくいろんな戦略を間違った結果なんだよね。たらればだけど。ソフトウェアライフサイクルの定義は難しい。

2018-08-22

llvmとrustにおけるWindows/aarch64のサポート

llvm自体には基本的にはWindows/aarch64 (COFF/aarch64) の初期サポートがすでに入っていたのだけど、Unwind InformationとかExceptiion Handlerのサポートは入ってなかった。そのため、C++のコードをコンパイルしようとしても以下のようなInternal Compiler Errorでclangとかがクラッシュする状況だった。
clang version 6.0.1-5 (tags/RELEASE_601/final)
Target: aarch64-pc-windows-msvc
Thread model: posix
InstalledDir: /usr/bin
...
fatal error: error in backend: Funclet EH is not implemented for this target clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 6.0.1-5 (tags/RELEASE_601/final)
Target: aarch64-pc-windows-msvc
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test-1a3737.cpp
clang: note: diagnostic msg: /tmp/test-1a3737.sh
clang: note: diagnostic msg:
先月くらいからいろいろLLVMにコードが入り始めており (ex. https://reviews.llvm.org/D49637)、基本的なUnwind Informationとかをllvmが生成できるようになってきている。そのため、rustにもWindows/aarch64対応が入った。ただし、rustup等でインストール可能ではなく、自分でビルドする必要がある。
rustc.exe --target aarch64-pc-windows-msvc -O hello.rs
で生成されたバイナリをみると確かにaarch64のコードが生成されている
Microsoft (R) COFF/PE Dumper Version 14.15.26726.0
Copyright (C) Microsoft Corporation.  All rights reserved.

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
AA64 machine (ARM64)
8 number of sections
5B7D2340 time date stamp Wed Aug 22 19:38:00 2018
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
Application can handle large (>2GB) addresses

...

main:
str     lr,[sp,#-0x10]!
mov     x3,x1
adrp    x8,0000000140001000
adrp    x1,anon.4a7df3b253b8104c34e7c5ba0fd9252b.0.llvm.9631437952416841302
sxtw    x2,w0
add     x8,x8,#0x30
add     x1,x1,#0
add     x0,sp,#8
str     x8,[sp,#8]
bl      _ZN3std2rt19lang_start_internal17hac3e63ad7889c515E
ldr     lr,[sp],#0x10
ret
なお、Microsoft Visual Studio 15.8に入っているaarch64アセンブラ (armasm64) はそれ単体だとUnwind Informationを生成できないので、Cプリプロセッサを使ってマクロを読み込んでUnwind Informationを生成しないといけないという面白状態 (それもドキュメントがないのだけど、dotNETとかChakraのコードを読めば理解できる) なのだが、Cプリプロセッサ通さなくてもいいようにしてほしいと願ってる。

2018-07-22

Web Replay

Mozillaとして今年はWeb or アドオン開発者へ向けての機能を充実させようというのがテーマにあるんだけど、Brian Hackett (元々SpiderMonkeyの型推測とかやってた人) がWeb Replayというものを作ってる。まだ本体には入っていないのだけど、これはRecording & Replayデバッガと呼ばれてるもの。

デバッグをしていと誰もが経験すると思うのだけど、ブレークポイントを仕掛けて止まった時に、調べようと思ってた現象 (バグ) がすでに起きてしまってて、「あー、このポイントでは遅かったか。。。」ということは何度も経験あると思う。そうするともう一度デバッグのやり直しになると思う。Recording & Replayデバッガがあると、その際にその現象が起きるところまで巻き戻すことができる。そのためデバッグの効率が非常に高くなる。

またその一連の動作を保存できれば、現象を何度も起こす必要なくそれを再生すればいいだけなので、QAが見つけてきたものを開発者がより効率的に調査できる。

そのような機能をFirefoxに搭載しようとしていて、これがWeb Replayと呼ばれているもの。

ちょうど今月のJSConf EUでJason Lasterがそのプレゼンやっててビデオがここにある。10分くらいからそのデモがある。


こういう機能がブラウザに入ればよりデバッグが楽になるよね!Firefox 63 or 64くらいかなと。

追記

Replyじゃなくて、Replayですね。emkさんありがとうございます。