次の野望はアプリ開発環境の天下統一？

　Windows 10は、PC、タブレッド、スマートフォン、ゲーム（Xbox One）、VR（Hololends）、従来型の組み込みデバイスを含むIoT（Internet of Things）デバイスなど、多種多様なデバイスに対して、デバイスドライバーやアプリの共通のプラットフォーム「OneCore」を提供することを目指して開発されたOSです。

　Windowsはこれまでもさまざまな種類のデバイスに対して提供されてきましたが、Windows 10のOneCoreによってその統合がひとまずの完成をみたということになります。



　しかしながら、OneCoreの重要な一角であったはずのスマートフォンがOneCoreから脱落しました。

　実際に、Windows Phone 8.1以前のサポートはすでに終了しています。2019年12月10日にWindows 10 Mobileバージョン1709のサポート終了をもって、スマートフォンからは完全撤退となります。後継製品についての発表はなく、マイクロソフトは利用者に対してAndroidまたはiOSデバイスへの乗り換えを案内しています。

Windows 10 Mobileのサポート終了：よくあるご質問

　マイクロソフトの次なる野望は、この世のすべてのデバイスを対象としたユニバーサルな開発プラットフォームということになるようです。OneCoreからスマートフォンが脱落したことで、モバイルアプリの開発についてはAndroidやiOSに注力することになります。

　Windowsのアプリ開発プラットフォームである.NET Frameworkを、クロスプラットフォームに対応させるため、.NET Coreとしてオープンソース化しました（2014年11発表、2016年6月バージョン1.0リリース）。

　その後、Android、iOS、macOS向け.NETアプリの開発が可能なXamarinの買収（2016年2月）、開発向けリポジトリサービスであるGitHubの買収（2018年6月）、Windows向け.NET Frameworkと.NET Core、Mono Project（Xamarinに含まれる.NET Frameworkのオープンソース実装）を統合することになる次期バージョン「.NET 5」の発表（2020年11月リリース予定）の流れからも、その野望が見て取れます。

　そしてその野望から見ると、Windowsは、macOS、Linux、iOS、Androidなどと並ぶ「デバイスの一種に過ぎない」というわけです。

アプリ開発者にうれしい機能が続々と追加、一方で…

　Windows 10バージョン1803からはOpenSSH（ssh.exe、ssh-keygen.exe、sftp.exeなど）、curl、tarといったよく使うオープンソースのコマンドツールが標準搭載されるようになりました。

　SSH接続のための端末アプリや鍵生成ツール（たとえば、Putty）をわざわざダウンロードしてインストールする必要はなく、標準のコマンドで公開鍵と秘密鍵のペアを生成し、コマンドプロンプトやWindows PowerShellウィンドウからSSH接続を開始することができます。これらの機能はアプリ開発者だけでなく、IT管理者にとってもうれしい機能だと思います（たとえば、Linuxとの混在環境、クラウド管理など）。

　しかし、1つ懸念があります。オープンソースのこれらのツールに脆弱性が発見された場合、Windows Updateを通じて修正版に更新されるのかどうかということです。

　Windows 10バージョン1803以降に標準搭載されている各ツールのバージョン（ssh -V、curl --version、tar --version）は以下のとおりです。


　これまでのところ、標準搭載されているツールのバージョンが、Windows 10の同じバージョン中に更新されたことはありませんでした。Windows 10バージョン1809には、10年間のサポートが提供されるLTSC（長期サービスチャネル）版のWindows 10 Enterprise 2019 LTSCがあります。

　特にOpenSSHのSSL/TLS対応部分であるLibreSSL（OpenSSLから派生したOpenBSD版）に脆弱性があると影響は重大ですし、長期的にはTLSプロトコルの新しいバージョンへの対応も必要になるでしょう。

　マイクロソフトが修正版を提供することがないなら、エンドユーザー側で何かしらの対応（OpenSSHクライアントを削除するなど）が必要になるかもしれません。もちろん、マイクロソフトがWindows Updateを通じて更新版を提供するのかもしれませんが、過去に実績がないため、過度に期待することはできません。

メモ帳の既定文字コード変更はトラブルの元では？

　Windows標準のテキストエディターといえば「メモ帳」（Notepad.exe）です。従来のメモ帳はWindowsの改行コードであるCRLFのみを認識しました。Windows 10バージョン1809のメモ帳からはLFのみ（UNIX/Linuxの標準）、およびCRのみ（MacOS 9以前の標準）の改行コードをサポートするようになりました。これは、さまざまなプラットフォーム間でテキストデータをやり取りするアプリ開発者にとってはうれしい機能だと思います。

　しかし、アプリ開発者ならよりプログラミングに適した高機能なテキストエディターを追加して利用しているでしょうから、あまり関係ないかもしれません。むしろ、一般的な利用において、ダウンロードしたテキストファイルから改行が失われる（実際にはLFとして存在する）ようなトラブルが減ることになるでしょう。

　Windows 10バージョン1903ではメモ帳で「UTF-8」（BOMなし）のサポートが追加され、既定の文字コードが従来の「ANSI」（日本語環境なら「Shift_JIS」のこと）から「UTF-8」（BOMなし）に変更されました。「UTF-8」で保存されるのは新規に作成したテキストの保存時の既定の文字コードであり、従来のANSIコードで作成されたテキストが扱えなくなるわけではありません。

　詳しくは触れませんがShift_JISコードは、古くからプログラミングする上で厄介な文字コードでした（「申」や「ソ」が文字化けする問題）。アプリ開発者はそれを承知の上でShift_JISコードをエスケープしたり、UTF-8に変換したりして工夫してきました。

　しかし、メモ帳の既定の文字コードまで変更してしまうことは、多くのユーザーを戸惑わせることにならないかと心配です。

　Windowsは内部的にはUnicode（UTF-16LE）を使用していますが、日本語環境のコマンドプロンプトやWindows PowerShellのコードページは932（Shift_JIS）です。

　UTF-8で保存されたテキストファイルの内容をTYPEコマンドやGet-Contentコマンドレットで参照すると、文字化けします。Shift_JISを期待して組まれたバッチファイルやスクリプトは、特にWindowsバージョンの混在環境によっては、誤動作する可能性があります。

　コマンドプロンプトやWindows PowerShellなどのシェル環境やスクリプトを利用することがない一般ユーザーにはほとんど影響がないように思えるかもしれませんが、テキストファイルの文字コードはエクスプローラーの検索結果にも影響します（画面1）。


　たとえば、エクスプローラーの検索ボックスに入力した日本語はShift_JISコードで扱われるため、UTF-8で保存されたテキストファイルを期待通りに検索できませんし、コンテンツのプレビュー表示はUTF-8の場合に文字化けします。

　Windowsやアプリに含まれるテキスト形式のリソースファイル（.psd1、.psm1、.xml、.jsonなど）やログファイル（.log）を少し調べてみると、文字コードや改行コードの統一性がすでに失われていることを確認できます。昔のメモ帳だと、正しく参照できないものばかりです。

　メモ帳の改良は、そのような実情に対応するためにも不可欠だったのでしょうが、既定の文字コードまで変更する必要は、本当にあったのでしょうか。

【次ページ】“このWindowsにpythonがない”と悩む開発者なんていない