Re: How do you modify PATH on Windows XEmacs 21.4.3

On Wednesday, October 24, 2001, at 09:37 PM, Stephen J. Turnbull wrote: > > Isn't this an abuse of PATH searching? PATH searching is intended to > provide a way for applications to find executable code that they > _don't_ provide themselves. But you already know where those DLLs > are, you found the ELL (XEmacs-specific DLL) there, right? This works > fine for XEmacs itself, and has the additional advantage of avoiding > version skew (or breakage of delay-loaded modules) if the user should > do something like manipulate PATH themselves. > > Or the ELL could just call the platform's setenv(3) itself. This has > its own problems, namely possible name conflicts for other ELLs that > abuse PATH searching in the same way. But since you're changing the > fundamental assumption that XEmacs makes about `process-environment' > anyway, why not? This has the advantage from my point of view that > _all_ non-module XEmacs functionality will work the same way it ever > did, because your PATH-munging will be totally ignored by XEmacs. > There's one flaw in the logic. The above argument assumes that the ELL is loading dependent DLLs via dlopen() (LoadLibrary() on Win32). However, if you've merely mentioned the dependent DLL on the link line for the ELL, Windows will load the dependent DLLs automagically as a result of said dlopen() call. Thus, there's no time/place for the ELL to modify the PATH, since it's not completely loaded by Windows yet, and therefore can't run any of its own code. > I don't much like this off-hand. It will be another gratuitous API > incompatibility with GNU Emacs. What's wrong with just defining new > primitive functions, say `{get,set}-real-environment', and in a module > of their own? Also, why impose the extra path in PATH on subprocesses > etc that just don't care about your DLLs? See above. The alternative, suggested a few messages back, is that our application installer modify the user's PATH during the installation process -- which effectively leads to the same effect as your last question in the above paragraph. We impose the extra PATH on all Windows applications that don't care about our DLL instead of just XEmacs. :)