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

Re: Compile 6.0ap under Cygwin

Expand Messages
  • Thore B. Karlsen
    ... Basically, when you re not using MFC you can include this to speed up the compilation. It never _has_ to be used, other than in cases like the above where
    Message 1 of 22 , Aug 1, 2001
    • 0 Attachment
      On Wed, 01 Aug 2001 14:25:18 +0200, you wrote:

      >> I have just build vim 6.0ap under Cygwin using the standard UNIX
      >> Makefile. I had to apply the following patch to src/mbyte.c to
      >> get it compiled due to a collision of the `Status' type with
      >> an unused Windows header (winspool.h):
      >>
      >> --- mbyte.c.ORIG Wed Aug 1 12:19:52 2001
      >> +++ mbyte.c Wed Aug 1 12:21:22 2001
      >> @@ -77,6 +77,7 @@
      >>
      >> #include "vim.h"
      >> #if defined(WIN3264) || defined(WIN32UNIX)
      >> +# define WIN32_LEAN_AND_MEAN
      >> # include <windows.h>
      >> # ifndef __MINGW32__
      >> # include <winnls.h>

      >This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In several
      >files where windows.h is included it is used, in others it is not. What is
      >the rule for using it?

      Basically, when you're not using MFC you can include this to speed up
      the compilation.

      It never _has_ to be used, other than in cases like the above where
      windows.h includes an unused header file and that messes things up.

      I don't know if there are cases when you don't want to use it in a
      non-MFC program.
    • Corinna Vinschen
      ... I m not that sure but I think WIN32_LEAN_AND_MEAN only includes header files which are needed for the basic win32 API. Everything else is dropped (COM,
      Message 2 of 22 , Aug 1, 2001
      • 0 Attachment
        On Wed, Aug 01, 2001 at 02:25:18PM +0200, Bram Moolenaar wrote:
        > Corinna Vinschen wrote:
        >
        > > I have just build vim 6.0ap under Cygwin using the standard UNIX
        > > Makefile. I had to apply the following patch to src/mbyte.c to
        > > get it compiled due to a collision of the `Status' type with
        > > an unused Windows header (winspool.h):
        > >
        > > --- mbyte.c.ORIG Wed Aug 1 12:19:52 2001
        > > +++ mbyte.c Wed Aug 1 12:21:22 2001
        > > @@ -77,6 +77,7 @@
        > >
        > > #include "vim.h"
        > > #if defined(WIN3264) || defined(WIN32UNIX)
        > > +# define WIN32_LEAN_AND_MEAN
        > > # include <windows.h>
        > > # ifndef __MINGW32__
        > > # include <winnls.h>
        >
        > This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In several
        > files where windows.h is included it is used, in others it is not. What is
        > the rule for using it?

        I'm not that sure but I think WIN32_LEAN_AND_MEAN only includes
        header files which are needed for the basic win32 API. Everything
        else is dropped (COM, MFC, etc.). Typically it's a good thing
        since it shortens compile time in 99% of the cases.

        > > I have another question. In the standard Makefile there's a define
        > > `SUFFIX' which is set to ".exe" but it's commented out. This
        > > requires manual intervention before compiling it on a Win32 UNIX
        > > layer like Cygwin. Why doesn't vim use the autoconf macro AC_EXEEXT?
        > > Is there a special reason for that or would a patch be welcome?
        >
        > For Cygwin the Make_cyg.mak file should work. Otherwise, I don't think there

        Uhm..., I don't want to annoy anybody but the Make_cyg.mak is sort
        of a mess from the Cygwin point of view:

        It uses native DOS commands instead of typical UNIX functionality
        ("del" instead of "rm", etc.) which is part of Cygwin for years.

        It links explicitely windows DLLs which are linked automatically
        by Cygwin's gcc (kernel32.dll, user32.dll, etc.)

        It defines symbols which are already defined (__CYGWIN__) and it
        defines symbols which shouldn't be defined (WIN32).

        The Make_cyg.mak file looks as if somebody wants to only use
        Cygwin's gcc to create a native Windows application instead
        of a Cygwin application.

        Cygwin is a UNIX porting layer which allows typically to build
        applications from the UNIX build process in a UNIX-like build
        environment. There's no need to create a separate Makefile for
        Cygwin. A Cygwin vim uses only POSIX system calls except
        when compiled as GVIM for the Win32 GUI.

        Since I'm the maintainer for Vim in the Cygwin net distribution
        I would like to keep the UNIX way of building things.

        Currently vim-6.0ap build OOTB from the UNIX Makefile except for
        the above `WIN32_LEAN_AND_MEAN' problem and the `SUFFIX' part in
        the Makefile.

        > is a reason not to use AC_EXEEXT. It's just that nobody suggested this until
        > now. If you can make a patch for it and test it, that's welcome.

        I'm a bit spare on time but I will try to do this in a week or
        two.

        Corinna

        --
        Corinna Vinschen
        Cygwin Developer
        Red Hat, Inc.
        mailto:vinschen@...
      • Dan Sharp
        ... Exactly. Some people may have Cygwin gcc installed as their only compiler and want to compile a native Windows gvim. Instead of having to download a
        Message 3 of 22 , Aug 1, 2001
        • 0 Attachment
          >The Make_cyg.mak file looks as if somebody wants to only use
          >Cygwin's gcc to create a native Windows application instead
          >of a Cygwin application.

          Exactly. Some people may have Cygwin gcc installed as their only compiler
          and want to compile a native Windows gvim. Instead of having to download a
          whole new compiler (like MingW or Borland 5.5) or always have an X-server
          running to use the Athena or GTK version, they can just use
          Make_cyg.mak. Granted, Make_cyg.mak may not be the cleanest
          implementation, but it works well enough.

          >Since I'm the maintainer for Vim in the Cygwin net distribution
          >I would like to keep the UNIX way of building things.

          I knew I recognized your name from somewhere! :) The Cygwin SSHD server is
          the only remote-access service I run on my Win2k machine anymore. Adding
          cygrunserv was very helpful, too! Thanks for all the work!

          >Currently vim-6.0ap build OOTB from the UNIX Makefile except for
          >the above `WIN32_LEAN_AND_MEAN' problem and the `SUFFIX' part in
          >the Makefile.

          Are you going to be including gvim in the vim 6.0 Cygwin distribution?

          Dan Sharp
        • Dan Sharp
          ... I tried a quick test and stuck #define WIN32_LEAN_AND_MEAN in front of every call to #include and it breaks compilation of if_ole.cpp and
          Message 4 of 22 , Aug 1, 2001
          • 0 Attachment
            At 02:25 PM 8/1/2001 +0200, Bram Moolenaar wrote:

            >This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In several
            >files where windows.h is included it is used, in others it is not. What is
            >the rule for using it?

            I tried a quick test and stuck #define WIN32_LEAN_AND_MEAN in front of
            every call to #include <windows.h> and it breaks compilation of if_ole.cpp
            and gui_w48.c. Removing it from if_ole.cpp fixed that problem, and
            removing it from gui.h fixed the gui_w48.c problem (removing it from
            gui_w48.c didn't help. I guess since it was already done in gui.h, the
            #include <windows.h> in gui_w48.c is a little redundant, at least for
            win32). It looks like the idea behind it is to speed up compilation time
            by not reading in the lesser used header files. I didn't see any change in
            code size, and didn't really pay attention to compile time differences.

            Dan Sharp
          • Bram Moolenaar
            ... I suppose this means we can define it globally then. Vim doesn t use COM or MFC. ... Make_cyg.mak is using the Cygwin compiler to produce a Windows
            Message 5 of 22 , Aug 1, 2001
            • 0 Attachment
              Corinna Vinschen wrote:

              > > This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In
              > > several files where windows.h is included it is used, in others it is not.
              > > What is the rule for using it?
              >
              > I'm not that sure but I think WIN32_LEAN_AND_MEAN only includes
              > header files which are needed for the basic win32 API. Everything
              > else is dropped (COM, MFC, etc.). Typically it's a good thing
              > since it shortens compile time in 99% of the cases.

              I suppose this means we can define it globally then. Vim doesn't use COM or
              MFC.

              > Uhm..., I don't want to annoy anybody but the Make_cyg.mak is sort
              > of a mess from the Cygwin point of view:
              >
              > It uses native DOS commands instead of typical UNIX functionality
              > ("del" instead of "rm", etc.) which is part of Cygwin for years.
              >
              > It links explicitely windows DLLs which are linked automatically
              > by Cygwin's gcc (kernel32.dll, user32.dll, etc.)
              >
              > It defines symbols which are already defined (__CYGWIN__) and it
              > defines symbols which shouldn't be defined (WIN32).
              >
              > The Make_cyg.mak file looks as if somebody wants to only use
              > Cygwin's gcc to create a native Windows application instead
              > of a Cygwin application.

              Make_cyg.mak is using the Cygwin compiler to produce a Windows application.
              When using Makefile you get a Cygwin application. That last method is needed
              for Unix applications that have not been ported to Windows. But since Vim has
              been ported, isn't it better to make it work like a Windows application?

              I suppose you know how to cleanup Make_cyg.mak. Unfortunately it doesn't
              mention who has been working on this (must be several people). Any comments
              from them?

              > Cygwin is a UNIX porting layer which allows typically to build
              > applications from the UNIX build process in a UNIX-like build
              > environment. There's no need to create a separate Makefile for
              > Cygwin. A Cygwin vim uses only POSIX system calls except
              > when compiled as GVIM for the Win32 GUI.
              >
              > Since I'm the maintainer for Vim in the Cygwin net distribution
              > I would like to keep the UNIX way of building things.

              The question is why you would want to do this. It probably makes the
              executable larger, perhaps problems with file names, etc. What would be the
              advantage?

              > Currently vim-6.0ap build OOTB from the UNIX Makefile except for
              > the above `WIN32_LEAN_AND_MEAN' problem and the `SUFFIX' part in
              > the Makefile.

              That's a good sign, both for Vim being portable and for Cygwin being able to
              compile this rather complex program.

              > > is a reason not to use AC_EXEEXT. It's just that nobody suggested this
              > > until now. If you can make a patch for it and test it, that's welcome.
              >
              > I'm a bit spare on time but I will try to do this in a week or two.

              I notice it's just a matter of including AC_EXEEXT in configure.in and
              defining EXEEXT in config.mk.in in the usual way. Oh, and rename SUFFIX to
              EXEEXT in Makefile, that's clearer anyway. I'll add it and we can test it
              with the next version. Looks harmless if it's empty anyway.

              --
              From "know your smileys":
              C=}>;*{)) Drunk, devilish chef with a toupee in an updraft,
              a mustache, and a double chin

              /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
              ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
              \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
            • Corinna Vinschen
              ... No. A native Windows port is a different thing. Cygwin provides stuff in it s environment which isn t available under Windows, for example mount points,
              Message 6 of 22 , Aug 1, 2001
              • 0 Attachment
                On Wed, Aug 01, 2001 at 06:04:48PM +0200, Bram Moolenaar wrote:
                > Make_cyg.mak is using the Cygwin compiler to produce a Windows application.
                > When using Makefile you get a Cygwin application. That last method is needed
                > for Unix applications that have not been ported to Windows. But since Vim has
                > been ported, isn't it better to make it work like a Windows application?

                No. A native Windows port is a different thing. Cygwin provides
                stuff in it's environment which isn't available under Windows,
                for example mount points, symbolic links and so on. If you
                compile a vim for native Windows it doesn't have access to this
                POSIX environment. You can Cygwin handle as another UNIX target
                like Sun, OpenBSD, Linux, etc.

                > I suppose you know how to cleanup Make_cyg.mak. Unfortunately it doesn't
                > mention who has been working on this (must be several people). Any comments
                > from them?

                Since `Make_cyg.mak' is just for creating a native Windows application
                I will not touch that file because it's not falling into my expertise.
                A native Cygwin application should be created by using the UNIX
                Makefiles.

                > > Cygwin is a UNIX porting layer which allows typically to build
                > > applications from the UNIX build process in a UNIX-like build
                > > environment. There's no need to create a separate Makefile for
                > > Cygwin. A Cygwin vim uses only POSIX system calls except
                > > when compiled as GVIM for the Win32 GUI.
                > >
                > > Since I'm the maintainer for Vim in the Cygwin net distribution
                > > I would like to keep the UNIX way of building things.
                >
                > The question is why you would want to do this. It probably makes the
                > executable larger, perhaps problems with file names, etc. What would be the
                > advantage?

                As I described above. Cygwin is a whole POSIX layer like U/WIN,
                Interix, MKS, it's just open source. The net distribution contains
                a whole lot of UNIX tools for development (gcc, gdb, ...), shells
                (ash, bash, tcsh), OpenSSH, inetd, a database (postgreSQL), TeX,
                mutt and much much more. Vim-5.8 is already part of that environment
                as well.

                Ask former UNIX guys which are stuck on Windows due to their
                employers policy about working only in a native Windows environment...

                > > Currently vim-6.0ap build OOTB from the UNIX Makefile except for
                > > the above `WIN32_LEAN_AND_MEAN' problem and the `SUFFIX' part in
                > > the Makefile.
                >
                > That's a good sign, both for Vim being portable and for Cygwin being able to
                > compile this rather complex program.

                I just found an issue with "\" vs. "/". At one point Vim-6.0 seems
                to call a Windows function for file access instead of the standard
                UNIX functions so that a path

                $ vim machine/setjmp.h

                doesn't open the file but

                $ vim machine\\setjmp.h

                does. I have to debug that.

                > > > is a reason not to use AC_EXEEXT. It's just that nobody suggested this
                > > > until now. If you can make a patch for it and test it, that's welcome.
                > >
                > > I'm a bit spare on time but I will try to do this in a week or two.
                >
                > I notice it's just a matter of including AC_EXEEXT in configure.in and
                > defining EXEEXT in config.mk.in in the usual way. Oh, and rename SUFFIX to
                > EXEEXT in Makefile, that's clearer anyway. I'll add it and we can test it
                > with the next version. Looks harmless if it's empty anyway.

                It's not all, unfortunately. The symlinks (view, ex, ...) are
                currently created with $SUFFIX but they should be created w/o
                the suffix. Only the real executables should have the ".exe".
                It doesn't disturb Cygwin but it's not usual (lame excuse).

                Thanks,
                Corinna

                --
                Corinna Vinschen
                Cygwin Developer
                Red Hat, Inc.
                mailto:vinschen@...
              • Bram Moolenaar
                ... OK, I get the idea. There are two ways to compile Vim with Cygwin and the results are both useful, but in a different way. I ll add a remark in the
                Message 7 of 22 , Aug 1, 2001
                • 0 Attachment
                  Corinna Vinschen wrote:

                  > No. A native Windows port is a different thing. Cygwin provides
                  > stuff in it's environment which isn't available under Windows,
                  > for example mount points, symbolic links and so on. If you
                  > compile a vim for native Windows it doesn't have access to this
                  > POSIX environment. You can Cygwin handle as another UNIX target
                  > like Sun, OpenBSD, Linux, etc.

                  OK, I get the idea. There are two ways to compile Vim with Cygwin and the
                  results are both useful, but in a different way. I'll add a remark in the
                  Make_cyg.mak file about this.

                  > I just found an issue with "\" vs. "/". At one point Vim-6.0 seems
                  > to call a Windows function for file access instead of the standard
                  > UNIX functions so that a path
                  >
                  > $ vim machine/setjmp.h
                  >
                  > doesn't open the file but
                  >
                  > $ vim machine\\setjmp.h
                  >
                  > does. I have to debug that.

                  Strange, since Windows functions also allow using a forward slash. That
                  shouldn't be a problem, unless calling an external program, where the slash is
                  used for options. I would expect problems with backslashes, since the Unix
                  version handles them differently.

                  > > > > is a reason not to use AC_EXEEXT. It's just that nobody suggested
                  > > > > this until now. If you can make a patch for it and test it, that's
                  > > > > welcome.
                  > > >
                  > > > I'm a bit spare on time but I will try to do this in a week or two.
                  > >
                  > > I notice it's just a matter of including AC_EXEEXT in configure.in and
                  > > defining EXEEXT in config.mk.in in the usual way. Oh, and rename SUFFIX
                  > > to EXEEXT in Makefile, that's clearer anyway. I'll add it and we can test
                  > > it with the next version. Looks harmless if it's empty anyway.
                  >
                  > It's not all, unfortunately. The symlinks (view, ex, ...) are
                  > currently created with $SUFFIX but they should be created w/o
                  > the suffix. Only the real executables should have the ".exe".
                  > It doesn't disturb Cygwin but it's not usual (lame excuse).

                  I wonder how you make symlinks at all, since Windows doesn't have them. I
                  have cygwin 1.0, but I can't find a reference to symlinks.

                  I'll use $(LNKEXT) for the targets used with symbolic links. Keeping it empty
                  by default should work then. Example:

                  VIMTARGET = $(VIMNAME)$(EXEEXT)
                  EVIEWTARGET = $(EVIEWNAME)$(LNKEXT)

                  ln -s $(VIMTARGET) $(EVIEWTARGET)

                  --
                  hundred-and-one symptoms of being an internet addict:
                  100. The most exciting sporting events you noticed during summer 1996
                  was Netscape vs. Microsoft.

                  /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                  ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                  \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                • Corinna Vinschen
                  ... I began to debug that and it s not related to backslash issues. It has something to do with fchdir() but I haven t got what the whole function
                  Message 8 of 22 , Aug 1, 2001
                  • 0 Attachment
                    On Wed, Aug 01, 2001 at 08:48:20PM +0200, Bram Moolenaar wrote:
                    >
                    > Corinna Vinschen wrote:
                    >
                    > > No. A native Windows port is a different thing. Cygwin provides
                    > > stuff in it's environment which isn't available under Windows,
                    > > for example mount points, symbolic links and so on. If you
                    > > compile a vim for native Windows it doesn't have access to this
                    > > POSIX environment. You can Cygwin handle as another UNIX target
                    > > like Sun, OpenBSD, Linux, etc.
                    >
                    > OK, I get the idea. There are two ways to compile Vim with Cygwin and the
                    > results are both useful, but in a different way. I'll add a remark in the
                    > Make_cyg.mak file about this.
                    >
                    > > I just found an issue with "\" vs. "/". At one point Vim-6.0 seems
                    > > to call a Windows function for file access instead of the standard
                    > > UNIX functions so that a path
                    > >
                    > > $ vim machine/setjmp.h
                    > >
                    > > doesn't open the file but
                    > >
                    > > $ vim machine\\setjmp.h
                    > >
                    > > does. I have to debug that.
                    >
                    > Strange, since Windows functions also allow using a forward slash. That
                    > shouldn't be a problem, unless calling an external program, where the slash is
                    > used for options. I would expect problems with backslashes, since the Unix
                    > version handles them differently.

                    I began to debug that and it's not related to backslash issues.
                    It has something to do with fchdir() but I haven't got what the
                    whole function `os_unix.c::mch_FullName()' is doing. It has called
                    a fchdir() which returned 0 (and actually has changed the cwd) but
                    a few lines later it calls mch_chdir() which again tries to chdir
                    to the same directory which obviously failes now... As I said, I'm
                    not in a state where I actually understand the code here...

                    > > > > > is a reason not to use AC_EXEEXT. It's just that nobody suggested
                    > > > > > this until now. If you can make a patch for it and test it, that's
                    > > > > > welcome.
                    > > > >
                    > > > > I'm a bit spare on time but I will try to do this in a week or two.
                    > > >
                    > > > I notice it's just a matter of including AC_EXEEXT in configure.in and
                    > > > defining EXEEXT in config.mk.in in the usual way. Oh, and rename SUFFIX
                    > > > to EXEEXT in Makefile, that's clearer anyway. I'll add it and we can test
                    > > > it with the next version. Looks harmless if it's empty anyway.
                    > >
                    > > It's not all, unfortunately. The symlinks (view, ex, ...) are
                    > > currently created with $SUFFIX but they should be created w/o
                    > > the suffix. Only the real executables should have the ".exe".
                    > > It doesn't disturb Cygwin but it's not usual (lame excuse).
                    >
                    > I wonder how you make symlinks at all, since Windows doesn't have them. I
                    > have cygwin 1.0, but I can't find a reference to symlinks.

                    The current Cygwin 1.3.2 version can create symlinks in two
                    different ways. The old method (already supported by 1.0)
                    creates regular files with a special content (a magic cookie
                    and the actual target path) and which has the `system' bit
                    set in the file attributes. This type of symlinks is only
                    recognized by native Cygwin apps.

                    The second way is by creating Windows shortcuts (*.lnk files)
                    with a special content and the R/O bit set. Native Cygwin apps
                    will not see the .lnk extension and native Windows apps are
                    able to use the links as normal Windows shortcuts.

                    > I'll use $(LNKEXT) for the targets used with symbolic links. Keeping it empty
                    > by default should work then. Example:
                    >
                    > VIMTARGET = $(VIMNAME)$(EXEEXT)
                    > EVIEWTARGET = $(EVIEWNAME)$(LNKEXT)
                    >
                    > ln -s $(VIMTARGET) $(EVIEWTARGET)

                    Yes. That's what I meant. Thank you!

                    Corinna

                    --
                    Corinna Vinschen
                    Cygwin Developer
                    Red Hat, Inc.
                    mailto:vinschen@...
                  • Corinna Vinschen
                    ... Yep, it s a good reason to stuck with Make_cyg.mak. It s just that this isn t what I m maintaining so I keep my hands from that file. ... Thanks :-) ...
                    Message 9 of 22 , Aug 1, 2001
                    • 0 Attachment
                      On Wed, Aug 01, 2001 at 11:09:25AM -0400, Dan Sharp wrote:
                      >
                      > >The Make_cyg.mak file looks as if somebody wants to only use
                      > >Cygwin's gcc to create a native Windows application instead
                      > >of a Cygwin application.
                      >
                      > Exactly. Some people may have Cygwin gcc installed as their only compiler
                      > and want to compile a native Windows gvim. Instead of having to download a
                      > whole new compiler (like MingW or Borland 5.5) or always have an X-server
                      > running to use the Athena or GTK version, they can just use
                      > Make_cyg.mak. Granted, Make_cyg.mak may not be the cleanest
                      > implementation, but it works well enough.

                      Yep, it's a good reason to stuck with Make_cyg.mak. It's just that
                      this isn't what I'm maintaining so I keep my hands from that file.

                      > >Since I'm the maintainer for Vim in the Cygwin net distribution
                      > >I would like to keep the UNIX way of building things.
                      >
                      > I knew I recognized your name from somewhere! :) The Cygwin SSHD server is
                      > the only remote-access service I run on my Win2k machine anymore. Adding
                      > cygrunserv was very helpful, too! Thanks for all the work!

                      Thanks :-)

                      > >Currently vim-6.0ap build OOTB from the UNIX Makefile except for
                      > >the above `WIN32_LEAN_AND_MEAN' problem and the `SUFFIX' part in
                      > >the Makefile.
                      >
                      > Are you going to be including gvim in the vim 6.0 Cygwin distribution?

                      Probably not. At least not if my time slices for such stuff keep
                      as thin as currently. I will concentrate on a clean non-GUI
                      version for the Cygwin net distribution first. Sure I would
                      like to have a Cygwin gvim as well but which version should I
                      build, a native Windows GUI or a version for Cygwin-XFree86?

                      I think if Cygwin-XFree86 will become part of the net distro
                      once, that's the way to go but that's only _my_ opinion. I
                      can already see heated debates...

                      Corinna

                      --
                      Corinna Vinschen
                      Cygwin Developer
                      Red Hat, Inc.
                      mailto:vinschen@...
                    • Corinna Vinschen
                      ... Ok, got it. It s a buggy implementation of fchdir() in Cygwin which doesn t correctly handle changing to relative paths under all circumstances. Since I
                      Message 10 of 22 , Aug 1, 2001
                      • 0 Attachment
                        On Wed, Aug 01, 2001 at 09:16:21PM +0200, Corinna Vinschen wrote:
                        > I began to debug that and it's not related to backslash issues.
                        > It has something to do with fchdir() but I haven't got what the
                        > whole function `os_unix.c::mch_FullName()' is doing. It has called
                        > a fchdir() which returned 0 (and actually has changed the cwd) but
                        > a few lines later it calls mch_chdir() which again tries to chdir
                        > to the same directory which obviously failes now... As I said, I'm
                        > not in a state where I actually understand the code here...

                        Ok, got it. It's a buggy implementation of fchdir() in Cygwin
                        which doesn't correctly handle changing to relative paths under
                        all circumstances. Since I have implemented fchdir() in Cygwin
                        I have to blame myself.

                        Probably it would be the best way to stuck with chdir() (not
                        defining HAVE_FCHDIR for Cygwin even if the function is
                        available) for two reasons.

                        - fchdir() is currently implemented only in the Cygwin developer
                        snapshots. Even the current official Cygwin release (1.3.2)
                        doesn't have it.
                        - It's incorrect as aforementioned. I have to rethink the implementation
                        somehow...

                        Corinna

                        --
                        Corinna Vinschen
                        Cygwin Developer
                        Red Hat, Inc.
                        mailto:vinschen@...
                      • Bram Moolenaar
                        Dan - ... Thanks for verifying that. I can imagine the OLE version needs some extra header files. gui_w48 must also use something that requires an extra
                        Message 11 of 22 , Aug 1, 2001
                        • 0 Attachment
                          Dan -

                          > >This makes me wonder when WIN32_LEAN_AND_MEAN has to be defined. In
                          > >several files where windows.h is included it is used, in others it is not.
                          > >What is the rule for using it?
                          >
                          > I tried a quick test and stuck #define WIN32_LEAN_AND_MEAN in front of
                          > every call to #include <windows.h> and it breaks compilation of if_ole.cpp
                          > and gui_w48.c. Removing it from if_ole.cpp fixed that problem, and
                          > removing it from gui.h fixed the gui_w48.c problem (removing it from
                          > gui_w48.c didn't help. I guess since it was already done in gui.h, the
                          > #include <windows.h> in gui_w48.c is a little redundant, at least for
                          > win32). It looks like the idea behind it is to speed up compilation time
                          > by not reading in the lesser used header files. I didn't see any change in
                          > code size, and didn't really pay attention to compile time differences.

                          Thanks for verifying that. I can imagine the OLE version needs some extra
                          header files. gui_w48 must also use something that requires an extra header
                          file (resolving the .lnk file perhaps?).

                          I'll include the define in the places where it's possible, not in a global
                          place. Will do some more testing later (it might depend on the features
                          included).

                          - Bram

                          --
                          hundred-and-one symptoms of being an internet addict:
                          103. When you find yourself in the "Computer" section of Barnes & Noble
                          enjoying yourself.

                          /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                          ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                          \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                        • Bram Moolenaar
                          ... mch_FullName() expands a path name to an absolute path. Thus it becomes independent of changing directory. The fchdir() doesn t change directory the first
                          Message 12 of 22 , Aug 1, 2001
                          • 0 Attachment
                            Corinna Vinschen wrote:

                            > I began to debug that and it's not related to backslash issues.
                            > It has something to do with fchdir() but I haven't got what the
                            > whole function `os_unix.c::mch_FullName()' is doing. It has called
                            > a fchdir() which returned 0 (and actually has changed the cwd) but
                            > a few lines later it calls mch_chdir() which again tries to chdir
                            > to the same directory which obviously failes now... As I said, I'm
                            > not in a state where I actually understand the code here...

                            mch_FullName() expands a path name to an absolute path. Thus it becomes
                            independent of changing directory.

                            The fchdir() doesn't change directory the first time, it's used to remember
                            the current directory ".". The mch_chdir() then changes directory and another
                            fchdir() takes us back to the old current directory. This works fine on Unix,
                            perhaps the special handling of directories under Cygwin has some problems
                            with this construction.

                            > > I wonder how you make symlinks at all, since Windows doesn't have them. I
                            > > have cygwin 1.0, but I can't find a reference to symlinks.
                            >
                            > The current Cygwin 1.3.2 version can create symlinks in two
                            > different ways. The old method (already supported by 1.0)
                            > creates regular files with a special content (a magic cookie
                            > and the actual target path) and which has the `system' bit
                            > set in the file attributes. This type of symlinks is only
                            > recognized by native Cygwin apps.

                            Ah, a trick. That doesn't explain why the ".exe" can't be added though.

                            > The second way is by creating Windows shortcuts (*.lnk files)
                            > with a special content and the R/O bit set. Native Cygwin apps
                            > will not see the .lnk extension and native Windows apps are
                            > able to use the links as normal Windows shortcuts.

                            Even more complicated trick (the .lnk file format is undocumented, at least we
                            couldn't find it). I suppose that .lnk extention is the reason we can't use
                            .exe.

                            --
                            hundred-and-one symptoms of being an internet addict:
                            104. When people ask about the Presidential Election you ask "Which country?"

                            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                            ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                            \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                          • Denis (work)
                            ..snip.. ... ..snip.. ... ah, i would pay to have some ms windows programmers around here, and hear them say something similar about some things in that other
                            Message 13 of 22 , Aug 1, 2001
                            • 0 Attachment
                              ..snip..

                              | Since I have implemented fchdir() in Cygwin
                              | I have to blame myself.


                              ..snip..

                              | - It's incorrect as aforementioned. I have to rethink the implementation
                              | somehow...


                              ah, i would pay to have some ms windows programmers around
                              here, and hear them say something similar about some things
                              in that other OS :)

                              denis

                              ps. dont get me wrong, i like windows and all...

                              --

                              /*
                              * Denis Perelyubskiy
                              * icq : 12359698
                              * mailto: denisp@...
                              * PGP : http://www.cs.ucla.edu/~denisp/files/pgp.asc
                              */
                            • Corinna Vinschen
                              ... You can read and write them using COM functions. ... Sorry if that was unclear in my first mail. The .exe extensions are no problem anymore for the current
                              Message 14 of 22 , Aug 1, 2001
                              • 0 Attachment
                                On Wed, Aug 01, 2001 at 10:43:13PM +0200, Bram Moolenaar wrote:
                                > > The second way is by creating Windows shortcuts (*.lnk files)
                                > > with a special content and the R/O bit set. Native Cygwin apps
                                > > will not see the .lnk extension and native Windows apps are
                                > > able to use the links as normal Windows shortcuts.
                                >
                                > Even more complicated trick (the .lnk file format is undocumented, at least we
                                > couldn't find it).

                                You can read and write them using COM functions.

                                > I suppose that .lnk extention is the reason we can't use
                                > .exe.

                                Sorry if that was unclear in my first mail. The .exe extensions
                                are no problem anymore for the current implementation of the symlink
                                code but IIRC they were a problem a few months ago and they are
                                somehow *gulp* unaesthetic. The symlinks to executables don't
                                have a .exe suffix in the whole net distro, so...

                                Corinna

                                --
                                Corinna Vinschen
                                Cygwin Developer
                                Red Hat, Inc.
                                mailto:vinschen@...
                              • Corinna Vinschen
                                ... Hey, I like Windows NT/W2K as it is! I wouldn t have that fun working on Cygwin if Windows would be perfect ;-) OTOH, don t talk about 9x/ME... Corinna --
                                Message 15 of 22 , Aug 1, 2001
                                • 0 Attachment
                                  On Wed, Aug 01, 2001 at 01:54:53PM -0700, Denis (work) wrote:
                                  >
                                  > ..snip..
                                  >
                                  > | Since I have implemented fchdir() in Cygwin
                                  > | I have to blame myself.
                                  >
                                  >
                                  > ..snip..
                                  >
                                  > | - It's incorrect as aforementioned. I have to rethink the implementation
                                  > | somehow...
                                  >
                                  >
                                  > ah, i would pay to have some ms windows programmers around
                                  > here, and hear them say something similar about some things
                                  > in that other OS :)
                                  >
                                  > denis
                                  >
                                  > ps. dont get me wrong, i like windows and all...

                                  Hey, I like Windows NT/W2K as it is! I wouldn't have that fun
                                  working on Cygwin if Windows would be perfect ;-)

                                  OTOH, don't talk about 9x/ME...

                                  Corinna

                                  --
                                  Corinna Vinschen
                                  Cygwin Developer
                                  Red Hat, Inc.
                                  mailto:vinschen@...
                                • Thore B. Karlsen
                                  ... But they do, maybe not so often in public, but they do. When I was up at Microsoft the developers weren t brainwashed to the extent one would think. The
                                  Message 16 of 22 , Aug 1, 2001
                                  • 0 Attachment
                                    On Wed, 1 Aug 2001 13:54:53 -0700, you wrote:

                                    >| - It's incorrect as aforementioned. I have to rethink the implementation
                                    >| somehow...

                                    >ah, i would pay to have some ms windows programmers around
                                    >here, and hear them say something similar about some things
                                    >in that other OS :)

                                    But they do, maybe not so often in public, but they do. When I was up at
                                    Microsoft the developers weren't brainwashed to the extent one would
                                    think. The users, on the other hand. :)
                                  • Corinna Vinschen
                                    ... I have further investigated that problem and I have fixed fchdir() in the Cygwin CVS repository. However, since the current official and previous releases
                                    Message 17 of 22 , Aug 3, 2001
                                    • 0 Attachment
                                      On Wed, Aug 01, 2001 at 10:31:38PM +0200, Corinna Vinschen wrote:
                                      > Ok, got it. It's a buggy implementation of fchdir() in Cygwin
                                      > which doesn't correctly handle changing to relative paths under
                                      > all circumstances. Since I have implemented fchdir() in Cygwin
                                      > I have to blame myself.
                                      >
                                      > Probably it would be the best way to stuck with chdir() (not
                                      > defining HAVE_FCHDIR for Cygwin even if the function is
                                      > available) for two reasons.
                                      >
                                      > - fchdir() is currently implemented only in the Cygwin developer
                                      > snapshots. Even the current official Cygwin release (1.3.2)
                                      > doesn't have it.
                                      > - It's incorrect as aforementioned. I have to rethink the implementation
                                      > somehow...

                                      I have further investigated that problem and I have fixed fchdir()
                                      in the Cygwin CVS repository. However, since the current official
                                      and previous releases don't have fchdir() at all, I think it's better
                                      to not use fchdir() for Cygwin to keep backward compatibility.

                                      For that reason I would like to propose the following patch to
                                      `configure.in' which results in skipping the fchdir check when
                                      configuring for Cygwin:

                                      --- configure.in.ORIG Fri Aug 3 13:16:07 2001
                                      +++ configure.in Fri Aug 3 13:15:57 2001
                                      @@ -59,6 +59,13 @@ case `uname` in
                                      QNX=no; AC_MSG_RESULT(no);;
                                      esac

                                      +dnl If Cygwin is found, assume we don't want to use fchdir to be
                                      +dnl backward compatible to versions before 1.3.3
                                      +AC_MSG_CHECKING(for Cygwin)
                                      +case `uname` in
                                      + CYGWIN*) ac_cv_func_fchdir=no;;
                                      +esac
                                      +
                                      AC_SUBST(OS_EXTRA_SRC)
                                      AC_SUBST(OS_EXTRA_OBJ)


                                      Corinna

                                      --
                                      Corinna Vinschen
                                      Cygwin Developer
                                      Red Hat, Inc.
                                      mailto:vinschen@...
                                    • Bram Moolenaar
                                      ... OK. But it s a bit strange to do this in configure. I rather do this in vim.h. How about this instead: ... *************** ... # if (SIZEOF_INT == 0)
                                      Message 18 of 22 , Aug 3, 2001
                                      • 0 Attachment
                                        Corinna Vinschen wrote:

                                        > I have further investigated that problem and I have fixed fchdir()
                                        > in the Cygwin CVS repository. However, since the current official
                                        > and previous releases don't have fchdir() at all, I think it's better
                                        > to not use fchdir() for Cygwin to keep backward compatibility.
                                        >
                                        > For that reason I would like to propose the following patch to
                                        > `configure.in' which results in skipping the fchdir check when
                                        > configuring for Cygwin:

                                        OK. But it's a bit strange to do this in configure. I rather do this in
                                        vim.h. How about this instead:

                                        *** vim.h~ Fri Aug 3 15:55:26 2001
                                        --- vim.h Fri Aug 3 17:41:05 2001
                                        ***************
                                        *** 37,42 ****
                                        --- 37,49 ----
                                        # if (SIZEOF_INT == 0)
                                        Error: configure did not run properly. Check auto/config.log.
                                        # endif
                                        +
                                        + /*
                                        + * Cygwin may have fchdir(), but in most versions it doesn't work well.
                                        + */
                                        + # if defined(__CYGWIN32__) && defined(HAVE_FCHDIR)
                                        + # undef HAVE_FCHDIR
                                        + # endif
                                        #endif

                                        #ifdef __EMX__ /* hand-edited config.h for OS/2 with EMX */

                                        --
                                        hundred-and-one symptoms of being an internet addict:
                                        145. You e-mail your boss, informing him you'll be late.

                                        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                        ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                                        \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
                                      • Corinna Vinschen
                                        ... I m usually trying to solve such problems in the configuring to minimize target dependent code. If you like the below solution more, that s ok with me. I
                                        Message 19 of 22 , Aug 3, 2001
                                        • 0 Attachment
                                          On Fri, Aug 03, 2001 at 05:49:24PM +0200, Bram Moolenaar wrote:
                                          > OK. But it's a bit strange to do this in configure. I rather do this in
                                          > vim.h. How about this instead:

                                          I'm usually trying to solve such problems in the configuring to
                                          minimize target dependent code. If you like the below solution
                                          more, that's ok with me. I would like to see another comment,
                                          though. As I said, fchdir() is only implemented in the developers
                                          version and not in an official release. So not using fchdir()
                                          is mainly to keep backward compatibility even if the next Cygwin
                                          release is out. And, btw., due to restrictions of the Win32 API
                                          the fchdir() function is actually slower than chdir()...

                                          Corinna

                                          >
                                          > *** vim.h~ Fri Aug 3 15:55:26 2001
                                          > --- vim.h Fri Aug 3 17:41:05 2001
                                          > ***************
                                          > *** 37,42 ****
                                          > --- 37,49 ----
                                          > # if (SIZEOF_INT == 0)
                                          > Error: configure did not run properly. Check auto/config.log.
                                          > # endif
                                          > +
                                          > + /*
                                          > + * Cygwin may have fchdir(), but in most versions it doesn't work well.

                                          + * Only newer Cygwin releases have fchdir(). We don't use it to
                                          + * keep the binary backward compatible.

                                          > + */
                                          > + # if defined(__CYGWIN32__) && defined(HAVE_FCHDIR)
                                          > + # undef HAVE_FCHDIR
                                          > + # endif
                                          > #endif
                                          >
                                          > #ifdef __EMX__ /* hand-edited config.h for OS/2 with EMX */
                                          >
                                          > --
                                          > hundred-and-one symptoms of being an internet addict:
                                          > 145. You e-mail your boss, informing him you'll be late.
                                          >
                                          > /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
                                          > ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
                                          > \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///

                                          --
                                          Corinna Vinschen
                                          Cygwin Developer
                                          Red Hat, Inc.
                                          mailto:vinschen@...
                                        Your message has been successfully submitted and would be delivered to recipients shortly.