Windows installer pre-prelease

The Windows installer is always hard to get just right. If you have a moment, go to http://www.python.org/1.6/ and download the Windows Installer prerelease. Let me know what works, what doesn't! I've successfully installed it on Windows NT 4.0 and on Windows 98, both with default install target and with a modified install target. I'd love to hear that it also installs cleanly on Windows 95. Please test IDLE from the start menu! --Guido van Rossum (home page: http://www.python.org/~guido/)

All worked without incident for me under Win95. Nice! Would still prefer that it install to D:\Python-1.6\ by default, though (instead of burying it under "Program Files" -- if you're not on the Help list, you can't believe how hard it is to explain how to deal with embedded spaces in paths). So far I've seen one system crash in TK83.DLL upon closing an IDLE window, but haven't been able to reproduce. OK, I can, it's easy: Open IDLE. Ctrl+O, then navigate to e.g. Tools\idle\config.txt and open it. Click the "close window" button. Boom -- invalid page fault in TK83.DLL. No time to dig further now.

On Sun, 2 Apr 2000, Tim Peters wrote:
Ack! No way... Keep my top-level clean! :-) This is Windows. Apps go into Program Files. That is Just The Way It Is. When was the last time you saw /python on a Unix box? Never? Always in .../bin/? Thought so. Cheers, -g -- Greg Stein, http://www.lyra.org/

Greg Stein <gstein@lyra.org> wrote:
if you're on a US windows box, sure. but "Program Files" isn't exactly an international standard... we install our python distribution under the \py<version>, and we get lot of positive responses. as far as I remember, nobody has ever reported problems setting up the path...
When was the last time you saw /python on a Unix box? Never? Always in .../bin/? Thought so.
if the Unix designers had come up with the bright idea of translating "bin" to "whatever might seem to make sense in this language", I think you'd see many more non-std in- stallations under Unix... especially if they'd made the root directory writable to everyone :-) </F>

On Mon, 3 Apr 2000, Fredrik Lundh wrote:
Yes it is... if you use the appropriate Windows APIs (or registry... forget where). Windows specifies a way to get the localized name for Program Files.
*shrug* This doesn't dispute the standard Windows recommendation to install software into Program Files.
heh :-) Cheers, -g -- Greg Stein, http://www.lyra.org/

Greg Stein wrote:
no, but Tim's and my experiences from doing user support show that the standard Windows recommendation doesn't work for command line applications. we don't care about Microsoft, we care about Python's users. to quote a Linus Torvalds, "bad standards _should_ be broken" (after all, Microsoft doesn't put their own command line applications down there -- there's no "\Program Files" [sub]directory in the default PATH, at least not on any of my boxes. maybe they've changed that in Windows 2000?) </F>

On Mon, 3 Apr 2000, Fredrik Lundh wrote:
Valid point. But there are other solutions, too. VC distributes a thing named "VCVARS.BAT" to set up paths and other environ vars. Python could certainly do the same thing (to overcome the embedded-space issue).
to quote a Linus Torvalds, "bad standards _should_ be broken"
Depends on the audience of that standard. Programmers: yah. Consumers? They just want the damn thing to work like they expect it to. That expectation is usually "I can find my programs in Program Files."
Incorrect. Site Server had command-line tools down there. Cheers, -g -- Greg Stein, http://www.lyra.org/

[/F]
[Greg Stein]
And put the .bat file where, exactly? In the Python root, somewhere under "Program Files"? Begs the question. MS doesn't want you to put stuff in System32 either, but it's the only rational place to put the DLL. Likewise the only rational place to put the cmdline EXE is in an easy-to-get-at directory. If C:\Quickenw\ is good enough for the best-selling non-MS Windows app, C:\Python-1.6\ is good enough for Python <wink>. Besides, it's a *default*. If you love MS guidelines and are savvy enough to know what the heck they are, you're savvy enough to install it under "Program Files" yourself. The people we're trying to help here have scant idea what they're doing, and dealing with the embedded space drives them nuts at the very start of their experience. Other languages understand this. For example, here are pieces of the PATH on my machine: C:\PERL5\BIN D:\JDK1.1.5\BIN C:\WINICON\BIN E:\OCAML\BIN

Sorry I'm late -- I've been out of town. Just two FYIs: 1) ActivePerl goes into /Perl5.6, and my guess is that it's based on user feedback. 2) I've switched to changing the default installation to C:/Python in all my installs, and am much happier since I made that switchover. --david

