Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
PHP Microsoft Windows

Microsoft Announces It Won't Be the Ones Building PHP 8.0 for Windows (bleepingcomputer.com) 67

Posted by EditorDavid from the curtailing-contributions dept.
Today I learned that Microsoft "has been providing support for the development and building of the PHP programming language on Windows," according to Bleeping Computer. "This support includes developing security patches for PHP and creating native Windows builds."

But that's going to change: Microsoft has announced that it will not offer support in 'any capacity' for PHP for Windows 8.0 when it is released... To add some clarity to Microsoft PHP Windows Lead Dale Hirt's post, PHP Release Manager Sara Golemon posted to Reddit explaining that this does not mean PHP 8.0 will not be supported in Windows. It just means that Microsoft will not be the one building and supporting it. "For some possibly missing context, Microsoft runs https://windows.php.net and produces all the official builds of PHP for Windows... This message means Microsoft aren't going to produce official builds for PHP 8 onwards. This message does NOT mean that nobody will."

Microsoft has not stated why they will no longer support PHP 8.0, but it could be due to the extensive PHP support already existing in the Windows Subsystem for Linux (WSL). Microsoft has been actively developing WSL, which allows users to install various Linux distributions that run directly in Windows 10.

As these distributions already support PHP 7.4 and will support PHP 8.0 when released, Microsoft may see it as unnecessary to continue supporting a native PHP build in Windows.
This discussion has been archived. No new comments can be posted.

Microsoft Announces It Won't Be the Ones Building PHP 8.0 for Windows More

Microsoft Announces It Won't Be the Ones Building PHP 8.0 for Windows

