パスワードを忘れた? アカウント作成
14241360 story
PHP

Microsoft、PHP 8.0をサポートしないと公式に表明 52

ストーリー by nagazou
使えないわけではない 部門より
MicrosoftはPHPの次期バージョン「PHP 8.0」をサポートしないそうだ。MicrosoftでPHP関連のプロジェクトマネージャを担当するDale Hirt氏は、公式サイト上でPHP 8.0以降では、PHP for Windowsをサポートする予定はないと明言した。

Microsoftが公式にサポートするPHPは現行でサポートしているPHP 7.2、PHP 7.3。PHP 7.4のみとなる。この中で最も新しいPHP 7.4のMicrosoftサポート期限は2022年11月28日までとなっている(Microsoft Support of PHP on Windows - Externals窓の杜)。

なおKOYAMA Tetsujiさんのツイートによれば

これってバイナリ提供の話ではなくて、Windows版PHPは実はMSの公式サポートによって開発が支えられていたってことだよね。8.0以降で同レベル開発力をコミュニティが維持できるのか問題。 / “Microsoftが「PHP」サポートを縮小 ~「PHP 8.0」バイナリは公式提供せず - 窓の杜”

これにsjiさんが、

はい、その通りです。Windows 版特有のバグとかはわりと MS の中の人が対応して直したりしてました

