> On Fri, Jan 08, 2010 at 02:50:22PM +0800, pansz wrote:
>>
>> Sergey Khorev 写道:
>>>>
>>>> However, when I load the dll from within win32 gvim.exe, the gvim hangs
>>>> up
>>>> To study the problem, I had made the dll as simple as "hello world". So
>>>> the
>>>
>>> I hope you are not doing hello world in DllMain.
>>> I suspect the problem is not in Vim but rather with Cygwin. So I
>>> suggest to rectify your problem even further:
>>> 1) Create console win32 application which does NOT use Cygwin and uses
>>> your library with LoadLibrary, GetProcAddress. Test whether this works
>>> or not.
>
> As I had a few minutes to spare and found this topic interesting I did what
> Sergey suggested above, and found that if the test application is compiled
> with -mno-cygwin then the LoadLibrary call never returns.
>
> So unless you want to investigate further _why_ LoadLibrary behaves this way
> you have 2 options:
IIRC, cygwin1.dll does extra magic before main() in a cygwin program,
which sets up internally data structures and such to be able to handle
future cygwin dlls. I don't think there's any way to get a cygwin DLL
working in a non-cygwin application. Even if you could get it
working, it certainly wouldn't be supported by the cygwin folks, and
future versions of cygwin might break your hack.
> 1) Use the -mno-cygwin flag when building your .dll, this way you get a
> native win32 .dll. This of course also means that you won't have access to
> any of the POSIX emulation API provided by cygwin.
The -mno-cygwin flag just requests that the application be compiled
with a Win32-targeting mingw compiler on the backend, rather than the
Cygwin-targeting gcc compiler. If you're going to go the route of
creating a Windows DLL using POSIX code, I'd look into mingw instead
of cygwin. Note that the -mno-cygwin flag is going away in new cygwin
versions.
> 2) Use a cygwin-compiled version of vim (e.g. the one available via the
> cygwin-installer)
~Matt
No comments:
Post a Comment