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

Dynamic link with perl and python (vim60k-w32)

Expand Messages
  • Muraoka Taro
    Hello vim-dev. On Windows, if we want to use vim with language (perl or python) interfaces, we must recompile vim source code. But for many Windows users,
    Message 1 of 19 , Nov 1, 2000
      Hello vim-dev.

      On Windows, if we want to use vim with language (perl or python) interfaces,
      we must recompile vim source code. But for many Windows users, compile is
      not easy. And we cannot use vim executable binary compiled with language
      interfaces on Windows not installed language. It is not portable.

      Appended patch I have made give some solution for that. It try to make
      "runtime" link with language DLL. If it could not link with DLL, it conduct
      as no language interface. If it could link successfully, automatically
      language interface is enabled. These all are do at "runtime". We can
      execute same binary on system both installed language and non-installed
      language. Binary once compiled with this patch is very portable.

      I made this patch from Vim60k.


      HOW TO USE
      1. Install language you want to use.
      2. Get compliled binary and put it in correct directory.
      3. Execute it.
      4. :perl VIM::Msg("Hello") or :python print "Hello"


      HOW TO COMPILE
      1. Install ActivePerl and Python1.5
      2. Get vim60k source and extract it.
      3. Apply this patch.
      4. Make with below command.

      - Compile command example
      nmake -f Make_mvc.mak GUI=yes ACTIVEPERL=c:\Perl "DYNAMICPYTHON=c:\Program F
      iles\Python"


      URL
      - Pre-compiled binary
      http://ixeris.bios.ics.saitama-u.ac.jp/~koron/software/vim/gvim_dyn.zip

      - URL of this patch
      http://ixeris.bios.ics.saitama-u.ac.jp/~koron/software/vim/dyn.diff.gz

      - ActivePerl
      http://www.activestate.com/Products/ActivePerl/index.html

      - Python (I have tested version 1.5)
      http://www.python.org/download/download_windows.html

      ----
      Muraoka Taro <koron@...>
    • Bram Moolenaar
      ... Looks like a good idea. It is indeed not easy to get Vim compiled with Perl and/or Python on Windows. I could distribute the Windows binaries with this
      Message 2 of 19 , Nov 1, 2000
        Muraoka Taro wrote:

        > On Windows, if we want to use vim with language (perl or python) interfaces,
        > we must recompile vim source code. But for many Windows users, compile is
        > not easy. And we cannot use vim executable binary compiled with language
        > interfaces on Windows not installed language. It is not portable.
        >
        > Appended patch I have made give some solution for that. It try to make
        > "runtime" link with language DLL. If it could not link with DLL, it conduct
        > as no language interface. If it could link successfully, automatically
        > language interface is enabled. These all are do at "runtime". We can
        > execute same binary on system both installed language and non-installed
        > language. Binary once compiled with this patch is very portable.

        Looks like a good idea. It is indeed not easy to get Vim compiled with Perl
        and/or Python on Windows. I could distribute the Windows binaries with this
        dynamic loading included.

        Is there a catch in trying to load the Perl and/or Python library? I suppose
        the executable will become a bit bigger, I'll have to find out by how much. I
        suppose the running program will be a bit bigger too (I know the OLE version
        is quite a bit bigger).

        A few remarks:
        - The is_enable_python() function starts with "is", which is reserved for
        system functions. Rename it to python_enabled()? Same for
        is_enable_perl().
        - The number of GetProcAddress() calls can be drastically reduced by making a
        table of function_name/function_pointer pairs.
        - I don't understand why you changed ".\ObjGC" to "ObjGD".

        --
        The process for understanding customers primarily involves sitting around with
        other marketing people and talking about what you would to if you were dumb
        enough to be a customer.
        (Scott Adams - The Dilbert principle)

        /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
        \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
      • Muraoka Taro
        ... Yes, executable become bigger about 40KB when compiled with dynamic link to both Perl and Python. Normal(GUI): 815104 bytes Dynamic(Perl and
        Message 3 of 19 , Nov 1, 2000
          Bram Moolenaar wrote:

          > Is there a catch in trying to load the Perl and/or Python library? I suppose
          > the executable will become a bit bigger, I'll have to find out by how much. I
          > suppose the running program will be a bit bigger too (I know the OLE version
          > is quite a bit bigger).

          Yes, executable become bigger about 40KB when compiled with dynamic link to
          both Perl and Python.

          Normal(GUI): 815104 bytes
          Dynamic(Perl and Python): 856064 bytes

          > - The is_enable_python() function starts with "is", which is reserved for
          > system functions. Rename it to python_enabled()? Same for
          > is_enable_perl().

          OK. I have renamed to perl_enabled() and python_enabled().

          > - The number of GetProcAddress() calls can be drastically reduced by making a
          > table of function_name/function_pointer pairs.

          I have done this.

          > - I don't understand why you changed ".\ObjGC" to "ObjGD".

          I had made this for compiling warning messages at early version of Vim 6 and
          left it as it is. I have canceled this.

          Attached patch is new version of Perl/Python dynamic link.
          ----
          Muraoka Taro <koron@...>
        • George V. Reilly
          I ll freely admit that I haven t dug into the two patches to verify this, but it seems to me that you re duplicating the delayload functionality of the
          Message 4 of 19 , Nov 1, 2000
            I'll freely admit that I haven't dug into the two patches to verify this,
            but it seems to me that you're duplicating the delayload functionality of
            the Microsoft VC6 compiler. See
            http://msdn.microsoft.com/library/periodic/period98/hood1298.htm for a
            description of how it works.

            Leveraging the compiler would make the code a lot simpler. Unfortunately, I
            don't think the other Win32 compilers that appear to be popular around here
            (Borland and Ming) have any support for this kind of thing. VC5 and earlier
            certainly don't. Portability makes your patch more desirable.
            --
            /George V. Reilly mailto:george@...
            http://george.reilly.org
            Co-author "Professional Active Server Pages 3.0"
            and "Beginning ATL 3 COM Programming", Wrox Press 1999


            ----- Original Message -----
            From: "Muraoka Taro" <koron@...>
            To: "Bram Moolenaar" <Bram@...>
            Cc: <vim-dev@...>
            Sent: Wednesday, November 01, 2000 5:53 PM
            Subject: Re: Dynamic link with perl and python (vim60k-w32)


            > Bram Moolenaar wrote:
            >
            > > Is there a catch in trying to load the Perl and/or Python library? I
            suppose
            > > the executable will become a bit bigger, I'll have to find out by how
            much. I
            > > suppose the running program will be a bit bigger too (I know the OLE
            version
            > > is quite a bit bigger).
            >
            > Yes, executable become bigger about 40KB when compiled with dynamic link
            to
            > both Perl and Python.
            >
            > Normal(GUI): 815104 bytes
            > Dynamic(Perl and Python): 856064 bytes
            >
            > > - The is_enable_python() function starts with "is", which is reserved
            for
            > > system functions. Rename it to python_enabled()? Same for
            > > is_enable_perl().
            >
            > OK. I have renamed to perl_enabled() and python_enabled().
            >
            > > - The number of GetProcAddress() calls can be drastically reduced by
            making a
            > > table of function_name/function_pointer pairs.
            >
            > I have done this.
            >
            > > - I don't understand why you changed ".\ObjGC" to "ObjGD".
            >
            > I had made this for compiling warning messages at early version of Vim 6
            and
            > left it as it is. I have canceled this.
            >
            > Attached patch is new version of Perl/Python dynamic link.
            > ----
            > Muraoka Taro <koron@...>
            >
            >
          • Bram Moolenaar
            ... The /delayload functionality certainly is very useful. It avoids all the manual GetProcAddress() calls. ... Well, I only have VC 5.0, so I won t be able
            Message 5 of 19 , Nov 2, 2000
              George Reilly wrote:

              > I'll freely admit that I haven't dug into the two patches to verify this,
              > but it seems to me that you're duplicating the delayload functionality of
              > the Microsoft VC6 compiler. See
              > http://msdn.microsoft.com/library/periodic/period98/hood1298.htm for a
              > description of how it works.

              The /delayload functionality certainly is very useful. It avoids all the
              manual GetProcAddress() calls.

              > Leveraging the compiler would make the code a lot simpler. Unfortunately, I
              > don't think the other Win32 compilers that appear to be popular around here
              > (Borland and Ming) have any support for this kind of thing. VC5 and earlier
              > certainly don't. Portability makes your patch more desirable.

              Well, I only have VC 5.0, so I won't be able to use /delayload too. Don't
              Borland and/or Ming have a similar facility?

              --
              A)bort, R)etry, D)o it right this time

              /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
              \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
            • Bram Moolenaar
              Muraoka Taro wrote: Thanks for updating the patch. It looks good to me now. ... Hmm, that s 5%. Well, I ll include the patch now. We can decide later if the
              Message 6 of 19 , Nov 2, 2000
                Muraoka Taro wrote:

                Thanks for updating the patch. It looks good to me now.

                > > Is there a catch in trying to load the Perl and/or Python library? I
                > > suppose the executable will become a bit bigger, I'll have to find out by
                > > how much. I suppose the running program will be a bit bigger too (I know
                > > the OLE version is quite a bit bigger).
                >
                > Yes, executable become bigger about 40KB when compiled with dynamic link to
                > both Perl and Python.
                >
                > Normal(GUI): 815104 bytes
                > Dynamic(Perl and Python): 856064 bytes

                Hmm, that's 5%. Well, I'll include the patch now. We can decide later if the
                distributed executable should be compiled with it or not.

                --
                A)bort, R)etry, B)ang it with a large hammer

                /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
              • Moore, Paul
                From: George V. Reilly [mailto:george@reilly.org] ... That was my first thought as well. However, when I looked, I couldn t see an easy way of checking whether
                Message 7 of 19 , Nov 2, 2000
                  From: George V. Reilly [mailto:george@...]
                  > I'll freely admit that I haven't dug into the two patches to
                  > verify this, but it seems to me that you're duplicating the
                  > delayload functionality of the Microsoft VC6 compiler. See
                  > http://msdn.microsoft.com/library/periodic/period98/hood1298.htm for
                  > a description of how it works.

                  That was my first thought as well. However, when I looked, I couldn't see an
                  easy way of checking whether a delayloaded call would fail - for instance, I
                  don't want the :perl command to pop up a system box saying "Cannot delayload
                  <some Perl internal function>" - I want the :perl command to be disabled at
                  runtime.

                  There's something about hooks in the documentation, but the information is
                  sparse, to be polite...

                  Regardless, the portability aspect is the killer - I'm just interested for
                  my own information.

                  Paul.
                • Moore, Paul
                  From: Bram Moolenaar [mailto:Bram@moolenaar.net] ... By the way, I had a brief glance at the patch last night. There are two points I would raise: 1. The
                  Message 8 of 19 , Nov 2, 2000
                    From: Bram Moolenaar [mailto:Bram@...]
                    > Hmm, that's 5%. Well, I'll include the patch now. We can
                    > decide later if the distributed executable should be compiled
                    > with it or not.

                    By the way, I had a brief glance at the patch last night. There are two
                    points I would raise:

                    1. The dynamic loading is not restricted to ActiveState Perl. I'd recommend
                    changing the defines - how about DYNAMIC_PERL and DYNAMIC_PYTHON?

                    2. I note that the Makefile hard-codes python15.dll - as Python 1.6 and 2.0
                    are now available, this is probably a mistake. I'd suggest making the user
                    specify the version on the Make command line. I'll take a look in more
                    detail in the next day or so, and offer a revised patch, if that's useful.

                    Do you want to hold off including this patch, Bram, or should I wait for
                    6.0l and submit a patch then?

                    Paul.
                  • Bram Moolenaar
                    ... There are also a few changed function prototypes. Is this not specific to Activestate Perl? ... Yes. Same for Perl. ... I already included the patch.
                    Message 9 of 19 , Nov 2, 2000
                      Paul Moore wrote:

                      > By the way, I had a brief glance at the patch last night. There are two
                      > points I would raise:
                      >
                      > 1. The dynamic loading is not restricted to ActiveState Perl. I'd recommend
                      > changing the defines - how about DYNAMIC_PERL and DYNAMIC_PYTHON?

                      There are also a few changed function prototypes. Is this not specific to
                      Activestate Perl?

                      > 2. I note that the Makefile hard-codes python15.dll - as Python 1.6 and 2.0
                      > are now available, this is probably a mistake. I'd suggest making the user
                      > specify the version on the Make command line. I'll take a look in more
                      > detail in the next day or so, and offer a revised patch, if that's useful.

                      Yes. Same for Perl.

                      > Do you want to hold off including this patch, Bram, or should I wait for
                      > 6.0l and submit a patch then?

                      I already included the patch. You could make a diff against 6.0k plus the
                      patch. Or wait for 6.0i, whatever you want.

                      --
                      hundred-and-one symptoms of being an internet addict:
                      4. Your eyeglasses have a web site burned in on them.

                      /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                      \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                    • Dan Sharp
                      ... It looks like for Borland 5.5, ilink32.exe has a parameter -d with the description Delay load a .DLL though I don t know how it compares / if it is
                      Message 10 of 19 , Nov 2, 2000
                        Bram Moolenaar wrote:

                        > George Reilly wrote:
                        >
                        >> Leveraging the compiler would make the code a lot simpler. Unfortunately, I
                        >> don't think the other Win32 compilers that appear to be popular around here
                        >> (Borland and Ming) have any support for this kind of thing. VC5 and earlier
                        >> certainly don't. Portability makes your patch more desirable.
                        >
                        >
                        > Well, I only have VC 5.0, so I won't be able to use /delayload too. Don't
                        > Borland and/or Ming have a similar facility?
                        >
                        It looks like for Borland 5.5, ilink32.exe has a parameter -d with the
                        description "Delay load a .DLL" though I don't know how it compares / if
                        it is compatible with the MSVC feature. I don't see a corresponding
                        option for Ming, but I am not too familiar with that compiler yet. I
                        would imagine, though, that if the feature isn't in GCC in general, then
                        Ming wouldn't have it.

                        Dan Sharp
                      • Moore, Paul
                        From: Bram Moolenaar [mailto:Bram@moolenaar.net] ... No, there should be nothing specific to ActiveState these days - the ActiveState build is identical to
                        Message 11 of 19 , Nov 2, 2000
                          From: Bram Moolenaar [mailto:Bram@...]
                          > There are also a few changed function prototypes. Is this
                          > not specific to Activestate Perl?

                          No, there should be nothing specific to ActiveState these days - the
                          ActiveState build is identical to Perl core. The prototype changes make the
                          code work with the latest version of Perl (5.6), whereas the previous code
                          was compatible with the old version (5.005).

                          Paul.
                        • Bram Moolenaar
                          ... Aha. Perhaps there is a more generic #ifdef to be used then? -- hundred-and-one symptoms of being an internet addict: 9. All your daydreaming is
                          Message 12 of 19 , Nov 2, 2000
                            Paul Moore wrote:

                            > From: Bram Moolenaar [mailto:Bram@...]
                            > > There are also a few changed function prototypes. Is this
                            > > not specific to Activestate Perl?
                            >
                            > No, there should be nothing specific to ActiveState these days - the
                            > ActiveState build is identical to Perl core. The prototype changes make the
                            > code work with the latest version of Perl (5.6), whereas the previous code
                            > was compatible with the old version (5.005).

                            Aha. Perhaps there is a more generic #ifdef to be used then?

                            --
                            hundred-and-one symptoms of being an internet addict:
                            9. All your daydreaming is preoccupied with getting a faster connection to the
                            net: 28.8...ISDN...cable modem...T1...T3.

                            /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                            \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                          • Ron Aaron
                            ... I have just uploaded a mingw32 compiled version of vim60k-win32 to my web site: http://www.mossbayeng.com/~ron/vim/gvim.exe It is compiled with Perl and
                            Message 13 of 19 , Nov 2, 2000
                              Bram Moolenaar <Bram@...> writes:
                              >> > There are also a few changed function prototypes. Is this
                              >> > not specific to Activestate Perl?


                              I have just uploaded a mingw32 compiled version of vim60k-win32 to my web
                              site:

                              http://www.mossbayeng.com/~ron/vim/gvim.exe

                              It is compiled with Perl and Python (Dynamic!!!) support. You do *not* have
                              to have either perl or python installed to use the exe, but (of course) you do
                              if you want to use the perl or python interfaces. In which case, you will
                              want to install the ActiveState versions of same:

                              http://www.activestate.com/

                              The patch to 'Make_ming.mak' is attached here; NOTE: I had to cross compile
                              from Linux, because for some reason, the make on Win32 didn't accept e.g.:

                              -DBLAH=\"a string\"

                              and I couldn't figure out how to get that part working (which it does, just
                              fine, on Linux).

                              Enjoy,
                              ROn
                            • Bram Moolenaar
                              ... I ll merge it in. It seems part of the previous patch is also needed. ... Doesn t this work: -DBLAH= a string I suspect the backslashes work differently
                              Message 14 of 19 , Nov 3, 2000
                                Ron Aaron wrote:

                                > I have just uploaded a mingw32 compiled version of vim60k-win32 to my web
                                > site:
                                >
                                > http://www.mossbayeng.com/~ron/vim/gvim.exe
                                >
                                > It is compiled with Perl and Python (Dynamic!!!) support. You do *not* have
                                > to have either perl or python installed to use the exe, but (of course) you
                                > do if you want to use the perl or python interfaces. In which case, you
                                > will want to install the ActiveState versions of same:
                                >
                                > http://www.activestate.com/
                                >
                                > The patch to 'Make_ming.mak' is attached here;

                                I'll merge it in. It seems part of the previous patch is also needed.

                                > NOTE: I had to cross compile from Linux, because for some reason, the make
                                > on Win32 didn't accept e.g.:
                                >
                                > -DBLAH=\"a string\"
                                >
                                > and I couldn't figure out how to get that part working (which it does, just
                                > fine, on Linux).

                                Doesn't this work:
                                -DBLAH="a string"

                                I suspect the backslashes work differently on Windows.

                                --
                                hundred-and-one symptoms of being an internet addict:
                                13. You refer to going to the bathroom as downloading.

                                /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                                \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                              • Moore, Paul
                                From: Ron Aaron [mailto:ron@mossbayeng.com] ... Try -DBLAH= a string (with the outer quotes as well...) Paul.
                                Message 15 of 19 , Nov 3, 2000
                                  From: Ron Aaron [mailto:ron@...]
                                  > The patch to 'Make_ming.mak' is attached here; NOTE: I had to cross
                                  > compile from Linux, because for some reason, the make on Win32
                                  > didn't accept e.g.:
                                  >
                                  > -DBLAH=\"a string\"
                                  >
                                  > and I couldn't figure out how to get that part working (which
                                  > it does, just fine, on Linux).

                                  Try "-DBLAH=\"a string\"" (with the outer quotes as well...)

                                  Paul.
                                • Dan Sharp
                                  ... Are you sure? I downloaded the file and tried to run it, but I get an Unable to Locate DLL error that python20.dll could not be found the specified
                                  Message 16 of 19 , Nov 3, 2000
                                    Ron Aaron wrote:

                                    > Bram Moolenaar <Bram@...> writes:
                                    >
                                    >>>> There are also a few changed function prototypes. Is this
                                    >>>> not specific to Activestate Perl?
                                    >>>
                                    >
                                    >
                                    > I have just uploaded a mingw32 compiled version of vim60k-win32 to my web
                                    > site:
                                    >
                                    > http://www.mossbayeng.com/~ron/vim/gvim.exe
                                    >
                                    > It is compiled with Perl and Python (Dynamic!!!) support. You do *not* have
                                    > to have either perl or python installed to use the exe, but (of course) you do
                                    > if you want to use the perl or python interfaces.

                                    Are you sure? I downloaded the file and tried to run it, but I get an
                                    "Unable to Locate DLL" error that python20.dll could not be found the
                                    specified path, and so the program will not load. I have perl 5.6 and
                                    python 1.5.2 installed, but I figured if it couldn't find the correct
                                    version of the python DLL, it would consider it to not be installed and
                                    disable the python interface.

                                    Dan Sharp
                                  • Ron Aaron
                                    ... Alas, you ve found me out! I had the Python and perl installed, so I didn t catch the failure to really dynamically load. I have just uploaded a *new*
                                    Message 17 of 19 , Nov 3, 2000
                                      Dan Sharp <vimuser@...> writes:
                                      >Ron Aaron wrote:
                                      >
                                      >>
                                      >> I have just uploaded a mingw32 compiled version of vim60k-win32 to my web
                                      >> site:
                                      >>
                                      >> http://www.mossbayeng.com/~ron/vim/gvim.exe
                                      >>
                                      >> It is compiled with Perl and Python (Dynamic!!!) support. You do *not* have
                                      >> to have either perl or python installed to use the exe, but (of course) you do
                                      >> if you want to use the perl or python interfaces.
                                      >
                                      >Are you sure? I downloaded the file and tried to run it, but I get an
                                      >"Unable to Locate DLL" error that python20.dll could not be found the
                                      >specified path, and so the program will not load. I have perl 5.6 and
                                      >python 1.5.2 installed, but I figured if it couldn't find the correct
                                      >version of the python DLL, it would consider it to not be installed and
                                      >disable the python interface.
                                      >


                                      Alas, you've found me out! I had the Python and perl installed, so I didn't
                                      catch the failure to really dynamically load.

                                      I have just uploaded a *new* version, which is *really* dynamically loaded (!)
                                      to the same place:

                                      http://www.mossbayeng.com/~ron/vim/gvim.exe

                                      Also, I have had to redo my patches. Here are the new, improved patches,
                                      against 6.0k *with* the dynamic perl/python patch from that fellow...

                                      I have solved the cross-platform problem (e.g. the -Dwhat=\"string\" not
                                      working on Win32). The solution is to write a temporary .h file (dyn-ming.h)
                                      and include it in the if_python.c and if_perl.xs if using MINGW32. Thanks to
                                      those of you who offered suggestions.

                                      My make file is also updated. Here's the patches:
                                    • Dan Sharp
                                      ... That one works much better :) For me, the perl interface worked fine, and it said the python interface was disable (the spelling needs to be fixed on
                                      Message 18 of 19 , Nov 3, 2000
                                        Ron Aaron wrote:

                                        > Alas, you've found me out! I had the Python and perl installed, so I didn't
                                        > catch the failure to really dynamically load.
                                        >
                                        > I have just uploaded a *new* version, which is *really* dynamically loaded (!)
                                        > to the same place:
                                        >
                                        > http://www.mossbayeng.com/~ron/vim/gvim.exe

                                        That one works much better :) For me, the perl interface worked fine,
                                        and it said the python interface was "disable" (the spelling needs to be
                                        fixed on that message) since I only had 1.5 installed and it wanted 2.0.

                                        Dan Sharp
                                      • Ron Aaron
                                        ... Good. You should get the ActiveState Python 2.0 to use with this gvim.exe. If you use another version, I don t know if it will work (probably not!). Have
                                        Message 19 of 19 , Nov 3, 2000
                                          Dan Sharp <vimuser@...> writes:
                                          >Ron Aaron wrote:
                                          >
                                          >> Alas, you've found me out! I had the Python and perl installed, so I didn't
                                          >> catch the failure to really dynamically load.
                                          >>
                                          >> I have just uploaded a *new* version, which is *really* dynamically loaded (!)
                                          >> to the same place:
                                          >>
                                          >> http://www.mossbayeng.com/~ron/vim/gvim.exe
                                          >
                                          >That one works much better :) For me, the perl interface worked fine,
                                          >and it said the python interface was "disable" (the spelling needs to be
                                          >fixed on that message) since I only had 1.5 installed and it wanted 2.0.
                                          >
                                          >Dan Sharp

                                          Good. You should get the ActiveState Python 2.0 to use with this gvim.exe.
                                          If you use another version, I don't know if it will work (probably not!).

                                          Have a good weekend,
                                          Ron
                                        Your message has been successfully submitted and would be delivered to recipients shortly.