Hi! When starting to port Gentoo Prefix to Cygwin, the first real problem discovered is that fork() does use the original executable's location to Create the child's Process, probably finding linked dlls that just have emerged in the current directory (sth. like /my/prefix/usr/bin), causing "Loaded different DLL with same basename in forked child" errors. Diving into the details, I'm coming up with (a patch-draft based on) the idea to create hardlinks for the binaries-in-use into some cygwin-specific directory, like \proc\\object\ ('ve seen this name on AIX), and use these hardlinks instead to create the new child's process. Thoughts so far? For now, when \proc\ directory does exist, the patch (roughly) does: For /bin/bash.exe, cygwin1.dll creates these hardlinks at process startup: \proc\\object\bash.exe -> /bin/bash.exe \proc\\object\bash.exe.local (empty file for dll redirection) \proc\\object\cygwin1.dll -> /bin/cygwin1.dll \proc\\object\cygreadline7.dll -> /bin/cygreadline7.dll And frok::parent then does: CreateProcess("\proc\\object\bash.exe", "/bin/bash.exe", ...) Resulting in another \proc\\object\ directory with same hardlinks. While attached patch does work so far already, there's a few issues: *) dll-redirection for LoadLibrary using "app.exe.local" file does operate on the dll's basename only, breaking perl's Hash::Util and List::Util at least. So creating hardlinks for dynamically loaded dlls is disabled for now. Eventually, manifests and/or app.exe.config could help here, but I'm still failing to really grok them... *) Who can clean up \proc\\ directory after power-loss or similar? For now, if stale \proc\\ is found, it is removed beforehand. But when this was from a different user, cleanup will fail. However, using \proc\S-\\ instead could help here... *) Is it really necessary to create these hardlinks in the real filesystem? I could imagine to create them directly in $Recycle.bin instead, or some (other) memory-only thing... Thoughts welcome! Thank you! /haubi/