Short version:
When I moved to Win7, I manually removed the MDAC 2.7 lines from my .ISM module, built it, and installed my software. It seems to work. Can I trust it?
Longer version:
We have just gone from XP to Windows 7. The software we deliver is C# (.NET 4 framework), targeting XP and Windows 7. It contains a few older COM modules, one of which is written in VB6. (Yes, I would love to rewrite this in a modern technology, but that's not an option at this point.)
I use InstallShield 2010 to build the installer for this package. Building this installer on XP worked with no problems. When I try on Windows 7, it wants MDAC 2.7 as a prerequisite merge module. Microsoft doesn't allow you to download 2.7 anymore, and I'm not going to get it from "Sharewarez R'us" sites.
The error InstallShield gave me when it couldn't find the merge module was: File not found. An error occured merging Module 'MDAC27ENU...'
From what I've read on the web, Windows 7 has the latest-greatest MDAC (now renamed WDAC) already installed. On a whim, I manually deleted the MDAC dependencies from the .ISM, built and installed, and my software seemed to run just fine.
What I think is happening is Win7 is noticing that something in VB6 is using MDAC and the OS is supplying the latest-greatest and it just works. I no longer need the merge module because Windows 7 has WDAC built in. (Can it really be that simple?)
My main question is: can I trust it?
My secondary question is: What about XP deployments? They will still need MDAC 2.7... Does that indicate I can't build on Windows 7 to target XP if I require MDAC 2.7? Please point me in the right direction. Thanks.
You need a comprehensive review (dependency analysis) of your installer. The VB6 runtime and MDAC/WDAC components are all built into windows these days. This is also the case with Windows XP and the latest service pack.
Either your ISM is referencing the MDAC merge module or it's referencing another merge module that has a dependency on the MDAC merge module. Hence why I suggest a complete review.
Without looking at your application I can't give you a 100% answer but odds are that if you implement a setup condition (launch condition) to check for XP latest service pack or newer that you will likely work without installing a bunch of stuff you don't need to be installing.
Related
On our PC (under Windows XP there is MiKTeX, and it have been working well for many years. However, several month ago, after installing the latest version (setup from 09/16/2017), dvipdfmx stopped working reporting something like 'it is not win32 application'. It has been appeared that the problem is arisen by mgs.exe (ghostscript for MiKTeX). The first thought was that a 64-bit version of mgs.exe was mistakenly included into 32-bit MiKteX. However, it is appeared not the bug: MiKTeX team says that it is worked under 32-bit Windows 7.
I do know that officially MiKTeX now requires Windows 7 or higher (so, XP is not supported). However. it was perfectly well until the latest update, and even now latex.exe, yap.exe and others still work. So, the question: is it possible to go the problem around within XP?
Without knowing what the actual problem is, its impossible to offer any advice. When quoting errors it is important to quote the exact error message.
"Something like 'it is not win32 application'" is not precise enough.
This is also not a Ghostscript question, because 'mgs.exe' isn't Ghostscript, its clearly a fork of some kind.
My guess is that its the fact you are using an ancient version of Windows, most likely the application is no longer compatible with such an old version, possibly because whoever built it is using a newer version of Visual Studio.
In order to build Ghostscript for Windows XP I think you need to use Visual Studio 2005 or earlier, a more recent version will create an executable that will not run on Windows XP.
The only solution to this would be to build 'mgs.exe' with an older version of Visual Studio, or try the pre-built executable 'gswin32.exe' which is available from the ghostscript.com website in the downloads section. Obviously that's not the same as mgs.exe, but I can't help you with a fork since I have no clue what's been done.
The first thing to try is running 'mgs.exe' from the command line, if that fails to work then its almost certainly because the developer who built it used too recent a version of Visual Studio.
If this is the case then no, you can't fix it within Windows XP, you need to do one of:
1) Upgrade to a newer OS
2) Downgrade your MikTeX and live with the older version until you are prepared to upgrade your OS.
3) Rebuild 'mgs.exe' yourself using an old version of Visual Studio. This could be challenging because I can't find anywhere on the MikTeX website where they make the source files available. I've been to their Github repository and I can't find anything from Ghostscript there either. I'm going to have to contact the developers, they are not using a stock version of Ghostscript, they do not appear to make their revisions available, ansd although they correctly reference Ghostscript as AGPL I cannot see anywhere in the install or their Github repository which lists Artifex as the owner or points to the Artifex website. They also don't copy the Licence or readme files (slapped wrists for them).
I was going to try using the regular Ghostscript instead of the modified version, but I don't have know anything about MikTeX so I have no way of testing whether that works. It looks to me like it probably would, since it appears that MikTeX forks Ghostscript as a process. So copying and renaming the 64-bit Windows version of Ghostscript's binaries would probably work.
As you note, the developers state themselves that they no longer support Windows XP.
I'm trying to install Visual Studio 2005 on a Windows 7 box but am repeatedly getting the same error. When I run the installer it starts to run then pops up with a message saying:
"A problem has been encountered while loading the setup components. Canceling setup."
Various suggestions has said that maybe the install is corrupted so I downloaded a fresh copy of the ISO from MSDN today, same issue. Another suggestion is that installing from the ISO may be the issue so I extracted the contents of the ISO to a folder on my HDD, same issue. I have also tried running the files as administrator and in XP compatability mode, same issue.
Searching for this issue the most common responses I've found have been about installing SP1, however I cannot get the base product to install and therefore cannot apply SP1.
Does anyone have any further suggestions as to what I can do to fix this issue and get VS2005 installed? If anyone wants any log files of any variety I am happy to supply so long as you tell me where to look as I'm not sure.
As for why I am using VS2005 and not a newer product, it is required for the ongoing support and maintenance of some older applications we manage. These cannot be easily migrated to a newer version of Visual Studio without some considerable investment of time and that would probably be longer than the time it will take to develop newer, replacement applications (which is currently in progress). Until the new applications are available though we need to maintain an environment to use.
Did you try running setup.exe in compatibility mode with Windows XP? Some discussion here on how to do this.
Another alternative since you alluded to having an MSDN subscription. Download Windows XP and install it into a VM. (If HyperV isn't already in installed with your Win7, you can add it from Control Panel->Programs&Features->Turn Windows Features on/off). Then install VS2005 from there.
I'm using Microsoft Visual Studio 2008 (VC9) to compile a project that has a .dsw file. I already have the 2010 and would prefer to use it, but it seems this dsw was built for 2008.
I'd like to compile and produce a binary that's also compatible with Windows 7. My questions:
if I compile with 2008, will the resulting binary be compatible with Windows 7? I'm not sure at which version of VS did Windows 7 support start.
or does this have nothing to do with the VS version, and is instead related to the Windows SDK? If that's the case, can I use VS2008 with a newer Windows SDK?
Can someone please clarify.
Microsoft has a great backwards compatibility "story", so pretty much anything you compile with any version of Visual Studio/Visual C++ will be compatible with Windows 7. The same may not neccessarily apply in reverse, i.e. if you use an API that's introduced in Windows 7, your application will error when you try to run it on prior versions of Windows.
There are a couple of things to consider though:
If the project was originally written to target Windows XP or earlier, it may fall foul of UAC
There are changes to directory structures (such as %systemdrive%\Documents and Settings becoming %systemdrive%\Users) that are fairly well handled by the link that Windows 7 creates in the root of `%systemdrive%, but you may fall foul of these.
VS2010 includes version 7.0 of the Windows SDK and VS2008 does not. You need Windows SDK v7.0 if you want your app to take advantage of Windows 7 features like jump lists.
Since you already have VS2010 installed, you can just change your include file / lib file paths in VS2008 to point to the Windows SDK v7.0 instead of the default one provided with VS2008. This is assuming you need that version of the SDK.
You do not need the latest Windows SDK if you do not plan to use the latest Windows 7 features like ribbons and jump lists. If you are building your app for the lowest-common-denominator OS (i.e. Windows XP), then really you should be fine using VS 2008 with default settings.
The other concern is, if your code was originally written before Windows Vista came out, it is likely that it will not work properly on Windows 7 unless it is run in Administrator mode, which is something you want to avoid. The only way to fix that is to rewrite much of your code to avoid writing to certain protected directories and avoid using certain APIs that require Administrator privileges.
Windows SDK is well backward compatible. See binary compatibility report between Windows 6.0 and Windows 7.0 on x86_64 generated by the abi-compliance-checker tool for the detailed comparison.
Reports for other Windows versions are here: https://abi-laboratory.pro/index.php?view=windows
VS6 popped off a series of errors before bombing out completely during install on Windows 7. I specifically need to get VB6 functioning on Windows 7. Anyone having any luck?
Folks on the VB6 newsgroup report they have managed to get it working on Windows 7.
There's this step-by-step guide on how to install the IDE on Windows 7 (including 64 bit).
If that doesn't work (scrapes barrel) try this old tip about persuading the install not to install the Java VM? Link is now broken so here is the tip:
Before trying to install VB6. Create a new file, name it msjava.dll and place it in your windows directory. The file can be zero length. You can then happily install without the prompt to install an old version of Microsoft's flavour of Java. Once you have installed VB6, delete the msjava.dll otherwise windows update will prompt you to update it.
Or (scrapes hole in barrel) these tips from an article about getting the IDE working on Vista?
Footnote: if developing with ADO, be aware of this.
The only way I've found that works is Windows XP mode (i.e. a virtual machine). Works fine there, but otherwise, not at all.
I found ALL the answers in a thread at vbmonster.com. As mentioned above, you CAN install Visual Studio 6 with Service Pack 6 under Windows 7 by following Derek's detailed instructions at fortypoundhead.com.
I had a problem because I needed to install Service Pack 5. I use a third party program that does not work with Service Pack 6. A really smart programmer (GuideX) came up with a great hack to get around the MDAC 2.5 error.
Win 7 64 bit service pack 5 & 6. Turn compatability off and it seems to work.
Recently I had to debug an ancient application written in Visual C++ 6.0 on Windows 8.1. Tried different solutions all of them failed, only this one worked.
This guys made a special installer that allows installing VC++6, VB6, and SP6 on Windows Vista/7/8/8.1/10 without any errors whatsoever.
Hope it would be helpful to someone.
I installed VB6 on Windows 7 Pro without having to use compatibility settings or run as administrator.
Doesn't really help you, but does show that it can work.
Several people in my office have installed Visual Studio 6 (without VC++) on Windows 7, both 32-bit and 64-bit with no problems. The one thing we have in common: we've all turned UAC down to it's lowest setting. Nothing else special required.
I am using vb6 on windows 7 32 bit system for a long time.
you will need to install your vb6 with compatibility of xp2.
Create a 0-byte file in the C:\Windows directory called msjava.dll.
Don't just install via the Autorun executable; instead browse the Visual Studio 6 CD (or folder), right-click Setup.exe and select Run As Administrator.
On any Program Compatibility Assistant warnings, click Run Program.
Step through the setup screens until you're able to choose Custom Setup, then click next.
On the setup options, install the following items and nothing else:
Microsoft Visual Basic 6.0
ActiveX
Data Access
Graphics
Click continue and the process will start, and (hopefully) eventually complete.
Skip the installations of the MSDN CD, BackOffice, VSS and SNA Server, and clear the checkbox for "Register Now". Setup should be complete.
Download the VB6 Service Pack 6 from http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=A8494EDB-2E89-4676-A16A-5C5477CB9713&displaylang=en and install.
Change the compatibility settings for Visual Basic (to get it to run a little more smoothly under Windows 7) by browsing to C:\Program Files\Microsoft Visual Studio\VB98, right-clicking the VB6.exe file, and selecting properties.
On the Compatibility tab, check the following:
Run this program in compatibility mode for Windows XP (Service Pack 3)
Disable Visual Themes
Disable Desktop Composition
Disable display scaling on high DPI settings
When you start up the IDE, you may get a notification saying that the color scheme has been changed to Windows 7 Basic, but it will be changed back to Aero once you exit. Everything should be working fine at this point!
Note: when you first run your new install vb6 run it with admin rights and with xp2 compatibility so that your exe can run on any system.
The word "supported" is used loosely in this thread, potentially leading the unwary reader to the conclusion that Microsoft supports the VB6 IDE (that is, the integrated development environment) on operating systems beyond Windows XP. This fact clearly is stated in the table that appears on the page at this link:
https://blogs.msdn.microsoft.com/nikosan/2012/04/20/support-statement-for-visual-basic-6-0-on-windows-8-updated/
Note that executables developed using VB6 are in fact compatible with Windows OS's from Windows XP through Windows 10--32/64-bit versions:
https://blogs.windows.com/buildingapps/2015/06/22/getting-ready-for-windows-10-sdks-compatibility-bridges/
Anyone using non-standard methods to coax the IDE into working on OS's that Microsoft does not support is exposing themselves/their organizations/their employers to risk and is not suitable for risk-averse organizations.
Having said that, I think the purest solution is to install Windows XP onto a virtual machine and run that VM in a modern host OS, such as Windows 10. That works just fine, and you can install directly from the VB6 Setup disc without making any pre-install/post-install customizations.
I had a Vista x64 box with a working copy of the VB6 IDE (which was supported). I upgraded the OS to Windows 7 x64 and the VB6 IDE still works fine. You could try that. I know, a huge PITA and kludgy but still, it worked for me.
I run Windows 7 Ultimate 32-bit, installed Windows Virtual PC - XP Mode, and that solved my problem isince I can run MSDEV 6.0 in the XP Window.
Not esay to install XP Mode though, the MS site is buggy.
The VB6 programming language is supported on the Windows 10 Technical Preview.
Visual Vasic 6 applications run and the VB6 IDE installs and works too.
I have the VB6 IDE running OK on Win-XP-16, Win-7-32, Win-7-64, Win-8.1-32, Win-8.1-64, win-10-32 and win-10-64 by using the instructions above which basically say, turn off UAC, run the installer AS ADMIN, and then set the VB6.exe file to run in XP-SP3 Compatibility mode.
I have had some issues with it and have had to do a bit more googling to solve these but I don't remember any more what those issues or solutions were.
I've even got the VB3 IDE running on the 32-bit versions of XP, Win-7, Win 8.1 and Win-10 - without even installing them - just copied the C:\VB folder from another computer and copied the *.LIC license files and *.VBX etc files as well.
I have successfully installed vb6 on win 7 32 bit by installing xp first then installing new win 7, (not upgrade), and do not format. then it will install vb6 without a problem
It's depending on your build version of Windows 7.
If your Win7's version is lower or is not updated, it has MANY PROBLEMS with compatibility.
But mine is newer Win7 version and has NO COMPATIBILITY TROUBLE.
I am currently using VB6 , VS6 and they still work fine!
If Properties->Compatibility->Windows XP doesn't help, fix it with UPDATING your Win7.
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