MSVCRT differnet in Vista
Rattman
(Visual Studio package and deploy) my applications in XP they work across
2000,XP,Vista and 7. But if I Package them under Vista I get an "unable to
find entry point " in the MSVCRT.dll when installing on 2000 or XP machines.
Under windows 2000 and XP it appears this DLL only had handlers 1 and 2 but
in Vista it has 1,2,3,4. So when packaged it is looking for 3 & 4 on the
older machines. Has anybody else come across this? Is there a fix?
Ralph
Don't include the MSVCRT.dll in your package. In fact you should not have
been including it starting with Win2000.
MSVCRT is the Microsoft C Runtime library and the correct version is
installed with every Windows versions. If and when it is upgraded it should
only be upgraded via O/S Service Packs.
It often gets included with a P&D package become many components list it as
a dependency. Either manually delete it from the file list when building the
package or modify the .dep file for any particularily troublesome component.
-ralph
Rattman
the VB "Package and deploy" because it only gives the error during installing
on older systems and not when running the program.
Ralph
Besides removing the file from the List when creating a package.
Open the ...~\vb98\Wizards\PDWizard\Vb6dep.ini file with a text editor.
Scroll down to the [Do Not Redistribute] section and add ...
msvcrt.dll=
msc40.dll=
msc42.dll=
olepro32.dll=
oleaut32.dll=
stdole2.tlb=
If you already have a package and don't won't to rebuild:
Open the Setup.lst file in a text editor.
Look in the [Bootstrap Files] and [<packagename> Files] Sections for any
reference to Msvcrt.dll
Delete it
Then renumber the following files.
hth
-ralph
Rattman
there is no reference t o this DLL. See below
[Bootstrap]
SetupTitle=Install
SetupText=Copying Files, please stand by.
CabFile=DigiSelect.CAB
Spawn=Setup1.exe
Uninstal=st6unst.exe
TmpDir=msftqws.pdw
Cabs=1
[Bootstrap Files]
File1=@VB6STKIT.DLL,$(WinSysPathSysFile),,,7/15/00 12:00:00
AM,101888,6.0.84.50
File2=@COMCAT.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,6/1/99 12:00:00
AM,22288,4.71.1460.1
File3=@STDOLE2.TLB,$(WinSysPathSysFile),$(TLBRegister),,6/3/99 12:00:00
AM,17920,2.40.4275.1
File4=@ASYCFILT.DLL,$(WinSysPathSysFile),,,3/8/99 12:00:00
AM,147728,2.40.4275.1
File5=@OLEPRO32.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,3/8/99 12:00:00
AM,164112,5.0.4275.1
File6=@OLEAUT32.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,4/12/00
12:00:00 AM,598288,2.40.4275.1
File7=@MSVBVM60.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,2/23/04
12:00:00 AM,1386496,6.0.97.82
[IconGroups]
Group0=DigiSelect
PrivateGroup0=-1
Parent0=$(Programs)
[DigiSelect]
Icon1="DigiSelect.exe"
Title1=DigiSelect
StartIn1=$(AppPath)
[Setup]
Title=DigiSelect
DefaultDir=$(ProgramFiles)\DigiSelect
AppExe=DigiSelect.exe
AppToUninstall=DigiSelect.exe
[Setup1 Files]
File1=@Playlist.dat,$(AppPath),,,6/16/09 5:08:15 PM,88,0.0.0.0
File2=@DigiSelect.htm,$(AppPath),,,12/29/09 7:05:11 PM,112370,0.0.0.0
File3=@test1.mp3,$(AppPath),,,6/15/09 5:30:28 PM,40150,0.0.0.0
File4=@thankyou.wav,$(AppPath),,,6/15/09 5:26:55 PM,317694,0.0.0.0
File5=@MSCOMCTL.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),4/15/05
8:58:16 PM,1071088,6.1.97.86
File6=@COMDLG32.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),3/9/04
12:00:00 AM,152848,6.1.97.82
File7=@dx8vb.dll,$(WinSysPath),$(DLLSelfRegister),$(Shared),5/30/03 8:00:02
AM,1189888,5.3.1.902
File8=@quartz.dll,$(WinSysPath),$(DLLSelfRegister),$(Shared),6/2/09 6:23:28
PM,1225728,6.5.1.911
File9=@ftd2xx.dll,$(WinSysPath),,$(Shared),6/27/07 7:10:44 AM,202048,3.1.12.1
File10=@digiselect.exe,$(AppPath),,,12/30/09 9:29:24 AM,409600,1.4.0.5
; The following lines may be deleted in order to obtain extra
; space for customizing
Ralph
> Ralph I really appreciate ou help on this. I looked in the Setup.1st
> file and there is no reference t o this DLL. See below
>
> [Bootstrap]
> SetupTitle=Install
> SetupText=Copying Files, please stand by.
> CabFile=DigiSelect.CAB
> Spawn=Setup1.exe
> Uninstal=st6unst.exe
> TmpDir=msftqws.pdw
> Cabs=1
>
> [Bootstrap Files]
> File1=@VB6STKIT.DLL,$(WinSysPathSysFile),,,7/15/00 12:00:00
> AM,101888,6.0.84.50
Delete these lines to remove these files:
> File2=@COMCAT.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,6/1/99
> 12:00:00 AM,22288,4.71.1460.1
> File3=@STDOLE2.TLB,$(WinSysPathSysFile),$(TLBRegister),,6/3/99
> 12:00:00 AM,17920,2.40.4275.1
> File4=@ASYCFILT.DLL,$(WinSysPathSysFile),,,3/8/99 12:00:00
> AM,147728,2.40.4275.1
> File5=@OLEPRO32.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,3/8/99
> 12:00:00 AM,164112,5.0.4275.1
> File6=@OLEAUT32.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,4/12/00
> 12:00:00 AM,598288,2.40.4275.1
> File7=@MSVBVM60.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,2/23/04
> 12:00:00 AM,1386496,6.0.97.82
>
Leave the rest as is.
> [IconGroups]
> ...
...
-ralph
Rattman
Visual Basic 6.0 Setup Toolkit: Setup1.exe - entry Point not found
The procedure Entry Point memcpy_s could not be located in the Dynamic Link
Library msvcrt.dll
C. Kevin Provance
drive search for that file and post the results.
--
2025
If you do not believe in time travel,
your beliefs are about to be tempered.
http://www.facebook.com/group.php?gid=43606237254
"Rattman" <Rat...@discussions.microsoft.com> wrote in message
news:8D802C68-A334-4769...@microsoft.com...
Ralph
> "Rattman" <Rat...@discussions.microsoft.com> wrote in message
> news:8D802C68-A334-4769...@microsoft.com...
>> Great try but Still got the error. Here is the exact error I get
>>
>> Visual Basic 6.0 Setup Toolkit: Setup1.exe - entry Point not found
>> The procedure Entry Point memcpy_s could not be located in the
>> Dynamic Link Library msvcrt.dll
C. Kevin Provance wrote:
> Sounds like you have a mismatched MSVCRT.DLL in your SYS folder. Do
> a hard drive search for that file and post the results.
>
The OP is compiling and packaging on Vista and attempting to distribute to
Win2k and XP. Thus, that is exactly what is going on, however, a search 'n
compare is not going to help, the OP already knows the msvcrt.dll on Vista
is "different".
The most common reason for "setup" failures, is including newer 'system'
components (runtime and OLE). Going the other way is not a problem because,
while you shouldnt include these components, 'older' components are
generally ignored and thus including them has little effect. So I thought
removing msvcrt.dll would fix the problem. However, as the OP has removed
the component and has now posted the exact error it appears the problem is
Setup1 itself is getting compiled against one version and subsquently can't
run with another.
The OP obviously can't replace the Vista version with a "lower" one - more
things would likely break on Vista if he did. One might build a kind of Rube
Goldberg solution where Setup1 compiles are done against a different
version. But this shouldn't be necessary.
I haven't seen this problem myself, but then I haven't done much going from
Vista down. [Everyone I know that still supports VB, builds on Win2k/XP
boxes.] I did a quick little test compiling and packaging a "Hello World"
app on Vista - and didn't have any problems running it on a Win2k box.
This and the fact that there hasn't been a universal cry of alarm that
programs compiled on Vista don't run on lower O/Ss, afterall the C runtime
is used by just about every language out there, leads me to believe that
something else is going on.
For the OP:
Is there anything particularly unique to your VB environment, or how and
where you are building, on Vista compared to a Win2k or XP configuration?
Compile a test app in your Vista environment and then xcopy it to Win2k/XP
and see if it runs.
Use a JIT debugger (Dr. Watson) or WinDbg to peek at the stack. ie, the
final straw might be in msvcrt but the cause could be earlier.
-ralph
Ralph
That was just a long-winded way to say - if msvcrt.dll is no longer included
in the setup package, I doubt it is the real problem. <g>
-ralph
mayayana
> >> Visual Basic 6.0 Setup Toolkit: Setup1.exe - entry Point not found
> >> The procedure Entry Point memcpy_s could not be located in the
> >> Dynamic Link Library msvcrt.dll
>
> it appears the problem is
> Setup1 itself is getting compiled against one
> version and subsquently can't
> run with another.
Setup1 doesn't normally get compiled and none
of the setup files needs msvcrt.dll. If they did it
would have had to have been part of setup from
the start.
The VB distributable version of msvcrt.dll, 6.00.8397,
does not have a function memcyp_s. It does have
memcpy. (Isn't it unlikely that *anything* has a function
named with that sort of syntax?)
The "setup toolkit" mentioned in the error
message is actually vb6stkit.dll. It's used for making
links, CAB extraction, setup1 logging, and registration.
It's got several dependencies, but not msvcrt.dll. How
could any PDW file or system file depend on the VC6
runtime?
Looking at vb6stkit.dll in Depends shows that it
accesses shlwapi.dll via shell32.dll, and also seems
to use comctl32.dll. Maybe there's some sort of Shell
bug or broken compatibility there somewhere in Vista?
I still don't see how any of those would be calling the
VC6 runtime, though.
In any case, the problem can't be setup1.exe itself.
I use my own custom version of that for installs. It's
just a normal VB program, with no calls to msvcrt.dll.
It sounds to me like vb6stkit is getting an error that's
coming "up the line" from something that's messed up
on a specific Vista PC.
Paul Clement
� I am upgrading to Vista but still support some VB6 application. If I Package
I know longer use the PDW because of all the gotchas. Try Inno Setup instead or a more up to date
installer:
http://www.jrsoftware.org/isinfo.php
Paul
~~~~
Microsoft MVP (Visual Basic)
Ralph
>>>> Visual Basic 6.0 Setup Toolkit: Setup1.exe - entry Point not found
>>>> The procedure Entry Point memcpy_s could not be located in the
>>>> Dynamic Link Library msvcrt.dll
>>
>
>> it appears the problem is
>> Setup1 itself is getting compiled against one
>> version and subsquently can't
>> run with another.
>
> Setup1 doesn't normally get compiled and none
> of the setup files needs msvcrt.dll. If they did it
> would have had to have been part of setup from
> the start.
>
Setup1 can be compiled. I compile my own all the time. Which tended to
distract me - My reply was pretty much talking out loud.
Practically every component or program compiled for windows uses the MS
CRTs.
"C Run-Time Libraries (CRT)"
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
> The VB distributable version of msvcrt.dll, 6.00.8397,
> does not have a function memcyp_s. It does have
> memcpy. (Isn't it unlikely that *anything* has a function
> named with that sort of syntax?)
>
Functions with an added wart are the latest 'secure' versions of the
published WinAPI functions. Practically all the 'string' functions have a
secure version in the CRTs. They are seldom used 'directely' but mostly by
'system' components, or redirection with compiler options.
Distributing a crt has been a no-no since Win98.
> The "setup toolkit" mentioned in the error
> message is actually vb6stkit.dll. It's used for making
> links, CAB extraction, setup1 logging, and registration.
> It's got several dependencies, but not msvcrt.dll. How
> could any PDW file or system file depend on the VC6
> runtime?
>
The "vc" part of the name may be confusing, but all the crts since the now
extinct libc's have been labelled "msvc" or "Microsoft Visual C" runtimes.
They could have just as easily been called "Microsoft Windows C" ("mswinc")
but they aren't. But by any other name they are the same - c runtime
libraries to provide base services. Every Windows and VB program/component
is compiled against a crt. (Well, not really. There are alternative
libraries out there, but damn rare. Few vendors care to re-invent the wheel
any more.)
> Looking at vb6stkit.dll in Depends shows that it
> accesses shlwapi.dll via shell32.dll, and also seems
> to use comctl32.dll. Maybe there's some sort of Shell
> bug or broken compatibility there somewhere in Vista?
> I still don't see how any of those would be calling the
> VC6 runtime, though.
>
Everyone of them are compiled against a crt. But I believe you are on the
right track. Difficult to see how "msvcrt" itself is at fault.
> In any case, the problem can't be setup1.exe itself.
> I use my own custom version of that for installs. It's
> just a normal VB program, with no calls to msvcrt.dll.
> It sounds to me like vb6stkit is getting an error that's
> coming "up the line" from something that's messed up
> on a specific Vista PC.
If you compiled it - it is using a 'msvcrt' of some kind.
But again, I agree - the real error or problem is most likely coming from
somewhere else.
-ralph
mayayana
> > I use my own custom version of that for installs. It's
> > just a normal VB program, with no calls to msvcrt.dll.
> > It sounds to me like vb6stkit is getting an error that's
> > coming "up the line" from something that's messed up
> > on a specific Vista PC.
>
> If you compiled it - it is using a 'msvcrt' of some kind.
>
You may be right that it's using a crt of some kind, but
I don't think that's the same thing. This is ms *V* crt.
The VS C runtime.
It's my understanding that the VS6 C++ runtime is msvcrt
and later versions have similar names. My software has
no dependency on msvcrt. Neither does setup1. Win98
1st edition came with msvcrt.dll v. 5, which I assume
was the VC5 runtime. Win95 did not have msvcrt.dll.
Circa 1999, msvcrt.dll had to be shipped with software
that used VC (scrrun.dll comes to mind, which I'm
guessing was written in VC6.) Under the file properties ->
Product Name it says "Microsoft Visual C++".
Rattman
advice was from Paul Clement. I tried inno and it works great - thanks
Karl E. Peterson
Rattman laid this down on his screen :
> Hey I want to thank everyone for this great discussion. I guess the best
> advice was from Paul Clement. I tried inno and it works great - thanks
Yeah, anytime an MVP tells you to use the non-MSFT solution, it's
definitely worth a shot. ;-)
--
.NET: It's About Trust!
http://vfred.mvps.org
mayayana
> advice was from Paul Clement. I tried inno and it works great - thanks
It's good that Inno's working but unfortunate that
the problem was never resolved, in case it comes
up again.
. It seems very mysterious. I could see the added
OCXs causing problems, but the PDW files you used
seem to be pre-Vista. So it's hard to see how a
pre-Vista PDW setup could be looking to call post-Vista
functions.
Karl E. Peterson
> advice was from Paul Clement. I tried inno and it works great - thanks
Yeah, anytime an MVP tells you to use the non-MSFT solution, it's
Rattman
steps.
C. Kevin Provance
kicking back that message on *his* machine, which tells me he may have a
mismatched version locally. My bad.
--
2025
If you do not believe in time travel,
your beliefs are about to be tempered.
http://www.facebook.com/group.php?gid=43606237254
"Ralph" <nt_cons...@yahoo.com> wrote in message
news:edlOTb4k...@TK2MSFTNGP02.phx.gbl...
C. Kevin Provance
|I am still willing to look for a MS solution if anyone has any ideas for
next
| steps.
That would be MSI. You don't want to go there. Trust me on that.
![Tony Toews [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVFNFhAO8kxGtutFBSPYzx5Lbrrty7WRKPHNhjuWtTEHvsoQdk=s40-c)
Tony Toews [MVP]
>> Hey I want to thank everyone for this great discussion. I guess the best
>> advice was from Paul Clement. I tried inno and it works great - thanks
>
>Yeah, anytime an MVP tells you to use the non-MSFT solution, it's
>definitely worth a shot. ;-)
<guffaw>
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
C. Kevin Provance
news:jrdtk5l59dk78p6af...@4ax.com...
| Karl E. Peterson <ka...@exmvps.org> wrote:
|
| >> Hey I want to thank everyone for this great discussion. I guess the
best
| >> advice was from Paul Clement. I tried inno and it works great - thanks
| >
| >Yeah, anytime an MVP tells you to use the non-MSFT solution, it's
| >definitely worth a shot. ;-)
|
| <guffaw>
|
Karl probably should have been more specific.
Anytime an MVP who evenaglises .Nxt tells you...
Paul Clement
� Rattman laid this down on his screen :
� > Hey I want to thank everyone for this great discussion. I guess the best
� > advice was from Paul Clement. I tried inno and it works great - thanks
�
� Yeah, anytime an MVP tells you to use the non-MSFT solution, it's
� definitely worth a shot. ;-)
LOL! So I'm not such a .NET evangelist after all. ;-)
Karl E. Peterson
Paul Clement expressed precisely :
Heh, it just seems anti-VB, period, given this latest plot twist. ;-)
Karl E. Peterson
Heh, it just seems anti-VB, period, given this latest plot twist. ;-)