Hi, This is a question about development how can python meet "OEM Ready programs". Right now most of python is passing that programs but not all of it. Right now some of the executable are failing some of the tests. Only few test are failings. That why I need a contact I don't want to swamp that mailing list with a lot of things. Gerald -----Original Message----- From: Leif Walsh [mailto:leif.walsh@gmail.com] Sent: Wednesday, November 26, 2008 11:21 AM To: Koenig, Gerald Cc: python-dev@python.org Subject: Re: [Python-Dev] Python for windows. This list is for the development of python. Questions about programming with python go to c.l.python or python-list at python dot org. If your question is about the development of python, you can probably just ask here. On Wed, Nov 26, 2008 at 2:06 PM, Koenig, Gerald <gerald.koenig@hp.com> wrote:

Hi all,

I am working For Hewlett-Packard designing PC Consumer Desktop

We have been including Python since over 10 years now on our systems.

It is a wonderful language and very powerful.

Now I am having a small issue and I was wondering how I can solve it.

So I would like to know who should I contact to be able to work on that issue together ?

The issue is about some requirement I need to have on our systems and even tools need to pass those requirement.

Regards

Gerald Koenig Software Builds Architect Hewlett-Packard Work Phone: +(1) 408 873 6202

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/leif.walsh%40gmail.com

-- Cheers, Leif

Koenig, Gerald wrote:

I am working For Hewlett-Packard designing PC Consumer Desktop We have been including Python since over 10 years now on our systems.

I am writing this on a Pavilion that came with Python2.2. I hope you are able to continue including Python.

Now I am having a small issue and I was wondering how I can solve it. So I would like to know who should I contact to be able to work on that issue together ? The issue is about some requirement I need to have on our systems and even tools need to pass those requirement.

If you are looking for one person to give you professional support (which would not be me for your problem) with professional discretion for professional pay, you should say so. As far as I know, the Python Software Foundation does not have an on-call corporate-support person. If you are will to take your chances with volunteer support from whoever responds to each item, then you can choose between the general list for issues relating to past and current releases or the bug tracker or this list for issue relating to future releases (including Pythonx.y.z bug-fix releases). Without more information (Which version is not passing "OEM Ready"? Have previous versions passed such?), it is hard to say more. Terry Jan Reedy

I completely understand that this is a volunteer organization. That why I am already proposing that HP will submit for your guys after we figure out how to fix the issues if it is possible to fix them of course.

I don't fully understand why it is in HPs interests to install a normal python.dev installer, and have their other bundled software rely on it working forever. IMO it is likely people will not understand the association, and may upgrade or remove the package. Wouldn't it make more sense for HP to treat Python as a "private" tool and bundle it hidden away inside their applications? This is the exact approach many applications written in Python take - I can't think of any commercial applications that rely on the standard installer - think the Python implemented IDEs, the various Zope windows binaries, etc. Or obviously I'm missing some key point :)

The OEM Ready program is: http://msdn.microsoft.com/en- us/windowsvista/cc315067.aspx Personally I am ready to do the job of submitting and testing if you pass all the tests.

You can find some info about all those test here also:

http://www.codeproject.com/KB/vista/Certified_for_Vista.aspx?display=Pr intAll&fid=406261&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26

But these are written with applications in mind - Python isn't an application - its used to *write* applications. I don't see a good reason to support these guidelines. I do see a reason to help support people ensure their Python implemented applications can meet the guidelines, but I'd never advise such people to install the python.org installer and have their application use Python from that directory. In other words: Python implemented apps should meet the guidelines, but as such apps shouldn't use the standard installer, there is no need for Python itself to meet them.

- Some of the executable deliver in the python package It does not have manifest that is compliant with UAC guidelines.. c:\program files\python\lib\distutils\command\\wininst- 6.0.exe c:\program files\python\lib\distutils\command\\wininst- 7.1.exe c:\program files\python\lib\distutils\command\\wininst- 8.0.exe

These are stubs for installers. It is the installers created from these stubs that need the manifest, as the manifest requirements will differ for each use of the stub. Ditto for python.exe etc - its impossible to add a reasonable manifest, as the manifest requirements would depend entirely on what the python program itself does. There is no way python.exe can know what it will be asked to do.

We could add a manifest manually outside the executable if there is no manifest at all in those.

