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

Vim 6.0h alpha available

Expand Messages
  • Bram Moolenaar
    Yet another Vim in the 6.0 series. It will be at least a month until the next one (I m going on holidays). Major changes ... There is now the possibility to
    Message 1 of 16 , Aug 31, 2000
      Yet another Vim in the 6.0 series. It will be at least a month until the next
      one (I'm going on holidays).

      Major changes
      -------------

      There is now the possibility to auto-indent for any language:
      - Added the 'indentexpr' option: Expression which is evaluated to get the
      indent for the current line.
      - ":filetype indent on": Automatically load indent files from the "indent"
      directories in 'runtimepath'.
      - Added "=word" to 'cinkeys' option, to be able when to re-indent after typing
      (part of) a word.
      See ":help indent-expression".

      There is one example file for indenting Vim scripts: runtime/indent/vim.vim.
      Please attempt to create an indent file for your favorite language. I would
      suggest exchanging them on vim-dev for a few weeks, so that we can see if this
      new feature works well.

      While you are at it, also try writing a settings file for the language. See
      ":help filetype-settings". To make this a bit easier the "<Map>" special key
      was added. In a mapping "<Map>" can be used to get the value of the
      "localmapchar" variable. This simplifies mappings that use "localmapchar".
      "<Map>" defaults to ",". See runtime/settings/mail.vim for an example.

      Allow writing to a device (on Unix, MS-DOS and MS-Windows).
      Added Access Control List (ACL) support for FreeBSD and Win32. Mostly
      untested. Still needs more work!


      Minor changes
      -------------

      ":drop" now expands its arguments like ":next".

      Values for local window options are now saved for each window-buffer
      combination. This solves the problem that window-local options were lost when
      'hidden' is set and doing CTRL-^. E.g. on fold.c the options set from the
      modeline are gone.

      The 'lisp', 'smartindent' and 'cindent' options are not switched off when
      'paste' is set. The auto-indenting is disabled when 'paste' is set, but
      manual indenting with "=" still works.

      Execute 'foldexpr' and 'indentexpr' in a sandbox. Don't allow them to change
      text, external commands, write files, etc.

      New functions: getfsize() stridx() strridx() toupper() tolower() (Utz-Uwe
      Haus)

      Changed GvimExt again to do the "Edit in existing Vim" in a much simpler way.
      (Tianmio Hu)

      The number of marks kept in the jumplist has been increased from 50 to 100.

      Fixed redraw problem after undo: Two separate changes that delete lines.

      Fixed hang in syntax syncing for Perl.

      Unix: ":e`" caused a crash (but not on every system).

      Rxvt sends a termresponse whith a high version number. Don't mistake this for
      a recent xterm version. Could cause the termcap requests to show up in the
      display.

      Fixed: When re-using the current buffer for a new buffer, buffer-local
      variables were not deleted.

      Fixed: Search for /[a][^a]/ didn't work (range followed by complement of
      range).

      Fixed redraw problems when in 'compatible' mode and displaying a dollar for a
      change.

      Fixed: 'langmap' interfered with mouse and cursor keys, because of the
      negative value of special keys.

      Fixed crash when translated message for executing autocommands is a bit long.

      Fixed syntax highlighting error when deleting a line below another changed
      line.

      GUI fixed: when 'scrolloff' is 0 dragging the mouse above the window didn't
      cause a down scroll. Now pass on a mouse event with mouse_row set to -1.

      GUI fixed: ptys didn't work on HP-UX 10.20. (David Green)

      GUI fixed: Scrollbars would sometimes disappear when vertically splitting a
      window or closing a vertically split window.

      Fixed: ":map" listed mappings with K_SPECIAL codes in multi-byte characters
      wrong.

      Fixed: Backspacing in Replace mode didn't display the un-replaced characters.


      Epilogue
      --------

      WARNING: This is really an unstable version. Many things have been added
      without proper testing. It does crash. It may destroy your work.

      This version is for developers, thus it comes as source code only.
      If you run into something that doesn't work, please try to figure out why,
      try to solve it and send me a patch. If you can't do that, at least send me
      precise information to save me time.

      If you don't like the syntax of a command, the name of an option or how the
      new features work, let's discuss this in the vim-dev maillist.


      More info for the new 6.0 features at ":help version6".

      Lots of things are not working yet. Check ":help todo" for known items.

      I NEED YOUR HELP: There is still a lot of work to be done. If I have to do it
      all by myself it will take a very long time until Vim.6.0 is ready. Please
      give a hand by implementing one of the items in the todo list.


      You can find it here: ftp://ftp.vim.org/pub/vim/unreleased/

      unix/vim-6.0h-rt.tar.gz runtime files
      unix/vim-6.0h-src.tar.gz sources

      extra/vim-6.0h-extra.tar.gz extra files
      extra/vim-6.0h-lang.tar.gz multi-language files

      Happy Vimming!

      --
      BLACK KNIGHT: I'm invincible!
      ARTHUR: You're a looney.
      "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

      /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
      \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
    • Johannes Zellner
      6.0h is also in CVS. -- Johannes
      Message 2 of 16 , Aug 31, 2000
        6.0h is also in CVS.

        --
        Johannes
      • Johannes Zellner
        ... here is a hint for CVS users: You should use the `update -d flag to get new directories like the runtime/indent directory. Personally I use the following
        Message 3 of 16 , Aug 31, 2000
          On Thu, Aug 31, 2000 at 11:18:39PM +0200, Johannes Zellner wrote:
          > 6.0h is also in CVS.

          here is a hint for CVS users:
          You should use the `update -d' flag to get new directories
          like the runtime/indent directory. Personally I use the
          following lines in my ~/.cvsrc:

          cvs -z3
          update -P -d
          checkout -P

          --
          Johannes
        • Ron Aaron
          Hi all - Using the mingw32 version of gcc-2.95.2, I encountered a problem compiling os_win32.c (line 1948). The function used there is only available on NT,
          Message 4 of 16 , Aug 31, 2000
            Hi all -

            Using the 'mingw32' version of gcc-2.95.2, I encountered a problem compiling
            os_win32.c (line 1948). The function used there is only available on NT, so
            Win95 (and 98?) users cannot have it. This needs to be dealt with.

            Ron
          • Bram Moolenaar
            ... I don t see a problem on my Win 98 system. I would expect the ACL functions to return a FAIL on Windows 95 and 98, which is handled correctly. How about
            Message 5 of 16 , Sep 1, 2000
              Ron Aaron wrote:

              > Using the 'mingw32' version of gcc-2.95.2, I encountered a problem compiling
              > os_win32.c (line 1948). The function used there is only available on NT, so
              > Win95 (and 98?) users cannot have it. This needs to be dealt with.

              I don't see a problem on my Win 98 system. I would expect the ACL functions
              to return a FAIL on Windows 95 and 98, which is handled correctly.

              How about this patch:

              *** os_win32.c~ Thu Aug 31 20:42:31 2000
              --- os_win32.c Fri Sep 1 11:58:17 2000
              ***************
              *** 1940,1945 ****
              --- 1940,1949 ----
              {
              struct my_acl *p;

              + /* This only works on Windows NT and 2000. */
              + if (g_PlatformId != VER_PLATFORM_WIN32_NT)
              + return (vim_acl_t)NULL;
              +
              p = (struct my_acl *)alloc_clear((unsigned)sizeof(struct my_acl));
              if (p != NULL)
              {

              Or do you need some #ifdefs?

              --
              Any resemblance between the above views and those of my employer, my terminal,
              or the view out my window are purely coincidental. Any resemblance between
              the above and my own views is non-deterministic. The question of the
              existence of views in the absence of anyone to hold them is left as an
              exercise for the reader. The question of the existence of the reader is left
              as an exercise for the second god coefficient. (A discussion of
              non-orthogonal, non-integral polytheism is beyond the scope of this article.)
              (Ralph Jennings)

              /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
              \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
            • Brent Fulgham
              ... Unfortunately, they appear to be stubbed out in such a way that they allow the executable to be successfully linked, but fail at runtime (i.e., when it
              Message 6 of 16 , Sep 1, 2000
                > I don't see a problem on my Win 98 system. I would expect
                > the ACL functions to return a FAIL on Windows 95 and 98,
                > which is handled correctly.
                >

                Unfortunately, they appear to be stubbed out in such a way that
                they allow the executable to be successfully linked, but fail
                at runtime (i.e., when it loads the ADVAPI32.DLL). I'm afraid
                #ifdef's will be necessary.

                -Brent
              • Brent Fulgham
                Vimmer s: This patch solves my problem. Thanks, -Brent ... *************** ... { struct my_acl *p; + /* This only works on Windows NT and 2000. */ + #if
                Message 7 of 16 , Sep 1, 2000
                  Vimmer's:

                  This patch solves my problem.

                  Thanks,

                  -Brent

                  ---------------------------------------------------------------


                  *** os_win32.c~ Fri Sep 1 09:18:10 2000
                  --- os_win32.c Fri Sep 1 09:15:30 2000
                  ***************
                  *** 1940,1945 ****
                  --- 1940,1947 ----
                  {
                  struct my_acl *p;

                  + /* This only works on Windows NT and 2000. */
                  + #if defined(_WIN32_WINNT)
                  p = (struct my_acl *)alloc_clear((unsigned)sizeof(struct my_acl));
                  if (p != NULL)
                  {
                  ***************
                  *** 1962,1967 ****
                  --- 1964,1973 ----
                  p = NULL;
                  }
                  }
                  + #else
                  + p = NULL;
                  + #endif
                  +
                  return (vim_acl_t)p;
                  }

                  ***************
                  *** 1976,1981 ****
                  --- 1982,1989 ----
                  {
                  struct my_acl *p = (struct my_acl *)acl;

                  + /* This only works on Windows NT and 2000. */
                  + #if defined(_WIN32_WINNT)
                  if (p != NULL)
                  (void)SetNamedSecurityInfo(
                  (LPTSTR)fname, // Abstract filename
                  ***************
                  *** 1990,1995 ****
                  --- 1998,2004 ----
                  p->pDacl, // Discretionary
                  information.
                  p->pSacl // For auditing purposes.
                  );
                  + #endif
                  }

                  void
                • Bram Moolenaar
                  ... OK, so it s a Mingw32 problem. Your suggested patch contains: #if defined(_WIN32_WINNT) Won t that also disable the code when I compile with MS-VC on my
                  Message 8 of 16 , Sep 1, 2000
                    Brent Fulgham wrote:

                    > > I don't see a problem on my Win 98 system. I would expect
                    > > the ACL functions to return a FAIL on Windows 95 and 98,
                    > > which is handled correctly.
                    > >
                    >
                    > Unfortunately, they appear to be stubbed out in such a way that
                    > they allow the executable to be successfully linked, but fail
                    > at runtime (i.e., when it loads the ADVAPI32.DLL). I'm afraid
                    > #ifdef's will be necessary.

                    OK, so it's a Mingw32 problem. Your suggested patch contains:

                    #if defined(_WIN32_WINNT)

                    Won't that also disable the code when I compile with MS-VC on my Win 98
                    system? I think it's better to add an #ifdef for the ming compiler, since
                    it's their stub that causes the problem, right?

                    --
                    Team-building exercises come in many forms but they all trace their roots back
                    to the prison system. In your typical team-building exercise the employees
                    are subjected to a variety of unpleasant situations until they become either a
                    cohesive team or a ring of car jackers.
                    (Scott Adams - The Dilbert principle)

                    /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                    \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                  • Brent Fulgham
                    ... Sorry! I was unclear. I m compiling using MS Visual Studio 6.0 (Service Pack 4) on Windows 95. This is not limited to Mingw32 -- it s going to be common
                    Message 9 of 16 , Sep 1, 2000
                      > > > I don't see a problem on my Win 98 system. I would expect
                      > > > the ACL functions to return a FAIL on Windows 95 and 98,
                      > > > which is handled correctly.
                      > > >
                      > >
                      > > Unfortunately, they appear to be stubbed out in such a way that
                      > > they allow the executable to be successfully linked, but fail
                      > > at runtime (i.e., when it loads the ADVAPI32.DLL). I'm afraid
                      > > #ifdef's will be necessary.
                      >
                      > OK, so it's a Mingw32 problem. Your suggested patch contains:
                      >
                      > #if defined(_WIN32_WINNT)
                      >
                      > Won't that also disable the code when I compile with MS-VC on
                      > my Win 98 system? I think it's better to add an #ifdef for
                      > the ming compiler, since it's their stub that causes the
                      > problem, right?
                      >

                      Sorry! I was unclear. I'm compiling using MS Visual Studio 6.0
                      (Service Pack 4) on Windows 95. This is not limited to Mingw32
                      -- it's going to be common to any windows build.

                      Maybe we need a different define for Win 98, but I don't see anything
                      in the headers that would allow me to do that. Perhaps Win98
                      satisfies the _WIN32_WINNT define?

                      Thanks,

                      -Brent
                    • Ron Aaron
                      ... Sadly, mingw32 doesn t seem to support those APIs. At least, I get problems when I try to link (the APIs are in the libadvapi32.a file, so I don t know
                      Message 10 of 16 , Sep 1, 2000
                        Bram Moolenaar <Bram@...> writes:
                        >Ron Aaron wrote:
                        >
                        >> Using the 'mingw32' version of gcc-2.95.2, I encountered a problem compiling
                        >> os_win32.c (line 1948). The function used there is only available on NT, so
                        >> Win95 (and 98?) users cannot have it. This needs to be dealt with.
                        >
                        >I don't see a problem on my Win 98 system. I would expect the ACL functions
                        >to return a FAIL on Windows 95 and 98, which is handled correctly.
                        >
                        >How about this patch:
                        >
                        >*** os_win32.c~ Thu Aug 31 20:42:31 2000
                        >--- os_win32.c Fri Sep 1 11:58:17 2000
                        >***************
                        >*** 1940,1945 ****
                        >--- 1940,1949 ----
                        > {
                        > struct my_acl *p;
                        >
                        >+ /* This only works on Windows NT and 2000. */
                        >+ if (g_PlatformId != VER_PLATFORM_WIN32_NT)
                        >+ return (vim_acl_t)NULL;
                        >+
                        > p = (struct my_acl *)alloc_clear((unsigned)sizeof(struct my_acl));
                        > if (p != NULL)
                        > {
                        >
                        >Or do you need some #ifdefs?

                        Sadly, mingw32 doesn't seem to support those APIs. At least, I get problems
                        when I try to link (the APIs are in the libadvapi32.a file, so I don't know
                        what the exact problem is).

                        Anyway, the following patch against the os_win32.c *as distributed* in 6.0h,
                        should be applied. The compile works for mingw32, and it *SHOULD WORK* for
                        other compilers and should also work for Win95 et. al.

                        Sorry for all the headaches, but it's Microsoft's fault! :-)
                      • Bram Moolenaar
                        ... When I compile Vim on my Win 98 machine, and then run the binary on a Win NT machine, it should work. Thus the code should not depend on #ifdefs, which
                        Message 11 of 16 , Sep 2, 2000
                          Brent Fulgham wrote:

                          > Sorry! I was unclear. I'm compiling using MS Visual Studio 6.0
                          > (Service Pack 4) on Windows 95. This is not limited to Mingw32
                          > -- it's going to be common to any windows build.

                          When I compile Vim on my Win 98 machine, and then run the binary on a Win NT
                          machine, it should work. Thus the code should not depend on #ifdefs, which
                          work at compile time, but on something that doesn't use the ACL functions when
                          running on a system that doesn't support it.

                          The real problem was that the Ming compiler doesn't have the libraries for the
                          ACL functions. Thus it doesn't work at compile time.

                          > Maybe we need a different define for Win 98, but I don't see anything
                          > in the headers that would allow me to do that. Perhaps Win98
                          > satisfies the _WIN32_WINNT define?

                          Win 98 is very similar to Win 95, from a programmers viewpoint. Just like
                          Win NT and 2000 are similar.

                          --
                          "You're fired." (1980)
                          "You're laid off." (1985)
                          "You're downsized." (1990)
                          "You're rightsized." (1992)
                          (Scott Adams - The Dilbert principle)

                          /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                          \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                        • Bram Moolenaar
                          ... Thanks, this looks good, I ll include it. ... Or perhaps Ming s? -- Managers are like cats in a litter box. They instinctively shuffle things around to
                          Message 12 of 16 , Sep 2, 2000
                            Ron Aaron wrote:

                            > Sadly, mingw32 doesn't seem to support those APIs. At least, I get problems
                            > when I try to link (the APIs are in the libadvapi32.a file, so I don't know
                            > what the exact problem is).
                            >
                            > Anyway, the following patch against the os_win32.c *as distributed* in 6.0h,
                            > should be applied. The compile works for mingw32, and it *SHOULD WORK* for
                            > other compilers and should also work for Win95 et. al.

                            Thanks, this looks good, I'll include it.

                            > Sorry for all the headaches, but it's Microsoft's fault! :-)

                            Or perhaps Ming's?

                            --
                            Managers are like cats in a litter box. They instinctively shuffle things
                            around to conceal what they've done.
                            (Scott Adams - The Dilbert principle)

                            /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
                            \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
                          • Vince Negri
                            The correct way to solve this problem is for Vim to perform run-time linking to the DLLs using LoadLibrary and GetProcAddress. (The code would be similar to
                            Message 13 of 16 , Sep 4, 2000
                              The correct way to solve this problem is for Vim to perform
                              run-time linking to the DLLs using LoadLibrary and GetProcAddress.
                              (The code would be similar to that in mch_libcall.) Such a technique
                              would result in code that would compile with mingwin32 or any
                              other compiler, and produce a single binary that would run on all
                              systems (95, 98, NT/2000)


                              Vince




                              Legal Disclaimer: Any views expressed by the sender of this message are
                              not necessarily those of Application Solutions Ltd. Information in this
                              e-mail may be confidential and is for the use of the intended recipient
                              only, no mistake in transmission is intended to waive or compromise such
                              privilege. Please advise the sender if you receive this e-mail by mistake.
                            • Brent Fulgham
                              ... Okay, so then the library will need to be dynamically loaded. ... No -- what I am saying is that the Microsoft compiler exhibits the same behavior. Simply
                              Message 14 of 16 , Sep 5, 2000
                                > When I compile Vim on my Win 98 machine, and then run the binary
                                > on a Win NT machine, it should work. Thus the code should not
                                > depend on #ifdefs, which work at compile time, but on something
                                > that doesn't use the ACL functions when running on a system that
                                > doesn't support it.
                                >
                                Okay, so then the library will need to be dynamically loaded.

                                > The real problem was that the Ming compiler doesn't have the
                                > libraries for the ACL functions. Thus it doesn't work at
                                > compile time.
                                >
                                No -- what I am saying is that the Microsoft compiler exhibits
                                the same behavior. Simply #ifdef'ing around MING will NOT
                                fix this problem.

                                Thanks,

                                -Brent
                              • Bill McCarthy
                                I can t get this to compile on Win2k using Ming s GCC. Here s the problem part of the output from: make -f Make_ming.mak gcc -Iproto -DWIN32 -DPC
                                Message 15 of 16 , Oct 20, 2000
                                  I can't get this to compile on Win2k using Ming's GCC. Here's the
                                  problem part of the output from:

                                  make -f Make_ming.mak

                                  gcc -Iproto -DWIN32 -DPC -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_BIG -pipe
                                  -malign-double -mwide-multiply -march=i386 -mcpu=i686 -Wall -s
                                  -fomit-frame-pointer -freg-struct-return -malign-double -mwide-multiply
                                  -finline-functions -O3 -c os_win32.c -o os_win32.o
                                  os_win32.c:267: warning: `enum SE_OBJECT_TYPE' declared inside parameter list
                                  os_win32.c:267: warning: its scope is only this definition or declaration,
                                  which is probably not what you want.
                                  os_win32.c:267: warning: parameter has incomplete type
                                  os_win32.c:270: warning: `enum SE_OBJECT_TYPE' declared inside parameter list
                                  os_win32.c:270: warning: parameter has incomplete type
                                  os_win32.c: In function `mch_isFullName':
                                  os_win32.c:2208: warning: suggest parentheses around && within ||
                                  os_win32.c: In function `mch_get_acl':
                                  os_win32.c:2364: sizeof applied to an incomplete type
                                  os_win32.c:2369: `SE_FILE_OBJECT' undeclared (first use in this function)
                                  os_win32.c:2369: (Each undeclared identifier is reported only once
                                  os_win32.c:2369: for each function it appears in.)
                                  os_win32.c:2375: dereferencing pointer to incomplete type
                                  os_win32.c:2376: dereferencing pointer to incomplete type
                                  os_win32.c:2377: dereferencing pointer to incomplete type
                                  os_win32.c:2378: dereferencing pointer to incomplete type
                                  os_win32.c:2379: dereferencing pointer to incomplete type
                                  os_win32.c:2380: type of formal parameter 2 is incomplete
                                  os_win32.c: In function `mch_set_acl':
                                  os_win32.c:2408: `SE_FILE_OBJECT' undeclared (first use in this function)
                                  os_win32.c:2414: dereferencing pointer to incomplete type
                                  os_win32.c:2415: dereferencing pointer to incomplete type
                                  os_win32.c:2416: dereferencing pointer to incomplete type
                                  os_win32.c:2417: dereferencing pointer to incomplete type
                                  os_win32.c:2418: type of formal parameter 2 is incomplete
                                  os_win32.c: In function `mch_free_acl':
                                  os_win32.c:2431: dereferencing pointer to incomplete type
                                  make: *** [os_win32.o] Error 1



                                  ######################################################################
                                  This e-mail message has been scanned and cleared by MailMarshal
                                  ######################################################################
                                • Bill McCarthy
                                  The post from me (quoted below) was about 6.0i (not 6.0h).
                                  Message 16 of 16 , Oct 20, 2000
                                    The post from me (quoted below) was about 6.0i (not 6.0h).

                                    On Fri, 20 Oct 2000 16:31:48 -0400, Bill McCarthy wrote:

                                    >I can't get this to compile on Win2k using Ming's GCC. Here's the
                                    >problem part of the output from:
                                    >
                                    > make -f Make_ming.mak
                                    >
                                    >gcc -Iproto -DWIN32 -DPC -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_BIG -pipe
                                    > -malign-double -mwide-multiply -march=i386 -mcpu=i686 -Wall -s
                                    > -fomit-frame-pointer -freg-struct-return -malign-double -mwide-multiply
                                    > -finline-functions -O3 -c os_win32.c -o os_win32.o
                                    >os_win32.c:267: warning: `enum SE_OBJECT_TYPE' declared inside parameter list
                                    >os_win32.c:267: warning: its scope is only this definition or declaration,
                                    > which is probably not what you want.
                                    >os_win32.c:267: warning: parameter has incomplete type
                                    >os_win32.c:270: warning: `enum SE_OBJECT_TYPE' declared inside parameter list
                                    >os_win32.c:270: warning: parameter has incomplete type
                                    >os_win32.c: In function `mch_isFullName':
                                    >os_win32.c:2208: warning: suggest parentheses around && within ||
                                    >os_win32.c: In function `mch_get_acl':
                                    >os_win32.c:2364: sizeof applied to an incomplete type
                                    >os_win32.c:2369: `SE_FILE_OBJECT' undeclared (first use in this function)
                                    >os_win32.c:2369: (Each undeclared identifier is reported only once
                                    >os_win32.c:2369: for each function it appears in.)
                                    >os_win32.c:2375: dereferencing pointer to incomplete type
                                    >os_win32.c:2376: dereferencing pointer to incomplete type
                                    >os_win32.c:2377: dereferencing pointer to incomplete type
                                    >os_win32.c:2378: dereferencing pointer to incomplete type
                                    >os_win32.c:2379: dereferencing pointer to incomplete type
                                    >os_win32.c:2380: type of formal parameter 2 is incomplete
                                    >os_win32.c: In function `mch_set_acl':
                                    >os_win32.c:2408: `SE_FILE_OBJECT' undeclared (first use in this function)
                                    >os_win32.c:2414: dereferencing pointer to incomplete type
                                    >os_win32.c:2415: dereferencing pointer to incomplete type
                                    >os_win32.c:2416: dereferencing pointer to incomplete type
                                    >os_win32.c:2417: dereferencing pointer to incomplete type
                                    >os_win32.c:2418: type of formal parameter 2 is incomplete
                                    >os_win32.c: In function `mch_free_acl':
                                    >os_win32.c:2431: dereferencing pointer to incomplete type
                                    >make: *** [os_win32.o] Error 1
                                  Your message has been successfully submitted and would be delivered to recipients shortly.