I've been toying with including a script that will update the Python 2.6 embedded manifest to include a dependency on the common controls DLL so wxPython apps launched from python[w].exe will properly use the themed controls, but I've run into a glitch. The script is not able to update the python that is used to execute it, because that exe is in use so the system won't allow it to be written to.
I thought of getting real tricky and use python to update pythonw, and pythonw to update python, but that won't help if the user has some other program running using one or the other. Has anybody else run into this issue and have a workaround? If not then I'll just document the issue in an error message and leave it up to the user to ensure that no other Python apps are running when they try to do the update.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Sorry, I don't know how to solve this in a reasonable way. But this turns up a question. What if I want to install other packages who need a specific manifest, possibly conflicting with the wxPython one. If wxPython and the other package both patch the same global python.exe this will create some issues.
I'm mainly asking, because I've created a SWIG wrapper for a project of mine which also uses manifests. Now I haven't tried with python 2.6 yet, but if the same issue arises that arose for wxPython then this might create conflicts for me, because I need users to have both manifests working.
I've glanced over the manifest documentation superficially and found something called "Private Assemblies" ( Microsoft Learn: Build skills that open doors in your career ). Now if it was possible to install two manifests for the same python.exe the conflict could go away and your original problem would be solved as well. I don't know if this is possible though, I didn't look at it in-depth. In the past I used SetDllDirectory to get around some manifest problems as well.
Another thing I just thought of is if some kind of preloader could help. E.g. it loads an the image of the .exe file into memory, patches the manifest file and then executes this memory as a new process (e.g. with LoadLibraryEx). This sounds like really evil black magic though and might not even be possible (e.g. there are things like Data Execution Prevention).
-Matthias
···
Am 02.02.2009, 19:33 Uhr, schrieb Robin Dunn <robin@alldunn.com>:
Hi all,
I've been toying with including a script that will update the Python 2.6 embedded manifest to include a dependency on the common controls DLL so wxPython apps launched from python[w].exe will properly use the themed controls, but I've run into a glitch. The script is not able to update the python that is used to execute it, because that exe is in use so the system won't allow it to be written to.
I thought of getting real tricky and use python to update pythonw, and pythonw to update python, but that won't help if the user has some other program running using one or the other. Has anybody else run into this issue and have a workaround? If not then I'll just document the issue in an error message and leave it up to the user to ensure that no other Python apps are running when they try to do the update.
I've been toying with including a script that will update the Python 2.6 embedded manifest to include a dependency on the common controls DLL so wxPython apps launched from python[w].exe will properly use the themed controls, but I've run into a glitch. The script is not able to update the python that is used to execute it, because that exe is in use so the system won't allow it to be written to.
I thought of getting real tricky and use python to update pythonw, and pythonw to update python, but that won't help if the user has some other program running using one or the other. Has anybody else run into this issue and have a workaround? If not then I'll just document the issue in an error message and leave it up to the user to ensure that no other Python apps are running when they try to do the update.
Sorry, I don't know how to solve this in a reasonable way. But this turns up a question. What if I want to install other packages who need a specific manifest, possibly conflicting with the wxPython one. If wxPython and the other package both patch the same global python.exe this will create some issues.
I'm mainly asking, because I've created a SWIG wrapper for a project of mine which also uses manifests. Now I haven't tried with python 2.6 yet, but if the same issue arises that arose for wxPython then this might create conflicts for me, because I need users to have both manifests working.
I've glanced over the manifest documentation superficially and found something called "Private Assemblies" ( Microsoft Learn: Build skills that open doors in your career ). Now if it was possible to install two manifests for the same python.exe the conflict could go away and your original problem would be solved as well. I don't know if this is possible though, I didn't look at it in-depth. In the past I used SetDllDirectory to get around some manifest problems as well.
Another thing I just thought of is if some kind of preloader could help. E.g. it loads an the image of the .exe file into memory, patches the manifest file and then executes this memory as a new process (e.g. with LoadLibraryEx). This sounds like really evil black magic though and might not even be possible (e.g. there are things like Data Execution Prevention).
My understanding is that the common controls DLL is a special case in that the system will automatically fall back to the non-themed version of the DLL if the new one is not specified in the EXE's manifest. Other DLLs or assemblies do not need to be loaded from the EXE's manifest (well, except for the C/C++ runtime libraries probably) and so they are able to be specified in the PYD's manifest. So if I understand correctly I don't think it will be a problem.
···
Am 02.02.2009, 19:33 Uhr, schrieb Robin Dunn <robin@alldunn.com>:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I've been toying with including a script that will update the Python 2.6
embedded manifest to include a dependency on the common controls DLL so
wxPython apps launched from python[w].exe will properly use the themed
controls, but I've run into a glitch. The script is not able to update
the python that is used to execute it, because that exe is in use so the
system won't allow it to be written to.
I'm no so sure, I was reading and understanding correctly.
Are you proposing to modifiy the original python[w].exe so that
it suits the wxPython need's ?!
I thought of getting real tricky and use python to update pythonw, and
pythonw to update python, but that won't help if the user has some other
program running using one or the other. Has anybody else run into this
issue and have a workaround? If not then I'll just document the issue
in an error message and leave it up to the user to ensure that no other
Python apps are running when they try to do the update.
No idea. Maybe because python.exe and pythonw.exe use the same dll,
python26.dll. I have noticed, (Lars's disccussion), python26.dll also
contains an embedded manifest. Now if it is really used, that's
one another question... I have read somewhere (?), there is some
kind of "flag" indicating if a manifest file should be used of
not (assuming I understand it correctly).
No idea. Maybe because python.exe and pythonw.exe use the same dll,
python26.dll. I have noticed, (Lars's disccussion), python26.dll also
contains an embedded manifest. Now if it is really used, that's
one another question... I have read somewhere (?), there is some
kind of "flag" indicating if a manifest file should be used of
not (assuming I understand it correctly).
This is an interesting thread. I can only support the "Side-by-side is an abortion" statement. If I am not mistaken the thread also holds a solution to the original problem.
It would go like:
ACTCTX wxPythonContextInfo;
wxPythonContextInfo.lpSource = "path to wxPython common controls manifest";
// ... setup other members here ...
HANDLE wxPythonContext = CreateActCtx( &wxPythonContext );
ActivateActCtx( wxPythonContext );
I think this code would go somewhere before the wx package imports the .pyd (e.g. _core.pyd) files.
No idea. Maybe because python.exe and pythonw.exe use the same dll,
python26.dll. I have noticed, (Lars's disccussion), python26.dll also
contains an embedded manifest. Now if it is really used, that's
one another question... I have read somewhere (?), there is some
kind of "flag" indicating if a manifest file should be used of
not (assuming I understand it correctly).
Ok, thanks for the clarification. So it will only get a problem if I explicitly want the non-themed common controls. Something which nobody wants
-Matthias
···
Am 03.02.2009, 01:04 Uhr, schrieb Robin Dunn <robin@alldunn.com>:
My understanding is that the common controls DLL is a special case in that the system will automatically fall back to the non-themed version of the DLL if the new one is not specified in the EXE's manifest. Other DLLs or assemblies do not need to be loaded from the EXE's manifest (well, except for the C/C++ runtime libraries probably) and so they are able to be specified in the PYD's manifest. So if I understand correctly I don't think it will be a problem.
I've been toying with including a script that will update the Python 2.6 embedded manifest to include a dependency on the common controls DLL so wxPython apps launched from python[w].exe will properly use the themed controls, but I've run into a glitch. The script is not able to update the python that is used to execute it, because that exe is in use so the system won't allow it to be written to.
I'm no so sure, I was reading and understanding correctly.
Are you proposing to modifiy the original python[w].exe so that
it suits the wxPython need's ?!
No, just providing a script to allow wxPython users to do it themselves.
I don't see any other way around it other than convincing the Python team to modify the stock Python distribution, (but that won't help people with existing 2.6 installs.) Unless I'm missing something critical the only way that the themed version of the common controls DLL can be loaded is if it is specified in the EXE's manifest. By the time the wx DLLs or the wxPython PYDs are loaded it is too late.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
No idea. Maybe because python.exe and pythonw.exe use the same dll,
python26.dll. I have noticed, (Lars's disccussion), python26.dll also
contains an embedded manifest. Now if it is really used, that's
one another question... I have read somewhere (?), there is some
kind of "flag" indicating if a manifest file should be used of
not (assuming I understand it correctly).
This is an interesting thread. I can only support the "Side-by-side is an abortion" statement. If I am not mistaken the thread also holds a solution to the original problem.
It would go like:
ACTCTX wxPythonContextInfo;
wxPythonContextInfo.lpSource = "path to wxPython common controls manifest";
// ... setup other members here ...
HANDLE wxPythonContext = CreateActCtx( &wxPythonContext );
ActivateActCtx( wxPythonContext );
I think this code would go somewhere before the wx package imports the .pyd (e.g. _core.pyd) files.
Even if there were such a place besides Python itself, I don't think it would work for the common controls DLL because by the time it gets there the system will have already decided to load the old un-themed version of the DLL, and will probably have already loaded it.
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
You are right. I was naively assuming the python2x.dll didn't have the common controls in its dependency. I've looked at it with Dependency Walker now and there's a python.dll -> shell32.dll -> shdocvw.dll -> ieframe.dll -> mshtml.dll -> common controls dll path.
-Matthias
···
Am 03.02.2009, 20:39 Uhr, schrieb Robin Dunn <robin@alldunn.com>:
Even if there were such a place besides Python itself, I don't think it would work for the common controls DLL because by the time it gets there the system will have already decided to load the old un-themed version of the DLL, and will probably have already loaded it.
