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

Vim 6.0h: Win32 compile problem

Expand Messages
  • 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 1 of 16 , Aug 31, 2000
    • 0 Attachment
      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 2 of 16 , Sep 1, 2000
      • 0 Attachment
        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 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.

          -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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.