[Patch] Loading cygwin1.dll from MinGW and MSVC

Christopher Faylor cgf-no-personal-reply-please@cygwin.com
Mon Jun 6 19:52:00 GMT 2005


On Mon, Jun 06, 2005 at 03:40:10PM -0400, Igor Pechtchanski wrote:
>On Mon, 6 Jun 2005, Christopher Faylor wrote:
>
>> I fat fingered my response to Max, ended up sending a personal message
>> and never noticed until I received a personal reply from him.  I, of
>> course, asked him not to send me personal email which was pretty
>> confusing since I'd previously just sent him a personal reply.
>>
>> Translation:  I am a maroon.
>>
>> Anywhay this is what should have gone out days ago.
>>
>> On Fri, Jun 03, 2005 at 03:58:09PM -0700, Max Kaehn wrote:
>> >This patch contains the changes to make it possible to dynamically load
>> >cygwin1.dll from MinGW and MSVC applications.  The changes to dcrt0.cc are
>> >minimal and only affect cygwin_dll_init().  I've also added a MinGW test
>> >program to testsuite and a FAQ so people will be able to locate the
>> >test program easily.
>> >
>> >I wrote how-cygtls-works.txt because it took me a while to figure out how it
>> >was storing the information, and I hope I can save someone else the effort in
>> >the future.  (I had no idea Windows was still using segment registers!)
>> >I hope I got the copyright message right for it.
>>
>> Wow! That's great! Thanks for doing this.  It is much appreciated.  This
>> is something that I had been meaning to do and you did a better job than
>> I would have.  This truly deserves a gold star.  I know that understanding
>> the cygtls stuff could not have been easy.
>>
>> Can I get a gold star over here for this truly heroic effort?
>
>One(?) gold star coming up.  What's it for, though -- the changes that
>enable dynamically loading cygwin1.dll, or how-cygtls-works.txt?

For now:  how-cygtls-works.txt.

>> I have checked in everything but the test suite stuff.  I would like to
>> see some changes there:
>>
>> 1) Use '.cc' rather than '.cpp' for the extension to be consistent with
>> the rest of winsup.
>>
>> 2) Use the same formatting that is used throughout cygwin for brace
>> placement, etc.
>>
>> 3) Submit the new files as diffs against /dev/null so that I can apply
>> like a normal patch.
>>
>> Did you consider other ways of dealing with the need for space at the
>> bottom of the stack?
>>
>> Having an interface which requires a "main" function name so that you'd
>> do something like:
>>
>> int
>> main (int argc, char **argv)
>> {
>>   initialize_cygwin (rest_of_main, argc, argv);
>>   /* never returns */
>> }
>>
>> int
>> rest_of_main (argc, argv)
>> {
>>   /* do main stuff */
>>   .
>>   .
>>   .
>>   exit or return here
>> }
>>
>> And in cygwin initialize_cygwin would look something like:
>>
>> void
>> initialize_cygwin (int (*) main, int argc, char **argv)
>> {
>>   struct _cygtls dummy_tls;
>>   initialize_main_tls (&dummy_tls);
>>   cygwin_dll_init ();
>>   exit (main (argc, argv));
>
>Did you mean "exit (rest_of_main (argc, argv));" here?

No.  I meant to use the function that was passed in, i.e.  main,
although maybe it would be safer not to call it "main".  This is a DLL
routine that wouldn't know about rest_of_main.

As Max points out, though, this does stand the chance of nuking argv,
though, so that would have to be copied before before initialize_main_tls was
called:

i.e., something like (modulo typos):

  void
  initialize_cygwin (int (*main) (int argc, char **argv), int argc, char **argv)
  {
    struct _cygtls dummy_tls;
    char *newargv = alloca (argc * sizeof (argv[0]));
    for (char **av = newargv; *av; av++)
      *av = *argv++;
    *av = NULL;
    initialize_main_tls (&dummy_tls);
    cygwin_dll_init ();
    exit (main (argc, newargv));
  }

cgf



More information about the Cygwin-patches mailing list