At one point, not too long ago, I felt confident in an understanding of
the installation process but with the advent of VB5 and the DAO3.5
engine I've had to reconsider that position, and have some questions
concerning such.
First, let me begin with a preface of hardware/software specs. I'm
using NT4(svc pack 2) as the development o/s, targeting both NT4 and
Win95 platforms. The setup programs I'm using are VB5's setup wizard
(only as a benchmark, to verify if it does an install correctly and get
a list of the requisite files) and InstallShield3 (3.00.111). The
hardware is probably a lot less relevant, however, it's a basic Asus
Pentium 133 w/64mg. The testbed is networked with the development
machine along with enough partitions that everytime I want to test an
installation I copy a fresh install of the Windows and Program Files
directories into the desired partition and reboot the machine. This
ensures no lingering dll's or registry entries to cloud the results.
I have never had such problem with the DAO engine until recently. For
some reason it simply wouldn't fly, no matter what I tried. Either the
program looped unending in an error, or I got wierd run-time errors like
"...unable to load dll" during a form load event. None of the problems
experienced were visible during development in the design environment,
and neither VB5's setup wizard or the InstallShield installation
differed in that respect. Then when trying to document the problem for
tech support I ran into something I'd never noticed before, there are a
number of files critical to the installation process which are
completely different in the [vb directory]\setupkit\kitfil32\system32
directory than are in my development machine's system32 directory.
Specifically for the DAO installation:
file setupkit directory windows system directory
--------------------------------------------------------------------------------
ASYCFILT.DLL 120,592 01/15/97 120,592 12/14/96
COMCAT.DLL 22,288 10/31/96 21,504 04/04/97
MFC40.DLL 921,872 07/31/96 921,872 08/02/96
MSVCRT20.DLL 253,952 07/31/96 253,952 08/02/96
MSVCRT40.DLL 326,656 07/31/96 65,024 08/02/96
OLEAUT32.DLL 491,792 01/15/97 491,992 12/14/96
STDOLE2.TLB 16,896 01/15/97 16,896 04/04/97
Some questions that I've got now are:
1) Why the difference in versions of these files between the
development Windows System directory and the setupkit files?
2) When installing core system components, some files are operating
system specific. Where would such a list as that be for the benefit of
developers? A good for instance would be the COMCTL32.DLL file. Unless
I'd seen someone else posting a message to that effect I may have gone
through a few hoops before realizing the cause-and-effect relationship
there.
3) Without the benefit of the InstallShield White Paper on Win95 logo
compliance, I wouldn't have a clue as to the nuances of registry entries
for DAO and core components. Am I looking in the wrong places or is
there someplace where I can receive up-to-date information about these
issues?
4) What subtle differences are there between a Win95 versus a WinNT
installation? Where do I find that as well?
5) The setup wizard has an entry for a process "tlbregister":
ACTION: TLBRegister: "C:\WINDOWS\SYSTEM\StdOle2.tlb"
What exactly is the registration process for a type library?
Hey, I know this has been a long and boring business. I hope that I'm
not the only one experiencing these problems, and with these questions.
Many thanks in advance for whatever response you care to submit.
jb
PS: You may be wondering what tech support had to offer...
We ourselves sometimes have trouble finding information of the sort you
seek, as far as file versions and platform differences.
I can tell you that many files are operating system specific. For
example, there's a copy of msvcrt40.dll that comes with NT4 and is
explicitly non-distributable. In this case it helps to look at the file
properties, and then the extended version information under the version
tab. I use information provided by properties and by QuickView
constantly when taking calls, as well as resources like the dependency
files. In VB5 that's vb5dep.ini and the *.DEP files. In VB4 that's
sw16tmpl.ini and sw32tmpl.ini for 16 and 32 bit respectively. That tells
me what is a dependency of what, and whatneeds to be registered.
Obviously depending on the issue I may look at the help files, or query
in our KB. Sometimes I use the MSDN, Technet, or the KB at
www.microsoft.com if the usual tools are down or I need information like
the API documentation that's specific to MSDN. I checked in the April
MSDN and couldn't find anything that looked like tips for querying, but
last I knew the web site offered tips for effective KB querying.
Unfortunately, the syntax I'm used to for our internal KB interface
differs somewhat from that used on the web site and MSDN, and I always
find querying on those a bit more difficult for that reason. It's always
a good idea to try querying an error message or a distinctive piece of
it verbatim in quotes, like "failed to initialize when called" or
whatever the case may be. Querying tends to be something of an art and
has a definite learning curve. It's one of the things that separates new
support personnel from experienced ones. It never hurts to poke around
our web site in general, and through www.microsoft.com/vbasic there are
many links to other useful sites. If you browse MSDN and the web site
just to get acquainted when you're not actively having a problem, it's
easier to find things when you need to. It can be extremely useful to
post issues on usenet, usually on
comp.lang.basic.visual.misc. Check out www.dejanews.com to query the
entire base of past postings, and maybe you'll find information you need
without making anew post to the group at all. I'm not certain this
precisely answers your question, but the fact is that there isn't really
information particularly on file version difference problems, so you're
not remiss in being unable to locate it. I do hope this helps and
provides you with some useful tips.
Joseph, on the idea that the above information should address your
questions sufficiently, however obliquely, I am closing this case as
resolved. Should you find that you need further assistance with this
particular issue, please open a NEW service request and in it clearly
indicate that you still need help with [###############]. We will then
reopen this support incident and not decrement your support account.
Microsoft Developer Support
VB5/DAO3.5 Install