Open .vbp,.frm files in VB 6.0 - vb6

I've some .vbp,.frm files and i want to open them with VB 6.0 but i am using Windows 8.1 is there any version of Visual Basic that is compatible with Windows 8.1.Please do suggest me.Thanks in Advance.

Whats not working? Microsoft is supporting run time files for at least a few more years works up to 10 and maybe will be for a few more versions, install vb 6 and it should have no problem running unless the systems messed up.

As indicated by others, the VB6 development tools can be installed and work (with limitations) on all versions of Windows Longhorn (including Windows Vista, Windows 7, Windows 8, Windows 8.1, on up through Windows 10). Most of the limitations are project types rendered useless when Microsoft ripped away the infrastructure for them as they mutated IE and IIS over the years with little regard.
So without a license for VB6 or preferably VS6 there isn't much you can do with these files. If the projects are fairly simple you might get somewhere trying to make the completely unsupported VB5 work if you have a license for that, or if the project files are for even simpler applications VB5CCE might be of some limited use if you have that.
But in general there are no other products that can use these files to any useful extent. So as already covered many times in other questions here and elsewhere you need VB6/VS6 and the only remaining source is an MSDN Subscription or used or remaindered copies that may be for sale here and there.

Related

Will VS2008 compile binaries compatible with Windows 7

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

where does msscript.ocx gets installed from

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?

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.

Windows 7, A Good Platform for Developers?

