Register DLL Question
boaz
I have been working with VB6 for a long time. I have to admit that I have
never written myself a single ActiveX DLL. So, I don't know how to do it.
Would you guys explain to me the concept please? Thanks!
I don't use DLL in my project. I place everything in one big bag.
However, I do need third party DLL like a grid and a toolbar.
When distributing all these files, do I really need to register all these
DLL files in order for my program to work?
Can I copy the files in a folder and my program will somehow know where to
find the grid and the toolbar?
--
> There is no answer.
> There has not been an answer.
> There will not be an answer.
> That IS the answer!
> And I am screwed.
> Deadline was due yesterday.
>
> There is no point to life.
> THAT IS THE POINT.
> And we are screwed.
> We will run out of oil soon.
Ralph
"boaz" <nos...@yahoo.com> wrote in message
news:ePPq0T00...@TK2MSFTNGP12.phx.gbl...
When ever you install/distribute a VB application you need to use an install
package.
The package will contain the components and will 'register' your ActiveX
components on the target. In most cases with common controls - they are
already installed on the target system. If not you can package them up as
well.
So the next question is what package to use...
1) Package & Deployment comes with VB6 Pro and Enterprise. Free
2) Inno Setup (http://www.jrsoftware.org/). Free
3) Visual Installer
(http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/download.aspx)
Free
3) InstallShield
(http://www.macrovision.com/products/flexnet_installshield/index.shtml) $$$$
4) Wise (http://www.wise.com/products.asp) $$$$
hth
-ralph
boaz
"Ralph" <nt_cons...@yahoo.com> wrote in message
news:4rudndQ4rsX...@arkansas.net...
Ralph
boaz
What I did was to compile my program and then I just "copy" the EXE and the
DLL files to another computer to the same folder. I then ran the EXE and it
seemed to work just fine without registering the DLL files.
It seems to me that I don't have to register the dll files... by some
unknown reason here.
What is going on here????
"Ralph" <nt_cons...@yahoo.com> wrote in message
news:Ge6dnZPGN9E...@arkansas.net...
Someone
> the DLL files to another computer to the same folder.
The target OS did not use the DLL that you put in your App's folder. It had
the same DLL, probably in the SYSTEM folder, so your EXE worked without
problems. If you deleted your copied DLL file, your EXE will work too. With
ActiveX DLL/OCX's, the registry is used to tell where the DLL/OCX is
located.
> I then ran the EXE and it seemed to work just fine without registering the
> DLL files.
You probably are using a mostly used DLL with VB6, like ADO, etc., but this
will not work if you make your own ActiveX DLL's.
There are 2 different types of DLL's:
1 - Standard Windows DLL's. These are created with C++ and other programming
languages. These don't require registration. Example: Win32 API DLL's.
2 - ActiveX DLL's. These require registration.
VB6 always creates ActiveX DLL's, so you have to register them. In your
development machine, VB6 auto registers your DLL/OCX when you compile it, so
it's ready for use in testing. It's best to use Package & Deployment Wizard
when you want to install your software on another machine. You may want to
read more about it in MSDN and check this article as well:
Best practices for deploying Visual Basic 6.0 applications
http://support.microsoft.com/default.aspx?scid=kb;en-us;830761
"boaz" <nos...@yahoo.com> wrote in message
news:uT2koP10...@tk2msftngp13.phx.gbl...
Michael C
>I was playing with these dll files.
> What I did was to compile my program and then I just "copy" the EXE and
> the DLL files to another computer to the same folder. I then ran the EXE
> and it seemed to work just fine without registering the DLL files.
>
> It seems to me that I don't have to register the dll files... by some
> unknown reason here.
> What is going on here????
Most likely it automatically registered it for you because it found it in
the same folder.
Jim Carlock
installers...
> 1) Package & Deployment (VB6 Pro and Enterprise).> 3) Visual Installer.
> (http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/download.aspx)
> 3) InstallShield $$$$
> (http://www.macrovision.com/products/flexnet_installshield/index.shtml)
> 4) Wise $$$$ (http://www.wise.com/products.asp)
You left out NSIS. I'd rank NSIS on par (or better) than
the others, and it's available free of charge as well... In fact,
NSIS and InnoSetup both are great Setup.exe compilers.
Microsoft suggests MSI (MicroSoft Installer(?)).
--
Jim Carlock
Post replies to the newsgroup, thanks.
boaz
The computer is a clean Win2K computer with nothing in it.
And the OCX file is a third party OCX I just got from the other company.
So, I am sure it is not in this computer.
Is it possible that Win2K registers the OCX automatically?
If I remember correctly, there are different ways/types of registering an
OCX.
"Someone" <nob...@cox.net> wrote in message
news:OjTz2f1...@TK2MSFTNGP12.phx.gbl...
boaz
free stuffs are for "Personal" use only.
Plus it is not a sound decision in a marketing point of view. I need to
market my stuffs with well known brand names... huh... like InstallShield...
Photoshop... etc. etc.
I remembered one of my customers had problem installing a program of mine.
I told the IT guy that I was using InstallShield and it was one of the best.
This shut him up right away. ;)
But anyway. I am having DLL Hell problem. I am thinking I will not
register any DLL or OCX from now on. I will just copy the files to the same
folder and adding the ".local" file along with the rest of the files.
"Jim Carlock" <anonymous@localhost> wrote in message
news:%23e8kFG6...@TK2MSFTNGP09.phx.gbl...
Jim Carlock
> I cannot use the "free" stuffs.
That restriction is one you place upon yourself.
> I need to sell my products. Most of the free stuffs
> are for "Personal" use only.
There's only a limited set of things an installer does when
installing files, they're really simple when you boil the install
down to the purposes and needs.
a) Must be able to compress files into itself.
b) Must be able to extract the files and copy the files to
specific folders.
c) Must be able to register certain components in the
registry.
d) Must provide a small amount of user interaction. This
means providing a way to display windows with some
buttons, some textboxes, perhaps read the disk drives and
display the contents of the disk drive. Next buttons and
Previous buttons are typically common. "I agree" check
boxes, the option to use radio buttons.
That pretty much completes what's required for an installer.
They tasks are really simple ones. A batch file could be
used to install all software, if you really think about it and
consider what's going on.
Jordan Russel's licensing states:
"Permission is granted to anyone to use this software for
any purpose, including commercial applications,..."
He provides some restrictions but the restrictions seem to
apply to redistributing the source code for InnoSetup (or
redistributing new compilations of the source code).
> Plus it is not a sound decision in a marketing point of
> view.
Marketing has nothing to do with quality software. Any
company can hire extraordinary marketing professions to
sell unprofessional stuff. Just browse through your local
newspaper and take a look at the used car sales pitches
going on. Alot of the sales pitches are outstanding but the
actual cars... Maybe you've never bought a used car...
maybe you miss all the "Professional Commercials" on
the radio, on television, maybe you don't watch the Super
Bowl, and maybe you miss the Budweiser commercials
in between the quarters and at halftime. The commercials
certainly are high quality... but the beer itself... Ha! I'm
probably going to get blasted by some Budweiser loving
folks now. <g>
> I need to market my stuffs with well known brand names...
> huh... like InstallShield... Photoshop... etc. etc.
How do you know InnoSetup is not professional without
trying it out? Your blinding your own self! Your own arguments
show your own blindness and they restrict you. That's you
doing that!
> I remembered one of my customers had problem installing
> a program of mine. I told the IT guy that I was using
> InstallShield and it was one of the best. This shut him up
> right away. ;)
Why? Because he knew nothing about what InstallShield
does or how it operates? There's more than one reason
why a person will shut up. Did he quit trying to understand
things? You'll have to present your argument with facts
otherwise it's just a bunch of huffing and puffing.
> But anyway. I am having DLL Hell problem. I am
> thinking I will not register any DLL or OCX from now on.
> I will just copy the files to the same folder and adding the
> ".local" file along with the rest of the files.
I'm seeing signs that "you" gave up. We all face DLL Hell with
every application we write. I'll mention that InnoSetup offers
ways to detect the current version of the software that already
exists on the system, and it provides a way to overwrite the
file IF you want it to. You can provide the latest version... if
you so desire. Also, Microsoft proclaims that SFC and WFP
protect all of it's DLLs (for operating systems Windows Me
and later).
"You" should try it out before you lump it into the pile that
"you" created. I'm going to put myself on the line here, and
state that everything InstallShield does, InnoSetup can do
better. <g> I'm pretty confident in that statement. IF you
feel up to the challenge, I'll go along and we can compare
the abilities of each. <gulp>
The ONLY thing that I don't see in InnoSetup involves
archivers not being able to extract the files from the executable.
But then what installer provides this ability? NONE! :-) Really
you should try it out before you "lump" it into a pile.
By the way, Jordan Russel provides a newsgroup for InnoSetup.
Hook up to it and ask your licensing questions there.
I don't think any other installer "professional or not" offers such.
Sure, others might offer an HTML version which GOOGLE never
parses requiring you to log in, and so on... IF GOOGLE did
parse the newsgroups for the other software installers, I'd bet
you'd find mention of jrsoftware.org inside of them more than
not. <g>
I mentioned NSIS as well, although I haven't really messed with
it. Someone else will have to stick up for NSIS. I think you're
really shortchanging yourself.
Tell you what... take a look at the newsgroup. Ask your question
there about the licensing. I'd be surprised if Jordan Russel doesn't
answer the question personally.
--
Jim Carlock
Post replies to the newsgroup, thanks.
"Jim Carlock" <anonymous@localhost> wrote:
> "Ralph" <nt_cons...@yahoo.com> suggested some
> installers...
>> 1) Package & Deployment (VB6 Pro and Enterprise).
>> 2) Inno Setup (http://www.jrsoftware.org/).
>> 3) Visual Installer.
>> (http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/download.aspx)
>> 3) InstallShield $$$$
>> (http://www.macrovision.com/products/flexnet_installshield/index.shtml)
>> 4) Wise $$$$ (http://www.wise.com/products.asp)
>
> You left out NSIS. I'd rank NSIS on par (or better) than
> the others, and it's available free of charge as well... In fact,
> NSIS and InnoSetup both are great Setup.exe compilers.
>
> http://nsis.sourceforge.net/
>
> Microsoft suggests MSI (MicroSoft Installer(?)).
>
> --
> Jim Carlock.
Someone
>free stuffs are for "Personal" use only.
True, but Inno Setup is free for commercial use, even NASA used it. It can't
be that bad. InstallShield had problems with Outlook as far as I can
remember. If Outlook was open, InstallShield would show 98-99% finished then
take forever to install. It doesn't do that with any other program. I am not
sure if they fixed it. For that reason I avoided InstallShield altogether.
Inno Setup supports the basic things like Readme and License files, and it
has scripting support, easy registry checking/writing, and conditional
installation.
"boaz" <nos...@yahoo.com> wrote in message
news:%23QPW0qA...@TK2MSFTNGP09.phx.gbl...
boaz
I am selling my products like hot cake when I tell my customers that I am
using Photoshop,Installshield, and Macromedia, ODBC, etc. (and soon XML).
And they are willing to pay a whole lot more if I mention these products.
So, they have alot of my different programs installed in their computers on
their network. It comes to a point that the third party OCXs are not
compatible to the old OCXs. So, many of my old programs do not work
anymore. So, I get a lot of unhappy customers. Unhappy customers can
affect my bottomline. So, I need to find a way to have different version of
DLLs installed.
I am thinking Side-By-Side... something... (I forgot the term). So, I don't
have to register the DLL causing problem with the older programs.
But many people say that I need to register the DLL/OCX. So, I am confused.
DanS
news:#QPW0qA1...@TK2MSFTNGP09.phx.gbl:
> I cannot use the "free" stuffs. I need to sell my products. Most of
> the free stuffs are for "Personal" use only.
> Plus it is not a sound decision in a marketing point of view. I need
> to market my stuffs with well known brand names... huh... like
> InstallShield... Photoshop... etc. etc.
personally, i don't care if a program i use has a well known installer at
all. i just care that it installs properly, period.
so i must ask....what do you market ? what is YOUR brand name ?
(does this mean that YOUR s/w is crap because it's not from a well-known
brand name ? (going by your logic) i'm sure you would take offense to
that.)
Someone
DLL's that don't have a .local file, so they stop working.
Also, if you are using 3rd party DLL/OCX, you must update the set of DLL's
that came with it if any. You must compare the version number and update
only if newer, and by update I mean:
- Unregister old DLL/OCX.
- Replace the file.
- Register the new DLL.
It's not a good idea to compare just the file's date and time and do the
update based on that. Time zone differences can alter the file date and time
if the file was copied from a different computer with a different time zone.
Some people leave the default time zone in some computers to the default
PST, which cause problems when copying files.
Since I avoided InstallShield because its conflict with Outlook
98/2000(didn't test XP), I don't know how it handles this. There is a room
for error since it lets you do a lot of things.
Also, please read the following segment about permissions and NT and how
this effect your installation. In particular, you must check that the keys
were created successfully. Although it's for InnoSetup, it still applies to
other installations.
http://www.jrsoftware.org/isfaq.php#ntsecur
Registering DLL/OCX requires at least a Power User, and at least an
Administrator if a file is in use and must be replaced during reboot, so
it's best to exit the setup if the user doesn't have administrator
privileges on NT.
If you develop your own DLL/OCX, then you must maintain Binary Compatibility
when you compile your DLL/OCX. After your first release of the DLL/OCX, you
can't change the definition of Public interfaces(properties and methods),
but you can add new ones. You could still change the code inside them
because that doesn't change their definition. For example, If you used:
Public Function Search(FullName As String) As Long
' Code here
End Function
You cannot change it to:
Public Function Search(FullName As String, Company As String) As Long
' Code here
End Function
Nor to:
Public Function Search(Company As String) As Long ' Parameter name changed
' Code here
End Function
Nor to:
Public Function Search(FullName As String) As String ' Return type changed
from Long to String
' Code here
End Function
The reason for this is that older applications/DLL/OCX's that use your DLL
are still using 'x = Search("Test")'. COM cannot fill the second parameter
with arbitrary values for you, neither it can convert the data type for
parameters or return type for the function, so you get an error like (Method
~ of Object ~ failed) amongst other errors.
There are 2 ways if you still want to apply the changes:
1 - Change the project's name and the DLL file name. This creates a brand
new DLL. Your old Apps have to use the old DLL. Installing the new DLL has
no effect on the old App. They will continue to use the old DLL.
2 - Break Binary Compatibility and make the changes, but you have to erase
all traces of the incompatible DLL and all traces of the applications that
used it, and by erasing all traces I mean uninstall the DLL from every
single computer the DLL was installed on and the applications that depend on
it, that is. To uninstall the DLL, you must unregister it successfully
first, then delete it, followed by all applications that used it, then
install the newly compiled DLL and EXE.
2 - Maintain Binary Compatibility and add a "duplicate" function or
property, like "Search2" or "SearchEx". Another way is to add a new
"SearchMode" property to be filled before the function call so to keep the
function definition the same. You could change the code inside "Search"
function, but you cannot change its definition. With Binary Compatibility
you could define extra methods and properties, but you can't change the
definition of old ones.
For the above reason, you have to be careful with your first release so you
don't have to make a lot of changes later. If you think that a function
requires a lot of changes later, you could use variable parameters like
this:
Public Function Search(ParamArray p() As Variant) As Variant
Dim i As Long
' Code here
For i = LBound(p) To UBound(p)
Debug.Print p(i)
Next
End Function
When you turn on "Binary Compatibility" in your ActiveX project options, VB6
would show you a warning whenever you make these mistakes, but if you
clicked OK without reading the message box, it turns off "Binary
Compatibility" for you and then you are in trouble. You could turn it back
on again and fix the problem if that happened by undoing your changes.
Finally, what happens when a DLL is registered is that a function inside the
DLL is called (DllRegisterServer). This is a callback function that creates
the needed registry entries. DllUnregisterServer() does the opposite thing.
These would obviously fail if the user did not have enough permissions. VB6
create these for you, so you don't have to worry about them. C++ developers
could make the mistake of not checking if the registry entries were created
successfully, since they write their own routines. If they made that
mistake, that's an automation error for you. This is obviously not the only
way to make automation errors, setup programs have their faults, like
checking the file's date and time instead of the version number. While the
end user is most likely never going to copy the DLL back and forth between
computers, you, the developer could be copying the DLL back and forth and
thus it has a different file date and time. This can be an issue if you
released a second copy within few hours for instance.
You could tell if a DLL is a Standard Windows DLL or not by using "Depends"
in VS6 Tools in the start menu. If the DLL has DllRegisterServer function
listed, then it's a ActiveX/COM file that requires registration.
Please read more about "Binary Compatibility" if you are making your own
ActiveX.
INFO: Registry Entries Made by an ActiveX Component
http://support.microsoft.com/default.aspx?scid=kb;en-us;183771
Reference:
Version Compatibility in ActiveX Components
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconversioncompatibility.asp
"boaz" <nos...@yahoo.com> wrote in message
news:%23ZNnzaN...@tk2msftngp13.phx.gbl...
boaz
doesn't care.
And I don't worry about intallation problem. Many of my customers have a
big IT department. Many of them know what to do. Many of them don't. The
real problem is that "updating" (of any kind) for them is a big deal.
I actually was thinking to switch to Delphi. But the same problem came
back. I couldn't sell the stuffs if I told them it was written in Delphi.
I had to tell them that it was Microsoft and MacroMedia, and craps like
that.. So, the guys who were resposible for purchasing knew my craps were
good craps. ;-)
So anyway... according to "Someone", using ".local" may (and just may) not
do the trick. I look at my projects, I don't have any custome dll at all.
And the third party OCXs don't have any dependency (according to them).
So... back to the topic... do I good to go not to register the DLL/OCX? or
back to the original topic. Do I have to register OCX/DLL in order for my
program to work?
>
DanS
news:OpwJ8vO...@TK2MSFTNGP15.phx.gbl:
So what do your products do ? What are they ? Do you have a web page ?
What makes a company with a large IT department want your s/w ?
And, I'm kind of shocked that they would care what language they are
developed in as long as they work as promised. In fact, in the big business
world, I would tend to think that major IT departments have a perception of
VB as being a very hobby'ish language.
(NOTE: THAT I DON'T AGREE WITH THIS AT ALL.)
Regards,
DanS
Someone
Delphi can create EXE's with minimum dependency, like C++, but VB's syntax
is more easily read than Delphi(Delphi uses Begin/End keywords for every
block of code).
InnoSetup was written with Delphi and has no dependency, just like Notepad.
> So... back to the topic... do I good to go not to register the DLL/OCX?
> or back to the original topic. Do I have to register OCX/DLL in order for
> my program to work?
In English, OCX/DLL files must be registered before using them. If I am
reading MSDN correctly, ".local" trick don't work on ActiveX/COM components
with broken binary compatibility because you can't have 2 different set of
registry keys for the 2 DLL's simultaneously(The old and new DLL). There
isn't enough documentation. If MS is supporting this for ActiveX/COM
components, they have to redirect the registry as well, but the
documentation doesn't show anything about registry redirection.
The ".local" trick will load the alternative DLL, but will not register it
when the EXE is opened as far as I understand the documentation. If you
register this new version of the DLL and it's not compatible with older
versions then you will break older version of your applications unless you
recompile them and send them to your customers.
".local" comments in MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic_link_library_redirection.asp
You may want to check with the 3rd party vendor to see if they have any
suggestions or published bug reports.
If I were you, I would do one of the following:
1 - Use the old DLL: Uninstall the new incompatible DLL/OCX from my
development machine and make sure that the DLL/OCX was deleted, if not,
delete it manually. Never delete an ActiveX file without unregistering it
first by either uninstall or manually unregister it. Now install the older
DLL and recompile your application, no need to recompile applications that
already use the old DLL. At the end user, the user must unregister the new
DLL and make sure that it was deleted, then reinstall your new app which
uses the old DLL.
2 - Use the new DLL(Recommended): Make sure that you have the latest version
on your development machine, then recompile all of your applications that
use this DLL. Tell the end users to uninstall all of the old Apps first,
then install the new package.
If the DLL/OCX that you are using is widespread, and the user has an old App
that was made by a 4th party, then that application will stop working if it
uses that DLL. You, yourself could be that 4th party if the user had no
problems at all, then updated one application which updated to incompatible
DLL, in that case, all of your apps that use that DLL will stop working and
the user would blame you, when it's the DLL/OCX vendor's fault. But as far
as the user is concerned, you are one unit.
"boaz" <nos...@yahoo.com> wrote in message
news:OpwJ8vO...@TK2MSFTNGP15.phx.gbl...
boaz
Gates want us to put all the OCX/DLL in the System32 folder? And the
problem I had following this "good practice" was that when there was a new
OCX, the old program would load the new OCX from the other program's folder.
"It is good practice to install application DLLs in the same directory that
contains the application, even if you are not using DLL redirection. This
ensures that installing the application does not overwrite other copies of
the DLL and cause other applications to fail. Also, if you follow this good
practice, other applications do not overwrite your copy of the DLL and cause
your application to fail."
boaz
can't sell no crap without mentioning XML nowaday. ;-) Actually, you can
dump "VB" all together. They all want C# nowaday... by some unknown
reason...
Someone
installed it in the system folder, they are both going to have problems and
their clients. Usually, you have to follow their recommendation on where to
install the OCX.
If a company says install the OCX in the App's folder and they always
maintained binary compatibility, then this problematic scenario could easily
happen:
- The user installs your app with version 2.0 of the OCX installed in your
App's folder.
- Several months later, the user installs a 4th party App that uses version
1.0 of the OCX.
- Installers normally look in the target folder first before updating an
ActiveX file, not the registry. Since no file is there, they proceed with
installing the older version.
- The 4th party installer registers version 1.0, which includes where the
OCX is installed.
- Both App's would use OCX version 1.0 that was last installed, which is in
the 4th party App folder.
This could break your app if you used features in the new version(or may not
work at all) because when the 4th party installer installed the OCX, it
updated the registry too, so your App would be using version 1.0 of the OCX.
Remember; with binary compatibility you can add new properties and methods,
but you can't change the definition of old ones.
- Now the user tries to run your program and encounter problems and contacts
you. You won't know what is going on unless you ask the user if he or she
installed a software recently or used Windows update, not to mention
automatic software updates...
Finally, the best practice for OCX/DLL vendors to install their files is in
the following folder:
C:\Program Files\Common Files\VendorCompany\
The Windows API must be used to get the folder above, not hard code it.
Sample:
http://vbnet.mvps.org/index.html?code/browse/csidl.htm
"boaz" <nos...@yahoo.com> wrote in message
news:%23IWjBwP...@TK2MSFTNGP15.phx.gbl...
boaz
with C with so many {}. ;)
On the other hand, I kinda like Ada (another Pascal clone to me). No way to
make mistake in Ada... of course unless you are so bad with programming.
"Someone" <nob...@cox.net> wrote in message
news:%23HyRqkP...@TK2MSFTNGP09.phx.gbl...
>> I actually was thinking to switch to Delphi.
>
> ...but VB's syntax is more easily read than Delphi(Delphi uses Begin/End
DanS
news:unUXfzP1...@TK2MSFTNGP10.phx.gbl:
> Oh! They made a big deal about VB6. And the buzzword nowaday is XML.
> You can't sell no crap without mentioning XML nowaday. ;-)
> Actually, you can dump "VB" all together. They all want C# nowaday...
> by some unknown reason...
It's the whole .Net thing that M$ is forcing down everyone's throat.
So what do your products do ? What are they ? Do you have a web page ?
I've been reading your posts and the questions are all over the place. From
database questions to NNTP and I can really figure what kind of
application's you write.
boaz
"DanS" <t.h.i.s....@a.d.e.l.p.h.i.a..n.e.t> wrote in message
news:Xns96F4D3017...@216.196.97.142...
DanS
@TK2MSFTNGP09.phx.gbl:
> go to the epa website and look for nif.
>
whatever.
why can't you just say what you have written and sold 'like hotcake' ?
i would think that any programmer that wrote a decent piece of software
that was commercially successful would gladly take credit for it..or at
least say what it is.
Jim Carlock
> I cannot replace the old dll files.
>
>
> But many people say that I need to register the DLL/OCX.
> So, I am confused.
What kind of controls are you having problems with?
Maybe someone can suggest something based upon a
particular control, or perhaps they might be able to get
a clue as to the exact nature of your confusion. Maybe
you can elaborate a little on where or what you're
confused about... perhaps by explaining what controls
seem to present the problems. Maybe provide a little
more about the problem?
Messing with the InnoSetup software helped me alot with
understanding what's going on with specific DLLs during
an install. Also, understanding what's going on with Windows
File Protection (the SFC.EXE utility on Win2K and later)
helps.
For instance, you may run into problems where you put a
file on a system, and then the operating system over-rights
the file your installation with the "other" version. You can
see this by performing a simple test...
1) Open the C:\Program Files\Internet Explorer\ folder.
2) CUT iexplore.exe.
3) Navigate to the SIGNUP folder.
4) Paste into the SIGNUP folder. You'll see iexplore.exe
appear there.
5) Navigate back to the C:\Program Files\Internet Explorer
folder.
6) If iexplore.exe isn't there already, wait less than a minute.
It'll automatically reappear.
That applies to Win2K and later. It may apply to Windows
Me as well.
If you know what controls give problems, perhaps you can
tell us if they are controls you've created, or if they're controls
supplied by Microsoft (ie, come with Visual Studio).
boaz
Hehehe!
Michael C
>I cannot use the "free" stuffs. I need to sell my products. Most of the
>free stuffs are for "Personal" use only.
> Plus it is not a sound decision in a marketing point of view. I need to
> market my stuffs with well known brand names... huh... like
> InstallShield... Photoshop... etc. etc.
>
> I remembered one of my customers had problem installing a program of mine.
> I told the IT guy that I was using InstallShield and it was one of the
> best. This shut him up right away. ;)
I would have thought NSIS would be up there with InstallShield and Wise as
one of the well known installers. I installed a couple of programs recently
from some big name companies and noticed both were using NSIS.
Michael
Michael C
> Oh! They made a big deal about VB6. And the buzzword nowaday is XML.
> You can't sell no crap without mentioning XML nowaday. ;-) Actually, you
> can dump "VB" all together. They all want C# nowaday... by some unknown
> reason...
I'm sure there are plenty of apps out there selling a lot more than yours
that use some unheard of language installed by an unheard of installer and
don't use XML.
Michael
boaz
database system on VMS or something like that. Need to Telnet to the server
to get the records.
But... I am still confused about registering DLL. Most of the reply are off
topic.
"Michael C" <mcu...@NOSPAMoptushome.com.au> wrote in message
news:eUXxRNC2...@TK2MSFTNGP09.phx.gbl...
Michael C
>I know. Just like one of my projects. They are running some sort of
>database system on VMS or something like that. Need to Telnet to the
>server to get the records.
>
> But... I am still confused about registering DLL. Most of the reply are
> off topic.
Ok, if you're using vb6 I would forget about even attempting to run the dlls
'side by side'. If you really need both apps to have a seperate copy of the
dlls then I would break them into 2 seperate projects and run them as if
they are completely seperate components. To do this you compile your dll to
a new filename with No Compatibility and then go back to project or binary
compatibility. I think you should also rename the project before doing this.
This way they are no longer the same dll but 2 completely different dlls
that just happen to have all the same source code and both will run happily
on the users machine.
Regards,
Michael
boaz
This is the part that I don't understand.
My project doesn't have any DLL/OCX of my own.
My project consists of only 1 EXE (the main program) and couple of third
party OCXs.
I only have a third party grid and some other third party OCXs.
All my other projects use the same third party OCXs.
My old projects used to work fine until the other companies upgraded their
OCXs to support W2K/XP.
"Michael C" <mcu...@NOSPAMoptushome.com.au> wrote in message
news:eNHIxFP2...@TK2MSFTNGP10.phx.gbl...
vbexp
flawless. You may want to search their KB articles:
http://helpcentral.componentone.com/Search.aspx?Refresh=1
They have their own newsgroups:
http://helpcentral.componentone.com/Newsgroups.aspx
"boaz" <nos...@yahoo.com> wrote in message
news:eFXuFWP2...@TK2MSFTNGP09.phx.gbl...
boaz
So... if I not to register any of the new OCXs, and just copy the new OCXs
to the same Program Folders of my application (which is just 1 EXE file),
will it be ok to do so?
As I said before, if I copy the OCXs to my Program Folders and register the
OCXs, all my old programs will look for the new OCXs in the Program Folders
of my new program. This is not ok.
P.S.
This is going nowhere.
I am thinking that I am not describing my problem clearly.
"vbexp" <nob...@cox.net> wrote in message
news:%23dZ4coP...@TK2MSFTNGP12.phx.gbl...
Michael C
>I don't have any problem with the OCXs from ComponentOne.
>
> So... if I not to register any of the new OCXs, and just copy the new OCXs
> to the same Program Folders of my application (which is just 1 EXE file),
> will it be ok to do so?
>
> As I said before, if I copy the OCXs to my Program Folders and register
> the OCXs, all my old programs will look for the new OCXs in the Program
> Folders of my new program. This is not ok.
Ok, that makes a bit more sense. You are quite stuck then I think. You can't
have 2 copies of the same third party ocx on your machine and expect
different apps to use different files. OCXs shouldn't be in your programs
folder.
If I understand the problem, you have 2 or more apps that use the same third
party OCX. By updating app B and releasing it with the new third party OCXs
you are breaking app A? The only solution I can see is to go ahead and
release app B and allow app A to be broken. You will then need to provide an
update for app A. There's no other solution I can see because you are going
to have to release a new version of A because another vendor might release
an app with the updated ocxs anyway which would break A.
> This is going nowhere.
> I am thinking that I am not describing my problem clearly.
It could be that you have but the thread is so old and off topic that what
you said in the original post has been forgotten. :-)
Michael
vbexp
> to the same Program Folders of my application (which is just 1 EXE file),
> will it be ok to do so?
No, it will not work unless there was a binary compatible OCX in the system
already. I am not sure though if DLL redirection will work in this case.
> As I said before, if I copy the OCXs to my Program Folders and register
> the OCXs, all my old programs will look for the new OCXs in the Program
> Folders of my new program. This is not ok.
Sounds like Catch-22. I would contact the OCX vendor to see if they have any
solution.
"boaz" <nos...@yahoo.com> wrote in message
news:e8NSV4P...@TK2MSFTNGP09.phx.gbl...
boaz
> Ok, that makes a bit more sense. You are quite stuck then I think. You
> can't
> have 2 copies of the same third party ocx on your machine and expect
> different apps to use different files. OCXs shouldn't be in your programs
> folder.
>
Now this come to my second "Original" question. (yes it is going a cycle)
So, for the sake of it, I tested my new program on a brand new Win2K
computer. I just copied the main EXE and the OCXs to the same folder
without registering anything. (just copy and paste). And it worked. And
according to the previoues posts, if I didn't register the OCXs, the program
would not work. But this was not the case. I was confused. I was thinking
if I did the same thing for the rest of my programs, it would solve my
problem. (i.e.) Not to register anythng. Just copy and paste the EXE and
their own OCXs to their own folders. (and add the ".local" file there)
> If I understand the problem, you have 2 or more apps that use the same
> third party OCX. By updating app B and releasing it with the new third
> party OCXs you are breaking app A? The only solution I can see is to go
> ahead and release app B and allow app A to be broken. You will then need
> to provide an update for app A. There's no other solution I can see
> because you are going to have to release a new version of A because
> another vendor might release an app with the updated ocxs anyway which
> would break A.
>
You are correct.
I installed the new program and all the old programs stoped working.
boaz
solution."
They told me to recompile all my old programs.
This is not possible. This will freak out the IT guy over there. And he
already freaked out... people, lotz of people, were calling him to ask why
the old programs didn't work... And he was redirecting all the calls to
me... And this was very BAD to my mortal soul!!!!
And he just installed the new program to.. <g> god knows how many
computers... When I told him to update all old programs to the new versions,
he was... just... DAM#####... you know what...
Michael C
> "...I would contact the OCX vendor to see if they have any
> solution."
>
>
> They told me to recompile all my old programs.
> This is not possible. This will freak out the IT guy over there. And he
> already freaked out... people, lotz of people, were calling him to ask why
> the old programs didn't work... And he was redirecting all the calls to
> me... And this was very BAD to my mortal soul!!!!
>
> And he just installed the new program to.. <g> god knows how many
> computers... When I told him to update all old programs to the new
> versions, he was... just... DAM#####... you know what...
This is an internal app? Just update all the machines! When he complains how
much work that will be just say "Just automate it, you do have way of doing
that, right?"
Michael
boaz
"Michael C" <mcu...@NOSPAMoptushome.com.au> wrote in message
news:OIXH$VQ2FH...@TK2MSFTNGP09.phx.gbl...
Michael C
> It is not internal. It is for one of my customers.
But a single customer?
Michael
Michael C
> It is not internal. It is for one of my customers.
It seems to me you are going to a lot of trouble to save him a little. I
would just say to him there is nothing you can do, it's out of your hands
(which is true!) and you've done everything you can to attempt to resolve
the problem (which is also true).
Michael
boaz
"Michael C" <mcu...@NOSPAMoptushome.com.au> wrote in message
news:%23bcTZVR...@tk2msftngp13.phx.gbl...
vbexp
> registering anything. (just copy and paste). And it worked.
The OCX may have been registered already. Try this instead: before
installing on a new computer, search the registry for the OCX file, you will
either find that it was registered before, or see my comments below about
registering during DllMain call.
Perhaps part of your confusion is that ActiveX files are called
self-registering DLL's. This doesn't mean that they are magically
registered, a setup program or an update utility must call
DllRegisterServer() which is exposed by the DLL/OCX. Self-registering here
means that the DLL/OCX will create the registry entries that it needs to
function all by itself, i.e., self maintaining, however, an installer or
updater must call DllRegisterServer() inside the DLL/OCX during installation
time. Self-registering is actually self-maintaining, not auto register.
Programs like "regsvr32.exe" and installers register a DLL by calling
DllRegisterServer(), and unregister by calling DllUnregisterServer().
Having said that, it's possible for a vendor(using C++), when the DLL is
first loaded to check if the registry entries were present or not, and add
them. However, many don't do that and it could be a big mistake, since only
Administrators and Power Users can write to HKEY_LOCAL_MACHINE. The vendor
may have added such a check in DllMain(), which is called when the DLL is
first loaded. You can tell if the vendor is doing that by searching the
registry for the OCX file, and if not found, just copy the OCX files and
your EXE and run your EXE. While the EXE is open, search the registry again,
if you find the OCX, then the vendor is registering the DLL if it was not
registered during DllMain call, which is called by LoadLibrary API function.
P.S.: OCX files are DLL's as far as the OS is concerned.
Self Registration for Controls
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/0fff07e5-10bb-4052-8eb1-021efcb66d6c.asp
> Just copy and paste the EXE and their own OCXs to their own folders. (and
> add the ".local" file there)
I just double checked if the .local trick works with ActiveX files created
with VB6 when they are not registered, and it doesn't. I created a test DLL
"DotLocal.dll" and an EXE that uses it "DotLocalTest.exe". I used a
"DotLocalTest.exe.local" file, but it doesn't work.
"boaz" <nos...@yahoo.com> wrote in message
news:uvqf%23NQ2F...@TK2MSFTNGP15.phx.gbl...
vbexp
updated version. However, you could make it easier on your customer by
making an update utility in VB6. This utility would be run from a login
script so the admin doesn't have to visit each computer.
This utility would check a registry entry, like "Update=1", and if not
found, it creates it after a successful update so the update is not done
again.
Here is how I do it if I were you:
- Update.exe accepts "/admin" and "/doupdate" command line arguments.
- It has Public Sub Main and Form1. Main runs first.
- Add "VB 6 Resource Editor" to the project, and add a new resource file
from the project menu.
- When started, it checks for "/admin" using VB's Command Function, and when
specified, it shows Form1.
- Form1 lets the admin enter a user name, password, and a domain that is a
member of Administrators.
- I would use UpdateResource() API call to save the info in the EXE.
- Admin puts "update" in a login script, such as a batch file.
- When "update" runs without command line arguments, it uses
CreateProcessWithLogonW() API call to start "update /doupdate" with the more
privileged credentials so the update can be done successfully.
- When "/doupdate" is used, the actual update is done. VB's LoadResString
can be used to get the previously stored username/password/domain from the
EXE file.
- If the admin is worried about his/her password, either you could encrypt
it, or tell him/her to change his/her password to a temporary one and then
change it back after everything was done.
Note that CreateProcessWithLogonW requires Windows 2000+, if the user has
NT4, then you have to use CreateProcessAsUser which is slightly more
difficult to use. Note that these functions refer to HKEY_CURRENT_USER as
the user's profile, so you have to load it if you need to access it.
If the Admin doesn't have Windows 9x clients, then he or she could use
"RUNAS" in a batch file so you save a programming step. Also, if all users
are members of Power Users, then RUNAS is not needed. The difference between
an Administrator and a Power User in regard to installation is that under a
Power User the installer cannot tell the OS to replace a file during
reboot(if it was in use at the time). In your case, the OCX is not in use
since your App is not running because the user has just logged in and no
other Apps are running(except services), so this issue does not effect
you(unless your VB6 app runs as a service).
If you want to register a DLL using VB6, you could declare DllRegisterServer
as follows:
Public Declare Function DllRegisterServer1 Lib "One.ocx" Alias
"DllRegisterServer" () As Long
Public Declare Function DllRegisterServer2 Lib "Two.ocx" Alias
"DllRegisterServer" () As Long
Public Declare Function DllUnregisterServer1 Lib "One.ocx" Alias
"DllUnregisterServer" () As Long
Public Declare Function DllUnregisterServer2 Lib "Two.ocx" Alias
"DllUnregisterServer" () As Long
To call it, use:
ChDrive OCXPath
ChDir OCXPath
result = DllRegisterServer1()
The first 2 would change the current directory so the OCX that is registered
is the one at OCXPath, since LoadLibrary would check the current directory
before checking the SYSTEM folder. I would suggest that you check if the OCX
was registered first before calling DllRegisterServer. I think there is a
counter somewhere that counts how many times a DLL was installed so it's
only removed after the last application that uses it was uninstalled, so try
not to install the DLL repeatedly, I am not sure how this works or where
it's stored in the registry, nor if the counter is incremented by an
installer or DllRegisterServer.
Since you are going to need to find what OS version the utility runs on, you
may want to check this sample:
Obtaining Windows' Version Information
http://vbnet.mvps.org/index.html?code/system/getversionex.htm
"boaz" <nos...@yahoo.com> wrote in message
news:uTuzySQ...@TK2MSFTNGP10.phx.gbl...
Ken Halter
>
> I just double checked if the .local trick works with ActiveX files created
> with VB6 when they are not registered, and it doesn't. I created a test
> DLL "DotLocal.dll" and an EXE that uses it "DotLocalTest.exe". I used a
> "DotLocalTest.exe.local" file, but it doesn't work.
>
DLL/COM Redirection on Windows
"Isolated COM components must be registered with Windows so that different
versions of the assembly will not conflict with each other when loaded into
memory at the same time. The registration process requires that, while the
implementation of the component can change between versions, certain COM
metadata such as CLSID, ProgID, Type Library, and Threading Model cannot."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/dll_com_redirection_on_windows.asp
I tried a couple of weeks ago... worked fine.
fwiw, my test went a bit like this....
Built DLL in its own folder, DLL has only one method and shows a MsgBox that
contains a hard-coded string.
Copied that DLL to the EXE's folder, leaving the "built" version registered
and in place.
Rebuild the DLL in its own folder, changing the hard-coded string. This is
still the only registered version..
Ran the EXE. The results show the new hard-coded string.
Added the .local file to the exe's folder
Ran the EXE. The results now show the old hard-coded string.
.Local also works for subfolders (one level deep) under the EXE's app.path
(see first link below)
It's actually pretty cool but I haven't had a chance (or reason) to use it
in a real app.
More info....
Dynamic-Link Library Redirection
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic_link_library_redirection.asp
Implementing Side-by-Side Component Sharing in Applications (Expanded)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsetup/html/sidebyside.asp
The End of DLL Hell
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsetup/html/dlldanger1.asp
--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
Please keep all discussions in the groups..
boaz
though. I have never used SMS to roll out anything.
"vbexp" <nob...@cox.net> wrote in message
news:%23DpIOkZ...@tk2msftngp13.phx.gbl...
Michael C
> Can't do that. They pay well and they pay well on time.
You have to do that, you've got no choice.
Michael