This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]