See above - we don't know ahead of time what an appropriate manifest is. I agree manifests need thought and work for Python, but I'm fairly sure the answer isn't to try and come up with them ahead of time and assume they apply universally.

- This c:\windows\installer\{110eb5c4-e995-4cfb-ab80- a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager Aware

That sounds like something nice to have, but assuming we recommend against using the standard Python installer for 3rd party applications, this is a problem for the application installer, not ours. In other words, I'm sure we'd welcome a fix to this, but I'd still recommend against using our installer anyway!

- Last one is some of your executable do not contain any version numbers inside.

If the binaries don't currently include the python version number, I'd agree that would be a nice addition. Maybe your and others lives would be made easier if the Python MSI installer was split up to support "merge modules"? That way you could roll your own installer that met any guidelines or requirements that mattered to you, while still ensuring you got all the files that the official installer would have installed. I'm hand-waving a little here, but it sounds like we can do more to help *others* meet guidelines for their Python based apps instead of trying and meet it for our installer... Cheers, Mark

Hi Mark, See below my answers, We install your installer, for people to use python are the main language script on the system. My team recommend others team to use this as the main scripting languages for different software's, Due to that we use the standard install and people developed their script on the systems. We also leave it on the system for our customer later if they want to use special function of our consumer desktop like application drivers recovery for example. As it is on the system it would need to be passing those requirement for OEM ready because we use python like an application in our case to developed script / programs using your normal installer. This is the main reason we have it on all our system since over 10 years now :) Gerald -----Original Message----- From: python-dev-bounces+gerald.koenig=hp.com@python.org [mailto:python-dev-bounces+gerald.koenig=hp.com@python.org] On Behalf Of Koenig, Gerald Sent: Wednesday, November 26, 2008 2:03 PM To: mhammond@skippinet.com.au; python-dev@python.org Subject: Re: [Python-Dev] Python for windows. Hi Mark, Well we are having a lot of our teams using python are the script languages :) It is not only one team using it That why we use the normal installer :) Gerald -----Original Message----- From: Mark Hammond [mailto:skippy.hammond@gmail.com] On Behalf Of Mark Hammond Sent: Wednesday, November 26, 2008 1:59 PM To: Koenig, Gerald; python-dev@python.org Subject: RE: [Python-Dev] Python for windows.

I completely understand that this is a volunteer organization. That why I am already proposing that HP will submit for your guys after we figure out how to fix the issues if it is possible to fix them of course.

I don't fully understand why it is in HPs interests to install a normal python.dev installer, and have their other bundled software rely on it working forever. IMO it is likely people will not understand the association, and may upgrade or remove the package. Wouldn't it make more sense for HP to treat Python as a "private" tool and bundle it hidden away inside their applications? This is the exact approach many applications written in Python take - I can't think of any commercial applications that rely on the standard installer - think the Python implemented IDEs, the various Zope windows binaries, etc. Or obviously I'm missing some key point :)

The OEM Ready program is: http://msdn.microsoft.com/en- us/windowsvista/cc315067.aspx Personally I am ready to do the job of submitting and testing if you pass all the tests.

You can find some info about all those test here also:

http://www.codeproject.com/KB/vista/Certified_for_Vista.aspx?display=Pr intAll&fid=406261&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26

But these are written with applications in mind - Python isn't an application - its used to *write* applications. I don't see a good reason to support these guidelines. I do see a reason to help support people ensure their Python implemented applications can meet the guidelines, but I'd never advise such people to install the python.org installer and have their application use Python from that directory. In other words: Python implemented apps should meet the guidelines, but as such apps shouldn't use the standard installer, there is no need for Python itself to meet them.

- Some of the executable deliver in the python package It does not have manifest that is compliant with UAC guidelines.. c:\program files\python\lib\distutils\command\\wininst- 6.0.exe c:\program files\python\lib\distutils\command\\wininst- 7.1.exe c:\program files\python\lib\distutils\command\\wininst- 8.0.exe

These are stubs for installers. It is the installers created from these stubs that need the manifest, as the manifest requirements will differ for each use of the stub. Ditto for python.exe etc - its impossible to add a reasonable manifest, as the manifest requirements would depend entirely on what the python program itself does. There is no way python.exe can know what it will be asked to do.

We could add a manifest manually outside the executable if there is no manifest at all in those.

See above - we don't know ahead of time what an appropriate manifest is. I agree manifests need thought and work for Python, but I'm fairly sure the answer isn't to try and come up with them ahead of time and assume they apply universally.

