cygwin dll for gvim win32's libcall()?

[pansz]

He vimmers:

Is it possible for win32 gvim.exe to do libcall() for dll created by cygwin?

I've created a simple dll make with cmake 2.6.4 + cygwin 1.7.

The dll works great inside cygwin, i.e. I use cygwin console vim doing
libcall() of the dll works great.

However, when I load the dll from within win32 gvim.exe, the gvim hangs
up (not responding to any user action). I had checked that the dll has
the correct path and cygwin1.dll in the correct position and PATH has
been set.

To study the problem, I had made the dll as simple as "hello world". So
the content of the dll should not be a problem, anyway it works great
inside cygwin console vim.

Any hint? Thanks.

[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.
2) Create win32 windowed application and test it too.

--
Sergey Khorev
http://sites.google.com/site/khorser
Can anybody think of a good tagline I can steal?

[pansz]

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.
> 2) Create win32 windowed application and test it too.

I use cygwin to compile the dll because I have no experience in win32
programming, and I don't know anything about DllMain, LoadLibrary, etc.

My source is written in Linux, when compiled in Linux it generates
lib*.so. When compiled in Cygwin it generates a .dll. The source code
are the same, cmake does everything for me, there's no DllMain function
in the source code.

I know that cygwin compile Linux programs as .exe and it is a Windows
native executable and can be executed like any windows program.

I wonder whether the .dll from cygwin is a windows native dll or not.
the cygwin version of vim loads my .dll without problem while windows
gvim cannot load the .dll.

[Andy Kittner]

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:

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.

2) Use a cygwin-compiled version of vim (e.g. the one available via the
cygwin-installer)

Regards,
Andy
--
Being in the army is like being in the Boy Scouts, except that the
Boy Scouts have adult supervision.
-- Blake Clark

[Matt Wozniski]

On Fri, Jan 8, 2010 at 9:11 AM, Andy Kittner wrote:
> 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