While reading comments written to explain some code, I came across
this...

'Dim Cnn As cConnection 'define a SQLite-Connection
'Set Cnn = New_c.Connection("c:\SomeFolder\Some.db")

'and save some lines of code this way, but also keep
'your App prepared for regfree-loading, without replacing
'too many "normal" VB-instantiation-calls of the
'RichClient3-Classes later on, in case you are not
'making use of this module (or the New_c - Constructor)
'from the "very beginning".

Can someone explain in less 'greek-speak' what "regfree-loading" is
and the advantages/disadvantages?

Thanks.

Webbiz

in case you don't get a quick reply, that was given you by  olaf who also
provides the reg free com facilities
theres lots in the archives on this group already if you want to do some
background reading...
the obvious advantage is not having to register dlls via regsvr32, the
disadvantages i have no idea.

hth
mark

Show quoteHide quote

Thanks Mark.

Right now I'm wondering why we have to register dll's in the first
place if there are ways to get the same jobs done without having to
register, such as this 'reg-free' thingy. So I'm going to take your
suggestion and see if I can find the prior discussions on this
'reg-free' subject. Maybe what I'll find is that it isn't really
'reg-free' but instead does the registering so we don't have to?

No answer needed. Just thinking out loud prior to my searching on this
now.

Thanks again.

Webbiz




Show quoteHide quote

----- Original Message -----
Newsgroups: microsoft.public.vb.general.discussion
Sent: Saturday, May 30, 2009 8:50 PM
Subject: Re: regfree-loading

Dlls in common (not only the AX-ones which also need registering)
are there, to componentize (offer generic usable encapsulations
of functionality), which is a good thing in itself - but they also
help, to reduce the amount of *memory*, an Application
takes up. All the Dlls, hosted e.g. in \System32, can be shared
by many processes and do not take up that much Ram then on
the System as a whole (measured over-all) compared with
non-shared Dlls, which are placed beside your Exe in its
AppFolder.

And in case of commonly used COM-Dlls (as for example
the ComCtl32.ocx) this holds also true of course and should
be the recommended way (System32\ + registering).

But back to the (regfree) usable COM-Dlls, which one
creates himself and usually places beside the MainApp.exe
in his AppFolder.

In case I deliver an App-Suite that consists of many Exes,
I will place all the different Exes in an AppSuite\Bin-Folder
of course, so that each of these Exe-Files can reuse the
same (regfree loaded) COMponent-Dlls.

And then the Ram-resources are not that limited anymore
nowadays, that you should think about placing your *own*
Dlls inside \System32 for "reusage" (by what other programs?).
No need for that IMO.

And even if you would deploy a complete AppSuite of yours,
each Appsuite-"Exe-Part" sitting in its own Binary-Folder,
having separate copies of e.g. my 3 toolset-Dlls - why not -
if you start three different Exes of your suite, then the overall-
Memconsumption would be ca. 3MB larger, compared with
placing every part of such a suite in one commonly used
AppSuite-Folder. These 3MB "extra"-memory should be
seen in relation to the current amount of Ram available
on todays machines (and e.g. an already running "Office-suite"
or the FireFox for example, which easily take up hundreds
of MBs of Ram already on their own).

And regarding "why not simply compile everything into the Exe"?
VB is a wiring-tool, which makes working with COMponent-
Dlls very easy (one single project-reference-click and you can
make use of "outsourced generic stuff" per intellisense).
E.g. if I would include my "outsourced" RichClient-stuff into
each and every Exe I have to write (as code), I would go nuts
regarding startup- and compile-time and the debug-behaviour -
and my Exes would end up (each and every one) ca. 1MB larger.
Instead I spare this 1MB in the exe-binary itself and ship the
3Dll-Set alongside in the same folder - no problem, no difference
in the deployed overall-Bin-size - and no difference in Ram-usage.
And in case of an Appsuite with multiple Exes, all placed in the
same Bin-Folder, then even less Ram-usage than compared with
an "everything sitting in the Exe" approach.

So, think practical I'd say.
If you have commonly used functionality, then write your
own (nice and generically usable) component for this stuff -
reuse this COM-Dll then regfree in your deployment
if you want, and don't copy over the "same old" *.bas-
modules again and again. Componentitzed code is
usually cleaner code, since you are required to draw
"cleaner borders" (your COM-Interfaces) in your
encapsulations - you will force yourself a bit more,
to *isolate* sets of functionality better. Leads in the
end to smaller App-projects with much better startup-
and compile-times. Just look at the amount of code
which was needed, to do this small MetaStock-importer-
Application.

Speaking for my stuff, which is ensured over DirectCOM.dll,
this *is* indeed working really regfree - the registry is not
touched at all... delete the folder (you are running your App
from) and everything is gone.

It is also good to know, that a system is not that "vulnerable"
that way, since you don't publish the COM-Interfaces and
the ProgIDs (ClassIDs) in the registry - not that easy for
other (dirty) programs/processes, to call CreateObject
(CoCreateInstance) against something, which is not
visible to the systems "global instancing-mechanism" that
makes use of these registry-infos.
E.g., if one only wants to use the MS-Dictionary from
scrrun.dll, he could deploy it in his App-Path - and
tell the Sys-Admins who removed scrrun (together with
all the other vbscripting-stuff), that "your" scrrun.dll in
your private AppFolder is not visible in the registry - and
not touching it (and therefore not callable/instantiatable
by CoCreateInstance by potentially "bad processes").