- This c:\windows\installer\{110eb5c4-e995-4cfb-ab80- a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager Aware

That sounds like something nice to have, but assuming we recommend against using the standard Python installer for 3rd party applications, this is a problem for the application installer, not ours. In other words, I'm sure we'd welcome a fix to this, but I'd still recommend against using our installer anyway!

- Last one is some of your executable do not contain any version numbers inside.

If the binaries don't currently include the python version number, I'd agree that would be a nice addition. Maybe your and others lives would be made easier if the Python MSI installer was split up to support "merge modules"? That way you could roll your own installer that met any guidelines or requirements that mattered to you, while still ensuring you got all the files that the official installer would have installed. I'm hand-waving a little here, but it sounds like we can do more to help *others* meet guidelines for their Python based apps instead of trying and meet it for our installer... Cheers, Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com

Hi all, Yes we spend the time and resources to do those tests. You do not have to worry about that :) and We will submit to Microsoft instead of you like that you do not have to worry about it. Microsoft is totally fine with it. I already asked them if it was fine. Unless you do not want us to do it. We do it for 2 reasons: We are trying to have all our systems OEM ready Compliant. Second all our customers will not have to worry about it, as it is already passing. I can promise you Python on our system Python work perfectly. We use it very often as our main scripting/programming tool like some other would use jscript or C#. We also follow your license agreement to never change anything from the packages. That why I went to this development board to see if some change can be done to make it OEM ready :) I didn't want to change anything by myself. So out of the three issue: - The three executable could be change to .dat ? - So if I understand well python_icon.exe is only stocking all the icon for python ? - I just checked for the version number it is not required expect for the uninstalled key which is already clean. GErald -----Original Message----- From: "Martin v. Löwis" [mailto:martin@v.loewis.de] Sent: Wednesday, November 26, 2008 2:32 PM To: mhammond@skippinet.com.au Cc: Koenig, Gerald; python-dev@python.org Subject: Re: [Python-Dev] Python for windows.

But these are written with applications in mind - Python isn't an application - its used to *write* applications. I don't see a good reason to support these guidelines. I do see a reason to help support people ensure their Python implemented applications can meet the guidelines, but I'd never advise such people to install the python.org installer and have their application use Python from that directory.

I disagree. While it might not be really necessary for HP to have Python comply to a formal test suite, I'm sure other users do need to pass these test suites for whatever reason, and they are unhappy if they don't pass out of the box. Cleary, "we" (python-dev) would never run any of these test suites; it's to much effort to buy them, run them, and study the results. So I'm really glad HP spends the time on that stuff - not because HP needs it, but because "smaller" users might run into it, and then frustrate because they can't resolve the issues (rather than contacting us).

These are stubs for installers. It is the installers created from these stubs that need the manifest, as the manifest requirements will differ for each use of the stub.

See my other message. This "obviously" comes from a formal test suite. So it's not necessary to convince the operator of the test suite that the test is flawed, but to convince the test suite to look elsewhere. I think we can do that.

Ditto for python.exe etc - its impossible to add a reasonable manifest, as the manifest requirements would depend entirely on what the python program itself does. There is no way python.exe can know what it will be asked to do.

FWIW, python.exe *does* have a manifest. The manifest is primarily about static linking. I don't know what other uses a manifest may have, but if it makes the test suite happy that python.exe has a manifest, then I'm happy myself also.

See above - we don't know ahead of time what an appropriate manifest is. I agree manifests need thought and work for Python, but I'm fairly sure the answer isn't to try and come up with them ahead of time and assume they apply universally.

Can you please elaborate? What specific elements of the manifest are you thinking of that are not universally correct for python.exe?

...

