PyInstaller 2.0 one-file vs Windows 2000 (with Python 2.7.3 32-bit)

[Bill Tutt]

The download for PyInstaller 2.0 seems to include binaries that were created with Visual Studio 2010.

This means that the PE Header value in run*.exe/*.dll specifies a minimum subsystem version of 5.01.

Windows 2000 only supports 5.00 or less.

 

I have VS 2008, VS 2010, and VS2012 installed and I did the following:

* waf configure

* waf build

 

The configure output found VS 2008 and VS 2010 CLs, but only listed VS 2008 LINK/LIB, and the build used the VS 2008 CL and LINK.

 

It seems like the wscript should prevent VS 2010 from being used for all Python 2.x versions PyInstaller supports.

 

The output of the build produced a .exe/.dll (as shown by dumpbin /headers) that has subsystem set to 5.00:

            5.00 operating system version
            0.00 image version
            5.00 subsystem version

 

However, that wasn't the end of the saga.

When I ran the .exe on Windows 2000 I got an error dialog claiming it couldn't load the MSVC9 CRT DLL while run.exe was trying to LoadLibraryEx python27.dll.

 

The source of the problem seems to be wierdness with the ALTERNATE SEARCH flag to LoadLibraryEx()

 

Changing the working directory to the extractionpath before the LoadLibraryEx call seems to work and falling back to the one-dir approach if that isn't possible.

This hack seems like a deal breaker to some PyInstaller utilizing apps that want to run on Win2k though.

Changing the current working directory is a pretty big hammer. :(

 

The .exe works just fine on Win7/Win2k8R2 so this is just a Win2k lameness as far as I know.

 

Now that I think some more about it, I suppose one lame idea would be to copy the PyInstaller .exe (or just the appropriate run*.exe equivalent if that's possible) into extraction path and launch the child instance from there.

 

Bleh. I don't supose anybody else might have another idea that might be suitable to write a patch against the development branch?

 

Thanks,

Bill

 

[Martin Zibricky]

Bill Tutt píše v St 13. 03. 2013 v 20:48 -0700:

> The download for PyInstaller 2.0 seems to include binaries that were
> created with Visual Studio 2010.

I think they were compiled with VS 2008 Express.

> This means that the PE Header value in run*.exe/*.dll specifies a
> minimum subsystem version of 5.01.
> Windows 2000 only supports 5.00 or less. I have VS 2008, VS 2010, and
> VS2012 installed and I did the following: * waf configure * waf
> build

> The configure output found VS 2008 and VS 2010 CLs, but only listed VS
> 2008 LINK/LIB, and the build used the VS 2008 CL and LINK.

Did you mean that the build used VS2010?

You should be able to edit the wscript file to prefer VS2008 over
VS2010.

Could you try the development version?

[Bill Tutt]

On Thursday, March 14, 2013 5:55:09 AM UTC-4, Martin Z wrote:

Bill Tutt píše v St 13. 03. 2013 v 20:48 -0700:
> The download for PyInstaller 2.0 seems to include binaries that were
> created with Visual Studio 2010.

I think they were compiled with VS 2008 Express.

> This means that the PE Header value in run*.exe/*.dll specifies a
> minimum subsystem version of 5.01.
> Windows 2000 only supports 5.00 or less. I have VS 2008, VS 2010, and
> VS2012 installed and I did the following: * waf configure * waf
> build  

> The configure output found VS 2008 and VS 2010 CLs, but only listed VS
> 2008 LINK/LIB, and the build used the VS 2008 CL and LINK.

Did you mean that the build used VS2010?

 

No, the configure phase detected the VS 2010 C compiler, but didn't report a path for VS 2010's linker.

The actual build did occur with VS 2008 CL/LINK (from the Visual Studio 2008 command prompt console window).

I verified this with passing a single -v into waf build.

 

 

You should be able to edit the wscript file to prefer VS2008 over
VS2010.

Could you try the development version?

 

I'll try the development version today and let you know.

 

Bill

 

[Martin Zibricky]

Let's summarize:
- you tried bootloader from pyinstaller 2.0 on w2k
- not working - unsupported PE header number
- you think it was compiled with VS2010
- you recompiled bootloader with VS2008
- it still does not work on w2k for you
- pyinstaller
- bootloader for 2.0 was compiled with VS2008 Express
- I have never installed VS2010 on my system.
- the same applies for the development branch


Bill Tutt píše v Čt 14. 03. 2013 v 06:36 -0700:

[Bill Tutt]

Here's what I meant by the wierd waf configure output: (running from within a Visual Studio 2008 command prompt window)

 

Windows-32bit detected

Checking for program gcc or cc           : not found

Checking for program CL                  : c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\x86_amd64\CL.exe

Checking for program CL                  : c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\CL.exe

Checking for program CL                  : c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\CL.exe

Checking for program CL                  : c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\x86_amd64\CL.exe

Checking for program CL                  : c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\CL.exe

Checking for program CL                  : c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\CL.exe

Checking for program CL                  : c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\CL.exe

Checking for program LINK                : c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\LINK.exe

Checking for program LIB                 : c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\LIB.exe

Checking for program MT                  : C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\MT.exe

Checking for program RC                  : C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\RC.exe

msvc 10.0

        x86_amd64

        x86

        x64

msvc 11.0

msvc 9.0

        x86_amd64

        x86

        x64

Checking for library user32              : yes

Checking for library comctl32            : yes

Checking for library kernel32            : yes

Checking for library ws2_32              : yes

 

The development version worked (after rebuilding with VS 2008) except for seeing these duplicated warnings in the run.exe variant:

 

WARNING: file already exists but should not: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\
_MEI34402\pywintypes27.dll
WARNING: file already exists but should not: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\
_MEI34402\pywintypes27.dll
WARNING: file already exists but should not: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\
_MEI34402\pythoncom27.dll
WARNING: file already exists but should not: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\
_MEI34402\pythoncom27.dll

The rund.exe variant duplicated all of its log messages as well not just these two warning conditions.

I guess this is coming from the WIN32 version of stb__print.

 

The cause of the warnings seems to be that two copies of pythoncom27.dll and pywintypes27.dll were packaged in the .exe according to archive_viewer.py. :(

This seems to be due to the pywintypes and pythoncom hooks that unconditionally add these dlls as 'data' conflicting with some other addition of those files to the archive.

I haven't quite figured out which code is inserting the dlls that isn't the hook yet. 

 

Bill

 

[Bill Tutt]

Your summary is correct.

I don't have VS2008 Express installed locally, so I can't easily try that out at the moment.

The binaries for development branch also needed me to recompile them due to the PE header stuff.

On the plus side (aside from the warnings noted in my other reply) the development branch works with my recompiled bootloader .exes on Win2k for the variants that i've tried.

I've tried run.exe and its debug variation. I haven't tried runw.exe and its debug variation on Win2k yet.

 

Bill

[Bill Tutt]

Here's a possible fix for the pythoncom27 and pywintypes27 appearing twice in the archive and thus the warnings no longer occur.

 

Bill

 

Date: Thu, 14 Mar 2013 14:36:31 -0400
Subject: [PATCH] Ensure pywintypes and pythoncom dlls don't get included
 twice by adding the dll as a BINARY instead of as a data.

---
 PyInstaller/hooks/hook-pythoncom.py  |    9 ++++++---
 PyInstaller/hooks/hook-pywintypes.py |    9 ++++++---
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/PyInstaller/hooks/hook-pythoncom.py b/PyInstaller/hooks/hook-pythoncom.py
index 2fff576..3121d30 100644
--- a/PyInstaller/hooks/hook-pythoncom.py
+++ b/PyInstaller/hooks/hook-pythoncom.py
@@ -15,8 +15,11 @@ as a data file. The path to this dll is contained in __file__
 attribute.
 """
 
-
+import os.path
 from PyInstaller.hooks.hookutils import get_module_file_attribute
 
-
-datas = [(get_module_file_attribute('pythoncom'), '.')]
+def hook(mod):
+    pth = get_module_file_attribute('pythoncom')
+    name = os.path.basename(pth)
+    mod.binaries.extend([(name, pth, 'BINARY')])
+    return mod
diff --git a/PyInstaller/hooks/hook-pywintypes.py b/PyInstaller/hooks/hook-pywintypes.py
index 0c099c3..053a050 100644
--- a/PyInstaller/hooks/hook-pywintypes.py
+++ b/PyInstaller/hooks/hook-pywintypes.py
@@ -15,8 +15,11 @@ as a data file. The path to this dll is contained in __file__
 attribute.
 """
 
-
+import os.path
 from PyInstaller.hooks.hookutils import get_module_file_attribute
 
-
-datas = [(get_module_file_attribute('pywintypes'), '.')]
+def hook(mod):
+    pth = get_module_file_attribute('pythoncom')
+    name = os.path.basename(pth)
+    mod.binaries.extend([(name, pth, 'BINARY')])
+    return mod
--
1.7.6.msysgit.0