I have written a program in VB6. When I compile it and send it to my friend, he says it is not working. He (like me) has Windows Me.
Why my programs are not working there? Should he install something or what?
Your friend will need the VB6 runtime files to run any VB6 programs. You can find them on Microsoft's site.
You should be able to generate an installer project. There are a number of dependencies for the VB6 runtime (http://www.microsoft.com/downloads/details.aspx?FamilyID=bf9a24f9-b5c5-48f4-8edd-cdf2d29a79d5)
He should install Microsoft Visual Basic run-time files that all applications created with Visual Basic 6.0 need in order to run.
You can get it from Microsoft's Download Center.
He probably needs the VB runtimes.
But you should look into creating a proper msi installer package for you project.
There is a free one from MS to use with VB6 called the Visual Studio Installer 1.1.
Not much information to go on, if you have more, that would be helpful. I'm just guessing, but, your friend's computer may not have the VB6 runtime installed. If he's willing, he should try installing it and see if that fixes the problem.
Related
I'm following the instructions in
https://msdn.microsoft.com/en-us/library/office/hh361572(v=office.14).aspx but after installing the runtime, the voice, and the SDK, I couldn't figure out how to reference the Microsoft.Speech.Synthesis namespace on my Windows 7-64 bit machine with Visual Studio 2013 community edition update 4.
What's the real purpose of the SDK and how do I configure.
The installers are 64bit versions, and the voice synthesis works
PS: If you really think that my question is unappropriate here, please just put it in the comments or answers and suggest me where should I put it. I'll b glad move it far from your judgement in less than 10 hours
I believe you need to use C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Speech.dll (for whichever .NET version is appropriate). It is a wrapper around Microsoft.Speech.dll. I was having problems selecting the voice, but it turned out to be just build configuration.
I wrote a large and complex C application on Windows XP. Now I am recompiling on a 64bit Windows 7 machine. When I run certain executables I get this error:
The program cannot start because MSVCP71.dll is missing from your computer. Try reinstalling the program to fix the problem.
Apparently this is a .dll that used to come with windows but now does not (see especially this MSDN forum and this previous stack overflow question.)
Supposedly I should generate this DLL from Microsoft Visual C++ and "extract the DLLs from the merge modules." However, I am using gcc, mingw and make and I would prefer to avoid going to Visual Studio.
There are lots of copies of this dll available to download from unverified sources on the internet, but none directly downloadable from Microsoft. What should I do? Do I need to install Microsoft Visual C++? Is there any way to do this with gcc and mingw?
Update: #Sheng Jiang 蒋晟's hint was crucial. What I hadn't realized was that my dependency on MSVCP71.dll only arises out of linking to a third party DLL. I was able to identify the third party DLL and find a copy of MSVCP71.dll running on another system with that DLL in place. Now I can include the MSVCP711.dll along with the third party DLL and everything runs smoothly.
There is no downloadable redistributable released for this file. Only merge modules are provided on the CDs. Programmers are expected to embed those merge modules into their setup programs, or extract the files into their program's install folder. This file is not intended for System32 as that is a violation of Windows Logo requirement.
Since you are not using the Visual C++ tool chain, the MS-STL dependency comes with a third-party component whose author did not provide a proper setup program. Although you can get the dll from other products, however, you need a product that explicitly grant you the redistribute rights to be able to redistribute the file to your customers. Such redistribute rights come with Visual C++ 2003 and probably InstallShield X and other install package authoring software.
For evaluate proposes you can obtain the file for the component from other products that have a dependency on the file, such as SQL Server 2005, the .Net 1.1 runtime or its SDK, Crystal Report 10 etc. Beware of version mismatch. If the component requires SP1 or later edition of MSVCP71.dll, it may not work with the RTM edition.
I dont have a link from Microsoft but you can download it from here (link fixed and now points to correct file).
Now move it to C:/Windows/SysWOW64 (64 Bit) or C:/Windows/System32 (32 Bit)
Here's another download available: http://www.addictivetips.com/windows-tips/fix-msvcp71-dll-and-msvcr71-dll-missing-error-in-windows-7/
Not sure if this will work, but maybe a reinstallation or update of MS VC++ Runtime solves that (Microsoft Download Center ).
MS Office, Oracle client, and sql developer all have msvcp71.dll. I found a copy already on my PC. No need to download from untrusted website.
It works if we copy the file msvcp71.dll from C:\ORACLE\product\10.2.0\Client_4\oui\lib\win32\msvcp71.dll and past the file in the folder C:\winnt\system32.
I am using Visual Studio 2010 setup project
I don't think you are allowed to redistribute PowerShell. And at any rate, it is built in to Windows 7 and Server 2008 R2. All the other platforms have separate installers as well. I think it would be best to just notify your customers that they need PowerShell 2.0.
I had a similar problem in the StudioShell installer - wanted to make sure PoSh 2.0 is installed. I did a cursory check for the executable with a minimum version number, and added a launch condition that notified the user of the missing prerequisite and offered to open a web page to the PowerShell download. Seemed like the most legally helpful approach.
There is a way, albiet requiring you to build some MSI thing manually that will get it from MS and install it for you. I know the exchange install used that technique. You can also get a license/permission from MS to redistribute the official installers.
I'm using msscript.ocx in my application which is an activex scripting host for windows.
Although I want to be able to use the same for XP embedded(XPe) which's highly customizable.
1.I want to know whether on XPe, msscript.ocx can be optionally installed or not?
2.Where does it get installed from, IE?
3.Or is it a windows core component which gets installed during the XPe setup?(I know one can unregister it, but can it be an optional installation)
Answering any or all of these questions will be of great help to me.
Thanks in advance.
Sam.
Microsoft's documentation of the MSScript.ocx library is somewhat contradictory on this issue. The short answer is, starting with Windows 2000, the MSScript.ocx library became part of the Windows OS. Subsequent service packs for Windows 2000, XP, and 2003 included bug fixes (1,2,3) for this library. Since that time, the library has remained part of the 32bit portion of Windows and is still included with Windows 7/2008 R2. Even 64bit versions of Windows still include msscript.ocx with WOW64 in C:\Windows\SysWOW64.
For a little history of this library's distribution keep reading.
Msscript.ocx was originally included on the Visual Studio 6 CD as a "optional" library - optional meaning it had to be manually installed. While the library was part of Visual Studio, it was migrated to being part of the Windows OS starting with Windows 2000.
This is where the confusion comes into play. Since msscript.ocx is considered to be a component of both VS6 and Windows 2000, updates were distributed in service packs for both. Even after the last service pack for VS6 was released, additional bug fixes needed to be distributed for older OS's, so a separate download was created specifically targeting Windows 95, 98 and NT4.
This download is targeted for older OS's for the simple fact that it had become a part of the OS in "modern" versions of Windows. If you are using Windows 2000 or greater, the download is unnecessary and - in my experience - can cause compatibility problems.
I think it is not shipped with Windows XP(not a 100% sure)...
But the best choice is to ship it with your installer(even if it was shipped, it can be removed). About the installing - you can put it where you want (in the program folder in Program Files is ok), the important thing is to register it.
The best choice for making installers - Wix
EDIT: reference
The Script control ships with Visual
Basic 6.0; however, Visual Basic 6.0
setup does not install the Script
Control for you. The control is
located in the CD directory
Common\Tools\VB\Script. To install the
script control, try the following
steps:
I think this answers your question....
For those having issues getting MSSCRIPT.OCX to work do the following:
Go to References in Project settings:
Microsoft Script Control 1.0
Microsoft Scripting Runtime
Microsoft Scriptlet Library
Check all those on.
you'llneed to change your development environment to produce a 32 bit version of your appliation, which for most apps won't matter.
For this goto Project,
then select Properties,
select Compile,
Target CPU: x86
In your code, and i'm using visual studio 2019,
' by using the references above the ScriptControl
' should become available for inclusion into your source c
Dim ms As ScriptControl = New ScriptControl
ms.Language = "JavaScript"
ms.Reset()
Try
ms.ExecuteStatement(RichTextBox1.Text)
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
How can I create a setup file in visual basic 6 after completion of my programming work?
Front End language is Visual Basic 6,
Backend : MS Access 2003 and
Report Tools : Crystal Report 8.5. Operating System Windows XP.
You need to be a little clearer about some of this.
"Front end/back end" is really terminology and a thought pattern from the MS Access world. It doesn't really apply to VB6 development in any meaningful way unless you're doing something really odd like automating instances of MS Access.
That's about the only place where any "MS Access runtime" comes in as well. If you're actually using Access Reporting you might be doing this though - which seems odd but anything is possible.
See Deploying Complex Microsoft Office Access Runtime-Based Solutions.
Much more likely what you are trying to say is that you have a VB6 program that is using a Jet MDB as an embedded database, and using Crystal Reports 8.5 for reporting.
There should be no issue about any "runtime" for Jet on Windows XP, since Jet 4.0 is shipped as part of the OS even as far back as XP RTM (gold). It is also extremely unlikely that XP will have an MDAC release any older than 2.7 (see Microsoft Data Access Components (MDAC) release history).
So this leaves you looking for a way to package your VB6 program, any immediate dependencies such as possibly the VB6 runtime components, and the Crystal Reports 8.5 runtime components. You may also have INI files, etc. to bundle in there.
A long, long time ago (1998?) the PDWizard was replaced for most purposes by Visual Studio 6.0 Installer 1.0, and shortly after VSI 1.1 was released (1999?) which made up for a number of ills. This is a pretty basic tool for authoring Windows Installer packages, but it should meet your needs.
Along with this you'll want the recent merge modules for your dependencies: Merge Modules for Service Pack 6 for Visual Basic 6.0 and Visual C++ 6.0.
Then of course you need a merge module for Crystal Reports 8.5, and for this we have to turn to the community because BO didn't start releasing them until CR9. One place to look for this is InstallSite: Seagate Crystal Reports 8. Your real problem is that CR8.5 is ancient.
If this doesn't work out for you, you can always hope that CR8.5 Dev installed on your machine with a "good enough" set of .DEP files (which tell setup authoring tools what subdependencies each dependency has, among other things). This may still let you use VSI 1.1 to succesfully package your application with CR8.5.
You might also look at for-pay packaging tools as already suggested. If desperate enough you might look at some legacy installer technologies too, just in case their communities have addressed your issues.
If I misunderstood and you really do use your VB6 program to automate an instance of the "MS Access 2003 Runtime" you'll probably have to build some hybrid package.
But normal VB programs do not use Access or Access Runtimes to open and work with Jet databases.
You can search google for package and deployment vb6
and you will find millions of links showing in steps how to do that.
The Package & Deployment Wizard is quite primitive and not well-suited to distributing things like the MS Access runtime and Crystal Reports. You'd be better off using one of the more powerful commercial products like InstallShield or Setup Factory. However, these can be pricey (especially InstallShield).
There are also free products like Inno Setup and Nullsoft, but these may not be as easy to use or may lack some important features.
Bob's suggestion of using Visual Studio Installer 1.1 for a Visual Basic 6 application is sound but the Microsoft link he has given for the download does not work. I guess MS thinks nobody needs VB6 anymore. After searching a little I found a 2008 snapshot of MSDN page in web.archive.org complete with setup files:
http://web.archive.org/web/20080513102621/http://msdn.microsoft.com/en-us/vstudio/aa718352.aspx
Good suggestions above.
While it might seem unlikely that VB6 app could possibly be in use, there are those of us in the public sector that keep VB6-like apps and even Access apps alive because public dollars are not in a hurry to replace app that still work. A frequent mantra heard in many places is that you leave it alone if it is not broken. Broken enough that is--otherwise baling wire works just fine as long as VB/VBA developers can still found.