Loading ...
Sorry, an error occurred while loading the content.

Re: [patch] Move base Windows support to WinXP

Expand Messages
  • Bram Moolenaar
    ... What effect does this change really have on the generated binary? Besides no longer being able to run it on Windows NT and Windows 2K? I don t see anything
    Message 1 of 10 , Mar 18, 2013
    • 0 Attachment
      Mike Williams wrote:

      > Following discussion in another thread this patch moves the minimum
      > version of Windows supported in a default build of VIM up to Windows XP.
      > This should make it easier to use features in newer versions of Windows.
      >
      > Changes are only in the various Windows make files that mention WINVER -
      > bc5, cygwin, ming, and MVC - but I only have VS so have not tested the
      > other compilers. Can others try the patch with other compilers and
      > report any problems please.

      What effect does this change really have on the generated binary?
      Besides no longer being able to run it on Windows NT and Windows 2K?

      I don't see anything getting simpler yet. The docs I find for WINVER
      are not very specific.

      If we go this way we need to make a binary for Windows 95 available
      somewhere. I don't want to leave any user without their editor.
      This can be as simple as telling users which old version to use.


      --
      hundred-and-one symptoms of being an internet addict:
      66. You create a homepage with the impression to cure the afflicted...but
      your hidden agenda is to receive more e-mail.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ an exciting new programming language -- http://www.Zimbu.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Mike Williams
      ... The setting for WINVER filters the content of the Windows include files to remove newer APIs added in later version of Windows. That way the binary does
      Message 2 of 10 , Mar 19, 2013
      • 0 Attachment
        On 18/03/2013 20:39, Bram Moolenaar wrote:
        >
        > Mike Williams wrote:
        >
        >> Following discussion in another thread this patch moves the minimum
        >> version of Windows supported in a default build of VIM up to Windows XP.
        >> This should make it easier to use features in newer versions of Windows.
        >>
        >> Changes are only in the various Windows make files that mention WINVER -
        >> bc5, cygwin, ming, and MVC - but I only have VS so have not tested the
        >> other compilers. Can others try the patch with other compilers and
        >> report any problems please.
        >
        > What effect does this change really have on the generated binary?
        > Besides no longer being able to run it on Windows NT and Windows 2K?

        The setting for WINVER filters the content of the Windows include files
        to remove newer APIs added in later version of Windows. That way the
        binary does not accidentally try to use a non-existant API. In the case
        of cleartype support, since this did not exist in Win2k and using a
        WINVER value of 0x0400 for Win2k meant the cleartype functionality did
        not get compiled in. Leaving WINVER at 0x0400 will mean a lot of new
        Windows functionality cannot be used that easily.

        Note WINVER is meant to control what Windows APIs are available at build
        time, not a means of deciding what platform you are currently running on
        - the code in modify_fname() in eval.c based on _WIN32_WINNT (set to the
        same as WINVER) is most likely the wrong solution. I wouldn't be
        surprised if the #undef of WIN32_WINNT in if_ruby.c is also related fallout.

        > I don't see anything getting simpler yet. The docs I find for WINVER
        > are not very specific.
        >
        > If we go this way we need to make a binary for Windows 95 available
        > somewhere. I don't want to leave any user without their editor.
        > This can be as simple as telling users which old version to use.

        If we want to continue building for Win95/98/SE then that should be a
        build option that sets WINVER appropriately.

        The alternative would be hard code copies of Windows APIs into VIM and
        work out at runtime what VIM can actually use by querying which platform
        it is currently running on.

        Mike
        --
        Red meat isn't bad for you. Fuzzy green meat is.

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Bram Moolenaar
        ... I should build and release a 7.4 binary soon, we are running out of patch numbers :-). So how about this: 7.4.000 will be released with MS-Windows binaries
        Message 3 of 10 , Mar 19, 2013
        • 0 Attachment
          Mike Williams wrote:

          > >> Following discussion in another thread this patch moves the minimum
          > >> version of Windows supported in a default build of VIM up to Windows XP.
          > >> This should make it easier to use features in newer versions of Windows.
          > >>
          > >> Changes are only in the various Windows make files that mention WINVER -
          > >> bc5, cygwin, ming, and MVC - but I only have VS so have not tested the
          > >> other compilers. Can others try the patch with other compilers and
          > >> report any problems please.
          > >
          > > What effect does this change really have on the generated binary?
          > > Besides no longer being able to run it on Windows NT and Windows 2K?
          >
          > The setting for WINVER filters the content of the Windows include files
          > to remove newer APIs added in later version of Windows. That way the
          > binary does not accidentally try to use a non-existant API. In the case
          > of cleartype support, since this did not exist in Win2k and using a
          > WINVER value of 0x0400 for Win2k meant the cleartype functionality did
          > not get compiled in. Leaving WINVER at 0x0400 will mean a lot of new
          > Windows functionality cannot be used that easily.
          >
          > Note WINVER is meant to control what Windows APIs are available at build
          > time, not a means of deciding what platform you are currently running on
          > - the code in modify_fname() in eval.c based on _WIN32_WINNT (set to the
          > same as WINVER) is most likely the wrong solution. I wouldn't be
          > surprised if the #undef of WIN32_WINNT in if_ruby.c is also related fallout.
          >
          > > I don't see anything getting simpler yet. The docs I find for WINVER
          > > are not very specific.
          > >
          > > If we go this way we need to make a binary for Windows 95 available
          > > somewhere. I don't want to leave any user without their editor.
          > > This can be as simple as telling users which old version to use.
          >
          > If we want to continue building for Win95/98/SE then that should be a
          > build option that sets WINVER appropriately.
          >
          > The alternative would be hard code copies of Windows APIs into VIM and
          > work out at runtime what VIM can actually use by querying which platform
          > it is currently running on.

          I should build and release a 7.4 binary soon, we are running out of
          patch numbers :-).

          So how about this: 7.4.000 will be released with MS-Windows binaries
          that still support the old systems. Once it's out and it looks OK we
          drop support for older systems. That way 7.4 is what needs to be used
          for old systems. It includes a lot of bug fixes since the last binary
          release. And then 7.4.001 and further can add stuff that is not
          possible when building for the older systems.

          --
          "Thou shalt not follow the Null Pointer, for at its end Chaos and
          Madness lie."

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ an exciting new programming language -- http://www.Zimbu.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Roland Eggner
          ... Prior to dropping support for w2k please consider: (1) w2k is known to be the least faulty OS version released by its vendor so far, because the phrase
          Message 4 of 10 , Mar 19, 2013
          • 0 Attachment
            On 2013-03-19 Tuesday at 12:42 +0100 Bram Moolenaar wrote:
            > Mike Williams wrote:
            > > >> Following discussion in another thread this patch moves the minimum
            > > >> version of Windows supported in a default build of VIM up to Windows XP.
            > > >> This should make it easier to use features in newer versions of Windows.
            > > >>
            > > >> Changes are only in the various Windows make files that mention WINVER -
            > > >> bc5, cygwin, ming, and MVC - but I only have VS so have not tested the
            > > >> other compilers. Can others try the patch with other compilers and
            > > >> report any problems please.
            > > >
            > > > What effect does this change really have on the generated binary?
            > > > Besides no longer being able to run it on Windows NT and Windows 2K?
            > >
            > > The setting for WINVER filters the content of the Windows include files
            > > to remove newer APIs added in later version of Windows. That way the
            > > binary does not accidentally try to use a non-existant API. In the case
            > > of cleartype support, since this did not exist in Win2k and using a
            > > WINVER value of 0x0400 for Win2k meant the cleartype functionality did
            > > not get compiled in. Leaving WINVER at 0x0400 will mean a lot of new
            > > Windows functionality cannot be used that easily.
            > >
            > > Note WINVER is meant to control what Windows APIs are available at build
            > > time, not a means of deciding what platform you are currently running on
            > > - the code in modify_fname() in eval.c based on _WIN32_WINNT (set to the
            > > same as WINVER) is most likely the wrong solution. I wouldn't be
            > > surprised if the #undef of WIN32_WINNT in if_ruby.c is also related fallout.
            > >
            > > > I don't see anything getting simpler yet. The docs I find for WINVER
            > > > are not very specific.
            > > >
            > > > If we go this way we need to make a binary for Windows 95 available
            > > > somewhere. I don't want to leave any user without their editor.
            > > > This can be as simple as telling users which old version to use.
            > >
            > > If we want to continue building for Win95/98/SE then that should be a
            > > build option that sets WINVER appropriately.
            > >
            > > The alternative would be hard code copies of Windows APIs into VIM and
            > > work out at runtime what VIM can actually use by querying which platform
            > > it is currently running on.
            >
            > I should build and release a 7.4 binary soon, we are running out of
            > patch numbers :-).
            >
            > So how about this: 7.4.000 will be released with MS-Windows binaries
            > that still support the old systems. Once it's out and it looks OK we
            > drop support for older systems. That way 7.4 is what needs to be used
            > for old systems. It includes a lot of bug fixes since the last binary
            > release. And then 7.4.001 and further can add stuff that is not
            > possible when building for the older systems.

            Prior to dropping support for w2k please consider:

            (1) w2k is known to be the least faulty OS version released by its vendor so
            far, because the phrase “based on NT” was a lot more than just an advertising,
            the development history of this OS version differed significantly from all other
            OS versions of this vendor
            (2) when running as kvm or qemu guest, w2k yields best performance among all OS
            versions of this vendor

            For this two reasons IMHO support for w2k remains useful, even more than
            a decade after release of w2k.

            --
            Thanks
            Roland Eggner
          • John Beckett
            ... Bram (I assume) would prefer to support everything, and not drop Windows 2000 or anything else. However, the proposal is to start using certain features
            Message 5 of 10 , Mar 19, 2013
            • 0 Attachment
              Roland Eggner wrote:
              > Prior to dropping support for w2k please consider:
              >
              > (1) w2k is known to be the least faulty OS version released
              > by its vendor so far, because the phrase "based on NT" was a
              > lot more than just an advertising, the development history of
              > this OS version differed significantly from all other OS
              > versions of this vendor
              > (2) when running as kvm or qemu guest, w2k yields best
              > performance among all OS versions of this vendor
              >
              > For this two reasons IMHO support for w2k remains useful,
              > even more than a decade after release of w2k.

              Bram (I assume) would prefer to support everything, and not drop
              Windows 2000 or anything else. However, the proposal is to start
              using certain features that are only available in Windows XP and
              later. Supporting an older system would require complex compile
              options and a bunch of testing. All that makes developing Vim
              harder and more fragile.

              Why would someone who does not want to upgrade their operating
              system want to upgrade their editor? W2k is not safe to use on
              the Internet, unless in a very restricted mode, and the current
              Vim has few bugs that matter, and has plenty of features, so
              upgrades should be strictly optional.

              John

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • John Beckett
              Bram Moolenaar ... That s fine for experts, but very confusing for everyone else. It would be far better to have 7.3.999 (or whatever the final number is) be
              Message 6 of 10 , Mar 19, 2013
              • 0 Attachment
                Bram Moolenaar
                > So how about this: 7.4.000 will be released with MS-Windows
                > binaries that still support the old systems. Once it's out
                > and it looks OK we drop support for older systems. That way
                > 7.4 is what needs to be used for old systems. It includes a
                > lot of bug fixes since the last binary release. And then
                > 7.4.001 and further can add stuff that is not possible when
                > building for the older systems.

                That's fine for experts, but very confusing for everyone else.
                It would be far better to have 7.3.999 (or whatever the final
                number is) be the last version that runs on older Windows.

                The official binaries normally are not updated, but why not make
                an exception in this case and issue executables for 7.3.999 with
                a note that it is the last version that runs on Windows older
                than XP.

                People would find it a lot easier to understand that 7.4.x is
                the new system, and that 7.3.x was the last that supported old
                systems. I haven't upgraded Vim for a while, but I assume Vim
                still displays "7.3" for :version, with the included patches on
                a separate line. Standard users would not understand what is
                meant by 7.3.0 versus 7.3.1.

                John

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Gary Johnson
                ... It may not be a matter of not _wanting_ to upgrade their operating system. They may be stuck using it for one reason or another, while at the same time
                Message 7 of 10 , Mar 19, 2013
                • 0 Attachment
                  On 2013-03-20, John Beckett wrote:

                  > Why would someone who does not want to upgrade their operating
                  > system want to upgrade their editor?

                  It may not be a matter of not _wanting_ to upgrade their operating
                  system. They may be stuck using it for one reason or another, while
                  at the same time they may want to use the same version of Vim on all
                  their systems and may want to use the features of the latest
                  version.

                  I worked in a lab where we had an antique PC that IT really wanted
                  to get rid of. However, it ran a proprietary program that
                  controlled some important hardware and the program was not available
                  for newer OSs. We left it off the network.

                  Regards,
                  Gary

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Roland Eggner
                  ... Good arguments. I just want to mention, that in the huge vim community there is at least one user interested in w2k support. ... Because improvements of
                  Message 8 of 10 , Mar 19, 2013
                  • 0 Attachment
                    On 2013-03-20 Wednesday at 14:32 +1100 John Beckett wrote:
                    > Roland Eggner wrote:
                    > > Prior to dropping support for w2k please consider:
                    > >
                    > > (1) w2k is known to be the least faulty OS version released
                    > > by its vendor so far, because the phrase "based on NT" was a
                    > > lot more than just an advertising, the development history of
                    > > this OS version differed significantly from all other OS
                    > > versions of this vendor
                    > > (2) when running as kvm or qemu guest, w2k yields best
                    > > performance among all OS versions of this vendor
                    > >
                    > > For this two reasons IMHO support for w2k remains useful,
                    > > even more than a decade after release of w2k.
                    >
                    > Bram (I assume) would prefer to support everything, and not drop
                    > Windows 2000 or anything else. However, the proposal is to start
                    > using certain features that are only available in Windows XP and
                    > later. Supporting an older system would require complex compile
                    > options and a bunch of testing. All that makes developing Vim
                    > harder and more fragile.

                    Good arguments. I just want to mention, that in the huge vim community there is
                    at least one user interested in w2k support.

                    > Why would someone who does not want to upgrade their operating
                    > system want to upgrade their editor?

                    Because improvements of vim are useful for its users, whereas improvements of
                    newer windows versions are useful for the marketing of its vendor (e.g. licence
                    restrictions …). To improvements like IE8 and IE9 we have plenty of
                    alternatives.

                    > W2k is not safe to use on the Internet, unless in a very restricted mode,

                    Yes. For this reason I cannot imagine any usage other than inside virtual
                    machines without external NIC.

                    > and the current Vim has few bugs that matter, and has plenty of features, so
                    > upgrades should be strictly optional.

                    Agreed.

                    --
                    Roland Eggner
                  • Mike Williams
                    ... Windows builds of VIM are starting to fragment. You can take the default build which works on all versions of Windows. Great. You can change some
                    Message 9 of 10 , Mar 23, 2013
                    • 0 Attachment
                      On 20/03/2013 03:32, John Beckett wrote:
                      > Bram Moolenaar
                      >> So how about this: 7.4.000 will be released with MS-Windows
                      >> binaries that still support the old systems. Once it's out
                      >> and it looks OK we drop support for older systems. That way
                      >> 7.4 is what needs to be used for old systems. It includes a
                      >> lot of bug fixes since the last binary release. And then
                      >> 7.4.001 and further can add stuff that is not possible when
                      >> building for the older systems.
                      >
                      > That's fine for experts, but very confusing for everyone else.
                      > It would be far better to have 7.3.999 (or whatever the final
                      > number is) be the last version that runs on older Windows.
                      >
                      > The official binaries normally are not updated, but why not make
                      > an exception in this case and issue executables for 7.3.999 with
                      > a note that it is the last version that runs on Windows older
                      > than XP.
                      >
                      > People would find it a lot easier to understand that 7.4.x is
                      > the new system, and that 7.3.x was the last that supported old
                      > systems. I haven't upgraded Vim for a while, but I assume Vim
                      > still displays "7.3" for :version, with the included patches on
                      > a separate line. Standard users would not understand what is
                      > meant by 7.3.0 versus 7.3.1.

                      Windows builds of VIM are starting to fragment. You can take the
                      default build which works on all versions of Windows. Great. You can
                      change some compilation flags and then get more features but only work
                      on more recent versions of Windows. Working out which flags give you
                      which additional features is not always obvious, and patches have not
                      been policed as well as they could have to prevent this problem. If VIM
                      on Windows is mainly used by people who roll their own binaries this may
                      not be such a problem, but if there are a lot of Windows users who pick
                      binaries off servers then this may be a bigger issue.

                      I'm picking on WINVER at the moment since I believe it is not being used
                      correctly in the current source. It may be that the two cases I see are
                      the only problems, but it sets a precedent for others. Pinning down now
                      how such backward unsupportable changes should be coded up will help
                      future development. The simplest example is modify_fname() which
                      protects the call to GetLongPathName() which is not in Windows versions
                      prior to XP. It would be better coded up to use GetProcAddress() to
                      dynamically load and use if available.

                      My 2ps worth.

                      Mike
                      --
                      A swift kick in the butt is no way to get a dragon's attention.

                      --
                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    Your message has been successfully submitted and would be delivered to recipients shortly.