Mail Archives: djgpp/1996/06/18/16:17:08
This is a multi-part message in MIME format.
--------------6FDB229734D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Unsubscribe
--------------6FDB229734D
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Return-Path: <owner-djgpp-list AT delorie DOT com>
Received: from delorie.com ([199.125.93.1]) by pleiades.InterCable.net
(post.office MTA v1.9.3 ID# 0-11598) with SMTP id AAA198
for <rpenia AT intercable DOT net>; Thu, 13 Jun 1996 19:10:59 -0600
Received: by delorie.com (940816.SGI.8.6.9/940406.SGI)
for djgpp-list id UAA00081; Thu, 13 Jun 1996 20:19:44 -0400
Received: from relay1.geis.com by delorie.com via ESMTP (940816.SGI.8.6.9/940406.SGI)
for <djgpp AT delorie DOT com> id UAA00064; Thu, 13 Jun 1996 20:19:37 -0400
From: j DOT aldrich6 AT genie DOT com
Received: by relay1.geis.com
(1.37.109.16/15.6) id AA091111567; Fri, 14 Jun 1996 00:19:27 GMT
Message-Id: <199606140019 DOT AA091111567 AT relay1 DOT geis DOT com>
Received: by (genie.)relay1.geis.com
( 2rem/1.40 ) ; Fri, 14 Jun 96 00:19:27 UTC 0000
( from inet# ; Fri, 14 Jun 96 00:18:32 UTC 0000)
Date: Fri, 14 Jun 96 00:01:00 UTC 0000
To: djgpp AT delorie DOT com
X-Genie-Qk-From: J.ALDRICH6
X-Genie-Qk-Id: 9620068
X-Genie-Gateway-Id: 558213
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Installer
X-Mozilla-Status: 0011
Reply to message 8125042 from LEE_B AT CELESTI on 06/12/96 4:09PM
>Yep, but it's still very unfriendly. A lot of people could install
>windows by hand to, but the installer makes it a hell of a lot
>more bearable. I'm just thinking that making the thing more
>user-friendly is the way to get more users. I mean, that's what all
>the other work's for, isn't it ? Most of us could do without docs,
>and look at the source code every time we need to know something,
>but it might increase the development time a bit =)
Actually, Windows is such a disgustingly complex program that I
wouldn't want to try manual installation if my life depended on it. :)
OTOH, you're right about the user-friendliness issue. I use the docs
nearly every day, and having a reader like info around makes it MUCH
easier.
>something to consider too. The other thing is that the batch file
>was very unfriendly because you'd lots of files to choose from,
>going through them a screen at a time.. if you changed your mind
>about a file (for example, because of disk space restrictions) you
>had to go through the whole process again.
That's simply an example of bad batch file design. There are
commercial installers that do things just as messily.
>The point is that that a powerful script language for an installer is
>basically just an enhanced batch file.
That makes sense.
>Nope, I want a generic installer that can be used for all DJGPP
>programs, including the actual DJGPP distribution itself.
Essentially, everything in the v2* tree of simtel?
>Well, it's not commercial, but there's no reason why it can't be
>presented and supported in a professional way..
You're right, of course.
>Yep, if we do get inline stubs, then I'd like to recommend JPTUI -
>it's a free TUI, and it looks great..
We don't even really need inline stubs - simply including CWSDPMI
with each and every distribution zipfile might solve people's problems.
I could see the installer program as a self-extracting archive that
contains the installer, CWSDPMI, and a readme file. People would
probably still find a way to screw it up, but that unfortunately is
impossible to prevent.
>No, I'm talking about when different programs that use DJGPP stuff
>are installed, they won't install ten copies of the same file in
>their own abitrary dirs because there's no standardised installation
>dirs.. I don't know about you, but I've had to delete a few extra
>copies of go32 and cwsdpmi.. not to mention .BGI files from programs
>done in borland.. Also, if files are always in one directory, the
>installer can check whether the file already present (if there is
>one) is newer than the one to be installed, and not install it in
>that case (ie, only perform updates).
Well, this is a very difficult problem to solve even for professional game
programmers. Consider the problem of DOS4GW. Every 32-bit
game nowadays includes a copy of it with their program, simply
because there's no way to guarantee that the user will have a current
version of the program available. Also, consider the problem if the
user, not knowing the file's importance, deletes it, and thus wrecks
the game that depended on its existence.
I have installed several Windoze games that use Quicktime or Indeo,
and every single one seems to insist on installing its own version of the
drivers, usually on top of whatever driver(s) were already there, and
usually regardless of whether those drivers were newer or not. After
installing Civ II, I discovered a directory called Z~MSSTFQ.T which
apparently contains the benchmark programs the game uses to
profile my computer's video performance. Talk about wierdness!
One possibility, which seems to be what you are referring to, is for
the installer to create (or look for) some standardized directory into
which it installs the latest versions of CWSDPMI and any other
needed drivers, and sets up the PATH to include that directory.
This is a good idea, certainly, but there are many dumb users
(and even some smart ones) who will see something like this and
delete the drivers out of sheer pique, and then complain to us when
their program won't run.
>Hmm.. that's true about non-standard dirs, and using the env var.
>But people using DJGPP programs aren't likely to have DJGPP, and even
>if they have other programs which are done with DJGPP, it's not
>guaranteed that they will have the env var set up when installing a
>new program.. there's gotta be a safe way of finding the right
>directory.
See my point above... unless you copy stuff directly into the WINDOWS
or DOS directory, there's no way to guarantee that a rambunctious or
just plain stupid user won't simply go and delete the stuff because he/she
doesn't know what it's for.
>There's no need for both.. one good generic installation program
>would do everything. It would be much more consistant too...
Agreed. It would certainly also be fun working around the problems
I mentioned above. :) I think I'll go and take a look at some of these
windowing libraries (JPTUI, for one), and see how they work.
John
--------------6FDB229734D--
- Raw text -