Mail Archives: cygwin-developers/2000/01/26/00:05:12
On Mon, 24 Jan 2000, Chris Faylor wrote:
> It has occurred to me that we could trap the Win32 functions
> which understand paths and slip Cygwin style paths in there.
>
> At the most trivial, we could make a front-end for kernel32.dll
> although I'm sure it wouldn't be that easy.
Hmmm ... I'm trying to understand this. I can see hooking/replacing
selected kernel32 functions in Cygwin DLL and doing pre- and post-
processing before- and after- the real call.
Are you suggesting that you make a replacement for kernel32? Could
you elaborate a bit on your proposal please?
> That would allow much greater functionality for non-cygwin
> applications. So, you could do something like:
>
> notepad /etc/termcap
>
> or
>
> javac //d/foo/var.j
>
> (Hmm. I wonder why I thought of that example)
>
I know you can hook specific API functions, but don't know any detail
there. I do know one way -- you can muck with IAT and force your routine
to be called instead, but you need to modify the executable for that
one to work. Also, keep in mind that kernel32 is one of those "Known DLLs"
and who knows what magic that adds.
How about a trivial non-intrusive, albeit partial, solution? Provide a
program, cygrun, that takes the arguments, modifies the arguments that
may be cygwin paths into win32 paths, and executes the command line.
$ cygrun javac //d/foo/var.j
will actually result in the equivalent of:
$ javac `cygpath -w //d/foo/var.j`
If you want a slower way, have Cygwin exec check the list of imports and
if Cygwin is not present, modify argv before exec'ing it. Of course, it
assumes you're running under bash.
Regards,
Mumit
- Raw text -