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
