自分はちょうど半年前くらいにGeckoView Team (要はAndroid用のGeckoを作るチーム) に移籍してる。Input Systemとかがメインで (Windows + macOS + Linux は自分と中野さんがやってるのでAndroidがそれに加わったようなもの)、それ以外もいろいろバグ対応とかしてる。
GeckoViewってのはモバイルというかAndroid版の戦略変更によってここ2年くらいMozillaが作ってるもので、フロントエンドのUXさえ作ればいろんなバリエーションのブラウザを作りやすくなるという代物。例えばFirefox Focusようなものや、Firefox Reality、Amazon EchoShowでGeckoベースのブラウザを作ったりするなど、いろいろバリエーションが増やせるようになった。
そもそも従来のAndroidに内蔵するWebViewにはいろんな制限があって、簡単に言えば元となってるChromeと同様のWeb APIをサポートしてるわけではない。だからWebViewを使ったブラウザというのはそのバージョンのChromeと同等ではない。(もし同等なものができるのであれば、ChromeがWebView使ってると思う)。GeckoViewはそうではなくて、Geckoで実現可能なものはすべて使えるようにAPIをいろいろ追加してる。
超簡単なブラウザを作るのであれば、mozilla-centralのツリーに入ってるGeckoView Exampleのがサンプルになる。見てみればわかるけど、簡単なものを作るだけであれば、非常に少ないコードでブラウザをつくることができる。またこれだとヒストリ機能とか足りないので、Android Components (a-c)というものを使うことでブラウザをより現代のブラウザらしくつくることができる。なおa-cはGeckoViewじゃなくてもServoとかシステムWebViewとかに対しても動作するようになってる。
ということで従来のFirefox for Android (Fennec)はGeckoViewを使ってるわけでなかったのだけど、このGeckoView版といえるFirefoxがFenixと呼ばれてた、このFirefox Previewになる。
GeckoViewになって一番うれしいことは、やっとマルチプロセスであるということ (今後FissionとかWebRenderもあるので、プロセス数は増えると思う)。そのおかげでパフォーマンスはよくなってるはず。Firefox 68からでもあるけど、aarch64への標準対応もかな？
なお、従来のFennecは68で最後になる。ESRブランチに移行するので、セキュリティ修正等は当分行われる (今のところいつまでは決まってない)。
このFirefox Previewはまだ開発版なので、Tracking ProtectionとかPWAとかWeb Extentionのサポートが欠けてるけど、これは正式版までにははいるはず。要望やバグ報告は、Bugzillaではなくて、githubへ。日本語じゃないと無理であれば、Mozillazine.jpのフォーラムへ投稿してください。見ておきます。
2019-06-27
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の一番の判断のミスは、古いOSへのサポートがなかったことだろう。WinRTのサブセットをWindows 7に持ってくるか、二つのOS対応のコードを作ればよかったのでは (MainsoftがInternet Explorer 5に対して行ったようにshimレイヤー作ればよかった。Tridentだって抽象化レイヤーあったのに)。EdgeがWindows 7で動かない以上、Internet Explorer 11へ対応することが求められる。Internet Explorer 11だって2013年のリリースだから5年前。そりゃつらい。
個人的な感覚で言えば、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くらいかなと。
デバッグをしていと誰もが経験すると思うのだけど、ブレークポイントを仕掛けて止まった時に、調べようと思ってた現象 (バグ) がすでに起きてしまってて、「あー、このポイントでは遅かったか。。。」ということは何度も経験あると思う。そうするともう一度デバッグのやり直しになると思う。Recording & Replayデバッガがあると、その際にその現象が起きるところまで巻き戻すことができる。そのためデバッグの効率が非常に高くなる。
またその一連の動作を保存できれば、現象を何度も起こす必要なくそれを再生すればいいだけなので、QAが見つけてきたものを開発者がより効率的に調査できる。
そのような機能をFirefoxに搭載しようとしていて、これがWeb Replayと呼ばれているもの。
ちょうど今月のJSConf EUでJason Lasterがそのプレゼンやっててビデオがここにある。10分くらいからそのデモがある。
こういう機能がブラウザに入ればよりデバッグが楽になるよね！Firefox 63 or 64くらいかなと。
追記
Replyじゃなくて、Replayですね。emkさんありがとうございます。2018-07-06
Windows 10 + Snapdragon 835を採用したASUS NovaGoを手に入れてみた
これはWindows/arm64 (Windows on Arm) を採用し、Snapdragon 835を搭載したラップトップ。まずこのarm64を採用したWindowsの最初のリリースはHP Envy x2とこのASUS NovaGoとLenovo Miix 630はこの3機種。HPのは3月リリース、Lenovoのは6月。ASUSは4月くらいにはリリースされてたようなんだけど、6月になってやっと手に入りやすくなった。NovaGoがAmazon.com (US)で入手可能になったので手に入れてみた。なおUSのMicrosoft Storeでもオーダー可能になってる (日本へ発送可能かは知らない)
お値段は、本体価格が699ドル+送料で、781.08ドル。輸入コストも考えると比較的安く手に入った。(ホントは6月にアメリカ行ってる時に現地で入手したかったけどどこにもなかった)
普通に起動 & セットアップして、Windows Sモードを解除 (Microsoft StoreでWindows 10 Proを入手すればいいだけ。無償) した後、いろいろテストしてみた。
アプリケーション
- Edgeは当然のことながらネイティブアプリケーション
- x86なアプリケーションを動かすためのJITはXTCACHEというプロセスがやっている模様
- arm64なネイティブアプリ以外にも、arm 32bit (ARMNTと呼ばれるThumb2モードのみのもの。Surface RTとかWindows Phone 8以降で使ってたモード。これもネイティブで動作可能)、x86 (これはJIT使って動的にarm64へ変換してるはず)、と3つのアーキテクチャをサポートしてる
- \Windows\SysWow64、\Windows\SysArm32、\Windows\System32と各CPUモード毎にSystem32ディレクトリがある。なお、\Program Filesも\Program Files (Arm)とか\Program Files (x86)とか存在する
- Windows Subsystem for Linuxはversion 1803に上げると使える。
- Internet Explorer 11も含まれているけど、どうもx86版のみ
- Firefox (x86)は動作するけど、Chrome (x86)はVersion 1709だとちょくちょくクラッシュする。Version 1803にすれば安定するし、パフォーマンスもちょっとよくなる
WebブラウザのJITで生成されたコードをJITでarm64に変換するのはよりコストがかかる (モジュールだったら一回コンパイルした後キャッシュ持てばいいだけだし) ので、もっと遅いかと思ったら、まぁこんな程度でしょう的な感じ。これはFirefoxでSunSpiderを実行した結果
開発環境
- Visual Studioはx86なら動くのでインストール可能。x86_arm64なクロスコンパイラがあるので、これでクロス環境でなくてもネイティブアプリを作ることはできる (amd64_arm64なコンパイラだと起動できないため)
- デバッガ (cdb、windbg) はネイティブ版 (arm64) がWindows SDKに含まれているので、それを使えばネイティブアプリをデバッグ可能
- 生成コードを見る限りUNIXなAArch64 ABIと同様。ARMNT (Thumb2) の時と同様これはarmの定義したABIをそのまま使ってる
登録:
投稿 (Atom)