カテゴリーアーカイブ Windows

takahashi 著者:takahashi

DNS over HTTPS、近いうちにWindowsに実装される!?

先日、MicrosoftがDoHをWindowsに搭載することを発表しました。

Firefox/Google Chromeに続き、Windowsでも“DNS over HTTPS”をサポートへ – 窓の杜

DoH(DNS over HTTPS)は、DNSへのIPアドレスの問い合わせリクエストをHTTPSプロトコルを経由(カプセル化)することでDNS通信を暗号化する方法です。

DNSプロトコルそのものを暗号化するのではなく、既存のHTTPSの仕組みを使うため扱いやすいうえ、HTTPSポートをブロックしている環境はかなり限られてくるので、ファイアーウォールが置かれている環境でも設定の変更なく通信が通りやすいのが特徴です。

現時点ではまだDoHを正式に実装しているのはFirefox/Chromeの2ブラウザのみで、OSレベルでの対応は現状Androidのみですが、先日、MicrosoftがWindows OSの標準機能としてDoH対応を行う予定であることを明かした、というのが今回のニュースです。

ブラウザレベルでの対応では、あくまでDoH対応ブラウザを使用した通信でしかDoHが利用されませんが、OSレベルで対応されれば、そのマシンで行われる(OS上で動作する全アプリの)全通信のDNSリクエストをDoH経由で行わせることが可能になります。

DoHはユーザーのDNS要求を意図しない第三者に見せないようにすることでユーザーのプライバシーを保つ仕組みなので、OS全体で適用されるようになればより信頼性も向上することになります。

インターネットの自由性と安全性の担保の一つとして、DoHは重要になってくると個人的には考えているので、Windowsでの標準サポートはありがたい話だと思います。

今後。他のOSも追従してくるのか、今後の動きにも注目したいですね。

  • この記事いいね! (0)
村上 著者:村上

【Windows】「You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.」警告の対処法

昨日に引き続き、本日も webpack で発生したエラー・警告の対処法についてです。
昨日は「Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.」というエラーの対処法でしたが、今回の警告はこちらのエラーを解消した後に発生したものです。

警告なので、別に修正が必須ではないのですが、気になるので対応しました。
警告文は「You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.」というものです。

参考にさせていただいた記事はこちらから。

Webpack2のパフォーマンス警告を制御する – Qiita
https://qiita.com/terrierscript/items/f840b5ccff0c0be7420a

ビルドした際にファイルサイズがデフォルト設定よりも大きいです!という警告のようです。

 

対応策としては、下記の方法があります。

  1. 警告そのものを表示させないように設定する
  2. ファイルサイズ警告の閾値を変更する

私は 2の方を採用しました。
webpack.config.js に 下記を追加します。

module.exports = {
  ...
  performance: {
    maxEntrypointSize: [ファイルサイズの許容値],
    maxAssetSize: [ファイルサイズの許容値]
  }
}

どちらの値もデフォルト値は 250,000(=250kb)です。
警告になったファイルサイズによって適宜変更してください。
なお、カンマは不要ですのでお気を付けください。
あとは、npm run build を実行すればOKです。
閾値を超えなければ、警告は発生しません。

 

以上、npm run build を実行した際の「You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.」警告の対処方法でした。
ご参考になれば幸いです。

  • この記事いいね! (0)
村上 著者:村上

【Windows】「Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.」エラーの対処法

Windows 環境で、Cordova アプリをビルドしようと npm run build を実行しようとしたところ、「Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.」というエラーに遭遇したのでその解決方法についてです。
調べたところ、こちらのエラーは webpack で発生しているとのこと。

参考にさせていただいた記事はこちら。

webpack4に更新した時にこけた所まとめ – Qiita
https://qiita.com/shota_abe/items/fbd6d988188442a4d11c

上記のサイトによると、今回のエラーは webpack を 4 に更新したタイミングで発生したとのことでした。

 

解決方法ですが、webpack.config.jslodersrules に変更するだけでした!

module.exports = {
  ...

  module: {
    rules: [  // ここを loders から rules に変更
      ...
    ]
  },
  ...
}

あとは、念のため npm install を再度実行後、npm run build を実行したところ、エラーが解消されました!

