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

Re: Vim 6.0h: Win32 compile problem

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.