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

RE: Vim 6.0h: Win32 compile problem

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