ただし、今度は「The ‘mode’ option has not been set, webpack will fallback to ‘production’ for this value. Set ‘mode’ option to ‘development’ or ‘production’ to enable defaults for each environment.」というエラーが発生したので、今度はこの対策も必要です…。
こちらのエラーについては、次回に解決方法をご紹介させていただければと思います。

 

以上、「Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.」エラーが発生した時の対処法でした。
ご参考になれば幸いです。

  • この記事いいね! (0)
takahashi 著者:takahashi

AccessからDBにアクセスできなくなった場合の対処法

先日配信されたWindows Updateによって、AccessからODBCを経由したDBへの接続ができなくなってしまっているようです。

Access で、”クエリが破損しています” というエラー が表示される – パソコンのツボ ~Office のTIP

今回原因といわれているWindows UpdateのIDは下記のとおりです。

  • Office 2016 を使用している場合
    • KB4484113
    • KB4484148
  • Office 2013 を使用している場合
    • KB4484119
    • KB4484152
  • Office 2010 を使用している場合
    • KB4484127
    • KB4484160

Microsoftのサイトの記事によると、すでに修正版パッチはできているようですが、リリースは2019/12/10になってしまうようです。(なぜ一カ月後…)

それまでの間Accessが動かない状態で放置…というのは無理な場合も多いと思います。 一時的な 回避策として、下記の作業を行うことでAccessが使える状態に戻すことができます。

まずは問題を引き起こしている更新をアンインストールします。

Windowsの設定アプリから項目”アプリ” を開きます。

アプリの画面が表示されたら、”アプリと機能”内(右側もしくは最下部)にある”プログラムと機能”をクリックします。

開いたコントロールパネル内の”インストールされた更新プログラムを表示”をクリックします。

検索欄から対象となる更新プログラムを検索します。

見つかった対象の更新プログラムをひとつづつ選択し、”アンインストール”をクリックします。(※Accessを開いていた場合は終了させられる場合があるので、先にAccessを終了させてください。)

以降画面に従ってアンインストールを完了させます。

これを対象の更新をすべてアンインストールするまで続けます。

この時点で再びAccessからDBへ接続できるようになっているかと思いますが、このままにしておくと再び同じ更新が自動でインストールされてしまい、不具合が再発するため、問題の更新そのものを無効化して再発を防ぎます。

まず、 MicrosoftのWebページから、Windows Update更新除外ツールを入手します。

赤線で囲ったところから入手できます。

次に、ダウンロードしてきた wushowhide.diagcab を起動します。

するとトラブルシューティングの画面が起動します。

次へをクリックします。

Windows Updateのスキャンが始まるので待ちます。

“更新を隠す”と”隠した更新を表示する”の2項目が表示されます。上の”Hide updates(更新を隠す)”をクリックします。

まだ適用されていない更新の一覧が表示されるので、中から先程アンインストールした更新にすべてチェックを入れます。

チェックしたら”次へ”をクリックします。

更新の除外が行われます。完了するまで待ちます。

以上で問題の更新は自動でインストールされなくなります。

なお、先程書いた通り2019/12/10に今回の更新の修正版がリリースされる予定になっていますので、12/10を過ぎたら下記の手順で今回除外した更新を再度表示させて、インストールを実行する必要があります。

今回問題が起きたのがセキュリティに関するアップデートのため、更新をインストールせずに放置するとセキュリティ上の脆弱性に繋がる場合がありますので注意してください。

非表示にした更新は、次の手順で再表示できます。

先程の手順で入手した” wushowhide.diagcab”を再度起動します。

トラブルシューティングが起動します。”次へ”をクリックします。

Windows Updateのスキャンが始まるので待ちます。

再び “更新を隠す”と”隠した更新を表示する”の2項目が表示されます。今度は下の”Show hidden updates(隠した更新を表示する)”をクリックします。

現在隠しているアップデートの一覧が表示されます。対象のアップデートにチェックを入れて、”次へ”をクリックします。

以降は画面の指示に従って操作を行えば再表示化は完了です。

あとは通常通りWindows Updateを実行します。

しかし…今まで使えていたものが突然使えなくなるのは焦りますよね。

