Install Problems
hcau...@yahoo.com
I've been using VB6 SP6 and th MS Installer with no problems.
I read where 32 bit apps will run on a 64 bit machine but my
clients are getting an error when they try to install on a new Windows
7 - 64 bit computer.
"Install Setup Bad Image - Windows System 32 VB6STKIT.dl is either not
designed to run on Windows or it contains an error"
I may just be late to the game
thanks
Deanna Earley
The PDW installer has been mostly broken (by default) since Windows XP.
It's best to move to something more up to date like MSI or Inno:
http://hashvb.earlsoft.co.uk/Setups
--
Dee Earley (dee.e...@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/
iCode Systems
(Replies direct to my email address will be ignored.
Please reply to the group.)
ralph
This is basically the O/S 'launcher' (actually a suite of many
complicated processes) saying "I've fallen and can't get up".
By now you've done multiple searches online for possible solutions and
you have discovered two things ...
1) It can be caused by a wide variety of diverse issues.
(The indicated component may actually be corrupted, or it may only be
the component of interest at the time the O/S decided to bail. You may
be trying to install your product in the wrong locations.
Configuration of the target. Mallware products installed on the
target. ...)
2) The solutions offered are ALWAYS a reflection of the special
interest or opinions of the responder and seldom of any real help.
View them as "hints" at best.
(Virus vendors will recommend using their tools to 'clean' the target.
Others will recommend you don't use a particular product. Blah, blah,
blah, ...)
Just remember they have less of a clue of what might be the problem,
in YOUR problem domain, than you do. <g>
To ferret out the cause you will need to go back to basics, do a lot
of information gathering, and a lot of testing.
Having a Windows 7 platform to test on will help. (If not a
requirement!)
Until you can duplicate the problem or environment in which the error
occurs, you are just guessing - like the rest of them.
Using a different installer may help. Just as moving things, removing
items, or changing the order of an install may also help.
Take comfort that a solution will be found and it will be a trivial
fix when compared to all the time it will take to isolate the problem.
Wholesale reengineering is seldom, if ever, required.
>I may just be late to the game
>
No. But you will have to learn some new stuff. <bg>
-ralph
Mayayana
| >designed to run on Windows or it contains an error"
| >
Also, I imagine you noticed this:
If that error message is accurately copied it indicates
that the 32-bit setup support lib. has somehow been
copied to the 64-bit system folder.
I wonder if this link might shed some light:
http://msdn.microsoft.com/en-us/library/aa384187%28v=vs.85%29.aspx
ralph
Good suggestion.
I too suspect 'redirection' or something of that ilk is at fault. But
hesitated to go there in much detail without more information. I also
assume that once the OP started testing his install against a Windows
7/64 platform this possiblity as well as others would soon be
discovered.
-ralph
Abhishek
unless you specifically need windows installer based setup.
and VB6 apps runs fine on Win 7 32-bit/64-bit. also get virtual pc, it will
help you test your software under difference os.
--
abhishek
http://vb6zone.blogspot.com
<hcau...@yahoo.com> wrote in message
news:d5mg17p1kennprpt9...@4ax.com...
Mayayana
It doesn't need to be going into the system folder, but
it is needed for the PDW setup. It handles logging,
CAB extraction, and DLL registration. MS made it as
a handy little package of functions needed by a typical
setup:
Public Declare Function DllAbortAction Lib "vb6stkit.dll" Alias
"AbortAction" () As Long
Public Declare Function DllAddActionNote Lib "vb6stkit.dll" Alias
"AddActionNote" (ByVal lpszNote As String) As Long
Public Declare Function DllCommitAction Lib "vb6stkit.dll" Alias
"CommitAction" () As Long
Public Declare Function fDllWithinAction Lib "vb6stkit.dll" Alias
"fWithinAction" () As Long
Public Declare Function DllLogError Lib "vb6stkit.dll" Alias "LogError"
(ByVal lpszERROR As String, ByVal lpszDURINGACTION As String, ByVal
lpszErrMsg As String) As Long
Public Declare Function DllLogNote Lib "vb6stkit.dll" Alias "LogNote" (ByVal
lpszNote As String) As Long
Public Declare Function DllLogWarning Lib "vb6stkit.dll" Alias "LogWarning"
(ByVal lpszWARNING As String, ByVal lpszDURINGACTION As String, ByVal
lpszWarningMsg As String) As Long
Public Declare Function DllNewAction Lib "vb6stkit.dll" Alias "NewAction"
(ByVal lpszKey As String, ByVal lpszData As String) As Long
Public Declare Function DllEnableLogging Lib "vb6stkit.dll" Alias
"EnableLogging" (ByVal lpszFilename As String) As Long
Public Declare Function DllDisableLogging Lib "vb6stkit.dll" Alias
"DisableLogging" () As Long
Public Declare Function ExtractFileFromCab Lib "vb6stkit.dll" (ByVal Cab As
String, ByVal File As String, ByVal Dest As String, ByVal iCab As Long,
ByVal sSrc As String) As Long
Public Declare Function DLLSelfRegister Lib "vb6stkit.dll" (ByVal lpDllName
As String) As Integer
Public Declare Function RegisterTLB Lib "vb6stkit.dll" (ByVal lpTLBName As
String) As Integer
Abhishek
"Mayayana" <maya...@invalid.nospam> wrote in message
news:ivfn46$vqq$1...@dont-email.me...
Mayayana
|
Yes, but that's what he's doing! To say that VB6STKIT.DLL
is not necessary is inaccurate and confusing. It's like answering
a question about car maintenance with bicycle care advice,
simply because you hate cars and don't want to make it any
easier for other people to use them.
He may take the advice to use a different installer, but
the question was about VB6STKIT.DLL somehow ending up
in the 64-bit system folder *during a PDW install*, when it
shouldn't actually be getting moved, since it's a setup file
rather than a dependency.
In setup.lst, VB6STKIT.DLL is designated to be copied
to: WinSysPathSysFile. But since it's only needed by setup,
and since setup actually runs from the Windows folder, I'm
guessing that it might work to change that line to
[Bootstrap Files]
File1=@VB6STKIT.DLL,$(WinPath)....
But I haven't actually tried it. So far I haven't had any trouble
myself installing to Win7.
I'm still trying to figure out why Inno setup engenders the
sort of irrational devotion that one usually only sees with
Apple Seeds and sports fans.
HarryC
>Thanks guys, you have given me alot to work on. I changed the line to $(WinPath) like Mayayana suggested
and it works on my XP machine now we'll try it on a windows 7 64
machine.
ralph
<maya...@invalid.nospam> wrote:
>
> I'm still trying to figure out why Inno setup engenders the
>sort of irrational devotion that one usually only sees with
>Apple Seeds and sports fans.
>
I have exactly the same wonder.
I can and do understand why a new VB developer might use Inno. Inno
and its toolset does offer a few features and is perhaps prettier -
'out of the box'. Features that take extra strokes to instrument with
PWD. I've used Inno, and the memories of my initial, less than
stellar, brush with PDW are still fresh, so I can certainly appreciate
Inno's appeal.
[But never quite understood how learning a new scripting language and
associated nuances was somehow better than using VB code which the
developer already knew. Or how viewing a script file was 'easier' than
simply using the PDW dialogs?]
Inno is very popular and for some good reasons. I find no fault with
anyone that chooses to use it, nor would I ever go looking for one. I
believe their happy users could easily list a ton positives for it.
But they very seldom, if ever, do. It seems it is always - PDW is
trash, evil, ugly, odorous, disguised malware, blah, blah, ... ,
therefore use Inno Setup - period.
It might only be a case of Cognitive Dissounce gone wild. Deep down
they know there isn't a dime's worth of difference (or in fact in the
hands of an experienced user PDW is far more 'powerful'), but their
decision must be justified. <bg>
-ralph
Abhishek
Inno generates single exe file, it looks professional, it is used by a lot
by developers so it gives the user a 'standard' installation look and feel,
its flexible as I can shellexcute and wait, and many more feature.
no need to learn the Pascal script, there are script wizard for generating
the script. I have reviewed some installers on my blog here
http://vb6zone.blogspot.com/2010/08/installers.html
--
abhishek
"ralph" <nt_cons...@yahoo.net> wrote in message
news:g7qo179bi4e1nc168...@4ax.com...
Mayayana
| Inno generates single exe file, it looks professional,
That's what I like about the PDW. :)
I can package it all into a single SFX with my own
logo as an icon, and the GUI is whatever I want it to look
like. I'm not stuck with a bland, purple image of....
whatever that is. A PC with a cord coming out of it?
I'm with Ralph: I have no complaint with Inno. A lot
of people seem to like it and the author seems to try
to stay on top of changes. But Setup1 is VB. It's the
ultimate customizable installer. (Though it's true that
at this point it does, indeed, need some customizing
in order to ork well.)
Deanna Earley
> Inno is very popular and for some good reasons. I find no fault with
> anyone that chooses to use it, nor would I ever go looking for one. I
> believe their happy users could easily list a ton positives for it.
> But they very seldom, if ever, do. It seems it is always - PDW is
> trash, evil, ugly, odorous, disguised malware, blah, blah, ... ,
> therefore use Inno Setup - period.
Mainly because it's in reply to "I'm having XYZ problems with PDW" so I
point to an alternative, that by implication, doesn't have those problems :)
For more details, I normally link to an article that talks about the
various options.
(I can't speak for everyone else that recommends it though :)