開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

関連ジャンル

  • 会員限定
  • 2019/09/25

今のWindows 10は「開発者第一主義」に陥っていないか?

連載:山市良のマイクロソフトEYE

新機能が次々に追加され、進化し続けるWindows 10は、どこに向かっているのでしょうか。特に最近は「開発者第一主義」的な新機能が目立ちます。それが悪いというわけではありませんが「そこまで開発者のためにしてあげることもないのに」と思うことも。Windows 10を使用する大多数は、開発者ではなく、家庭や仕事場でPCを道具として使用している人なのですから。

フリーライター 山市 良

フリーライター 山市 良

IT 専門誌、Web 媒体を中心に執筆活動を行っているテクニカルライター。システムインテグレーター、IT 専門誌の編集者、地方の中堅企業のシステム管理者を経て、2008年にフリーランスに。雑誌やWebメディアに多数の記事を寄稿するほか、ITベンダー数社の技術文書 (ホワイトペーパー) の制作やユーザー事例取材なども行う。2008年10月よりMicrosoft MVP - Cloud and Datacenter Management(旧カテゴリ:Hyper-V)を毎年受賞。岩手県花巻市在住。
主な著書・訳書
『インサイドWindows 第7版 上』(訳書、日経BP社、2018年)
『Windows Sysinternals徹底解説 改定新版』(訳書、日経BP社、2017年)
『Windows Server 2016テクノロジ入門 完全版』(日経BP社、2016年)
『Windows Server 2012 R2テクノロジ入門』(日経BP社、2014年)
『Windows Server 2012テクノロジ入門』(日経BP社、2012年)
『Windows Server仮想化テクノロジ入門』(日経BP社、2011年)
『Windows Server 2008 R2テクノロジ入門』(日経BP社、2009年)
など

画像
Windows 10は開発者第一主義?
(Photo/Getty Images)

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

 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)は以下のとおりです。

  1. OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
    (Windows 10バージョン1803)

  2. OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
    (Windows 10バージョン1809/1903)

  3. curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
    (Windows 10バージョン1803/1809/1903)

  4. bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.5.f-ipp
    (Windows 10バージョン1803/1809/1903)

 これまでのところ、標準搭載されているツールのバージョンが、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)。

画像
画面1:Windows 10バージョン1903におけるメモ帳の既定の文字コードの変更は、コードページ932(Shift_JIS)のコマンドプロンプト環境で意図しない結果を招くことも。エクスプローラーの検索機能にも影響する

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

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

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

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

お勧め記事

OS ジャンルのトピックス

OS ジャンルのIT導入支援情報

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!