On Mon, 3 Apr 2000, Guido van Rossum wrote: >... > Actually, I just wanted to get the discussion started. It worked. :-) hehe. True :-) > I'm waiting for Tim Peters' response in this thread -- if I recall he > was the one who said that python1x.dll should not go into the system > directory. What's his physical address again? I have this nice little package to send him... >... > > IMO, put the DLL back into System32. If somebody can *demonstrate* (not > > hypothesize) a mechanism that works, then it can be switched. > > > > The underlying issue is this: Python16.dll in the app directory works for > > Python as an executable. However, it completely disables any possibility > > for *embedding* Python. On Windows, embedding is practically required > > because of the COM stuff (sure... a person could avoid COM but...). > > Yes, I know this. I'm just not happy with it, and I've definitely > heard people complain that it is evil to install directories in the > system directory. Seems there are different schools of thought... It is evil, but it is also unavoidable. The alternative is to munge the PATH variable, but that is a Higher Evil than just dropping DLLs into the system directory. > Another issue: MSVCRT.DLL and its friend MSVCIRT.DLL will also go into > the system directory. I will now be distributing with the VC++ 6.0 > servicepack 1 versions of these files. Won't this be a problem for > installations that already have an older version? Not at all. In fact, Microsoft explicitly recommends including those in the distribution and installing them over the top of *previous* versions. They should never be downgraded (i.e. always check their version stamp!), but they should *always* be upgraded. Microsoft takes phenomenal pains to ensure that OLD applications are compatible with NEW runtimes. It is certainly possible that you could have a new app was built against a new runtime, and breaks when used against an old runtime. But that is why you always upgrade :-) And note that I do mean phenomenal pains. It is one of their ship requirements that you can always drop in a new RT without breaking old apps. So: regardless of where you decide to put python16.dll, you really should be upgrading the RT DLLs. > David Ascher: if you're listening, could you forward this to someone > at ActiveState who might understand the issues here? They should have > the same problems with ActivePerl, right? Or don't they have COM > support? ActivePerl does COM, but I dunno much more than that. > (Personally, I think that it wouldn't be so bad if we made it so that > if you install just Python, the DLLs go into MAINDIR -- if you install > the COM support, it can move/copy them to the system directory. But > you may find this inelegant...) Eek. Now you're talking about one guy reaching into another installation and munging it around. Especially for a move (boy, would that throw off the uninstall!). If you copied, then it is possible to have *two* copies of the DLL loaded into a process. The primary key is the pathname. I've had two pythoncom DLLs loaded in a process, and boy does that suck! The bugs are quite interesting, to say the least :-) And a total bear to track down until you have seen the double-load several times and can start to recognize the effects. In other words, moving is bad for elegance/uninstall reasons, and copy is bad for (potential) runtime reasons. Cheers, -g -- Greg Stein, http://www.lyra.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4