Olaf

Show quote Hide quote "Regfree-loading" is a way to providing COM components to applications
without formally "universally" or "globally" registering the component on a
box.
This is useful for shrink-wrap applications - one can install the program
and its components with less fear of collision with existing registered
components.
Think of it as a "side-by-side" strategy where various programs can have
their own unique components.
It can allow one to more easier swap out components.
It allows programs with COM dependencies to run from removeable media.

The disadvantage is it provides COM components to applications without
formally "universally" registering them.
While useful on an application by application basis - it can become a
problem if one is managing a suite of applications with a universal
dependency on shared components.
If you use regfree strategies for versioning specific components for
specific applications - sooner or later - you'll run into a collision.
Especially if one these components gets 'registered'.

-ralph

Thanks Ralph.

Your explanation of the disadvantages and that which I found of the
advantages online has given me a good idea as to what this is.

I've had some personal experience with DLL-hell in the past (not with
my code, but with programs I've purchased in the past).

Now I'm thinking on why DLLs were created in the first place. This is
the purpose of reusuable code as well as to only have to update
specific DLLs rather than a complete application when changes are
made. Also, they allow for a common function-set for other
applications.

So then, if one is using reg-free DLLs, I would suspect they would
have to be placed in the app directory to avoid over-writing a DLL of
the same name in the system directory (one that is likely registered
as well). Then, if you are placing them in the app directory, you're
pretty much isolating these from other applications that could have
used them had they been registered DLLs, unless your app knew what
directory these other DLLs are located in order to use them since they
are not registered. But then, I'm thinking they will not be able to
use them if not registered unless you had a 'Manifest XML' file that
had all the details for the DLL in question for the application
wanting to use the DLL. At this point, I have to assume that the idea
of a centralized DLL library is being defeated by these reg-free DLLs,
since I assume a centralized DLL must be registered so that other
applications can know they exist on the system and use them.

So the bottom line, if I'm getting this right, is that having reg-free
DLLs in the app directory serves merely as a modulized code vehicle
(separating reusable functions into smaller compiled code) .  If the
developer writes a new project that will use those DLL functions,
additional copies of these reg-free DLLs can end up on the same
machine if the user has multiple programs from same developer,
assuming the developer has not originally created a central 'common'
directory for all his 'reg-free' DLLs, so that his Manifest file would
know it was there, etc. etc.

Did I get at least 10% of this right? :-*)

Webbiz


On Sat, 30 May 2009 13:51:46 -0500, "Ralph"
<nt_consultin***@yahoo.com> wrote:

Show quoteHide quote

Show quote Hide quote That's it.

Obviously the devil is in the details, and not every one's problem domain
and comfort-level is the same.

Frankly, (and since it is a weekend), I've never had a problem with COM and
its Registry requirement. I've spent my time in Dll Hell, but usually only
because I had to clean-up somebody else's mess, or I did something stupid.
The rules and protocol are simple and straight forward. Follow the rules and
all works well. Get cute, try to take short-cuts, or invent your own
protocol - and it gets ugly.

So my suggestion - Unless you are working with a shrink-wrap program or
trying to run something from from a USB device, etc. ie, an environment
where Reg-free IS a requirement - just use COM.

-ralph

In addition to the other answers, you might
find these helpful:

http://msdn.microsoft.com/en-us/magazine/cc188708.aspx

http://www.codeproject.com/KB/DLL/RegFreeCOM.aspx

    Also, you need to know that there are two
different reg-free COM methods that you might
be talking about. One is referenced at the above
links and only works, I think, with XP SP2.  (The second
article says that. The first article never mentions
that limitation, but that's become standard behavior
with Microsoft. They just pretend that nothing before
XP SP2 and .Net exists.)

   The other method is Olaf's 20KB DLL.

   I haven't really looked into the standard reg-free
COM methods, but in looking at the links above it
appears that it just substitutes manifest entries
for Registry entries. A registered object is normally
looked up by searching for the CLSID or ProgID in
the Registry, which then leads to the file path and
typelib info., allowing the lib. to be loaded. The link
above shows how the same thing is done in reg-free
COM by putting that info. into a manifest file. (But of
course that doesn't make much sense unless you're
only writing to XP SP2/Vista.)

   Olaf's method is different. While Microsoft's reg-free
COM just moves the Registry entries to a local manifest
file, Olaf's DLL does the actual loading of the COM library,
replacing the functionality that VB has done for it when
using New or CreateObject. Olaf's DLL has the advantage
that it can be used on any system. I'm using it myself for
one of my programs that runs on Win98+. It works fine.
I could have just registered and unregistered my ActiveX
DLL, but using Olaf's DLL "cuts out the middleman". I don't
have to worry about issues with bizarre security restrictions
in the Registry with Vista+.

How to test for array?
DLL in Visual BASIC 6
Stone Wall
GW-Basic
Getting pixels from EMF (StdPicture)
GetObject with VB6 ActiveX exe
Anyone know of a good Help Authorizing Tool
Format function question.....
Mayayana and others: Know The Notes now for 98SE using MM's new 'Never Replace' scheme
Prohibit Paste