I know of a similar question that got closed. But this one is from a developer's point of view.
I must say my experience in terms of software development (not including testing) has been more painful on Vista than on XP. I'm wondering if you guys have had similar experience; and if so, does Windows 7 eases the pain?
I'm using Vista on my lappy and XP at work, both for development purpose, .NET (all sorts), some php, MSSQL and MySQL.
Am setting this as a wiki.
I can honestly say that Windows 7 is what Vista always should have been, and then some. If you're mainly a Linux platform developer, then run that. If you're mainly a Windows platform developer, Windows 7 is the place to be.
In either case you can run the other OS in a VM.
Windows 7 is no better or worse than XP or Vista for development, at least as far I can tell. And yes, Windows 7 is like gas # 2.85/gal, not the 3.65/gal Vista charged -- that is, it seems better because it, well, is -- even if it still isn't great.
However, I find it still "lacking" by default I end up installing cygwin/mingw/rxvt and other tools to make (windows in general) more accommodating to my needs and expectations.
(Of course any particular dev. experience will be tied with what is -- or isn't -- supported across with windows versions and any small changes which have been introduced.)
Here's one data point: most of my fellow developers in MS seem to be running 7 these days (every now and then, you get a question on the team mailing list, "anyone got a Vista box to repro this?" ~). A large number of people ran it as a main development desktop in RC and even beta timeframe, too.
Most of Vista development hurdles, as I understand, are with UAC. 7 throws a few less prompts at you, but for particular usage scenarios when doing development, it probably won't be any different. Of course, you can always turn it off, too, but you could in Vista just as well.
Some nice parts are there if you work with RDP regularly - which you probably do if you have several boxes and don't like KVMs, and/or run VMs on Hyper-V or Virtual PC. When doing RDP 7 to 7, you can get full Aero Glass experience, with all the effects enabled. Apart from the eyecandy, it can be helpful when testing related functionality.
What else... PowerShell 2.0 final out of the box. I find it a very handy development tool, just as shell is on Unix. You can get PSh 2.0 RC for XP or Vista now, but not final (yet).
I think Vista and Win7 are great development environments. After all, it's what a large proportion of your end-users will be using, so you'll be able to see how your app interacts with the newer features of the platform, whilst almost everything else about your app will look and feel the same way as it did on XP.
Take UAC for example. Yes, it can be annoying (much improved in Win7 though), but used properly it works well. It separates administrative privileges from regular user operations. If you don't actively develop in Vista or Win7 then the temptation is to make the problem go away by telling people to turn off UAC or run as administrator all the time. If you develop on that platform then it forces you to come to a better solution.
Used Vista for 3 years, full-time C++ development with predominantly XP customers. No problems.
Have been running W7 RC 64bit for 2 months, same machine, same customers. No problems.
Way better than XP, but that's mainly because I assimilate to new features very quickly and don't resist change.
I find the following things noteworthy to Windows 7 being a lot better to develop on than XP:
A lot more drivers - So you happily plug your headset for meetings, that new video board with 4 monitor support, etc. Such things can be a pain in XP at times.
A lot more support to virtualization - Both of applications (Terminal Services) and of the OS. (Hyper-V)
Improved support for with multiple monitors and new UI to help at that - Aerosnap, gestures, etc.
A log of dev stuff out of the box,
.net runtime, powershell. This all
stuff that you can download and
install on XP, but it is always a
hassle when you have to reinstall
the machine.
Win 7 is a no brainer over XP, definitely something to have if you have the money and the hardware to upgrade, or if you a getting a new computer.
I don't think the question can be answered with "Yes" or "No". The best answer is "It depends".
If Windows 7 solves some problems you had with other operating systems while developing (or at least does not introduce new ones) then it is a good platform for you. On the other side, if you have problems with it then stick to what you know is working.
From my experience: Win 7 is good for me. There are ~3 months since installed it and is working well - is not interfering in any bad way with my development activities. Actually is not the final version of W7, is the RTM one.
It's pretty much same as Vista. The only problem I've ran into is the annoying UAC control which renders shell extensions (like TortoiseSVN) useless, unless you change the ownership of the folder. But I guess it's the same in Vista.
I'm running MySQL, IIS, apache, TortoiseSVN and Visual Studio on Windows 7 and so far everything is working perfectly.
I've personally switched to Windows Server 2008 R2 Standard as a development machine and I find it much faster than Windows 7 Ultimate x64. Try it and you will see the difference. It can be tweaked to be extremely lightweight and is blazingly fast.
But because the question was about Windows 7, I've used the RTM Ultimate x64 as a development machine since August and didn't find much of a difference compared to Vista Ultimate x32 I've used before. Surely it looks more polished but as I'm primarily looking for speed it didn't made much of a difference.
I have two development machines - one a laptop and one a desktop - both running Windows 7. The desktop is considerable faster, not just in launching VS 2008, but the lag I was seeing with ReSharper on some projects is completely gone.
On my laptop, Vista came installed and I have been running Windows 7 since the last beta. With Vista, VS felt sluggish. With W7, not only does it feel faster, I am running SQL Server Standard, a local SMTP Server (SmarterMail), hosting a Lucene.NET index, and running Velocity; all for a project that I am currently working on. And it is just as usable as it was when I just has VS on Vista on the same machine. I never expected I would be able to have all of that running on a laptop and still be usable, so my productivity on the train for my commute has skyrocketed.
One of my favorite features of W7 is the preview pane in Windows Explorer. With it on, I can select a C# file and look at the source without having to open it in VS or a text editor. Really handy for when I need to look at something in another project. I seriously do not have a single complaint about this OS - something I have not been able to say in a long, long time.
How does Visual Studio 2008 run on Windows 7? When I ran the Windows 7 Upgrade Advisor it was (ironically) the only software that was flagged as being potentially problematic.
My box:
Windows 7 Professional, VS2008, VS2010, Netbeans with PHP addon, MSSQl, MySQL, PHP, Apache, IIS
Everything works fine
A good platform for developers is Linux, but it depends of your language, .Net the best is Windows, Objective-C is Mac and C is Linux...

Has anyone ran into any issues developing on Windows 7?

I want to trial Windows 7 but wondered if anyone who has done so already ran into any issues specifically related to development?
i.e. problems with VS2008, SQL Management Studio and SQL Server, MySQL, PHP etc. etc.
Examples from XP -> Vista: in Vista there was a sudden loss of an SMTP server. And there were initially (if I remember correctly) issues with VS2005 with I seem to remember a patch coming out later to remedy.
EDIT: or on the contrary any big advantages or benefits to developing on Windows 7!
I been using windows 7 for a while now.
I been using VS2008, netbeans, tomcat, sql manager studio, mysql etc...
And i actually find it more stable and faster then windows vista.
There aren't many advantages to developing on Windows 7 before it's released. Most development features are a function of the IDE, not the OS. So, you might want to consider instead if you should be developing on Visual Studio 2010 instead of VS2008. Instead, you're more likely to have compatibility issues, although for the most part, Windows 7 is much more compatible with existing software than Vista was when it was in beta.
There could be one advantage to developing for Windows 7 before it's released -- you have a head start in taking advantage of features that competitors haven't yet, giving you an advantage in the market. That's the theory at least. That assumes you're going to develop something that uses a feature only available in Windows 7. That assumes you wouldn't be better off with the larger number of sales you'd get by developing something that works on existing platforms.
The only issue I've encountered so far involves compiling older vanilla C programs with Visual C++. You're usually presented with an error like so:
mt.exe : general error c101008d:
Failed to write the updated manifest
to the resource of file
".\Release\SomeProgram.exe". The
binary is not a valid Windows image.
You have to add an empty resource file to the solution.
More on the issue here.
I've never gotten any of the new audio stack examples working; thus this question. API works, documentation is... a bit lacking at the moment; sure to be fixed by RTM.
Other than that, Windows 7 has been faster than and just as stable as Vista (2 crashes from RTM, 0 crashes after SP1) was for me. Truly, you should be developing on Vista and testing on Windows 7 RC as a general practice with respect to pre-release operating systems; but I think we'll get away with it just fine in this particular case.
My advice would be to not develop on Windows 7. Note that I don't mean you shouldn't target it as a platform, just that you should be doing your development on a stable platform.
I personally won't trust a new release of Windows (or Linux for that matter) until it's been in the wild as a proper product (not release candidate) for many months. For Windows, I tend to wait until the first real service pack plus a month for all the nigglies to be fixed.
For Linux, I'm still using Ubuntu 8.04 LTS, not 8.1, and certainly not the 9 alphas.
Test machines are another matter, you should always have one at the "latest and greatest" level for testing, but I consider the development machine of prime importance, needing a stable platform.
No problems from my end yet, been working on a c# app with visual studio 2008 x64, and php web apps with dreamweaver cs3 and netbeans.
Windows7 seems to be just vista with more bells and wistles and a bit more responsive, not to sure if to much really change "under the hood" so to speak. But I have nothing to back that statement up with...
I've been using Win7 for a couple of months now and never had a problem. I went straight from XP to 7 and the only problems I faced were related to configuring SourceGear Vault to work with IIS7...other than that,it's been all good.
I use VS 2005, VS 2008, SQL Server 2005, Infragistics NetAdvantage, and a couple of third party components.
Although I haven't seen any advantages for the development side of the applications, I'd recommend you to upgrade to Win7 only for the better feel of a complete OS. I mean XP was good, but I really dig Win7.

Resources