This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Initialising gnuwin DLLs


These are (some of) the functions you can not use unless
you do something like the following

< from libc.info .../cdk/newlib/ >

*Equivalent for errno variable:*
     _errno_r
*Locale functions:*
     _localeconv_r  _setlocale_r
*Equivalents for stdio variables:*
     _stdin_r        _stdout_r       _stderr_r
*Stdio functions:*
     _fdopen_r       _mkstemp_r       _remove_r
     _fopen_r        _mktemp_r        _rename_r
     _getchar_r      _perror_r        _tempnam_r
     _gets_r         _putchar_r       _tmpnam_r
     _iprintf_r         _puts_r          _tmpfile_r
*Signal functions:*
     _raise_r        _signal_r
*Stdlib functions:*
     _dtoa_r         _realloc_r      _strtoul_r
     _free_r         _srand_r        _system_r
     _malloc_r       _strtod_r
     _rand_r         _strtol_r
*String functions:*
     _strtok_r
*System functions:*
     _close_r        _lseek_r        _stat_r
     _fork_r         _open_r         _unlink_r
     _fstat_r        _read_r         _wait_r
     _link_r         _sbrk_r         _write_r
*Time function:*
     _asctime_r

Code for dll's written under cygwin32, that
use the cygwin.dll libc services must initialize struct _reent.

Msvc apps that want to link in these dll's would
have to 
(A) start the link with cygwin's crt0.o (to correctly initialize libc)
(B) link with libcygwin.a themselves (currently not possible except when using my patched ld.exe)
(C) call into each user dll to initialize it's copy of
struct _reent with the values of the exe's copy of
struct _reent.

I thought for a while about retrofitting B18 with
a crt0.o and dllcrt0.o that would handle this automatically.
(yes you have to go through these same hoops
when linking straight cygwin32 apps if you want to
use cygwin.dll libc services in user dll's ;^)

However I couldn't find a win32 function to enumerate the
names of linked in dll's at runtime, so that the dll init
function could be called. (I didn't look REAL hard :)
and the only other way I could think of (reading the .idata
section header of the exe) looked like it would be
a lot of trouble to implement.

Maybe you better look at mingw32 ;^)

On Tue, 3 Feb 1998 14:57:09 GMT, you wrote:

>Dear Mikey,
>
>"struct _reent for each dll needs to be initialized from
>main() before any calls to dll funcs that use the
>std file handles, see the perl5 patch for details."
>
>Thanks for this reply.  Does this mean that for any program
>to use a gnuwin generated DLL, main() needs to know that it is
>a gnuwin DLL and initialise struct _reent?  This would mean 
>that you could not use gnuwin DLLs with code that did not
>know about _reent, I guess.  Could you not can you not 
>intialise _reent from the DLL code - e.g in the
>PROCESS_ATTACH routine - to initialise the Cygwin DLL from
>our new DLL?

Nope thought about that, the dll would have to know the name of the
.exe to get a handle to it, and have a callback function linked in to the .exe
to get the correct values for the exe's _reent passed back to it.
it wouldn't be that hard to write for special circumstances, but
to me it looked like a mess to use as a general solution.

>
>Does anyone have some skeletal code that does this?
>
>Thanks again,
>
>Matthew 


=====================================================
Linux a platform built by, and for users, standing on
the firm legs of reliability, and speed.

Microsoft Windows, a platform without a leg to stand on.

(jeffdbREMOVETHIS@netzone.com)
delete REMOVETHIS from the above to reply
         Mikey
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]