Greetings, Olivia Nelson!
> I need to use unix socket() interface, mingw does not seem to provide
> the following headers:
There's no UNIX interfaces in native applications.
Choose one or another, not both.
> #include
> #include
> #include
> #include
Also, please no top posting in this lis
I need to use unix socket() interface, mingw does not seem to provide
the following headers:
#include
#include
#include
#include
On Sat, Feb 8, 2020 at 1:40 PM Marco Atzeri wrote:
>
> please bottom post on this mailing list
>
> Am 08.02.2020 um 01:12 schrieb Olivia Nelson:
> > Sorry, I made
please bottom post on this mailing list
Am 08.02.2020 um 01:12 schrieb Olivia Nelson:
Sorry, I made a mistake. I've updated the title ..
To summarize:
1. I can load the DLL compiled with cygwin with LoadLibraryA,
but not remotely with CreateRemoteThread.
2. The same DLL compiled with msv
Sorry, I made a mistake. I've updated the title ..
To summarize:
1. I can load the DLL compiled with cygwin with LoadLibraryA,
but not remotely with CreateRemoteThread.
2. The same DLL compiled with msvc works with both LoadLibraryA and
CreateRemoteThread
Answer to Joost:
constructor and de
Does
static void __attribute__((constructor))
static void __attribute__((destructor))
work?
See e.g.
https://stackoverflow.com/questions/2053029/how-exactly-does-attribute-constructor-work
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/
Does
static void __attribute__((constructor))
static void __attribute__((destructor))
work?
See also:
https://stackoverflow.com/questions/2053029/how-exactly-does-attribute-constructor-work
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/
Am 07.02.2020 um 16:07 schrieb Olivia Nelson:
I compile it like this:
gcc dll.c -shared -fPIC -o dll.dll
I tried to run it with LoadLibraryA
But DllMain is not called.
you are building a Cygwin dll, that requires the Cygwin1.dll
but probably do you not intend it and need a standalone one
I compile it like this:
gcc dll.c -shared -fPIC -o dll.dll
I tried to run it with LoadLibraryA
But DllMain is not called.
On Fri, Feb 7, 2020 at 10:49 PM Marco Atzeri wrote:
>
> Am 07.02.2020 um 09:46 schrieb Olivia Nelson:
> > I have a simple C program that output something t
Am 07.02.2020 um 09:46 schrieb Olivia Nelson:
I have a simple C program that output something to DbgView on startup:
#include
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
I have a simple C program that output something to DbgView on startup:
#include
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case
Hello,
Is DllMain() supposed to work with Cygwin and gcc?
If so, could someone share a simple, working example?
I have a relatively simple example that works with mingw, but does not work
with gcc. I could post the example if that is easier.
% uname -a
CYGWIN_NT-6.1-WOW64 CDD-NB01 1.7.30
n libcrypto from
> > OpenSSL (which tries to be portable to more than just POSIX, and has a
> > DllMain() which is built for both cygwin and Win32), and a patch like that
> > at
> > [1] (or perhaps one which avoids DllMain on cygwin entirely) should be
> > applied.
>
y documented.
>
> >> However, it does seem that python (or one of its extensions) is doing
> >> something it shouldn't.
>
> Given the above clarification about cygwin, this is a bug in libcrypto from
> OpenSSL (which tries to be portable to more than just POSIX, and has a
the xDLL automatically by pyDist::Builder [or whatever],
> defining a custom DllMain()...") that's doing something windows-ish,
> when it ought to be doing it unix-ish on cygwin.
>
> E.g. I wonder if this is bigger than just Twisted, or just
> openssl+python/Lib/thread [
ed to be able to call anything you like here
>>> and it isn't clear why a POSIX/UNIX/Linux program would be relying on
>>> DllMain.
Thanks for the clarification.
>> There are cases where cygwin-ish code does win32-ish things, like
>> login.exe, or the PyWin32
ses PyWin32?
>
> The python Twisted stuff works on UNIX systems so there should be no
> reason to use Windows-isms in Cygwin code - especially when the
> Windows-ism *calls* UNIX code. The ability to get into trouble when you
> mix Windows stuff like DllMain with Cygwin stuff is ver
;>> where
>>> some tests just cause python to segfault. It seems to be the same issue
>>> with
>>> libcrypto as reported in [2],[3]
>
>>Actually you aren't supposed to be able to call anything you like here
>>and it isn't clear why a POSIX/UN
issue with
>> libcrypto as reported in [2],[3]
> Actually you aren't supposed to be able to call anything you like here and
> it isn't clear why a POSIX/UNIX/Linux program would be relying on DllMain.
There are cases where cygwin-ish code does win32-ish things, like
login.exe, or
e is attached to [2] as cygwin_crash.zip, referred to in
>msg76086, which shows that manipulating a semaphore in
>DllMain(DLL_THREAD_DETACH) causes a crash.
>
>There is a patch for openssl attached to [1] which makes sense to me. Surely
>the cleanup ERR_remove_state() does should be
that manipulating a semaphore in
DllMain(DLL_THREAD_DETACH) causes a crash.
There is a patch for openssl attached to [1] which makes sense to me. Surely
the cleanup ERR_remove_state() does should be requested using
pthread_cleanup_push() rather using DllMain(DLL_THREAD_DETACH)? But that
doesn't
* Dave Korn wrote, On 03/10/08 15:58:
> Sam Liddicott wrote on 03 October 2008 14:04:
>
>
>> * Dave Korn wrote, On 03/10/08 13:34:
>>
>>> DllMain is special. There's a lot you cannot do in there, in
>>> particular file i/o, printf etc, because
Sam Liddicott wrote on 03 October 2008 14:04:
> * Dave Korn wrote, On 03/10/08 13:34:
>> DllMain is special. There's a lot you cannot do in there, in
>> particular file i/o, printf etc, because you're running inside a lock
>> and it's a sort of critical sec
* Dave Korn wrote, On 03/10/08 14:38:
> Sam Liddicott wrote on 03 October 2008 14:00:
>
>
It crashes when I do the first sendmessage after hooking.
>>> ... with presumably a null pointer dereference?
>>>
>>>
>> it's hard to tell, it's explorer.exe that is crashing.
Sam Liddicott wrote on 03 October 2008 14:00:
>>
>>> It crashes when I do the first sendmessage after hooking.
>>>
>>
>> ... with presumably a null pointer dereference?
>>
> it's hard to tell, it's explorer.exe that is crashing.
... and? Explorer is just a program like any other.
Instal
* Dave Korn wrote, On 03/10/08 13:34:
> DllMain is special. There's a lot you cannot do in there, in particular
> file i/o, printf etc, because you're running inside a lock and it's a sort of
> critical section-y sort of situation, and indeed the MSVC CRT probably is
, you are quite right. I just changed this to
GetModuleHandle("GuiTest.dll"); and it no longer crashes - the hookproc
still isn't called though :-(
> ... and I have a memory that this issue cropped up recently in the context of
> the cygwin dll's DllMain call.
>
&
a handle to the file used
to create the calling process (.exe file)."
... and I have a memory that this issue cropped up recently in the context of
the cygwin dll's DllMain call.
>> I think that DllMain is called when DLL is not yet completely loaded,
>> so it is imposs
;
thanks!
>
>
> I think that DllMain is called when DLL is not yet completely loaded,
> so it is impossible to set values of global variables. Isn't it?
>
Makes sense, but most examples state to store hModule at this point...
however your suggestion was good, and I can now
I'm trying to use the Win32::GuiTest perl module on WinXP SP3.
I installed it under cygwin with something like:
perl -MCPAN -e 'install Win32::GuiTest'
However certain use is failing on the SetWindowHookEx because it is
passing a NULL hModule, which is surprising because dll
29 matches
Mail list logo