- This c:\windows\installer\{110eb5c4-e995-4cfb-ab80- a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager Aware

That sounds like something nice to have, but assuming we recommend against using the standard Python installer for 3rd party applications, this is a problem for the application installer, not ours. In other words, I'm sure we'd welcome a fix to this, but I'd still recommend against using our installer anyway!

Perhaps. I wouldn't go so far, though. It's surely puzzling if a system comes with a pre-installed Python, but if that Python actually works, I don't think that does much damage. Of course, anybody embedding Python *should* integrate it into his own application and installation procedure. If we really want this guideline to be followed, we should document explicitly how one does that (and no, pointing people to py2exe is not sufficient).

Maybe your and others lives would be made easier if the Python MSI installer was split up to support "merge modules"? That way you could roll your own installer that met any guidelines or requirements that mattered to you, while still ensuring you got all the files that the official installer would have installed. I'm hand-waving a little here, but it sounds like we can do more to help *others* meet guidelines for their Python based apps instead of trying and meet it for our installer...

If this list of complaints was complete, I don't find it too difficult to comply. If a merge module would contain the entire library (including distutils), then the wininst.exe issue would still exist for the merge module (for example). OTOH, if somebody wanted to contribute a procedure that builds merge modules (in whatever granularity) along with the msi file - that would also be appreciated. Regards, Martin

Mark Hammond wrote:

BTW - isn't there also a "\Program Files" requirement...?

The requirement as I read it is that /Program Files be the over-rideable *default*, as is normal for Windows programs. HP installed 2.2 on my machine in /Python2.2. Since HP does the installation, I presume they can override the default if they wish. The current Python installers are unusual for Windows in having the default be anything else. I personally am now putting Python in /Programs along with other development tools whose directory tree I need to access, so it matters not to me. If HP is happy with stock installs after 10 years, they must not have a severe problem with uninstalls. The one suggestion I have for HP, now that we have a reps attention, is that they add a README.txt file to the Python directory that explains what is it, why it should not be uninstalled, and where to get more info about how the user can use this bonus feature of having bought an HP machine ;-). Terry

IIUC, the test suite is about having the Python installer certified as "OEM Ready", which means a few special things - including, IIUC, the "right" to be installed in a new PC. My broader point is that I would advise against any application vendor reusing the standard Python installer for their application, as it exposes the ability for the user to remove it, thereby breaking the application.

Right, and I agree with it. However, that is HP's choice, and while there is a theoretical possibility that users break their systems, in practice, most users are too scared to actually attempt such breakage. However, "OEM ready" sounds like a good goal to achieve. Python has been shipping as part of the operating system on Linux for many years now, and ships with Solaris and OSX for several years now. I see nothing wrong with Python being preinstalled on PCs. If this approach would become standard practice, py2exe and friends would become much simpler (and I do know that I'm dreaming now).

Obviously I'm wrong here though - HP obviously *is* wanting to install it as is, and doesn't mind that the user could accidently break their scripts. I'm very surprised by that, but I have to accept it :) On the other hand, I'd really like to ensure they understand the risks and for me to understand why those risks are acceptable...

See above. I think the risk is theoretical. In any case, applications *can* make sure pythonxy.dll survives uninstallation (by increasing its refcount), although this probably doesn't help much if the standard library is gone.

Agreed. I'm just surprised app authors are willing to take the risk this implies. I still occasionally get email from people (presumably via my email addy which used to be in Pythonwin) saying "I've got this Python thing installed on my PC - is it a virus? Can I remove it?". I tend to say "it’s a programming language - if you don't know you need it, you probably don't, so sure, uninstall it".

We get these messages on python-help also. We even have http://www.python.org/doc/faq/installed/ so it *is* a frequently-asked question. I think that is a good thing. Regards, Martin

The only conflict I see here is the requirement to install into "\Program Files" and I'm surprised that hasn't been raised in this thread.

The question is whether the "OEM ready" is a property of the installer, or a property of the installed. The OEM can chose to install Python into program files, and while there is occasional breakage, we do want to support this case - just not make it the default.

However, should such a situation arise, my position would probably be that unless it was MS suggesting it be preloaded on *all* PCs, we should sacrifice that part of being "OEM Ready" to best look after the interests of people who seek it out for download.

So much agreement :-) Regards, Martin

Greg writes:

Mark Hammond wrote:

...

The only conflict I see here is the requirement to install into "\Program Files"

Doesn't that just mean that if an OEM decides to preinstall it, they need to put it in Program Files? They're at liberty to do that.

I'm not very familiar with the OEM process, but I believe the software is automatically installed after the first boot from MSI files supplied by the OEM partner (so technically, its not "pre-installed" at all). I don't know enough about how that works to know how easy it would be to override that option during installation - hopefully Gerald will fill us in with more details... [Hrm - looking closer at that HTML link I sent before, it says specifically "Per-machine installs must install to Program Files by default in order to pass this test case" - that seems pretty clear...] Cheers, Mark

...

