#VB Install routine
41 messages in this thread
George,
PLEASE, don't just use SendKeys, at least not for apps that are to be
released to the general public. I have had several install programs blow up
when using Norton Desktop as the shell, because some simple-minded install
program assumed that ProgMan was running as the shell!
— Jim F.
There is 1 Reply.
Jim,
Actually, I'd never assume that PROGMAN was running. Before using SendKeys,
I would always run the program in question, check to make sure it was
running….THEN use SendKeys. PROGMAN is always available, unless some
fool deleted it after installing Norton Desktop or some other
memory-hogging Windows shell program. All you have to do is Shell up the
program you want to use.
Still, you're absolutely right about not assuming anything about the user's
environment. For that reason, I choose not to distribute an installation
program with my applications. Rather, I provide step by step instructions
for manual installation.
George
There are 2 Replies.
George,
My mamma always said I was a little wierd, but never to the point of
calling me a "fool". <g!> I must confess that I submitted Progman to the
big DEL after using LAUNCH 2.0 as my shell for a while. I just couldn't see
wasting 54k of good disk space for this piece of garbage not to mention
only having 73% free resources while LAUNCH gives me 89% free resources. I
must further confess to having saved it to a diskette for those occurances
when some sadistic programmer insists on using the OF_Prompt parameter that
gives you the "Install diskette in drive A:" when it can't find a file.
Actually, I had a major "Book burning" one evening when Progman,
Smartdrive, Himem.sys, FileManager and PrintManager were all sacraficed
after being replaced by LAUNCH, Hyperdisk, Qemm and PrintCache along with
the return of the lowly MSDOS.EXE.
–dennis
There are 2 Replies.
Dennis,
I've heard of all of them BUT printcache. Now I need the WHO,WHAT
WHERE,WHEN and WHY (the 5 Ws)
Charlie
There are 2 Replies.
Charlie:
I use all of them BUT PrintCache. Actually, I have PrintCache too, but
it wasn't giving me any speed advantages under Windows 3.0 so I dumped
it. In the year and a half I've had it, I haven't heard a peep from the
vendor about an upgrade…
There is 1 Reply.
Keith,
What are you using with 3.0? PrintManager? I don't see any difference in
the time from clicking print until everything's in the spooler. Where I see
a *HUGE* difference is windows itself while the job is spooling out.
Windows seems to perform just as if nothing was being spooled to the
printer but under PrintMgr, even with low priority selected, things
definitely *slow* down until the print que empties. Were you using the
XXXX.PRN setting with the dynamic timer?
I just talked with Lasertools last week. They are just finishing up a
windows verison of Pcache which should be out by the end of the year. It
will be a free upgrade if you have ver 2.3a.
–dennis
There is 1 Reply.
Dennis:
Well, maybe I should check into getting 2.3a and trying it again. Yes, I'm
using Print Manager, but the only place I really see a slowdown is when I'm
using Unicom (you actually have to keep clicking on the nicom window to
update it's screen area with the downloaded characters; very strange). Also,
when I last tried it I only had 3 megs and now I have 8 and am using QEMM,
so it'll probably be a better "fit".
Charles,
PrintCache is from LaserTools in Emoryville, CA. Among the heavy duty DTP
and Postscript crowd, it is THE print spooler. It's literally just like
printing a job to a file. Once it's in the spooler, there is NO, and I
repeat NO, slowdown in windows! And that's using it with a disk cache.
Loads hi with Qemm and only takes up about 19k. It's SO nice not having
molassis windows for thirty minutes while you print a 4 or 5 meg PS file.
It even works beautifully for downloading fonts.
And the irony of the whole thing is that it's a DOS app not even designed
for windows. They will have a windows specific version out in a few months,
but other than being able to see the spooler status without having to shell
to DOS, I'm not sure what could be any better.
–dennis
There are 2 Replies.
Dennis:
They were promising the Windows version RSN a year ago. What version do
you have? I just checked (actually I just loaded it while shelled from
Recon while shelled from Windows, which hung my machine, but I guess that's
what I expected to happen anyway), and I have version 2.2; is there anything
newer?
There is 1 Reply.
Keith,
I'm pretty sure the latest version is 2.3a.
–dennis
Dennis,
Load Hi – whats that? <g> Us lowly 286 users can't do that!
Thanks Charlie
Dennis,
Well, I really didn't mean fool :). I'm going to test before I send any
keys anywhere. Actually, the more I see, the less likely I am to write an
Install program.
George
George,
I'm a little sensitive to this issue right now. I help out in the NORUTL
forum as section leader, and a lot people are having problems with installs
that aren't as "smart" as the method you outlined. Some major league
culprits are Ami 2.0 and Pagemaker.
— Jim F.
There is 1 Reply.
Jim,
Does the norton product have a nice DDE interface with which install
routines can interact? -=- Jonathan
There are 2 Replies.
Jonathan,
Install programs, whether you write them for the DOS or Windows
environments, always have some difficulties. Since users can do what they
want with their systems, you can't count on anything at all being there.
I confess that I would never even think of deleting Progman, just for the
installation reason. I suspect that many developers simply assume that
Progman is on the system and available. While I tend to agree that it's not
the best shell available for Windows, I can't imagine physically deleting
it.
Still, that's the reason I don't include an installation app with my
shareware, relying on step-by-step instructions to the user, often in a
separate doc file. That's not ideal, but at least it leaves things open
for the user.
I think the basic problem for low-end developers is that it's simply
impossible to test or even anticipate all of the ways a system could be set
up. I wish there was an answer.
George
There is 1 Reply.
George,
<< … impossible to test for all the ways a system could be setup … >>
This may not be that difficult with windows because so much of the setup
in included in the win.ini and system.ini files in very well defined
formats. Additionally, windows will tell you the name and location of the
main and system directory no matter what the name or location.
For example, you can find out which shell is used with a simple
GetPrivateProfileString call to system.ini. If it's not progman, you can
still easily see if progman is still in the windows directory with the
OpenFile call. If it's not the shell and not on disk, then bypass any code
in your install that would setup a program group. Pretty simple and
straight forward.
Perhaps some humble soul could put together a generic system
configuration generator that could be used with install programs. It would
be a fantastic way of really getting comfortable with the api calls.
–dennis
There is 1 Reply.
Dennis,
That sounds like a good idea to me. However, I'm not nearly competent
enough around external function calls to create what you're describing.
What I'd like to see someone do…and I'd pay for it…would be a generic
installation program. It could read a file containing the filenames to
copy or unzip from the source, then take care of the rest of the
installation.
If I knew enough about this stuff, I'd write a program like that in a
flash, just so I'd have it on hand for future apps. For now, though,
lacking something like that, I'll just continue to give my usual
installation instructions to the user, trusting that far more than my own
feeble efforts.
I'm still trying as much as possible to stay within the VB internal
stuff…for a couple of reasons. First, the more external calls a program
makes, the more likely it's going to have incompatibilities with Win 3.1, I
would think. For a shareware author, that's an unmitigated disaster, since
everyone would have to be sent an update if the current version wasn't
compatible. Since I charge just $15 for my shareware, I simply couldn't do
that for hundreds of registered users without bankrupting myself.
I'm assuming that MS is going to keep VB compatible with itself at least.
So I remain a conservative, using only those calls, such as to the GDI's
StretchBlt, which are unlikely to change.
Ah well….
There are 3 Replies.
<< That sounds like a good idea to me. However, I'm not nearly competent
enough around external function calls to create what you're describing. >>
George,
I've been BS'd before, but this may be the best! <G!!!> You may not be
familier enough, yet, but you're sure more than competent enough. If you
can use a statement like x = function(a, b, c) in basic, you've got all the
competence you need to use the api calls. That's literally all they are.
Plug in some variables and get back a return value.
Tell you what I'd be glad to do. You outline the generic install routine
you'd like to have. I'll indicate where, why and which API calls I'd use in
it as needed, but you get to code them. After the 3rd one, you'll be
saying, "Hey, this is NEAT!"
–dennis
There is 1 Reply.
Dennis,
Familiarity is probably the problem, I suppose. Still, you have to admit
that it's not as easy to make a complex API call, say to something like
StretchBlt, as it is to define a property in VB.
I'm getting more familiar all the time with the functions, and I can use
them. It's just that I'd prefer not to most of the time, for some of the
reasons I outlined before.
George
George,
I have actually put a number of hours into an installation program
written in VB for use by other programmers. The idea was to include it
with my book but to install the files on the disk but also as a sample
program. At one point, I was considering using it as an example of how to
create a p-code engine but I started to think that was foolish when
everyone that used it would have VB. I have instead opted for a module
that contains a number of high level functions and subs that can be used in
your installation "script." The idea here is that when you are all done,
you can actually create a custom SETUP.EXE but the code is easy to
maintain. The whole thing would be pure VB and it could use the Win
LZEXPAND DLL for decompression. One thing that would make it really unique
would be the option to have it copy files in the background while you play
Solitaire or something. This still leaves the issue that VBRUN100.DLL
would have to exist someplace in uncompressed form. I'm up in the air
about it now. What are your thoughts? -=- Jonathan
There is 1 Reply.
Jonathan,
That sounds like exactly what's needed for installation. You're right about
the VBRUN100.DLL problem, however. Is there a way to determine the path to
the Windows 3.0 directory? If so, you could simply check for the file's
existance, then copy the library to that directory if it wasn't already
there.
You might end up putting a second copy on the system, but in most cases, I
think users are putting the library in their Windows directory anyhow.
If I'm not mistaken, VBRUN100.DLL will work if it's anywhere in the path,
right? You could even check for the file in every pathed directory before
copying it.
In other areas, I'd be more than glad to pay a reasonable fee for such a
program, but it'd have to be on a non-royalty basis for distribution.
I'd also like, if it were my option, to be able to put my own logo and
other information on the screen as the install program ran, as a BMP file
or whatever.
My two cents worth,
George
There are 2 Replies.
George,
The API's OpenFile function will search the current directory and the
*entire* path for a file when used with the OF_EXIST parameter. It's very
useful for installation utilities in that sense. Hope this helps.
Costas
There is 1 Reply.
Now Costas, we *must* not pick on George about api calls like this! <G!>
I've been hard enough, and he's going to think we're ganging up on him.
BTW, OF_EXIST is a fantastic file existence tester. Definitely worth a
mention in VBTIPS.
–dennis
There is 1 Reply.
George,
The real problem with VBRUN100.DLL is that it would be required to
run the SETUP program! IOW, if you could not guarentee that it was in the
path someplace, (still hard to guarentee at this point!), than it would
have to exist in non-compressed glory on the install disk. It is this fact
that is holding me back the most. A 300k install routine is a *little* out
of the ordinary. Could we tell users tha they have to have the file on
their system already in order to install. Should I write a little C
program that checks/copies the DLL and then launches the VB program. The
stuff about the customizable bitmap would be a cinch because you would
actually have the source code to the install program, instead of a script
language. -=Jonathan
There are 2 Replies.
Jonathan,
Why not write a little PDQ program that copies the VBRUN100.DLL to the
appropriate place, and then runs the VB program? Heck, you could even do
it in assembly, though it'd probably be easier (and not much larger) to do
it with PDQ.
– Ted
There is 1 Reply.
Jonathan,
I hadn't though of that, actually. Hmmm. How about using a batch file and
the IF EXIST command, with a parameter the user must enter to identify
their Windows directory. You could copy or expand VBRUN100.DLL to the
appropriate directory, or even to the root, since that's always in the
path, then run your install program from the batch file. Clunky, but it'd
work, and I think just about everyone has C:\ in their path.
George
George,
I think you may be a bit too paranoid about making calls to the API. The
whole idea of Win 3.1 is that it's not supposed to break 3.0 apps. I'd say
that pretty much anything you'd call wouldn't be changed in 3.1. In fact,
the only thing that you should do is check the return values of the API
functions that you call because in 3.1 this will be more important, but you
should be doing this anyway. You might want to pick up the Sept. 1991
issue of the Microsoft Systems Journal which discusses the new things in
Win 3.1. Probably TrueType (scaleable fonts) will be the only thing that
would affect a VB programmer that I can think of.
– Ted
There are 2 Replies.
Ted,
I've olny seen 1 copy of MSJ, how do I get it!
Charlie
Ted,
I'm sure you're probably right about the API calls question, but there are
precedents for my concern. An app I wrote in QuickBASIC about a year ago
uses a large number of documented INTERRUPT calls. That application now
does not work with DOS 5.0. I'm still working on solving the problem.
That's why I'm sticking as far as possible with internal VB properties and
commands. They can't do it all, of course, so I've used API and GDI calls
when I need them, or when they can do something not available directly in
VB.
I'm sure that sticking with the basic calls will lead to a 3.1-compatible
app. I am concerned, however, with the reliance on external calls to
perform basic functions. It's been my experience that only a very small
percentage of programmers in QB *ever* used the INTERRUPT command….Ever!
Luckily, QB offered its own tools in sufficient quantity to make it
unnecessary.
Similarly, I expect that the bulk of VB programmers will not go to external
calls either. And there's the rub. Exploring StretchBlt, with the help
of Don Funk, leads me to the conclusion that very few people will be able
to figure that one out on their own. It's non-intuitive in the extreme. I
did a demo of using the tools (BMPKIT.ZIP in Library 1), to help out those
users who are not able to work this thing out. Still….how many VB users
are using this forum? A tiny percentage of VB owners, I suspect.
This is not obscure stuff, either. Being able to print bitmaps to a
standard device is essential for a graphical language. MS's omission of
that feature is still incomprehensible to me. It seems so basic that it
leads me to question motives here.
Too difficult to implement? No, that can't be it…MS could have made
those calls, keeping life simple for VB users.
I really like VB a lot, and will be developing in it from now on. I'm just
going to be glad when the next version appears.
George
George,
I understand your concerns about API calls and all. I just want to throw
in my two cents worth here. I think Microsoft would go out of business if
they suddenly decided to alter the API calls so significantly as to
endanger the operation of WinApps. I think that's one of the reasons MS
engages in such lengthy beta-test periods for both Windows and DOS. As a
result, from what I've been able to decipher from Petzold's article in MSJ,
Win3.1 *adds* functions to the API bringing the total to almost 1000
including the multimedia extensions. Of course, undocumented functions may
change at any moment and non-recommended approaches may become invalid but
I feel no threat when I'm making legitimate API calls.
Another point I'd like to raise is that in most cases whatever
display/graphics functions VB added would only be go betweens the API and
the run time DLL. As has been pointed out, this would make the DLL bigger
but also the execution time possibly slower. When I started fiddling with
Windows programming, I visited MSOPSYS to see what kind of issues the
Windows programming vets were up against. Frankly, not that different from
here: StetchBlt, BitBlt, DLLs, fonts, modal windows, same stuff. I felt
better. One message I read has really stuck in my mind. A novice Windows
programmer was seeking advice about taking the plunge into Windows
programming. The consensus there was: "if you're an experienced C
programmer, give yourself at least six months to learn Windows
programming." In all fairness to VB – it hasn't been out that long.
Costas
There is 1 Reply.
Costas,
You're absolutely right in everything you say. I'm sure that standard API
calls will survive the version change. MS wouldn't dare change the basics.
As I have said before, I love this environment. And you're right, stuff
like making some calls internal would just be go-betweens, but isn't that
what's happening throughout VB.
My concern comes when some particularly useful stuff *requires* API calls.
In QB, it was all there. I used external stuff only when it resulted in a
dramatic speed increase, sometimes ignoring a built-in function.
It's just that not everyone who buys VB is going to be as dedicated as you
and I and the rest of the people on this forum to exploring the external
possibilities. I look at the guy who just wants a little app that prints
sheets of his clip art files. With internal commands available, VB could
do that app in about 10 minutes. Without them….it could take forever.
I actually tried a Point/PSet version of a graphics printing utility. It
worked, but printing a 300X300 mono BMP file took over an hour! A simple
method added to the Printer and Picture Box objects could mediate this
problem.
I want Scalex, Scaley, and PrintImage available. It'd be a lot simpler for
MS to add that to VB than it will be for all those users to figure it out.
George
There are 2 Replies.
Jonathan,
I don't know what the particular DDE call is, but apparently there is a
"clean" way to send the message to create a group that any shell can react
to. Bill Hall, in the NORUTL forum, puts it in laymen's terms that "some
apps don't properly broadcast the messages to create a group, but instead
try to deal with ProgMan directly." I take this to mean that instead of
making the DDE call they use the equivalent of the SendKeys() function on
ProgMan.
— Jim F.
There are 2 Replies.
Jim,
That sounds crazy. Why wouldn't authors use the DDE interface since
it is documented and much cleaner than something like SendKeys. Are you
saying that ND will respond to the same DDE commands as ProgMan? Could you
confirm this for me? Thanks. -=- Jonathan
There is 1 Reply.
Jonathan,
I don't have all the technical details, but I *have* installed Windows
programs that correctly were able to create groups in Norton Desktop
without ProgMan running. They were obviously doing something right: i.e.
broadcasting the correct messages. I have also installed programs (Ami 2.0
and Backgammon, by George) that blow up when attempting to create a group
because they expect to find ProgMan. It was *my* interpretation that the
bad installs were using a Sendkeys()-type technique. I don't know
specifically what they were doing wrong. I'm sure Bill Hall in NORUTL would
be able to give a more specific answer. I'm interpreting "laymen's" terms
to the preachers!
— Jim F.
Jim,
Okay, I didn't mean to jump all over you, I was just curious. I
suppose if I am going to write an install routine, I should by Norton
Desktop of at least get the specs. Is it easy to un-install? -=- Jonathan
There is 1 Reply.
Jonathan,
NDW saves your important files (autoexec, config, win & system.ini) with
the extension .nd0. You can return to the original state by renaming these
files back.
— Jim F.
There is 1 Reply.
Jim,
Thanks for the info! -=- Jonathan
Jim:
Well, the ProgMan in 3.0 doesn't implement full DDE. I didn't have any
specs for it, but I played around with a VB tool for examining DDE
connections and the only thing I got to work was:
Application: PROGMAN
Topic: PROGMAN
Item: (null)
which returns a list of ProgMan groups. There must be more in there, but
since it doesn't even support a SYSTEM Topic, I gave up pretty early.
There is 1 Reply.
Keith,
The DDE protocol to talk to the Program Manager is defined in the Windows
Guide to Programming starting on pg 22-19. It shows how to add/delete/show
a group and add/delete an item.
– Ted
There is 1 Reply.
Ted:
I think it's more of a challenge to do it without reading the docs! <g>
Seriously, you SHOULD be able to query an application and get most of
anything you need back. For example, without reading the docs (if indeed
there are any) for Excel, I found the following:
EXCEL SYSTEM STATUS Ready
EXCEL SYSTEM FORMATS XlTable
Biff3
SYLK
Wk1
Csv
TEXT
Rich Text Format
DIF
BITMAP
METAFILEPICT
Printer_Picture
EXCEL SYSTEM SELECTION Sheet1!R1C1
EXCEL SYSTEM PROTOCOLS StdFileEditing
Embedding
EXCEL SYSTEM TOPICS Sheet1
System
EXCEL SYSTEM EditEnvItems StdHostNames
StdTargetDevice
StdDocDimensions
EXCEL SYSTEM SYSITEMS SysItems
Topics
Status
Formats
Selection
Protocols
EditEnvItems
Keith,
Oh, of course…ProgMan should support the SYSTEM DDE "standard," but I
think they fixed that in 3.1. However, at least it's documented, which is
more than I can say for other things! <g>
– Ted