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

RE: Vim 6.0h: Win32 compile problem

Expand Messages
  • 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 1 of 16 , Sep 1, 2000
    • 0 Attachment
      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 2 of 16 , Sep 1, 2000
      • 0 Attachment
        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 3 of 16 , Sep 1, 2000
        • 0 Attachment
          > > > 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 4 of 16 , Sep 1, 2000
          • 0 Attachment
            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 5 of 16 , Sep 2, 2000
            • 0 Attachment
              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 6 of 16 , Sep 2, 2000
              • 0 Attachment
                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 7 of 16 , Sep 4, 2000
                • 0 Attachment
                  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 8 of 16 , Sep 5, 2000
                  • 0 Attachment
                    > 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 9 of 16 , Oct 20, 2000
                    • 0 Attachment
                      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 10 of 16 , Oct 20, 2000
                      • 0 Attachment
                        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.