[Hrm - looking closer at that HTML link I sent before, it says specifically "Per-machine installs must install to Program Files by default in order to pass this test case" - that seems pretty clear...]

Given that the links in Gerald's examples were under Program Files, I had assumed that HP were tweaking the installer at least that much...

But wouldn't that leave us in the situation where Python's installer is *not* "OEM Ready", nor has it been certified as such - but an installer based on ours, but with unspecified changes has? Of course, I don't object to that and still think we should help where we can, but if that is true it would make the premise of this thread a little misleading, as obviously HP could then make *any* necessary changes without our agreement or even knowledge. Cheers, Mark

Hi all, I didn't look at the thread until this morning. The OEM ready program required that the installed force to program files. But as we preinstalled we use your msi with a normal parameter: python-2.5.2.msi TARGETDIR=c:\program files\python" That why I didn't ask you about that. WE have done already few weeks of test and nothing is breaking up to now :) Now about the 2 others issues what will be the easier way to fix them properly ? - for the executable without manifest as we are on vista OS only I can add a manifest for vista outside the executable it should work. - for python_icon.exe I do not know what is calling it in start menu can you help me on that ? Gerald -----Original Message----- From: python-dev-bounces+gerald.koenig=hp.com@python.org [mailto:python-dev-bounces+gerald.koenig=hp.com@python.org] On Behalf Of "Martin v. Löwis" Sent: Sunday, November 30, 2008 2:24 PM To: mhammond@skippinet.com.au Cc: 'Nick Coghlan'; python-dev@python.org Subject: Re: [Python-Dev] Python for windows.

Of course, I don't object to that and still think we should help where we can, but if that is true it would make the premise of this thread a little misleading, as obviously HP could then make *any* necessary changes without our agreement or even knowledge.

Perhaps. However, "help where we can" is about right. If its only the changes HP discussed so far, I think we should be able to help. For the Program Files issue, without going into the discussion whether Python's defaults are good or not, I think there would be still a number of technical solutions (such as providing a merge module which changes the default). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com

Mark, We do not install that on first boot. I can not tell how it is install but on first boot python is already there and installed properly Gerald -----Original Message----- From: Koenig, Gerald Sent: Monday, December 01, 2008 11:05 AM To: '"Martin v. Löwis"'; mhammond@skippinet.com.au Cc: 'Nick Coghlan'; python-dev@python.org Subject: RE: [Python-Dev] Python for windows. Hi all, I didn't look at the thread until this morning. The OEM ready program required that the installed force to program files. But as we preinstalled we use your msi with a normal parameter: python-2.5.2.msi TARGETDIR=c:\program files\python" That why I didn't ask you about that. WE have done already few weeks of test and nothing is breaking up to now :) Now about the 2 others issues what will be the easier way to fix them properly ? - for the executable without manifest as we are on vista OS only I can add a manifest for vista outside the executable it should work. - for python_icon.exe I do not know what is calling it in start menu can you help me on that ? Gerald -----Original Message----- From: python-dev-bounces+gerald.koenig=hp.com@python.org [mailto:python-dev-bounces+gerald.koenig=hp.com@python.org] On Behalf Of "Martin v. Löwis" Sent: Sunday, November 30, 2008 2:24 PM To: mhammond@skippinet.com.au Cc: 'Nick Coghlan'; python-dev@python.org Subject: Re: [Python-Dev] Python for windows.

Of course, I don't object to that and still think we should help where we can, but if that is true it would make the premise of this thread a little misleading, as obviously HP could then make *any* necessary changes without our agreement or even knowledge.

Perhaps. However, "help where we can" is about right. If its only the changes HP discussed so far, I think we should be able to help. For the Program Files issue, without going into the discussion whether Python's defaults are good or not, I think there would be still a number of technical solutions (such as providing a merge module which changes the default). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com

- Some of the executable deliver in the python package It does not have manifest that is compliant with UAC guidelines.. c:\program files\python\lib\distutils\command\\wininst-6.0.exe c:\program files\python\lib\distutils\command\\wininst-7.1.exe c:\program files\python\lib\distutils\command\\wininst-8.0.exe

Hmm. These binaries are not meant to be run as executables themselves. Instead, they are meant to be integrated into setup programs as-is. wininst-6.0.exe, in particular, is created by MSVC 6.0, which isn't even capable of dealing with manifests. Would it help compliance if we renamed them into .dat, so that the conformance test doesn't recognize them as .exe files? If that doesn't trick it, we could also binary-invert the contents (or the first 4 bytes).