Comments Filter:

  • I don't think Microsoft realizes the ramifications to pushing developers away from Windows.

    For what ever braindead reason I've never been able to understand, to get PHP syntax highlighting in VSCode, it requires a local installation of PHP.

    Now Microsoft wont help get latest PHP on Windows.

    So VSCode on Windows doing PHP work is going to be more difficult.

    Thanks M$!

    • Re: (Score:2)

      by sfcat ( 872532 )

      I don't think Microsoft realizes the ramifications to pushing developers away from Windows.

      They do and they don't care. Supporting Windows and the various programming languages for it is expensive. And Windows doesn't make the $$ it used to. PC and Laptop shipments are a fraction of what they were 10 years ago. They are sun-setting Windows and moving entirely to a hosted SAAS cloud model and leaving the desktop market. Obviously this isn't a switch you can just throw. So instead they make it increasingly more difficult and expensive to stay on Windows while moving most customers to cloud an

      • I don't think Microsoft realizes the ramifications to pushing developers away from Windows.

        They do and they don't care. Supporting Windows and the various programming languages for it is expensive. And Windows doesn't make the $$ it used to. PC and Laptop shipments are a fraction of what they were 10 years ago. They are sun-setting Windows and moving entirely to a hosted SAAS cloud model and leaving the desktop market. Obviously this isn't a switch you can just throw. So instead they make it increasingly more difficult and expensive to stay on Windows while moving most customers to cloud and SAAS offering which are cheaper to support and provide a much more predictable revenue stream for Wall Street. In a few years, Windows will become a flavor of Linux with an .exe compatibility layer. Don't believe me? My sources are in multiple departments in Microsoft. War's over, they lost, they know it now.

        I can see this happening, especially as they make most of their revenue from cloud-based computing, are moving to a Microsoft version of LINUX for IoT, and need a universal cloud client. However, I would argue that it's closer to 5 years out. They are going to need a few years just to get the bugs worked out on their IoT OS. Yes, both can happen in parallel, but there is still a question of making sure that Windows games still run properly (i.e.a compatibility layer) and as the WINE project found it, it'

      • Comment removed based on user account deletion

        • The OS doesn't matter. If you run office and one drive and Xbox games on Android that's fine. Or Linux or...

          They are making their money from your subscription. They want to be hardware and platform agnostic. Their dream is they make their software run in the cloud and you just stream it to a thin client.

          Microsoft actually tried this once. "Mira" but the idea was everybody ran a windows server in their basement. Now the dream is approaching of cloud based apps.

    • In order to do reliable syntax highlighting, the system must first parse the code. That is, it needs to figure out whether a particular line is a method call or if it's something else. For instance, it must answer "is $my_thing" an object of a class, or is it a scalar variable? That matters when the line says $my_thing->foo $bob;

      For some languages, running some code constructs can change the context in a way that alters the meaning of the code that follows. (For example, declaring classes or types). Wh

      • Let me state that another way.

        Suppose line #5 can change the parse of line #6.

        In order to parse line 6, we must first determine how line #5 effects the parse.

        In order to determine the effects of line 5, we must at least determine whether line 5 is an infinite loop that runs forever.

        If we can determine whether line ever finishes, we've solved the Halting Problem.

        The halting problem is unsolvable, therefore we cannot statically parse line 6 if it's meaning can be influenced by the preceding line.

        • Btw I said "you can't solve the halting problem", perhaps we should prove that. The halting problem is:

          Write a function that accepts any source code as input and determines whether that code will ever terminate.

          It is trivial to prove that cannot be done.
          Suppose we DO have a function called "will_halt()". We can then write this program:

          ###
          string source = read_my_source__file;

          while ( will_halt(source) == true) {
          1;
          }
          ###

          We can easily see that no correct implementation of will_halt() can e

      • Re: (Score:2)

        by darkain ( 749283 )

        For reference, Sublime Text, and various CLI editors don't require the actual language to be installed to do simple syntax highlighting. The ONLY place I've ever seen this is specifically in how VSCode is extremely limited on how it can do syntax highlighting, which is now the "preferred" code editor on Windows platform.

        • Yeah I've used tools that do "simple syntax highlighting" on non-trivial languages. The syntax highlighting is occasionally wrong. That's okay, I guess.

          In my case, generally I develop language X on a machine where I can debug language X. Which means language X is installed anyway. Since it needs to be there for debugging, there is an advantage to going ahead and using the real parser.

          Other languages, such as xslt, are designed specifically to be easy to parse. Xslt is of course XML, which means you onl

          • Other languages, such as xslt, are designed specifically to be easy to parse. Xslt is of course XML, which means you only need a generic XML parser plus some CSS to choose the colors etc to use.

            To me that kind of feels like cheating by dropping the level on which you highlight. I guess the equivalent would be if you were to merely color differently the individual characters in a language with a "traditional" syntax regardless of their context. If you highlight syntax in this way in XSLT, do you actually get highlighting of the XSLT constructs built out of XML elements, or merely the XML elements themselves? Or did I misunderstand what you were suggesting there?

            • > Or did I misunderstand what you were suggesting there?

              Indeed I was not clear. Even an XML syntax highlighter could handle the xml part. That's not the part I'm talking abkut, though that does get you halfway there, which is great.

              After parsing the XML with the xslt DTD, you should have a well-defined structure of xslt. The DTD essentially defines the syntax of xslt.

              I would imagine one could declare some CSS3 that would handle quite a bit of the xslt syntax highlighting.

      • Re: (Score:2)

        by timotten ( 5411 )

        Hm, yes and no, but mostly no.

        Here's one grain of truth for this line-of-thought - e.g. in the past, the Facebook/HHVM/Hack folks talked about how PHP 5.x was difficult to parse because it didn't have a good *spec*, and so there would be some wonky/ill-considered edge-cases in the spec (such as it was). If you don't have a good spec, then the only way to address ambiguities is to poke and prod at the canonical implementation.

        It is also true that the `php` runtime gives some parsing functionality like `token

        • Lisp is very much a dynamic language, and is easy to parse. In fact Lisp the first major language(s) to have about half the features that define what a dynamic language is. The issue is not really dynamic languages vs static.

          A language is unparseable without executing it for any language where the parse of a particular line depends on the lines before it.

          See here for my simple proof of that:
          https://slashdot.org/comments.... [slashdot.org]

          So the question is, can we (always) parse a line of PHP without context, without kn

          • Re: (Score:2)

            by narcc ( 412956 )

            Let me point out, for the benefit of others, that the problem you're arguing is unsolvable is "reliable" syntax highlighting for PHP without executing the code.

            I will also remind everyone that there exist many IDEs that reliably apply syntax highlighting to PHP code without executing it. That puts your proof in a bad place, but I'll see if I can find where you've gone wrong. Let's look at two of your points:

            In order to do reliable syntax highlighting, the system must first parse the code. That is, it needs to figure out whether a particular line is a method call or if it's something else.

            In order to determine the effects of line 5, we must at least determine whether line 5 is an infinite loop that runs forever.

            To the first point, it is not necessary that the code be parsed the same way to reliably highlight

            • > in PHP, the type is attached to the value, not the variable

              I like how you phrased that. Well put.
              That's more easily understood than the more technically correct statement that a container has a type and a value, wrapped in a union.

              > You don't need to know, for example, if a symbol represents a scalar or an array

              As in my example, you DO need to know whether $foo is (currently) a string or an object in order to know if $foo->whatever is even valid syntax at all. If you're trying to understand the

              • Re: (Score:2)

                by narcc ( 412956 )

                If you're trying to understand the syntax in order to do good syntax highlighting, it's useful to be able to distinguish whether it's valid syntax.

                But it shouldn't matter. Lets say that a program will be valid or invalid depending on the type of some variable which can't be known until runtime. Does that in any way affect highlighting? Probably not. a fragment like `$a["hello"]` or `$b->$c` can be colored appropriately even if they can be shown, though static analysis that $a and $b are booleans and that this is a completely invalid program!

                That was my last point, that there doesn't seem to be a case where it's necessary to execute, even in pa

                • > a fragment like `$a["hello"]` or `$b->$c` can be colored appropriately even if they can be shown, though static analysis that $a and $b are booleans and that this is a completely invalid program!

                  I suppose that's a matter of opinion of its "appropriate" for syntax highlighting to highlight it as valid syntax when it is in fact invalid. Whatever one's opinion on that, it does establish some limits on what syntax highlighting can do:
                  Syntax highlighting cannot distinguish valid from invalid syntax.
                  Synt

                  • Btw an interpreter can even handle this:

                    if ( rand() == 0.5 ) {
                          ____use-php4-compat-mode___
                    }

                    So it ia very much NOT the case that any code which can be executed can also be statically parsed for syntax. Get that idea out of your head because it'll lead you down wrong paths.

                  • Just to clarify and avoid getting side tracked, I think we can agree on this. Consider this peudo-code:

                    1. if ( some_function() == 1 ) {
                    2. skip_odd_bytes_in_code();
                    3. }
                    4. e_c_h_o_(_b_o'b_'_)_ ;

                    Consider *if* there were in fact code in line #2 which caused every odd byte in the rest of the code to be ignored, that would effect syntax highlighting. See the extra quote mark between "o" and "b"? It very much matters whether that's there, right?

                    We can't know the result of line 1 without executing it, so we

                    • Re: (Score:2)

                      by narcc ( 412956 )

                      I suppose that's a matter of opinion of its "appropriate" for syntax highlighting to highlight it as valid syntax when it is in fact invalid.

                      I'd argue that, in my example, the syntax is valid, but the program isn't. It's possible to have a syntactically valid program that is itself invalid.

                      So the defining question is

                      That seems fair.

                      Though I think your encoding idea is a massive stretch. At that point, we're not really talking about the language.

                      What I'm expecting is something that would change the syntax of the language in such a way as to make syntax highlighting ambiguous. If we accept changing the encoding, well, we're out of luck in any language. (Also, there's st

          • Lisp is very much a dynamic language, and is easy to parse.

            Common Lisp already ruins that by means of reader macros, so perhaps not quite that easy since you have to find out where the textual representation of an object ends, which you can't without running the reader macro. Now of course everybody uses SLIME/SLY these days, so that's not much of an issue in practice.

    • Probably because the syntax highlighter depends on the PHP token_get_all function to tokenize the PHP. This is smart because it will keep up with language changes, and PHP is still actively changing their syntax. The downside - of course - is you need PHP installed. But the upside is you're always current. You don't have to track down the PHP 7.4 plugin that knows how the null coalesce operator works, or whatever.

    • Just use the vscode wsl extension to connect to a wsl instance on your machine (or the remote-ah extension to connect to a different/virtual machine). Then you can just enable the php extension in that wsl instance and youâ(TM)ll be using the Linux php instance to do all the syntax hilighting while running the editor in your windows desktop. Best of both worlds.

  • PHP in Docker under WSL on ECS (Score:3, Interesting)

    by moxrespawn ( 6714000 ) on Sunday July 12, 2020 @01:43PM (#60290390)

    It's like a horse-drawn carriage glued to an jet engine assisted by oil liberally spilled on the road.

    Yes, I speak from experience.

    Let PHP die.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Indeed. There are bad languages, and then there is PHP. It is basically an accident waiting to happen, worst of the worst that is in actual use.

      • Re: (Score:2)

        by narcc ( 412956 )

        It's powered most of the web for 20 years. It can't be all bad.

        It can't all be inertia. It didn't start off on top. It got there by being better than the alternatives.

        • Re: (Score:2)

          by gweihir ( 88907 )

          It's powered most of the web for 20 years. It can't be all bad.

          Wide adoption has never been and will never be a sign of quality. Quite obviously.

          • Re: (Score:2)

            by narcc ( 412956 )

            Sorry, but reality disagrees with your belief that the language is an "accident waiting to happen". It's been 20 years and the web is still standing.

            I get it, it's free karma to say that you "think" that the language is terrible. It's a bit ridiculous though. Like the people who fall all over themselves to let you know that they're atheists in any thread about religion. Free karma, I guess, but it's ultimately just empty noise that distracts from the real discussion.

            The truth is that it's pretty average

  • It’s all WSL now (Score:3)

    by xack ( 5304745 ) on Sunday July 12, 2020 @01:46PM (#60290400)
    Windows is just a Linux hypervisor now. You get proprietary office and games while running the real work on WSL.
  • There's gonna be a version 8.0? Let it die already

  • It won't be missed. (Score:3)

    by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Sunday July 12, 2020 @02:08PM (#60290456)

    Disclaimer: PHP developer here.

    Most people develop on Linux anyway. Even on Windows it's either a VM or Docker or something running Linux, since XAMPP is a little flaky these days. You have to jump through so many hoops to get a proper PHP setup going on Windows 10 that will have its service borked on the next update anyway that it's best to move to Linux altogether. Which is what most people do these days.

    Truth be told, even MS themselves have more PHP running on Linux than on Windows - in Azure.

    I don't see this as a big loss really.

    • I have to assume the largest use case for win32 PHP by far are developers running Windows on their development boxes. A lot will depend on the quality of the builds post-Microsoft. If they suck, then itâ(TM)ll convince more PHP developers to run Linux or macOS on their development machines. If the community continues to release high-quality win32 builds, then canâ(TM)t see how there will really be any impact from this at all. Iâ(TM)d be curious to see what percentage of production PHP server

    • Re: (Score:2)

      by drolli ( 522659 )

      Exactly this: MS themself run linux +PHP in azure.

  • For what it's worth (Score:3)

    by nospam007 ( 722110 ) * on Sunday July 12, 2020 @02:39PM (#60290548)

    I announce that I won't do it either.

  • Microfocus, BMC Software, Attlasian, or even an enterprising company or opensource community...

    So, if y'all feel that there is a market for native PHP8 on Win10, here is a fantastic opportunnity for y'all to shine

    TL;DR: no biggie

  • To be honest it does cost Microsoft money to have staff do this. I didn't know they were doing this and I'm glad they are putting so much effort towards open source. I'm not trying to offend PHP programmers out there but I think Microsoft's investment in open source can be more wisely spent than building PHP.

    Microsoft could support more stuff on Mono, as just one example. I would be happy to see them do official builds of GCC and binutils.

    • Microsoft could support more stuff on Mono, as just one example.

      Microsoft is already planning to merge Mono into the official .NET runtime.

Slashdot Top Deals

Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!

Close