返信している

  • たとえばどんなの?
    PHPくらいのレイヤーだとそんなになさそうだと思ってしまうんだけど。。。

    ここに返信
    • by Anonymous Coward

      ドライブレター絡みとか、共有ディスク上のファイルのロックの挙動とかありそうですね。

      • トラブルとしてはたしかにありがちだけども、PHPほどのレベルと歴史で、そんなのが今さらそうそうあるの?
        # 内部的に汎用的な対処法が決まってそうだけど。

        • by Anonymous Coward

          日本語ファイル名を扱うとおかしな事になることが良くあったよ。

        • by Anonymous Coward

          新しい機能は常に追加されますし、Microsoft自身もハマることがあるほどの罠があったりするので、
          マイナーなものから始まって徐々に対処できなくなっていくんでしょうね。

          下記はソフトウェアRAIDの例。今日日見かけないけど。
          https://forest.watch.impress.co.jp/docs/news/1263453.html [impress.co.jp]

        • by Anonymous Coward

          ファイルシステムの文字コードがCP932の環境における
          所謂「Shift_JISのダメ文字」がファイル名にある時のファイル認識ができない問題は回避不能な時期がありました。
          ※ダメ文字について
          https://ja.wikipedia.org/wiki/Shift_JIS#2%E3%83%90%E3%82%A4%E3% [wikipedia.org]

          • by Anonymous Coward on 2020年07月17日 22時58分 (#3854249)

            PHP 7.1 でようやく解決されました。 https://www.php.net/manual/ja/migration71.windows-support.php [php.net]

            > 長いpath と UTF-8のpath のサポート
            > Webアプリケーションが UTF-8 に対応しているなら、追加の作業は必要ありません。 UTF-8 でないpathへの I/O に依存したアプリケーションについては、 明示的に INIディレクティブを設定する必要があります。 エンコーディングのINI設定のチェックは、コアの順番に依存します:
            >
            > internal_encoding
            > default_charset
            > zend.multibyte

            PHP 7.0 までは、ダメ文字問題が存在します。

          • by Anonymous Coward

            本題とは関係ないとこで
            UTF-8→UTF-16

            FAT環境のドライブ対象だとまだこの問題残ってたりするんかいな?

          • by Anonymous Coward

            (NTFSの)ファイルシステムは、リリース当初から今にいたるまでずっと UTF-16ですよ。
            UTF-8にはなってません。
            FAT系はSJISで、exFatからUnicodeもサポートされましたが、こちらもUTF-16です。

            • by Anonymous Coward

              FAT16でも長いファイル名はUTF-16(当時はUCS-2だったかも)をサポートしていたが?
              Win9xではアクセスAPIの都合で結局SJISしか使えなかったけど、WinNTはちゃんとUnicodeのファイル名をFATでも使えた。

  • WindowsネイティブじゃなくWSL2上で動かせということになるのかな?

    ここに返信
    • by Anonymous Coward on 2020年07月17日 9時18分 (#3853641)

      です。

      今後はネガティブ上で動かすことになります

      • by Anonymous Coward on 2020年07月17日 10時07分 (#3853681)

        ポジティブに動かしたいです。

        • by Anonymous Coward

          ポジとかネガとか、太田貴子にでも頼め。

      • by Anonymous Coward

        WSL2ってなんぞや?と思ってぐぐった。

        これって(WSL1が?)今すでに使ってる人いるのかな。
        自分が遅れてるだけ?それとも2になってすごくなったの?

        • by Anonymous Coward

          平気平気、またすぐ3が出てゴソっと変わるから。

        • by Anonymous Coward

          WSL1はイマイチで使えなかったけどWSL2は仮想マシンで動かすのと同じぐらい素のLinuxが動くようになったからこれからはバリバリ使えるぞ!という感じでは。
          いうても今現在Docker使ってても仮想マシンのオーバヘッドはほとんど気になってないし、
          VSCodeのおかげで何不自由なく開発ができてるけど、WSL2にしたらどんないいことがあるのだろう。

          • by Anonymous Coward

            wsl2だとハイパーV上でlinux動かしてるから仮想マシンで動かすのと同じくらいではなく仮想マシンで動かしてる。

        • by Anonymous Coward

          WSL1はLinux側から見たらLinuxカーネルっぽい振る舞いをするものでしたが、
          WSL2は、未だパッチが必要 [github.com]とはいえ、フル機能のLinuxカーネルが動作するようになっていますので、互換性が大きく改善されています。

        • by Anonymous Coward

          2004からの機能だから、遅れてるってことはないだろ

      • by Anonymous Coward

        マジかーやだなー 移行できる自信ないよ
        WSL2面倒くさいしなー 実績も無いし顧客に説明できないよ・・・
        そもそもWindows Serverに載るのいつなのさ

        # [ガ]がtypoかフリか迷ったのでAC

  • by Anonymous Coward on 2020年07月17日 9時07分 (#3853636)

    WindowsServerはASP.NET Coreで代替してねとか言わないよね?
    そういえばAMDのRaidXpert2でApache+PHP(XAMP)で管理画面作られてましたが
    バグる印象しかありませんねWindowsで運用とか考えたくもないです

    ここに返信
    • by Anonymous Coward

      そもそもLinuxでも本番稼働はしないよ。。。

      • by Anonymous Coward

        8は飛ばして9になるまで使わないんですか?

    • by Anonymous Coward

      そういうことなんじゃないですかね。
      もうPHP切っても支障がないという判断なんでしょう。
      今時はどのスクリプト言語も金太郎飴だし、時代はサーバレスですよ。
      考えたくない人は来なくて結構、ということなんだと思いますよ。

      • by Anonymous Coward

        > 今時はどのスクリプト言語も金太郎飴だし
        PHPでもPythonでもTypeScriptでも使えるtype hintingすら使えないクソ言語があるんですよ
        Rubyっていうんですけど

        • by Anonymous Coward

          でそれの何が突然暴れだすほどの問題なのさ?

          TypeProfilerあるけど(まだない)

      • by Anonymous Coward

        むしろ逆でしょう。
        「どれも同じ」ではないからこそ「(一番存在価値が無い)phpのサポートはやめてもいいだろう」となったのでしょう。

  • by Anonymous Coward on 2020年07月17日 10時44分 (#3853713)

    IISって基本的にスレッドモデルだから、IISで動かすとするとCGIになるんだよね。いまどきCGI?
    またはWindows版Apacheで動かすの?

    PythonやRubyも同様だけど、UNIX系のマルチスレッド非対応のスクリプト言語をWindowsで動かすにはプロセスベースのアプリサーバが必要だと思うんだけど、
    Windows用のプロセスベースのアプリサーバってほとんど聞かない。
    それを考えると、これらの言語はほとんど使われてないんではないかと思ってるんだけど。

    ちなみにWindowsのサーバ用言語はVBScriptの時代から現在のC#に至るまですべてマルチスレッド対応で、スレッドモデルで動くのが当たり前。

    ここに返信
    • by Anonymous Coward on 2020年07月17日 12時16分 (#3853773)

      > IISって基本的にスレッドモデルだから、IISで動かすとするとCGIになるんだよね。いまどきCGI?
      違います。
      PHPのサポート真面目にやるべ、ってなったとき(2007年)にFastCGIの仕組みをIISに用意したんでFCGIです。

      • by Anonymous Coward

        当時の記事を見付けた。

        MS、Windowsサーバ上でのPHP環境サポートでZendと提携 - ITmedia エンタープライズ [itmedia.co.jp] 2006年11月01日 06時59分 公開

        両社が共同で行う技術改良は、オープンソースであるPHPライセンスの下でPHPコミュニティーに公開されることになる。Microsoftはこの提携の一環として、MicrosoftのWebサーバ「Internet Information Services」(IIS)とPHPをつなぐインタフェース「FastCGI」を開発し、無料で公開する。一方のZendは、Windowsサーバ上でのPHP環境のテストを定期的に行い、パフォーマンスの維持・向上に努める。

    • by Anonymous Coward on 2020年07月17日 15時33分 (#3853928)

      いまどきCGI?

      今は、CGIを馬鹿にする方が一周回って時代遅れになってるんですよ。

      理由としては、
      ・サーバのスペック向上しているのでCGIを使うことによるオーバーヘッドなんてどうでもよくなってる
      ・CGIの方がOSレベルでサンドボックス化できて脆弱性の影響を受けにくい
      ・そもそもDDoS/DoS対策も兼ねてCDN・リバースプロキシの導入が当たり前になっているので、静的コンテンツで生じるCGIの負荷なんてキャッシュ時のみ
      ・動的コンテンツでもボルトネックはデータベース関係の負荷なので、CGIによる負荷なんてどうでもいい
      など。

      つまりは、CGI使ってもいいし、使わなくてもいい。
      今時そんなことは全体の負荷からすると誤差なのでどうでもいいので、「いまどきCGI?」と否定する理由が無くなったということです。

      • by Anonymous Coward

        FaaSとかCaaSってほぼCGIだしね。I/Fが独自なだけで。

        • by Anonymous Coward

          コモンゲートウェイインターフェースだからそのインターフェースが一番重要なのだが…。
          逆にインターフェースさえ満たしていればプロセス起動によって実装される必要もないはずだが

    • by Anonymous Coward

      一昔前は、本番環境や共有の開発環境はLinuxだけど、各開発者のローカルの開発環境はWindowsなのでWindows版PHP、ってことはちょくちょくあったと思う(俺もやってた)。
      もっとも、環境依存のトラブルも多かったから、仮想マシンが普及してからはみんなローカルでもVMのLinuxで動かしていると思うけど。

      • by Anonymous Coward

        未だに開発はwindowsですわ。
        だって楽なんだもの。

      • by Anonymous Coward

        Windows上での開発はちょっと選択肢が増えすぎて悩むくらいですね。
        WindowsネイティブのPHPもまあ大体動くし、PHP組み込みサーバーで簡単なアプリ動かすとかはやっぱありうる。

    • by Anonymous Coward

      IISのPHPは古典的なCGIじゃなくFastCGIだし
      イマドキLinuxのApacheでもPHPはfpmを呼ぶ構成にするっしょ(当然MPMはeventモデルで)

    • by Anonymous Coward

      Composerを動かすのにいるんじゃなかったっけ。

      それと、とあるPHPスクリプトを動かすのに使ってる。

    • by Anonymous Coward

      PHP には TS (Thread safe) 版と NTS (Non thread safe) 版の 2 モデルあり、

      IIS の ISAPI やら Apache の module やら、モジュールとして利用されるのは、マルチスレッドで稼働できる TS 版のほう。

      CGI や FastCGI は、シングルスレッドで実装できるので NTS 版が利用できる。

      因みに「カレントディレクトリ」は、プロセスの属性なのに… マルチスレッド対応の TS 版で chdir はどうやって実装しているの…? という疑問があると思います。

      これは TSRM (Thread safe resource manager) という機構があり「カレントディレクトリ」をシミュレーションできる設計になっています。

      しかし gettext など、ホンモノの「カレントディレクトリ」が必要なライブラリは TS 版では期待通りに動作しない問題があります。

      そういったケースでは FastCGI + NTS 版 PHP が適当な選択肢になるのでしょうか。

  • by Anonymous Coward on 2020年07月17日 20時20分 (#3854136)

    お逝きなさい

    ここに返信
    • by Anonymous Coward

      標準ライブラリですら「そんな仕様なら存在価値ないだろ」みたいなものが当たり前にあるのがPHP
      「まさか、そんなバカなことがある訳がない」を覆すのがPHP

      さすがにPerlやRubyをPHPと同類として語るのは問題だろう

      • by Anonymous Coward

        確かにもう滅びるPerlやRubyとPHPを同類として語るのは少々違和感があるな。

    • by Anonymous Coward

      CGI+Cとか、Javaとかはええのん?

typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...