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

Re[2]: bundling of vim.exe with gvim distribution

Expand Messages
  • Giuseppe Bilotta
    ... As a general rule I agree that the wrapper doesn t make sense. OTOH, I do think that a package should be provided that includes all three versions (GUI,
    Message 1 of 3 , Oct 3, 2003
    • 0 Attachment
      On Friday, October 3, 2003 Bram Moolenaar wrote:

      > Michael Geddes wrote:

      >> Er no. Renaming doesn't work with win32, sorry David.
      >>
      >> This question has been asked before, and the answer was something along
      >> the lines that there a bunch of potentially different versions of
      >> vim.exe that could sensibly be deployed, and that Bram was unable to
      >> choose any one of them (yes?).

      > On Unix a program always starts with just
      > stdin/stdout/stderr and has to
      > open a connection to the X server to start using windows. On MS-Windows
      > a program is either a "DOS" program or a "Windows" program. I don't
      > think it is possible, or at least it is not easy, to have a program that
      > starts in a DOS console and starts opening windows after that. Thus you
      > can't make Vim run in a console or open windows by adding a command line
      > option.

      > It would be possible to make a wrapper that starts vim.exe or gvim.exe
      > depending on an argument, but you still need the two executables, thus
      > it doesn't make much sense.

      As a general rule I agree that the wrapper doesn't make sense.
      OTOH, I do think that a package should be provided that
      includes all three versions (GUI, Vim-32, Vim-16); executables
      could be called gvim.exe, vim32.exe, vim16.exe (You could then
      make a wrapper vim.exe that chooses the appropriate version).

      Also, technicall speaking under DOS/Windows you can put more
      than one version in the same .exe; *most* of the time, the DOS
      part is just a stub that says "Hey man, you need Windows to run
      this program!", but nobody prevents you from using a
      "different" stub, like for example the 16-bit console version.
      So you could create a single vim.exe containing both the 16-bit
      and the 32-bit console version.

      --
      Giuseppe "Oblomov" Bilotta
    • Douglas E Cook
      ... If your system can run vim32 , why do you want vim16 ? ... This is very easy. Assume that you ve already built the DOS version of vim.exe, and renamed
      Message 2 of 3 , Oct 3, 2003
      • 0 Attachment
        > As a general rule I agree that the wrapper doesn't make sense.
        > OTOH, I do think that a package should be provided that
        > includes all three versions (GUI, Vim-32, Vim-16); executables
        > could be called gvim.exe, vim32.exe, vim16.exe (You could then
        > make a wrapper vim.exe that chooses the appropriate version).

        If your system can run "vim32", why do you want "vim16"?

        > Also, technicall speaking under DOS/Windows you can put more
        > than one version in the same .exe; *most* of the time, the DOS
        > part is just a stub that says "Hey man, you need Windows to run
        > this program!", but nobody prevents you from using a
        > "different" stub, like for example the 16-bit console version.
        > So you could create a single vim.exe containing both the 16-bit
        > and the 32-bit console version.

        This is very easy. Assume that you've already built the DOS version of
        vim.exe, and renamed it "vim16.exe", and put it in your object file
        directory. When you are linking "vim.exe" (the 32-bit Windows console
        version), add "/STUB:vim16.exe" to the LINK command line and the linker
        will do the rest. The only downside is that (obviously) the file would
        be somewhat larger...

        ________________________________________________________________
        The best thing to hit the internet in years - Juno SpeedBand!
        Surf the web up to FIVE TIMES FASTER!
        Only $14.95/ month - visit www.juno.com to sign up today!
      • Giuseppe Bilotta
        ... Because I might start in pure DOS mode and vim32 wouldn t work. ... Precisely. I also think that someone who wants to have all versions in a package won t
        Message 3 of 3 , Oct 4, 2003
        • 0 Attachment
          On Friday, October 3, 2003 Douglas E Cook wrote:
          >> As a general rule I agree that the wrapper doesn't make sense.
          >> OTOH, I do think that a package should be provided that
          >> includes all three versions (GUI, Vim-32, Vim-16); executables
          >> could be called gvim.exe, vim32.exe, vim16.exe (You could then
          >> make a wrapper vim.exe that chooses the appropriate version).

          > If your system can run "vim32", why do you want "vim16"?

          Because I might start in pure DOS mode and vim32 wouldn't work.

          >> Also, technicall speaking under DOS/Windows you can put more
          >> than one version in the same .exe; *most* of the time, the DOS
          >> part is just a stub that says "Hey man, you need Windows to run
          >> this program!", but nobody prevents you from using a
          >> "different" stub, like for example the 16-bit console version.
          >> So you could create a single vim.exe containing both the 16-bit
          >> and the 32-bit console version.

          > This is very easy. Assume that you've already built the DOS version of
          > vim.exe, and renamed it "vim16.exe", and put it in your object file
          > directory. When you are linking "vim.exe" (the 32-bit Windows console
          > version), add "/STUB:vim16.exe" to the LINK command line and the linker
          > will do the rest. The only downside is that (obviously) the file would
          > be somewhat larger...

          Precisely. I also think that someone who wants to have all
          versions in a package won't complain about the binary size :)
          given that it allows to have only one vim.exe instead of two (vim16.exe and
          vim32.exe).

          --
          Giuseppe "Oblomov" Bilotta
        Your message has been successfully submitted and would be delivered to recipients shortly.