Re: The bloated get bloatier

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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. :)


Actually, while I'm here, if you (i.e. you, not a generalised you)
install one of your VB6 apps on someone's Windows 98/98SE PC, which
versions of the runtime (MSVBVM60.DLL) and the other OCxs do you
deploy? You see, I updated to the latest 6B service pack recently,
which provides much later versions than were around when Windows 98SE
was mainstream. So once again I am loathe to use the *latest* versions
as I fear they might interfere with other, older OCXs on the user's
PC.

For instance, my latest music app uses COMDLG32.OCX, MSCOMCTL.OCX,
MSFLXGRD.OCX, MSVBVM60.DLL, RICHTX32.OCX, plus one third-party OCX and
three third-party helper DLLs. Specifically in regard to the Microsoft
controls, these obviously only represent a small subset of the entire
suite of controls supplied with VB6. So, if I come along with my
installer and put the latest versions of my few controls (above list)
on the user's machine, how can I tell whether there will be adverse
interaction effects if other apps on the user's PC suddenly are
subjected to part-new, part-current (for Windows 98) controls?

The user could have a number of apps running happily that were
installed with the OCX versions and VB6 runtime that were valid at the
time, but the risk is that introducing a small number of newest
versions could upset the apple cart. This is why I am so excited about
registration-free COM, since all the above fears are immediately
lifted if the technology can be made to work on XP and later OS's.

But maybe many hundreds of shareware authors never get any feedback
from angry users that users' PCs have been allegedly screwed up?

I was pondering this last night and this morning on reflection of what
you said about your continued use of Windows 98 and so I took a look
at my trusty Wise installer, which works fine. I opened up the
Application Files/Files/Details window and had a look at how I've
currently got the update settings configured: In all cases I've set
the condition: "Replace Existing File if date/time and version number
is older"

Fine, but then I thought, ah, but *my* latest versions are MUCH later
than I would have had four years ago! Unfortunately, Wise does not
provide a condition that says: "Replace Existing File if you promise
not to screw up the user's existing setup" ;)

MM


.

Relevant Pages

  • Re: Access VBA und ocx
    ... neuen OCX in VB6 inkl. ... Installer erstellt und das geht auch nicht. ... Hast Du die ocx Controls richtig registriert? ...
    (microsoft.public.de.access)
  • Re: The bloated get bloatier
    ... My avoidance of controls is partly due to using ... The OCX really just uses a "wizard" to write the API ... in the Redist folder with the next service pack. ... if you try to install a new system file it will get replaced. ...
    (microsoft.public.vb.general.discussion)
  • Re: Manifest file for an Ocx
    ... This doesn't appear to work for an OCX at least not in my context. ... So second question remains - how to make a User Control in an activeX ocx ... use xp style controls (triggering this from the OCX and not the app using ... recompile your EXE. ...
    (microsoft.public.vb.general.discussion)
  • Re: [Controls] ComboBoxEx
    ... > Why not use the ImageCombo from the Windows Common Controls OCX? ... > controls from this OCX, there's no point in not using the ImageCombo). ... CopyMemory nmCbex, ByVal lParam, Len ...
    (microsoft.public.vb.winapi)
  • Re: file installation order
    ... In the VS setup project, in the properties of those OCXs, what was your ... Register property set to? ... MSI file and the OCX copied to the system, ... Definitive Guide to Windows Installer ...
    (microsoft.public.dotnet.framework.setup)