Dependencies out of date error

Hi all.

I am struggling with my first public release and the PDW. I get through part of the build and get an error:

Code:

---

The wizard found dependency information for the listed files, but the information is out of date. To proceed with the out-of-date information, click OK.

---

Now, MS states that this was a bug in vb6 SP2 and earlier, but I have SP6, so theoretically, the error should go away with a Microsoft dll or ocx.
The files that throw the error are:
comdlg32.ocx
msstdfmt.dll
scrrun.dll

I also understand that ocx's and dll's are dangerous in that they can cause a system not to boot if the wrong version of ocx and dll are not installed with the matching OS.

MS also states that you can build a new .dep file for ocx files, but they explicitly say for ocx's that you built YOURSELF, not SOMEONE ELSE'S.

What to do?:(

While there was an old bug in the PDW this message is legit if you are on SP6.


What is really going on here is that you haven't really been following the rules by maintaining the Redist folder, normally at:

C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard\Redist

When using the PDW to make "real" builds for redistribution you are supposed to put the actual versions of VB6's DLLs and OCXs that you mean to deploy in here. Then the PDW will package using those copies and not your live system's copies (which has never been an approved thing to do). Along with those files you are supposed to put matching .DEP files in there.

The real reason for doing this is that your live system may well have patched versions (Windows Update, a newer OS, etc.) that can fail when deployed to downlevel systems.

Some people who do a lot of this will end up with several Redist folders and rename them before each PDW run. The reason for separate folders is that you may have to build separate PDW packages for different OS versions (Win9x vs. Win2K through WinXP vs. Vista through ...).


Of course most serious developers are creating Windows Installer MSIs instead of using the PDW. This lets you use the Merge Modules Microsoft supplies, which deal with the few cases where there are OS dependencies and a host of other potential ills.

These .MSMs have known stable versions that either (a.) run on any version of Windows, or (b.) are bundled in several tailored forms when there are OS-specific versions, or (c.) are older than the versions shipped as part of newer Windows versions and so they won't be deployed at all there.


But the vast majority of people can't be bothered to do either of these things. They want to use the PDW or some shabby 3rd party scripted setup maker and they want to deploy the live versions from their OS. In other words they don't want to work very hard as long as things mostly work most of the time.

If you fall into this camp you can either choose to just ignore those warnings or you can go in and update the .DEP files in your live system directories. Proceed with caution since it is easy to make small errors there.

VB6 Service Packs and Security Patches don't typically update the .DEP files and Windows Update never does. Contrary to what you might think from what you've read it is up to you to maintain .DEP files over time.

BTW: The main reason for the checking of the .DEP info against the library is in case a new version has new sub-dependencies that an "old" .DEP file won't have listed inside it. This has been rare to non-existant for the standard libraries shipped with VB6, making it a non-issue to ignore the warnings most of the time.


And of course a serious application needs both its install/uninstall and its runtime operation tested on various Windows versions before you ship it.

Thank you for the advice.

I'm one of those ones who do not want to make my program a headache for anyone. You can't please all the people all of the time, but you can certainly get close if you work at it. Someone in one of my other threads (perhaps yourself) mentioned to stay away from such installers as Inno Setup (referred to as No-No Setup). After playing with it for awhile to familiarize myself with it I could see that indeed, it is too easy to screw up somewhere if you are not familiar with it because you are screwing with behavior at the system level rather than more-or-less restricted to the program itself, which is roughly like a little sandbox in its own right.

But it looks like MS has managed once again to make a job harder than it needs to be for the programmer by leaving him with tasks that could easily have been handled automatically by a smarter compiler with more options (like target OS's, etc.).

So in that vain, if I run into dependency errors on some machines when I test install, are there any references out there that talk about editing dep files?

Also, when you mention to put your dependencies inside the redist folder, are you saying you can just pull them out of the system folders and PDW will sort out the details inside those files, and if not, where do you get pristine copies to put in there?

And it did not look like vb6 had anything to build msi's?

The biggest problem with setup tools that accomplish deployment by following a low-level script isn't so much the things they do, but the things they fail to do. Usually that means failing to examine file versions and not write old ones over new ones, failure to update usage counts for shared libraries and observe them on uninstall, etc. When you work at a low level you have to be very carefull to write all the script required and verify that it does what you need it to, which means you need to know a lot about how application "servicing" as it is called actually works.

VB6 suffers in that it was not originally designed to be used over the long lifetime it has had. Support fades rapidly for old tools because they are normally expected to be replaced by new tools or at least new versions. Consider that VB5 lasted a little over one year before replacement by VB6. VB4 lasted about a year and a half. VB3 about two years.VB6 has not been superceded by a new version in 14 years! It was the last of its kind.

There is no point in despair. If the effort to use it correctly on new operating systems is too much there are lots of alternatives you can move to such as the .Net languages, Java, and so on. Most people made the break by the time Vista finally appeared: 5 years after Win XP which itself had a good run as Windows versions go.


In late 1998 Microsoft provided Visual Studio 6.0 Installer 1.0 for creating Installer packages. Then in 1999 version 1.1 came out. These were meant to replace or supplement the PDW, and were free to Professional and Enterprise Edition licensees. Microsoft no longer hosts these downloads, having dropped them about 3 years ago.


A search on Google like dependency files site:support.microsoft.com should turn up quite a few MS KB articles of use in figuring out .DEP files. I have never seen any specific reference document that covers it cradle to grave though.


The only source for clean deployable VB6 libraries now is probably the set of SP6 merge modules. To use these with the PDW they need to be extracted and copied into the Redist folder, not a trivial task. To get around this I have taken a long detour:

• Create a Virtual PC VM.
• Install Windows 95 OSR2 in the VM. Windows 98 or 98SE work too.
• Install VB6 in the VM.
• Install VB6 SP6.
• Take the DLLs and OCXs from the VM and move them to the Redist folder of the development (real) machine.

Using Win9x gets around a lot of issues, leaving you with just the SP6 "universally deployable" versions. Of course they are only universal as long as your installers never write these over newer versions found on target machines.

I have an old laptop with an existing Win98 install on it. Could I not take the files from there and copy those?

You'd need to install VB6 and VB6 SP6 first.

But if the system isn't "clean" (never had VB6 or any VB6 application installed) you may still have a mishmash of versions there. And you still need to update .DEP files by hand since VB Service packs don't normally bother (after SP2 the assumption was that you use VSI 1.1 and the merge modules, not the PDW any more).

Plus we haven't even mentioned the VB6DEP.INI file's [Do Not Redist] section that you need to update to reflect changes since VB6 came out. A lot has changed since 1998.

Damn! Unnecessary headaches, but that's the way it is. Thanks for the guidance, and I'll check those KB articles, and fire up my old Toshiba Libretto...My tiny monster from the late 90s!

Let's cross our fingers and hope it still works ok. At least you'll only need to do this once: VB6 redistributable libraries are unlikely to ever get a new Service Pack.

If you haven't found the article yet Best practices for deploying Visual Basic 6.0 applications covers many of the issues we've talked about here.

Just note that some of it is out of date. For example the section there "Redistribute minimum dependencies" really only applies to downlevel systems (prior to XP SP3) since the items mentioned there are included in Windows starting with XP SP3. Go ahead and include them in setups you create that must install on downlevel systems, but make sure your setup package checks versions and won't try to write an older one over the top of a newer one already present on a target system. PDW setups and normal MSI packages do this check implicitly. Inno Setup and other 3rd party scripted installers might require that you script those tests yourself (or at least specify such a check for each deployed library).


But truthfully, in regard to your original question: the vast majority of people just "ok" the prompt about out of date dependencies.

I'm not sure yet, because I'm just starting to delve into deployment, but I think when I OK'd those, RichTx32.ocx wouldn't register. Not sure yet until I'm more familiar with what I'm doing, since when you're just playing around, you sometimes do things that you can't remember exactly what you did.

By the way, I downloaded VSI 1.1, and played around a little with that tonight.

Wel then you'll also want Merge Modules for Service Pack 6 for Visual Basic 6.0 and Visual C++ 6.0.

If you don't use those merge modules and you rely on the "Visual Basic Installer" wizard it will use the "live" DLLs and OCXs from your development system. Unlike the PDW it doesn't support a Redist folder as the source.


I did write a program that can extract the redist files out of those merge modules, however to do its job it needs Extract.exe from the Cabinet SDK, and Microsoft has pulled the download for that. While some may think it was combined into the Windows SDK, it wasn't - I've checked.

Fortunately I installed the CABSDK a long time ago, but for latecomers it's another case of "you snooze, you lose." :p

You might find a 3rd party hosting the download yet, but be sure to run a virus scan before using any you find out there on the wild and wooly web.

Thanks. I'll check.

Found two locations for cabsdk:
http://www.pixelsplasher.com/_downlo...t-Cabinet-SDK/
http://web.archive.o...n-us/cabsdk.exe

Checking for viruses now.

They're good...At least as far as Malwarebytes reports.

I have posted the extractor in the CodeBank at:

VB6 - Msms2Libs: Extract VS6/VB6 MSMs to Libraries

Ahh, Super! Thanks a million, dilettante!

Homework time!

dilettante,

In getting my dll''s and ocx's together, I noticed that three of them are not included in the merge modules, nor in the redist folder:
scrrun.dll 'Needed for the File System Object
richtx32.ocx 'Needed for RTBs
shfolder.dll 'Not sure what this one is needed for.

What do you do about these?

I suppose I could grab them from my old Win98 machine.

Hmm, I hadn't noticed that the RichTextBox's OCX isn't in that merge modules pack. That one is quite odd.

There is an alternate source for many ActiveX controls, a source of ActiveX control CAB files that was really intended for use by Web pages originally. It's a Microsoft site, and it is in disrepair like so many other things (home page is gone, index pages are gone, documentation pages are gone) but it is stil "alive" today and sourcing at least some ActiveX control CABs.

http://activex.microsoft.com/controls/vb6/richtx32.cab will get you the current stable RichTx32.cab file. Right-click and "save target as" in IE (or equivalent in other browsers). There isn't any human-readable HTML page there that I can locate right now.

The version there is 6.1.98.16 dated March 24, 2009 which is a bit newer than the baseline SP6 version. Be sure to test it for problems since it might contain the ill-fated hazardous "security rollup" patches that break so many VB6 controls (that's another topic: starting in late 2008 Microsoft has attempted to build and release a "security rollup" many times, most recently August 2012 I think - and they have never gotten it right yet).

But my guess would be that this version must be good and good across many versions of Windows since it is placed there for generic use within a Web browser page.

You'll want to extract the OCX manually. Either use the Cabinet SDK tools or on recent versions of Windows you can open a CAB file much like a ZIP file in Explorer, then right-click on a file there and choose the "Extract" menu item).


Regarding scrrun.dll and shfolder.dll:

These are non-deployable system components. They are great examples of things that should be listed in the [Do Not Redistribute] section of VB6DEP.INI to prevent the PDW from trying to package them.

See BUG: Distribution of Microsoft Scripting Runtime Library Fails for a discussion of a problem related to the DEP file for the Scripting Runtime. Also note the alternative suggested there for deploying to downlevel systems (prior to Windows 2000?) that do not already have scripting installed. Spoiler: It's an EXE package that must be run.

Don't fix the DEP file, instead don't redistribute the DLL at all except via that EXE package.

Why the DEP-breaking change at the ActiveX Cabinet site? Scripting changed to tailored code a long way back. The EXE package has different versions for different Windows versions and checks the system it is running on before picking a set of files to install there.

There are similar rules for deploying MDAC components. see:

How To Control Which MDAC Version the Package and Deployment Wizard (PDW) Distributes

A lot to chew on today. Just starting to get my mind around all of this.

Yeah, deployment is a large topic. Some people do nothing else as a full time job in itself.

Moved to the Application Deployment forum.

Thanks, Joacim!

dilettante,
The part about building one's own .dep files seems impossible unless there is some way to "launch" a dll and see what other dll's it tries to communicate with. I have opened up a few dlls and found that there are no strings called out for any dependencies, in the middle of all the binary, so something has to give away the dependencies. Otherwise, trying to build a .dep file from scratch seems futile.

Looks like Dependency Walker is the key.

But when I use Dependency Walker I find that it lists a bunch of dependencies that are different than what is in one ocx. For instance, if I check out comdlg32.ocx, the .dep file says there is only one dependency...comcat.dll (and versions of it for other languages). But when I use Dependency Walker, I see:
kernel32.dll
user32.dll
ole32.dll
advapi32.dll
oleaut32.dll
comdlg32.dll
...and more

as the "primary" dependencies (all the dep's. not including the ones that call still other libraries.)

Man, so many questions, so few answers from MS KBs.

If , for instance, we use a very early version of richtx32.ocx, then that means that it can overwrite a pre-existing LATER version in SysWOW64. Would that not cause problems for other apps?

If on the other hand, I put my earlier version of richtx32.ocx in my app folder, and register it there, it will not overwrite the LATER version in SysWOW64, BUT...It means that the OS will then, always go to my app folder to use it for all other apps (because it has the same name as the later version in SysWOW64), and I am back where I started, AND if my app is uninstalled, the ocx goes with it and the system is left in an unstable state due to the missing ocx. Unless I personally re-register the version residing inside SysWOW64.

If I rename my version of richtx32.ocx to something else, like Myrichtx32.ocx, then I would have to do the same for all of my redist dll's and ocx's. And since those are binary files, there is no easy way to change all of the myriad of dependency names in those files. So that seems dangerous and in the least, incredibly overkill and stupid.

Unless there is someway to tell the installer to keep my early versions of the libraries in my app folder completely isolated from the versions already existing in SysWOW64, allowing them both to function side-by-side...The SysWOW64 version for all other apps, and my early version in my app folder only used for my app.

Quote:

---

Originally Posted by treddie

But when I use Dependency Walker I find that it lists a bunch of dependencies that are different than what is in one ocx. For instance, if I check out comdlg32.ocx, the .dep file says there is only one dependency...comcat.dll (and versions of it for other languages)...

---

This is why these kinds of tools are useless or even dangerous in the hands of the untrained. For most libraries Dependency Walker results in information overload in terms of deployment. So this is why DEP files exist: to tell the PDW what dependencies need to be verified and possibly deployed. Otherwise it'd just do the same thing that the Dependency Walker does.

You have to know which are system libraries and which are redistributable libraries to safely build a DEP file by hand. Whenever possible go look at the ones that got installed by installing VB6 on a development machine. Copy them and then update the version numbers and timestamps. The only time you'd list a new sub-dependency in there is when you know there is a new one now (i.e. for the new version you are working with). Those are rare though, very rare (if any ever occurred at all) for the VB6-supplied OCXs over their lifetimes.

Quote:

---

Originally Posted by treddie

Man, so many questions, so few answers from MS KBs.

If , for instance, we use a very early version of richtx32.ocx, then that means that it can overwrite a pre-existing LATER version in SysWOW64. Would that not cause problems for other apps?

---

This is why you want to choose a setup technology that looks for the presence of the library on target systems and only replaces/updates them if an older version is found there. The PDW has these rules embedded in its setup1.exe, and the Installer merge modules for VB6 components have these rules embedded there as well.

When you package "version C" you are informing the setup process that your application requires at least "version C" so if you don't and can run with "version A" then package that instead.

Of course with a hand-built scripted installer you have to be sure you script those rules in yourself.

Quote:

---

Originally Posted by treddie

If on the other hand, I put my earlier version of richtx32.ocx in my app folder, and register it there, it will not overwrite the LATER version in SysWOW64, BUT...It means that the OS will then, always go to my app folder to use it for all other apps (because it has the same name as the later version in SysWOW64), and I am back where I started, AND if my app is uninstalled, the ocx goes with it and the system is left in an unstable state due to the missing ocx. Unless I personally re-register the version residing inside SysWOW64.

---

Never ever do this, it is very bad form and can lead to lots of nasty headaches. For example if you ever uninstall your application you may break any number of other applications that use the same library. It isn't about the name of the library, it's about the registry entries for the classes.

Quote:

---

Originally Posted by treddie

If I rename my version of richtx32.ocx to something else, like Myrichtx32.ocx, then I would have to do the same for all of my redist dll's and ocx's. And since those are binary files, there is no easy way to change all of the myriad of dependency names in those files. So that seems dangerous and in the least, incredibly overkill and stupid.

---

Very bad idea: won't help, and more evil (if possible) than your previous idea.

Quote:

---

Originally Posted by treddie

Unless there is someway to tell the installer to keep my early versions of the libraries in my app folder completely isolated from the versions already existing in SysWOW64, allowing them both to function side-by-side...The SysWOW64 version for all other apps, and my early version in my app folder only used for my app.

---

Why would you want to use an old version? Normally the main difference would be fixes to bugs and security holes anyway.

In rare cases where you must (and probably not for any libraries supplied by installing VB6) you can indeed run different versions side by side. That requires application and assembly isolation manifests though, another huge topic in itself.

Then I was misunderstanding earlier...The idea is NOT to overwrite a newer version of a file with an older one, but only to provide a very early one if it does not exist to begin with?

Also be sure to ignore anything that you read about ".local" files.

This was a half-baked attempt in WinMe/Win2K (though still supported in XP) to come up with a scheme to allow a "local" version of a library to be used by an application withou breaking the "global" shared version for other applications.

It has never applied to any components supplied with VB6 or any DLLs or OCXs created using VB6. These do not support registration features that DLL/COM Redirection relies on.

Quote:

---

Originally Posted by treddie

Then I was misunderstanding earlier...The idea is NOT to overwrite a newer version of a file with an older one, but only to provide a very early one if it does not exist to begin with?

---

Exactly. By packaging a library you are saying "if there isn't a library of at least this version already installed then install this one."

OK, that makes total sense. I was scratching my head thinking the reverse!
Well, my experience with one 3rd party setup is that it goes and replaces it regardless and then all kinds of "fun" ensues. I can play on this one machine because at any rate, I'm big on disk images, so I don't worry TOO much about screwing an OS up, but I spent some time going back into the sysWOW64 folder and putting some original files back in from my last image and re-registering them if they were the type that needed it. Heheh...MS...Loads of fun.

So, I can thank PDW or VSI for catching that automatically.

Maybe I'll just tell my customers they have to find a warez vb6 and run my program from the IDE. :))

Got word back from my brother that the Win7 Netbook finally installed fine, following your guidelines and the available KBs. It now installs fine on 3 Win7 machines and two XP machines. I am going to see if I can be surprised if it will install on the old Win95 machine, just for kicks. This was done via VSI 1.1, this time.

Now it is time to do a thorough check of all my program functions on all these machines plus more.

Am looking at Virtual PC here, too.

Excellent progress. :thumb:

HA! I spoke too soon. I made the awful assumption that since I already had done a good install with PDW on the two XP machines that that would somehow equate to successful install using VSI. Getting all kinds of permission issues in Virtual PC in XP mode, even when I'm admin. Fonts won't install or system files.

It looks like VSI does not automatically NOT install a file if it already exists unless you put a phrase in the Condition property. Is that right, or is that just for more conditions you can add on to a default do-not-install-if-exists?

Anyway, need to get some sleep and then I'll check my real XP machine and see if the same thing happens there, although it's kind of comparing apples to oranges...That machine already has vb6 and all my fonts on it. The VM just has XP and nothing else.

I'm not sure why you'd be messing with system files. That doesn't seem wise at all.

You may find How to package fonts in .msi file for easy deployment useful.

Normally files are version-checked so that only a newer file replaces an older one, assuming its a versioned file such as a PE file (EXE, DLL, etc.). I'm not sure why you'd want to force overwriting of an existing unversioned file type.

Sorry...By "system" I meant files that go into the system32 or sysWOW64 folder if they aren't there already.

I saw that article yesterday and I couldn't understand how VSI could not see that the Register property was set to vsifrFont, and install it just as simply as dragging & dropping a font into the font folder.

Could not get past the permissions fiasco thing, so I restarted my VSI install project from scratch, and the errors are gone now. I must have jacked up the script due to Pathonewbieosis.

But font still will not install if it does not exist on the target system. Just doesn't do anything. I followed that one guy's webpage instructions to the letter, but no go that route either. His .msi idea works if I run it separately, but it does nothing inside the installer. I'll bet I'm missing a really simple thing right under my nose. Best to eat and come back to it.

Well let's have another go at this, though it really should be a separate deployment thread here...


To start with, I'll try not to belabor the point but fonts are something that is much easier to get a copyright infringement court judgement on than almost anything else. Be very sure that you have the right to use and deploy a given font first. Even many "free" fonts have restrictive usage terms.


I probably gave you poor advice by referring you to that Web page about Advanced Installer (which as time goes on I find less and less "advanced" every day). Maybe we should just ignore it entirely.

Next I'll refer you to Font Table, which says:

Quote:

---

Because the installer does not refcount font files by default, preexisting font files may be removed with their component when uninstalling an application. To ensure that a font file is not removed, authors may set the msidbComponentAttributesSharedDllRefCount or msidbComponentAttributesPermanent bit flags in the Attributes column of the Component Table_msi_Component_Table for the component containing the font file.

---

Normally you do not want to install a font and have it uninstalled with your application later if it was already on the target system to begin with. So use either permanent (DoNotUninstall = True) or else reference counted (SharedLegacyFile = True) in VSI 1.1.

After adding the font file to the Fonts folder in VSI 1.1 you'll also want to set Register = vsifrFont.

The attached screenshot tries to show and highlight these points:

Attachment 97667

Now when you test your MSI on a test target system you may well see the non-fatal error (you can "Continue" past it): "Error 1907: Could not register font."

I suspect this is caused by poorly authored TrueType fonts missing some attributes as described in:

PRB: True Type Fonts Do Not Register Correctly with Windows Installer

I can cause this using a funky free font I downloaded, but I don't have a TrueType font editor good enough to give me access to the attributes described, so I can't tell whether the MS KB article's suggestion fixes the error/warning.

Of course the actual solution might be something else entirely, but I can't find any more useful suggestions on the Web.

I saw that article too, and went through the font table and found that everything was OK. The entries were there and the version number was written correctly, too.

Found this interesting tidbit on fonts not installing. Basically, you cannot use "Add File(s)..." for fonts. You have to drag & Drop them into the Font Folder of VSI via Windows Explorer:
http://am.net/lib/tools/Microsoft/ms...ntsCantBeAdded

At any rate, by itself it did not work, and I had Register = vsifrFont set, so I did that plus your suggestions for DoNotUninstall or SharedLegacyFile, and still no go. I have my Fonts folder open during installation, and the font never appears, if even momentarily.

I then tried all the above with a standard font that ships with Windows (MisterEarl BT Regular (TT1221M_.TTF), by de-installing it first to see if my installer would put it back, but to no avail. So it does not look like a bad font issue.

This gets curiouser and curiouser. I have a gut feeling there is a simple trick to pull here to get it to work. If I have to, I'll have my program install it if it doesn't exist on startup, but that means a slight startup penalty, which would probably not be much of a performance loss for just one font.

OK, now I'm just frustrated. IT WORKS NOW! But why?! It seems that something is wrong in VSI...I tell it to do something and if I set it up correctly the first time and don't change anything, it seems to work OK. But if I try to change something, like delete a font and add a new one, it may or may not work when I run the installer. I swear I haven't changed my approach when making changes and ReBuilding the msi. I went back in and did the MisterEarl font test and it worked. So I went back and tried my original font choice and all of a sudden it worked this time!

I must qualify that by stating that VSI is still new to me, so I MAY have THOUGHT I had done everything the same, but I think I was doing everything right. Yesterday I had played around with the DoNotUninstall and SharedLegacy properties before your post about those, combining them and using them separately, with Register always set to "vsifrFont". I could not get the damn thing to work. Now all of a sudden, it works. All my changes to the script were followed up by "ReBuild", not "Build".

I suggest you forget the Rebuild option.

It's a bit of a vestige left over from the case where your Installer Project is a subproject of a larger C or C++, InterDev, etc. Project - which use the same IDE (unlike VB6).

The Help file even says:

Quote:

---

To rebuild a changed installer project
:
:
On the Build menu, click the option to Build your project.

Note The Build menu may also include options for building or rebuilding the entire solution. If your project is part of a larger solution, you can select the Build Solution or Rebuild Solution option to rebuild the entire solution, including your installer project.

---

So when creating an installer for a VB6 application it may not do what you expect it to.

You should also almost always select "Release" before building for a VB6 application.

There is also a quirky case where you can make your font or fonts part of the VB6 application. You'd do this by changing the font files' Component property from "self" to your EXE.

This has the side-effect of putting your font(s) into the app folder instead of Fonts, and when you install... the Fonts folder on the target system gets a shortcut to the file in the app folder. I wouldn't recommend this except for fonts you want to always be "private" (they'll disappear when you uninstall your application).

However I agree the whole fonts thing is more than a little frustrating.

Pretty crazy, in the least.

Thank you VERY much for your help with all of this, dilettante! You really helped me get a good start on working with installations. I wish I could give you a great rating on all of your posts, but that's not possible on this forum.

I'm just glad it helped a bit. Perhaps others will find this thread and get something out of it too.

Yes, it can help prepare other newbies for the fact that installations are not a "one-click" proposition, even though MS could have gotten a lot closer to that ideal than they did.