- This c:\windows\installer\{110eb5c4-e995-4cfb-ab80-a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager Aware Not sure what can be the solution for that one.

Can you please elaborate? How does one detect that something is Restart Manager Aware? The file, again, is not ever meant to be run. Instead, it only serves as a container for icons. If it helps to use a different icon container (e.g. a DLL), that might solve the problem. Alternatively, if you can suggest the most trivial "hello world" style application that is Restart Manager Aware, that would also probably solve the problem. See PC/empty.c for the source of python_icons.exe.

- Last one is some of your executable do not contain any version numbers inside.

I was tempted to say "this is not true", but it probably is - only pythonxy.dll has the version resource. Patches are welcome. IIUC, PC/python_nt.rc is where the version resource for pythonxy.dll is defined, and PC/python_exe.rc defines the, well, .exe resources. For compliance, it's probably ok if python_exe.rc includes python_nt.rc, but it would probably be better if the version of python.exe didn't say "Python DLL" for "InternalName". So if you can come up with a series of defines and #includes that solves it all without any code duplication - that would be appreciated. For the other executables (other than python.exe and pythonw.exe): they aren't really executables. So if renaming them to .dll or even to something else solves the problem, we can happily do that. If they really need to get a version resource, so be it - they should all be version 1.0, and InternalName "we just included a version resource so that Microsoft's branding is happy". Regards, Martin

Hi Terry, And like you I really want to keep python on our systems. That why I am contacting python Foundation and try to fix those issues together. We are already running all those tests in house here. Gerald -----Original Message----- From: Koenig, Gerald Sent: Wednesday, November 26, 2008 12:35 PM To: python-dev@python.org Subject: RE: [Python-Dev] Python for windows. Hi all, Right now we are including 2.5.2 I am planning on rolling to 2.6 very soon. I completely understand that this is a volunteer organization. That why I am already proposing that HP will submit for your guys after we figure out how to fix the issues if it is possible to fix them of course. The OEM Ready program is: http://msdn.microsoft.com/en-us/windowsvista/cc315067.aspx Personally I am ready to do the job of submitting and testing if you pass all the tests. You can find some info about all those test here also: http://www.codeproject.com/KB/vista/Certified_for_Vista.aspx?display=PrintAll&fid=406261&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26 The list of issues are pretty simple: - Some of the executable deliver in the python package It does not have manifest that is compliant with UAC guidelines.. c:\program files\python\lib\distutils\command\\wininst-6.0.exe c:\program files\python\lib\distutils\command\\wininst-7.1.exe c:\program files\python\lib\distutils\command\\wininst-8.0.exe We could add a manifest manually outside the executable if there is no manifest at all in those. - This c:\windows\installer\{110eb5c4-e995-4cfb-ab80-a5f315bea9e8}\python_icon.exe do not answers to the Restart Manager Aware Not sure what can be the solution for that one. - Last one is some of your executable do not contain any version numbers inside. Gerald -----Original Message----- From: python-dev-bounces+gerald.koenig=hp.com@python.org [mailto:python-dev-bounces+gerald.koenig=hp.com@python.org] On Behalf Of Terry Reedy Sent: Wednesday, November 26, 2008 12:18 PM To: python-dev@python.org Subject: Re: [Python-Dev] Python for windows. Koenig, Gerald wrote:

I am working For Hewlett-Packard designing PC Consumer Desktop We have been including Python since over 10 years now on our systems.

I am writing this on a Pavilion that came with Python2.2. I hope you are able to continue including Python.

Now I am having a small issue and I was wondering how I can solve it. So I would like to know who should I contact to be able to work on that issue together ? The issue is about some requirement I need to have on our systems and even tools need to pass those requirement.

If you are looking for one person to give you professional support (which would not be me for your problem) with professional discretion for professional pay, you should say so. As far as I know, the Python Software Foundation does not have an on-call corporate-support person. If you are will to take your chances with volunteer support from whoever responds to each item, then you can choose between the general list for issues relating to past and current releases or the bug tracker or this list for issue relating to future releases (including Pythonx.y.z bug-fix releases). Without more information (Which version is not passing "OEM Ready"? Have previous versions passed such?), it is hard to say more. Terry Jan Reedy _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com