Christopher Faylor wrote:
Hmm. Would that even work?I remember speculating at one point about creating wrappers to the win32 functions like CreateFile, MoveFile, etc. which would understand cygwin paths. You could theoretically modify an .exe to load cygwin1.dll and use the wrapper functions. Or you could use some of Windows hook facilities to do that.
I remember trying, way back when, to provide a checking malloc library on Windows, and then discovering that there was *no* way of intercepting malloc() calls *inside LIBC itself*. In the Windows PE world (unlike the ELF world), a call to a routine that lives inside the same DLL is automatically bound to the local copy without any way to hijack the call.
Thus there's no way to play games with LD_LIBRARY_PATH (or PATH, rather) to load a malloc that'll hijack all calls successfully. And there's definitely nothing like the LD_PRELOAD mechanism to wrap existing pre-linked programs to inject support libraries into the lib list.
So any CreateFile calls inside the windows libraries would always go to the built-in CreateFile.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/