I've pretty much made my mind up about this one. Mark's mention of LoadLibraryEx() solved the last puzzle. I'm making the changes to the installer and hope to release alpha 2 with these changes later this week. - Default install root is \Python1.6 on the same drive as the default Program Files - MSVC*RT.DLL and PYTHON16.DLL go into the system directory; the MSV*RT.DLL files are only replaced if we bring a newer or same version - I'm using Tcl/Tk 8.2.3 instead of 8.3.0; the latter often crashes when closing a window - The Tcl/Tk and expat DLLs go in the DLLs subdirectory of the install root Thanks a lot for your collective memory!!! --Guido van Rossum (home page: http://www.python.org/~guido/)

All worked without incident for me under Win95. Nice! Would still prefer that it install to D:\Python-1.6\ by default, though (instead of burying it under "Program Files" -- if you're not on the Help list, you can't believe how hard it is to explain how to deal with embedded spaces in paths). So far I've seen one system crash in TK83.DLL upon closing an IDLE window, but haven't been able to reproduce. OK, I can, it's easy: Open IDLE. Ctrl+O, then navigate to e.g. Tools\idle\config.txt and open it. Click the "close window" button. Boom -- invalid page fault in TK83.DLL. No time to dig further now.

On Sun, 2 Apr 2000, Tim Peters wrote:
Ack! No way... Keep my top-level clean! :-) This is Windows. Apps go into Program Files. That is Just The Way It Is. When was the last time you saw /python on a Unix box? Never? Always in .../bin/? Thought so. Cheers, -g -- Greg Stein, http://www.lyra.org/

Greg Stein <gstein@lyra.org> wrote:
if you're on a US windows box, sure. but "Program Files" isn't exactly an international standard... we install our python distribution under the \py<version>, and we get lot of positive responses. as far as I remember, nobody has ever reported problems setting up the path...
When was the last time you saw /python on a Unix box? Never? Always in .../bin/? Thought so.
if the Unix designers had come up with the bright idea of translating "bin" to "whatever might seem to make sense in this language", I think you'd see many more non-std in- stallations under Unix... especially if they'd made the root directory writable to everyone :-) </F>

On Mon, 3 Apr 2000, Fredrik Lundh wrote:
Yes it is... if you use the appropriate Windows APIs (or registry... forget where). Windows specifies a way to get the localized name for Program Files.
*shrug* This doesn't dispute the standard Windows recommendation to install software into Program Files.
heh :-) Cheers, -g -- Greg Stein, http://www.lyra.org/

Greg Stein wrote:
no, but Tim's and my experiences from doing user support show that the standard Windows recommendation doesn't work for command line applications. we don't care about Microsoft, we care about Python's users. to quote a Linus Torvalds, "bad standards _should_ be broken" (after all, Microsoft doesn't put their own command line applications down there -- there's no "\Program Files" [sub]directory in the default PATH, at least not on any of my boxes. maybe they've changed that in Windows 2000?) </F>

On Mon, 3 Apr 2000, Fredrik Lundh wrote:
Valid point. But there are other solutions, too. VC distributes a thing named "VCVARS.BAT" to set up paths and other environ vars. Python could certainly do the same thing (to overcome the embedded-space issue).
to quote a Linus Torvalds, "bad standards _should_ be broken"
Depends on the audience of that standard. Programmers: yah. Consumers? They just want the damn thing to work like they expect it to. That expectation is usually "I can find my programs in Program Files."
Incorrect. Site Server had command-line tools down there. Cheers, -g -- Greg Stein, http://www.lyra.org/

[/F]
[Greg Stein]
And put the .bat file where, exactly? In the Python root, somewhere under "Program Files"? Begs the question. MS doesn't want you to put stuff in System32 either, but it's the only rational place to put the DLL. Likewise the only rational place to put the cmdline EXE is in an easy-to-get-at directory. If C:\Quickenw\ is good enough for the best-selling non-MS Windows app, C:\Python-1.6\ is good enough for Python <wink>. Besides, it's a *default*. If you love MS guidelines and are savvy enough to know what the heck they are, you're savvy enough to install it under "Program Files" yourself. The people we're trying to help here have scant idea what they're doing, and dealing with the embedded space drives them nuts at the very start of their experience. Other languages understand this. For example, here are pieces of the PATH on my machine: C:\PERL5\BIN D:\JDK1.1.5\BIN C:\WINICON\BIN E:\OCAML\BIN

Sorry I'm late -- I've been out of town. Just two FYIs: 1) ActivePerl goes into /Perl5.6, and my guess is that it's based on user feedback. 2) I've switched to changing the default installation to C:/Python in all my installs, and am much happier since I made that switchover. --david

I've pretty much made my mind up about this one. Mark's mention of LoadLibraryEx() solved the last puzzle. I'm making the changes to the installer and hope to release alpha 2 with these changes later this week. - Default install root is \Python1.6 on the same drive as the default Program Files - MSVC*RT.DLL and PYTHON16.DLL go into the system directory; the MSV*RT.DLL files are only replaced if we bring a newer or same version - I'm using Tcl/Tk 8.2.3 instead of 8.3.0; the latter often crashes when closing a window - The Tcl/Tk and expat DLLs go in the DLLs subdirectory of the install root Thanks a lot for your collective memory!!! --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (5)
-
David Ascher
-
Fredrik Lundh
-
Greg Stein
-
Guido van Rossum
-
Tim Peters