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

Re: [patch] Move base Windows support to WinXP

Expand Messages
  • 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 1 of 10 , Mar 19, 2013
      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 2 of 10 , Mar 23, 2013
        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.