Thu Jun 30 05:00:00 GMT 2005
Igor Pechtchanski wrote:
> Umm, why not? I mean, the mechanism for wrapping DLLs is very different
> than that of wrapping executables (and much more involved), but isn't
> there a possibility of writing a "wrapdll.dll" that looks up the name of
> the DLL in the /etc/alternatives database, dlopen's it, and emulates all
> of its functions somehow? ISTR something like this done in my OS class
> ages ago, but don't recall the exact details. Am I misremembering?
hoo boy. thinking about wrapping dlls makes my hair bleed. I'm gonna
pretend this was never mentioned. :-)
> I wonder if these could be "real" symlink approximations, i.e., the path
> to the executable to run would sit in some static string at a known
> offset, and the installer could simply write into the executable at that
> offset? Or is this too much?
Actually, I was kinda thinking about something like this:
$ ls /usr/bin
$ cp alternatives-wrap.exe /usr/bin/my-app.exe
$ ln -fs /usr/bin/my-app.from-package-1.exe /etc/alternatives/my-app
$ ln -fs /etc/alternatives/my-app '/usr/bin/.##wrap##my-app'
Obviously, those last three commands would actually be handled by the
update-alternatives program, and not done manually. Also, it'd be a
little different if the ultimate target were a script instead of a
The idea would be that the alternatives-wrap.exe binary would "know" to
look in its current directory for a symlink with the name
.##wrap##XXXXXX, where XXXXXX is argv stripped of its .exe extension
This avoids one issue with Bas' one-directory-to-wrap-them-all approach:
what if you have two different (but identically-named) binaries which
live in different directories, and you want to wrap them both? (Yes,
it's a pathological corner case ["WHY would you ever want to do that?"]
-- but somebody, somewhere, will try it -- and the results would be
confusing to say the least, under Bas' implementation).
> Looks good. You could also provide a "create-wrap" script/program, that
> would have "ln -s" semantics and create a wrapped executable (and it could
> also check that the thing you're wrapping *is* an executable, and not,
> say, a DLL). That way, if you decide to switch the implementation later,
> the scripts that create wrapped executables won't have to change.
That's a really good idea, for inclusion with the "main" wrap program
that Bas is proposing. The workalike for use by alternatives doesn't
need one; update-alternatives itself would be the only "authorized"
manipulator of alternatives-wrap and associated files/databases.
More information about the Cygwin-apps