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

bundling of vim.exe with gvim distribution

Expand Messages
  • esp@pyroshells.com
    hey all, I noticed that vim doesn t come bundled with gvim, ie: on win32 you are forced to use the GUI. Is this true? or is there an option which allows you to
    Message 1 of 5 , Oct 2, 2003
      hey all,

      I noticed that vim doesn't come bundled with gvim, ie: on win32 you are
      forced to use the GUI.

      Is this true? or is there an option which allows you to use the text
      version of vim via a flag or some such? And if not, how easy would it be
      to bundle the text version of vim in the future? (I don't want to be
      forced to get cygwin just to use vim)

      thanks much,

      Ed
    • David Brown
      ... gvim -v should work. You should also be able to rename the executable to vim.exe. Dave
      Message 2 of 5 , Oct 2, 2003
        On Thu, Oct 02, 2003 at 12:26:43PM -0700, esp@... wrote:

        > Is this true? or is there an option which allows you to use the text
        > version of vim via a flag or some such? And if not, how easy would it be
        > to bundle the text version of vim in the future? (I don't want to be
        > forced to get cygwin just to use vim)

        gvim -v should work.

        You should also be able to rename the executable to vim.exe.

        Dave
      • Michael Geddes
        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
        Message 3 of 5 , Oct 2, 2003
          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?).

          I tend to make my own deployment that includes a vim.exe .. I find it
          very useful. The one I choose to use is the win32 console version.

          //.ichael G.

          -----Original Message-----
          From: David Brown [mailto:vim@...]
          Sent: Friday, 3 October 2003 6:00 AM
          To: esp@...
          Cc: Vim Developer Discussion
          Subject: Re: bundling of vim.exe with gvim distribution


          On Thu, Oct 02, 2003 at 12:26:43PM -0700, esp@... wrote:

          > Is this true? or is there an option which allows you to use the text
          > version of vim via a flag or some such? And if not, how easy would it
          > be to bundle the text version of vim in the future? (I don't want to
          > be forced to get cygwin just to use vim)

          gvim -v should work.

          You should also be able to rename the executable to vim.exe.

          Dave
        • Bram Moolenaar
          ... 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
          Message 4 of 5 , Oct 3, 2003
            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.

            --
            hundred-and-one symptoms of being an internet addict:
            83. Batteries in the TV remote now last for months.

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
            \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
          • Douglas E Cook
            ... Technical term is Console mode . DOS has nothing to do with it, and good riddance! :) ... Actually, the only difference between a console and a windows
            Message 5 of 5 , Oct 3, 2003
              > 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

              Technical term is "Console mode". DOS has nothing to do with it, and
              good riddance! :)

              > 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.

              Actually, the only difference between a console and a windows mode
              program is that the console mode program automatically gets a console.
              It either attaches to the parent's console or has a console created for
              it (if the parent isn't attached to a console). A "Windows" mode app is
              born without a console. Otherwise, both systems are the same -- both can
              do the same kind of GUIs and Windowing. A Windows Mode app can create a
              console or attach itself to an existing console. Most of the time, that
              works ok, but all too often we want to have our cake and eat it, too.

              I keep on running into this -- how can you make a "dual" mode
              application? I've never tried it, but I think it is possible. Three
              possible solutions come to mind:

              1. Create a Windows mode program. At startup, decide whether you really
              want to be Windows or Console. If you want to be Windows, no problem,
              just do what you usually do. If you want to be a console app, call
              AllocConsole() (this allocates a console and attaches the process to it),
              and then continue on as a console app. The only issue is that the C
              Runtime might not be immediately conviced that you are a console app. I
              haven't tried it, but I find it easy to imagine that the C Runtime
              startup code could set itself up differently depending on whether you are
              a console app or a windows app. I don't think it would be a problem, but
              it is possible. If it is a problem, I think I know what the workaround
              would be...

              The only disadvantage to this is that you are on a different console from
              the process that spawned you. The expected behavior would be to have a
              new console pop up if you start vim from a GUI, but for vim to be in the
              original console if started from the command line.

              2. Create a console mode program. At startup, if you decide that you
              want to be a Windows app after all, just call FreeConsole() to detach
              from the console you're attached to.

              The disadvantage here is that you'll start out a console no matter what.
              If you start from the command line, this isn't a problem -- you start
              with the parent's console, then detach from it, and all is well. But if
              you are spawned by a process without a console, a new console will be
              created for you. You can detach from it immediately, but there will be a
              brief flicker of a console popping up and then disappearing.

              3. Create a Windows mode program. If you want to be on a console, call
              AttachConsole(ATTACH_PARENT_PROCESS). I think the call will fail if the
              parent doesn't have a console, in which case you just call
              AllocConsole().

              So now you're wondering why I didn't just give #3. Turns out that this
              didn't become an option until Windows XP. Windows 2000 and earlier
              cannot attach to an existing console -- processes either take the console
              they are born with or they create a new console.

              > 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.

              Strangely enough, it seems that Microsoft agrees with you. Check this
              out if you have Visual Studio. If you have 6.0, go to Program
              Files\Microsoft Visual Studio\Common\MsDev98\bin and look at MSDEV. If
              you have 7.x, go to Program Files\Microsoft Visual ...\Common7\IDE and
              look at DEVENV.

              Note that there are two versions of each -- msdev.EXE and msdev.COM,
              devenv.EXE and devenv.COM. COM-type programs are a very old style, and
              are DOS only. It turns out that these really aren't COM programs --
              they're EXE style programs that have been renamed. Windows uses the file
              extension to determine whether or not a file is executable, but looks
              inside the file to figure out how to execute it, so it runs the COM file
              properly as if it were an EXE program. And since by default the system
              looks for COM files before it looks for EXE files (legacy rule that was
              instituted while I was still in kindergarten), if you type MSDEV at the
              command prompt, it will run the COM program. But all of the shortcuts
              are to the EXE.

              The COM program is a console mode app. The EXE program is a windows mode
              app. Microsoft is using method #2 from above. All of the shortcuts go
              to the EXE version so that you don't get the console popping up if you
              start MSDEV from a GUI. But if you double-click on MSDEV.COM, you'll see
              a brief flicker of a console appearing and disappearing, then MSDEV.EXE
              will start up.

              All MSDEV.COM is doing is starting up MSDEV.EXE. The purpose is so that
              the main program, MSDEV.EXE doesn't have the flickering console popup,
              yet MSDEV can still be used as a command line utility. MSDEV.COM simply
              starts MSDEV.EXE, passing it the exact same command line parameters as it
              got. Even though MSDEV.EXE can't have MSDEV.COM's console, it DOES
              inherit MSDEV.COM's StdIn, StdOut, and StdErr handles. So it can't do
              ncurses-style stuff, but it CAN send text to the console, which is all it
              needs to be able to do.

              MSDEV.COM does have one job to do: it has to decide whether or not to
              wait for MSDEV.EXE to exit. If the user just typed MSDEV with no
              parameters or with the name of a source file, he/she probably just wants
              to start the IDE, so MSDEV.COM starts the IDE, then exits while the IDE
              continues running. But if the user types MSDEV MyProject.dsp /MAKE
              Debug, they want MSDEV to build MyProject. So MSDEV.COM starts the IDE,
              then waits for it to exit before exiting itself. This way, you can run
              MSDEV /MAKE from a batch file, and the batch file won't continue until
              the make has completed.

              ________________________________________________________________
              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!
            Your message has been successfully submitted and would be delivered to recipients shortly.