Please Help!! Calling Socket function in a dll file (that is created using cygwin library), by a Microsoft Visual C++ program resulting in infinite loop

kalasad mailu
Wed May 9 23:56:00 GMT 2007

Thanks for all your answers. I appreciate it. I have few more questions.

I used the socket.h file provided by cygwin(/usr/include/cygwin/.) and
wrote a program to create socket, made this a dll file and used this
dll in VC++.

I assume using of the socket.h( form cygwin) did all the conversion
form the linux system calls to the windows system calls and made my
socket program work. Please correct me if my understanding is wrong.

Now I want to try the same process for simple c++ functions like
"cout". I don't find any cygwin header files like iostream.h or
stream.h in the cygwin directory.

When I created this stand alone program.

#include <iostream>

int main () {
    std::cout << "Hello World\n";
    return 0;

I guess this picked the header file from
"cygwin\lib\gcc\i686-pc-cygwin\3.4.4\include\c++\" (a gcc header file)

Is there no iostream header file by cygwin (/usr/include/cygwin)?

I am running into header file conflict when I also include both cygwin
header files and the gcc header files. How to solve the conflict?

Is it possible to make a dll that uses the functions defined by the
gcc header file(***not the cygwin header file i.e. present in
(/usr/include/cygwin)***) and use it in the MSVC++?

The below question doesn't have any relation with the above mention context:

If including the header file from gcc works then why is cygwin
providing separate header files(like stdio.h, stdlib.h and etc in

-Thanks again.

On 5/8/07, Brian Dessent <> wrote:
> kalasad mailu wrote:
> > I read the following from the how-cygtls-works.txt
> >
> > "If you load cygwin1.dll dynamically from a non-cygwin application, it is
> >   vital that the bottom CYGTLS_PADSIZE bytes of the stack are not in use
> >   before you call cygwin_dll_init()"
> >
> > How do I make sure bottom CYGTLS_PADSIZE bytes of the stack are not in use
> > before you call cygwin_dll_init()"
> >
> > I could not find any information at: winsup/testsuite/cygload
> The files and cygload.h are in winsup/testsuite/winsup.api.
> They show a pretty complete example of how to dynamically load the DLL
> and deal with the stack and signals.  There are several general ways to
> make sure the bottom of the stack contains the scratch space, in roughly
> ascending order of ease/quality:
> - Reserve the space at the earliest possibility in the CRT startup
> objects (this is how native Cygwin apps do it, or rather how they don't
> have to worry about it)
> - Change the entry point to your custom routine that saves the state of
> whatever is at the bottom of the stack (hopefully nothing or close to
> nothing, since this is very early in the init sequence), replaces the
> bottom of the stack with your scratch/padding, calls the stock entry
> point, and after that returns restores the previous contents at the
> bottom of the stack.  This is how cygload does it, using the neat
> feature of C++ ctors and dtors to take care of some of the housekeeping.
> - If you can't do either of the above then you roughly do the same thing
> but at a later point in execution, e.g. by wrapping main() (or WinMain
> or DllMain or ....) or even by initializing/deinitialzing your scratch
> space as the first and last things in main(), etc.  (Look in CVS at
> older versions of cygload which did it with less finesse this way.)
> It's all still the same concept though, just with various amounts of
> already existing stuff (from zero to lots) at the base of the stack when
> your routine gets called.
> Note about terminology, the scratch space needs to exist at the bottom
> of the stack in logical terms, i.e. the very first n bytes pushed on the
> stack.  But because on x86 the stack grows down this scratch space will
> be at the numerically highest address.  Don't get confused though, it
> all essentially amounts to just being the first to allocate a large auto
> char[] array; or faking it by manipulating the stack pointer directly if
> you aren't the first in line to touch the stack, and saving the state of
> whatever was there before you so you can restore it before ceding
> control back to whoever called you.
> Brian
> --
> Unsubscribe info:
> Problem reports:
> Documentation:
> FAQ:         

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list