Message-ID: <31C72AC4.3C8@intercable.net> Date: Tue, 18 Jun 1996 15:16:36 -0700 From: rpenia AT intercable DOT net (Rafael Pena Villareal) Organization: ElecWorks S.A. de C.V. MIME-Version: 1.0 To: djgpp AT delorie DOT com CC: rpenia AT mail DOT intercable DOT net Subject: Unsubscribe Content-Type: multipart/mixed; boundary="------------6FDB229734D" 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: 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 ; 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 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--