On 26/12/2007, Lie Ryan <[EMAIL PROTECTED]> wrote: > > > On Dec 25, 2007 4:43 PM, Markus Gritsch <[EMAIL PROTECTED]> wrote: > > On 24/12/2007, Lie <[EMAIL PROTECTED]> wrote: > > > > > > (good programs are not DLL implementation specific > > > > Assume an application embedding Python being compiled with MSVC 8.0. > > It uses the runtime msvcr80.dll. If you now pass objects created in > > your application to the Python interpreter which is compiled with MSVC > > 7.1 which uses msvcr71.dll, you are asking for serious trouble. It is > > not a matter of being a "good program". > > don't cut my word, good programs aren't DLL implementation specific and good > DLL have consistent interface (consistent interface implies consistent > behavior). Of course this is a bit "utopia", as most DLL would sadly have to > change its interfaces once or twice and it is sometimes impossible for > programs to be completely free from its DLLs implementation
Instead of being upset about cutting your word (which was not my intention, sorry about that), it would be nice if you could make a statement concerning the problem I mentioned: Having an object being created by one MSVC runtime, msvcr80.dll and passing it to another one, msvcr71.dll. > > > If that's the case, just use the MSVC 7.1's compiled code, there won't > > > be much difference. > > > > See above. > > > > I think you don't get my point... if you don't modify the python interpreter > (from what I understand, you just recompile your Python DLL without > modification), there is no need to compile your own interpreter, it just > makes problem and the performance benefits is outweighed by the problems of > having to use 3rd party Python DLL (even if you don't modify the code and > just recompile it, it is not the official release, thus 3rd party). I do get your point, but your point is maintaining compatibility between two different *versions* of a DLL/Program. I am talking about having a DLL/Program combination which uses different MSVC runtimes. > > > If you insist to use your own version (or don't > > > have a choice), you could instead pack your own DLL, use the local > > > DLL, and ignore the system's DLL. > > > > Yes, that works fine when deploying the application. However, during > > development it is inconveninent to put our own Python DLL beside our > > executable every time. Our Python DLL (compiled with MSVC 8.0) is in > > the PATH. If the original Python DLL would be located in the Python > > installation folder, there would be no problem. But since it is > > placed in the system32 folder which is searched before the PATH > > > (http://msdn2.microsoft.com/en-us/library/ms682586(VS.85).aspx), > the > > original Python DLL (compiled with MSVC 7.1) is used instead of your > > own one. > > If that is the case, you could just simply substitute the system32's dll > with your in the test machine. If you don't want to dirty the system > (perhaps because you use the system for other things too), then you could > benefit from dual booting or virtualization technology. > > Dual Booting is putting two (almost) completely seperate OSes in a single > machine. > Virtualization is a technology that allows an OS to be run inside another > OS, an example would be VMWare. This result in degraded performance in the > client OS, but it's easier to manage than Dual Booting. > > You don't need any special program to set up a dual boot system, although > you might require special knowledge on how to do it. For virtualization > technology, VMWare and Microsoft have a free version of their virtual > machines. So basically, these two set ups costs nothing. Thank you for explaining that. -- http://mail.python.org/mailman/listinfo/python-list
