Windows distribution suggestions?

[Paul Rubin]

Bernhard Holzmayer <Holzmayer.Bernhard at deadspam.com> writes:
> > Hmm, ok, it looks like the paid version is around 500 USD....
> > I'll see what the
> > customer says but I think they might resist.
> 
> 1) Maybe you can start with the 30days demo license to find out.

Yes, I'd certainly do that first.

> 2) The high price is paid for the benefit, that you won't get lost inside
> the terrific installation jungle like registry, access restrictions, dlls
> etc. In the end, it's your benefit, not your customer's.

Well, both would benefit, I think.

> If I were the customer, I'd demand a fluent installation process at no cost
> and without any risk and/or conflict with other installed software. 

Of course the customer wants this, but in reality it's going to have
to cost them, so I have to explain that and let them decide.  

> If I were the developer (you), I'd compare all costs/times with that price.
> If you calculate one hour for let's say 25 USD, the question is: will it
> save you 20 hrs. I guess so. If you have spare time, it doesn't get paid.

I wonder if I'd be trading off 20 hours messing with py2exe or
whatever, against 20 hours of learning curve with Wise.  Is Wise
really easy and fast to get started with?  Well, I guess that's what
the evaluation version is to help find out ;-).  

I'm concerned that it's going to be the same 20 hours either way (as
compared with just having them install python.msi separately), and 20
hours of development probably means a full week on the calendar
because of meetings, phone calls and all that usual stuff.  This app
is a small component of a big project and spending an extra week on it
means the whole project takes longer, which is never a good thing.

> > The app works ok under Windows now.  
> Congratulations.

Ehh, no big deal, there's not much system dependency so far, and it
was developed under Windows (with IDLE even) from the beginning.  It
may get more system dependent later.

> Then you'll probably use ODBC, since the MySQL server will probably not be
> run under Windows and on the same machine. 

Hmm, at least at first I'd run MySQL on the same machine under Windows
(I know MySQL can run under Windows) but maybe that still needs ODBC.
Eventually it may have to talk to another DB like Oracle.

> > I don't want to need an admin account.  
> Nobody wants that. It just happens...

Sigh.  I guess it figures.

> > reads and writes a few files and talks to some sockets.  
> Not that trivial! Plan enough time for testing.
> And, if you install without sophisticated tool, reserve enough time for
> troubleshooting and modifications...

Yeah, I really want to keep the installation stuff simple.  

> If the customer runs it on different machines, make sure that you always
> have one installation around where you work, which is exactly as the one at
> the customer's site.

Hmm, maybe not so easy, the customer may be using several different
Windows configurations in different places.

> If the customer is able to run different versions at
> the same time, keep one living copy of every possible version.

For now, I think I can say they have to track the current version.
It may be an issue in the future.

> [self-updating feature built into the app]
> Have a look at one of the Adobe Acrobat Reader's newest versions. They do
> this. Indeed, it doesn't work on my computer, but that's the idea...

Well, it's something to keep in mind, but I'm hoping this stays simple.

> > I just put the app's files in C:/Program Files/appname...
> 
> Don't do that,... In other countries even Windows uses different
> path names (e.g. here in Germany C:/Programme). 

Good point!!!  Yes, the customer will be running some non-English
Windows installations.  Thanks for mentioning this, I'm sure I would
have otherwise found out the hard way.  

> According to Microsoft's Technical Reference, you'd better ask the
> registry to find out where applications usually reside. (That's what
> professional installation software does.)

Hmm, I think there's a Python function to read registry entries.  I
better check the docs.  Can I just use C:/Appname like the Python
installer does?  If I have a way to launch the gui at all, I guess I
can have a configuration screen that lets the user change that
location.

> >> Isn't Visual C++ still coming with a restricted version of InstallShield?
> >> ...
> Check the installation. Your StartMenu should show the appropriate entry
> under VisualStudio/...tools... If not, maybe you forgot to install it.
> Or, it's gone away like some other precious tools...

I didn't see anything like that in the tools menu, but it's possible I
didn't install it.  I think it's a 2-CD installation and I only
installed one of them (the guy at the office said that's the usual
way).  It's Visual Studio 6 (the customer is on MSDN and supplied me
with the machine).

> In contrary, that's what really makes fun. The registry is like a bomb in
> your hand - it provides mighty power over the user!!!

Arrgghhh!  ;-)

> > and something is sure to eventually go wrong and corrupt 
> > the registry, if this is anything like the Windows that I'm used to
> > hearing about.  Sigh.  Just how bad is that under Windows XP?
> Don't worry. That's very secure and fairly straigth-forward. 

Well, ok, I guess these fancy installers must have gotten better with
that.  The usual disease I've seen is some installer wants to change
100 registry entries and something goes wrong halfway through, so only
50 of them get changed and the registry is then hopelessly
inconsistent.  It's not like a real database with atomic commits and
rollback.  The system still runs with the corrupt registry, but it
sort of degrades and crumbles and eventually you have to reinstall the
OS from scratch.  I remember a common syndrome with Windows 95 was the
MSIE browser scroll bar grew to about 3x its usual width.  Your system
was then within a few hours of becoming completely wedged.

> Are you sure that this had to do with registry modifications?
> Take a Linux box, remove the contents of /etc, and then reboot.
> What happens???
> You're not stupid, are you? 
> You wouldn't do that on Linux, so why should you spoil the registry?

Well, it's uncommon for any Linux user app to go messing around with
system files, especially dozens of them haphazardly.  Usually the app
puts its config info in its own file.  

> > and then I can put together a distutils setup.py thingie 
> > which they'd run separately.  
> You're familiar with that? If so, yes, that's feasible.

I haven't done it before, but the docs look reasonable, so I'm
assuming I can figure it out.

> But don't ask the user to launch setup.py.
> If there's a GUI anyhow, why not launch it from there.

Hmm, how would the GUI get started?  I don't like the idea of making
the user type "python setup.py install" from a dos prompt but just
double clicking on a setup.py (or install.py) icon doesn't seem too bad.

> What about this, since you have VisualC++ around:
> 
> Write a simple C++ app, which launches the Python installer, then launches a
> Python script which does all the other stuff?
> Call it Setup.exe, place it on the top level of your CD, and there you
> are...

Hmmm, is that easy to do?  Just fork a process, wait for it, and fork
another one?  Maybe that's the simplest idea of all.