This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: update-alternatives
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
...
/usr/bin/my-app.from-package-1.exe
/usr/bin/my-app.from-package-2.exe
...
$ 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
binary executable.
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[0] stripped of its .exe extension
and path.
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.
--
Chuck