Re: The bloated get bloatier

Tech-Archive recommends: Speed Up your PC by fixing your registry

On Wed, 27 May 2009 10:11:05 -0400, "mayayana" <mayaXXyana@xxxxxxxxx>
wrote:

I use my own customized version of the PDW
and don't ship any extra support files. I don't use
OCXs, and I haven't shipped the runtime for years.
I used to include a note on download pages about
getting the runtime for Win95/98/NT4, but these days
I figure that anyone using those systems is going
to be familiar with the issues, so VB6 software can
safely be installed as stand-alond software.

My avoidance of controls is partly due to using
my own userControls. I use my own owner-drawn
RTB, my own sockets UC, and various customized
controls. I use straight code for OpenFile diaogues.
It's faster, more efficient, more customizable, and
provides a lot more available functionality than what
the MS planners decided was worth putting into the
VB controls.

In many cases it turns out that the ocx-free
version is not notably more difficult than the ocx
version. It's just a bit more "gritty". For instance,
the formatting of file extension strings for a common
dialogue is a pain in the neck whether you use comdlg.ocx
or comdlg32.dll. The main difference is that with the
latter one has to use API and be aware of data types.
The OCX really just uses a "wizard" to write the API
code so that VB programmers won't have to understand
data types. Arguably it doesn't save any work in
terms of setting it up or in terms of learning how it
works.

The owner-drawn RTB is nice because not
only is it faster and basically dependency-free, it
also runs RTB v. 2 or 3, depending on the system it's
on. RTB 2 included a couple of very nice additions:
multiple undo and find-backward. That's all coming
from riched20.dll. The VB control is based on
riched32.dll, which is Richedit v. 1 only. (Incidentally,
for the PDW it's standard to also ship riched32.dll -
on Win9x only.)

The other part of avoiding controls is that I've
limited my usage. I've never used a FlexGrid or
anything from the common controls libraries.
Admittedly, that does limit my options somewhat.
I was tempted to add a common controls dependency
at one point to get a tab control. But then Jerry French,
who used to frequent this group, provided a very
simple owner-drawn tab control that showed how easy
it was to make my own tabs.

If you want to use the Wise installer you could
combine that with the Redist folder. Do you know
about that? In the VB folder, Wizards\PDWizard\Redist.
When MS found a serious compatibility issue with
a new file version they would put the stable version
in the Redist folder with the next service pack. So if
you have an up-to-date VB service pack then you
should have the best versions to use in your Redist
folder and you can point Wise to those.
As for the actual runtime, I doubt it matters which
version people have except in the case of very specific
issues. (I didn't install a SP later than #3 for a long time
because according to the release notes of SP4/5 there
weren't any issues that were relevant to me. If I
remember correctly there were mostly database-related
fixes.

I think that, in general, the version of a system file
shipped should be the version that came with Win98.
(I think Win2000 is also OK. I don't remember for sure.)
After that Windows File Protection (formerly known as
System File Protection) started being used. On WinME/XP
if you try to install a new system file it will get replaced.
If you do it with the PDW you'll end up in a reboot loop
because the PDW will reboot to replace files, then Windows
will silently overwrite those files without telling you,
then the PDW will say, "Need to reboot to replace files."
And so on. You can avoid that by just not shipping any
system file newer than what's on ME+. For those systems
the official position from MS is that nothing should ever
be replaced except by official MS patches. They basically
took the system folder out of the hands of 3rd-party
programmers who are not MS partners.

I don't think the OCX files are considered to be system
files, but they still relate to the Redist folder. And if it
were me I still wouldn't ship anything later than what
I've used and I know works. (If there's a lesson in what
Microsoft has produced in the past 10 years it's that newer
is not necessarily better. :)

Very detailed reply, thanks.

However, my Redist folder contains only the following:

MDAC_TYP EXE 7,856,352 20/01/00 0:00 MDAC_TYP.EXE
CO2C40EN DLL 748,160 31/05/98 0:00 CO2C40EN.DLL
MFC40 DLL 924,432 01/06/99 0:00 MFC40.DLL
MSVCRT20 DLL 253,952 31/05/98 0:00 MSVCRT20.DLL
MSVCRT40 DLL 326,656 01/06/99 0:00 MSVCRT40.DLL
RICHED32 DLL 174,352 07/05/98 0:00 RICHED32.DLL
COMCAT DLL 22,288 31/05/98 0:00 COMCAT.DLL
ASYCFILT DLL 147,728 08/03/99 0:00 ASYCFILT.DLL
OLEAUT32 DLL 598,288 12/04/00 0:00 OLEAUT32.DLL
OLEPRO32 DLL 164,112 08/03/99 0:00 OLEPRO32.DLL
STDOLE2 TLB 17,920 03/06/99 0:00 STDOLE2.TLB
MSVCRT DLL 278,581 17/02/04 0:00 MSVCRT.DLL

So there are no .OCX files.

I checked the version of richtx32.ocx in my \system folder and it is
version 6.01.9782, i.e. miles later than anything comparable in
Redist. Maybe the Redist folder only got updated under certain
circumstances, since mine looks as old as a Tibetan monk.

I stopped using the PDW because I found it a PITA to use. At the time,
years ago now, many devs and VBPJ were extolling the virtues of Wise
so I bought my copy that I still use to this day. It is nice to use,
never crashed and you have the script editor view as well as the
Installation Expert view.

Actually, I've just thought of a possibly safer installation route:
"Only install if not present." I believe Wise covers this with the
option Replace File If... and then you select Never. Given that many
Windows 98 PCs will already have the runtime plus any controls that
other software may have installed, *adding* to the controls (rather
than replacing any of them) is likely to present the least problems.
Maybe I'll whack together an installation package and you can test it
for me!! ;) (You can always use the Backup feature for added security;
this is where Wise first copies any file it's about to replace into a
Backup folder. However, this should never arise if I implement my
wunnerful new brain fart! Let me know if you have the time... thanks!)

MM
.

Relevant Pages

  • Re: setup1
    ... It was impossible to install. ... As Nobody said, these are protected files included with Vista, and in some cases specific to Vista, and should NOT be installed on other versions of Windows, particularly older versions. ... For example, if you're using version 2.1.1 of an OCX in your app, you don't want to distribute version 2.0.0 of that OCX because that older version might have bugs that were fixed in the later version. ... Copy files from the service pack package to the Redist folder. ...
    (microsoft.public.vb.general.discussion)
  • Re: Never ending mscomct*.ocx problem
    ... re-add the new proper mscomctl.ocx controls to the project, ... Whenever I install a new VB6 service pack, ... CLSID for the new OCX version (i.e. ...
    (microsoft.public.vb.controls)
  • Re: The bloated get bloatier
    ... I use my own customized version of the PDW ... My avoidance of controls is partly due to using ... The OCX really just uses a "wizard" to write the API ... If you want to use the Wise installer you could ...
    (microsoft.public.vb.general.discussion)
  • Re: KB960715 blocks msflxgrd.ocx in VBA
    ... I'd go back to your original distro, do an install of the 'empty' VB6 ... All I did for my fix is create a VB6 project, ... same principle to apply in your case - once the affected controls are safely ... empty VB6 project with the affected tools selected. ...
    (microsoft.public.windowsupdate)
  • Re: From VC6 to .NET 2 questions
    ... Tech support is expensive. ... controls, or something that involves automation, either as a client or server. ... but those decisions are not mine but my clients'). ... correct version was installed because it was part of their install support problem. ...
    (microsoft.public.vc.mfc)