原因を調べて公開してくれる方がいなかったら、きっとパニックになっていたことでしょう…(;´∀`)

参考URL:

  • この記事いいね! (0)
著者:ym

Windows7 の有償延長サポート

来年2020年1月14日で Windows7 のサポートが終了しますが、有料でサポートを購入する事もできる様な情報が出てきました。

米マイクロソフトはこの方針を転換。ボリュームライセンス契約を結んでいるかどうかにかかわらず、あらゆる企業がWindows 7の延長サポートを購入できるようにすると発表しました

今回の発表で新たにWindows 7 ProfessionalとWindows 7 EnterpriseのESUが、マイクロソフトのクラウドソリューションパートナー経由で12月1日より購入可能になります。
Windows 7 ESUはデバイスごとに販売され、1年ごとに料金が値上がりしていく予定。

https://www.publickey1.jp/blog/19/windows_72023.html

どうしても Windows7 を安全に使い続ける必要がある場合は、ボリュームライセンスでなくてもこの有償サポートを購入する事で維持ができそうです。

ただし年々料金が上がっていく仕組みらしい。

  • この記事いいね! (0)
takahashi 著者:takahashi

Cygwinのバージョンを確認する方法

Unixライクな環境をWindows上で再現できるCygwinですが、使用しているとインストール済みのCygwinのバージョンが知りたくなる時があります。

Cygwinはインストーラーがパッケージマネージャを兼ねているような感じになっているので、Cygwinのインストーラーからインストール済みバージョンを確認することは可能です。

しかし、インストーラーをインストール後に破棄してしまった場合で、再度インストーラーをダウンロードできないような状況では困ることがあります。

実はCygwinではパッケージマネージャだけでなく、Cygwinターミナル上からもバージョンを確認することができます。

下記のコマンドを実行します。

cygcheck -c cygwin

すると下記のような形でバージョンが出力されます。

$ cygcheck -c cygwin
Cygwin Package Information
Package              Version        Status
cygwin               2.10.0-1       OK

cygcheckコマンドはインストールされたcygwinパッケージのバージョンなどを表示することができるコマンドなのですが、Cygwin本体もCygwinのパッケージとして扱われているので、このコマンドで情報が確認できるようになっているようです。

Cygwinのバージョンのチェックが必要な場合は参考にしてみてください。

  • この記事いいね! (0)
著者:杉浦

【Windows10】起動時に高頻度でブルースクリーンになる問題の対処法の一つ

 結論として、対処法の一つは高速スタートアップを切ることでした。切り方は以下の通りです。

アドレス:コントロール パネル\ハードウェアとサウンド\電源オプション\システム設定
UIを使った移動経路:コントロールパネル->ハードウェアとサウンド->電源オプション->電源ボタンの動作を選択する
移動した場所にある「高速スタートアップを有効にする(推奨)」のチェックを外す。
※チェックを外す前に「現在利用可能ではない設定を変更します」のメッセージをクリックする必要がある場合があります。


 これをするとPCが健康になる場合があります。勝手な想像ですが、高速スタートアップをするべきでないPCスペックであるにも関わらず高速スタートアップをしようとしていたのでしょう。
 以下、解決までの道筋です。
 今回起きていた問題は題にある通り、起動時に高頻度でブルースクリーンになる、というものでした。今回の問題の厄介な点はブルースクリーン時に表示されるエラーコードが多様だった点にありました。例えば、SYSTEM_THREAD_EXCEPTION_NOT_HANDLED、MEMORY_MANAGEMENT、BAD_POOL_CALLERです。このためエラーコードをググってピンポイントな解決を見つけることができませんでした。起きているエラーについて詳しく調べることでGoogle先生の提案する解決策を絞り込めます。エラーについて詳しく調べるにはWindowsのログを追うことが一つのやり方です。
 Windowsのログはコンピュータの管理のイベントビューアーから見ることができます。ここからエラー、警告、重大といった問題の起きそうなイベントのログを見ます。今回ならばとりあえず終了時の問題か、起動時の問題かの二択が想像でき、どちらの問題か調べようとしました。このログを見る限り、起動時に問題が発火、大炎上しています。

 これの中を読んでググってとしていくと起きていることがエラーコードのみよりもずっと深くわかります。今回は起点が常に高速スタートアップの失敗で、まさにそれが原因でした。(下図の様に高速スタートアップの失敗がいつも起きていた。そこから派生していくイベントのどこかしらで決定的な破綻が発生。)
 

 後は”高速スタートアップ”でググって予測で出てきた”高速スタートアップ 無効”で提案されたやり方を適用して処置完了です。
 処置後の経過をざっくり見るには信頼性モニター(コントロール パネル\システムとセキュリティ\セキュリティとメンテナンス\信頼性モニター)が便利です。以下の様に起きたイベントからPCの状態を評価、表示してくれます。処置後は回復に向かっており、一度も起動時のブルースクリーンは起きていません。

  • この記事いいね! (1)
村上 著者:村上

【Windows】npmがアップデートできない時の対処法

npm をアップデートしようとしたところ、更新コマンドは問題なく動くのですが、その直後にバージョンを調べても前のバージョンのままという現象が発生していたので、その対処法についてまとめ。

いくつかサイトを見たところ、下記2つのコマンドのどちらかを実行すれば、npm をアップデートできるとのことでしたが、何度実行してもアップデートできませんでした。

npm install -g npm
npm update -g npm

なお、teratail にも全く同じ現象で悩んでいる方がいらっしゃいました。

npm – npm 自身のアップデートができない|teratail
https://teratail.com/questions/152620

 

さて、こちらの現象の対処法ですが、上の teratail の回答で紹介されている Qiita の記事に詳しく掲載されていました。

“npm update -g npm”(npm自身のアップデート)が適用できないのは、実行元のnpmが複数存在するため – Qiita
https://qiita.com/itsumoonazicode/items/ae61c5787064bce3eff8

こちらの記事によると、「npm がアップデートできない原因は、実行元となる npm が複数存在するため」だとか。
…これだけだとわからないので、まずコマンドプロンプトで下記へ下記のディレクトリを確認してみてます。

C:\Program Files (x86)\Nodist\bin

で、このディレクトリ内に、npmnpm.cmdnpm.exe があるので、こちらのバージョンをそれぞれ下記のコマンドで確認します。

npm -v
npm.cmd -v
npm.exe -v

私の環境では、npmnpm.exe が以前のバージョンのままでした。
バージョンが確認できたら、バージョンが古い npm をリネームして、実行されないようにします。
コマンドは下記のとおりです。

move npm npm-orig
move .\npm.exe npm-orig.exe

上記を実行したら、npm -v でバージョンを確認してみてください。
バージョンが無事に上がっていたら成功です!

 

以上、npm のアップロードができない時の対処法でした。
何となくしっくりこない対処法でしたが、バージョン更新は無事できたので良しとします。

  • この記事いいね! (0)
takahashi 著者:takahashi

WSL上のLinuxでGUIを動かす方法

Windows上でLinux環境を動作させることができるWSLですが、実はGUI環境もインストールできることはご存知でしょうか。

今回はUbuntu・KaliLinuxにデスクトップ環境の一つであるXFceをインストールする方法をご紹介します。

まず、デスクトップ環境を起動する予定のあるユーザーの

~/.bashrc

ファイルをviなどで開き、ファイルの先頭に下記のように追記します。

export DISPLAY=:0.0 #display番号
export LIBGL_ALWAYS_INDIRECT=1

次に、必要なパッケージをインストールします。下記のコマンドを一行ずつ実行します。
なお、実際にパッケージをすべてインストールしたところ、2GB前後消費したので、PCに十分な空き容量があるかあらかじめチェックしておいてください。

sudo apt update
sudo apt upgrade
sudo apt install xfce4-terminal #Xfce4上で動作するターミナルアプリ
sudo apt install xfce4 #xfce4本体
sudo apt install fonts-takao #日本語用フォント(これがないと文字化けする)

インストール中に言語をどうするか聞かれるので、”日本語”を選択します。

インストールが完了すれば、Linux側の最低限のセットアップは完了です。

次にWindows上でLinuxのGUIが表示できるように準備します。

LinuxOSのGUIをWindowsで動作させるためにはWindows上で動作する”Xサーバー”が必要になるのでインストールします。

Windows用のXサーバーアプリはいくつかあるようなのですが、僕は”Xming”を使用しました。

Xming X Server for Windows – OSDN

リンク先ページのダウンロード一覧から

Xming-X-X-X-X-setup.exe

のような名前になっているファイルをダウンロードし、インストールします。

インストールが完了したら、”XLaunch” アプリを起動します。

赤枠の”One window”を選択し、Display numberを先程~/.bashrcに指定したdisplay番号と同じ番号(例: “0.0”なら0、”1.0″なら1)に合わせます。

以降の設定は最後の画面まで何も変更せずに”次へ”をクリックします。

上のような、最後の画面になったら、Save configurationをクリックすると、ここまでの設定内容をファイルに保存しておくことができ、次回以降はファイルを開くだけで設定した内容でXサーバーを起動できます。

configurationファイルの保存が完了したら、Xmingがすでに起動していないのを確認した上で”完了”をクリックします。

下の画像のような画面が表示されたら、準備完了です。

この状態で、Windows上からWSLのコンソールを開き、下記のコマンドを実行します。

startxfce4

すると、先程Xlaunchで起動したウインドウにXfceの画面が表示されます!

一見、見た目はかなり綺麗にでていて驚きました。

Windows上でLinuxがVMを通さずに動いているのを目の当たりしてしまうと、なかなか不思議な感覚になりますねw

ただし、完全に動作できるかというとまだまだ不具合もあるようで、なぜかChrome系のブラウザが起動できなかったり、ダブルクリックでファイルが開けなかったりなどの不具合があるようです。

これらについては今回参考にさせていただいた記事に緩和策も紹介されていましたが、完全には解決することはできないようです。

しかし次のWindows10 の大型アップデート(20H1) で、WSL2が搭載され、”本物”のLinuxカーネルが利用できるようになるとのことだったので、もしかするとこういった問題も解消するかもしれません。

Windows上でGUIも動かせるとなれば、余分なリソースを消費して仮想マシン上にLinuxをインストールすることなくほぼ実物に近いLinux環境をWindows上で動かせるということになり、開発もかなりしやすくなりそうですし、デュアルブートも必要なくなってくるかもしれませんね。

今後の展開が楽しみです。

参考: WSLでwindows上にLinuxのGUI環境を作る[メモ] – Qiita

  • この記事いいね! (0)
takahashi 著者:takahashi

Microsoftが開発したターミナルアプリ “Windows Terminal” を試してみた!

GitやWSL、SSHなど、最近は開発や保守などで、GUIメインなWindows上でもCUIを使用する機会が増えてきました。

しかし、LinuxやMacOSなどでは現在に至るまで伝統的にCUIが使われてきたためか、標準の仮想コンソールアプリケーションでもそこそこの機能を持つものが多いのですが、Windowsに標準で装備されている仮想コンソールアプリ(cmdなど)は必要最低限という印象で、しかもSSHなどで繋げた際にUnix系のOSとの互換性が微妙だったりという欠点が目立っていました。

そんな中、Microsoftが公式にWindows Terminal のプレビュー版をリリースしました。

Windows Terminal(Preview) – Microsoft Store

このアプリはWindows 10 1903以降でのみ利用可能となっていますが、従来のWindows標準ターミナルアプリの欠点をほぼすべて補うような内容になっています。

例えば、ほかのUnix系アプリでは標準で備えているタブ機能のほか、 SSHの標準サポート、さらに新規タブを開く際に使用するシェルを選択できたり、デザインのカスタマイズを行ったりといったことも可能になっています。

従来では、Windowsのコマンド操作はcmd/Powershellアプリを使い、WSLはコマンドで起動、SSHはTeratermで…といった形でかなり使い勝手が悪かったのですが、Windows Termialを使えばすべて1つのアプリで完結できるようになるのでとても便利そうです。

現状、ターミナルの動作設定はjsonファイル直接編集する形でのみ提供されているため少々扱いづらいです。ただ、多彩な設定が可能なので、GUIの設定画面が装備されたら最強のターミナルアプリになるかも…?

正直、Windowsのコンソールアプリは一つの悩みの種にもなっていたため、新しいターミナルをMicrosoft公式でリリースされるのはとてもありがたいです。

今後の動きが楽しみですね。

  • この記事いいね! (0)