Monday, August 29, 2016

Support Statement for Visual Basic 6.0 seen on August 2016 !

This post is just in case Microsoft changes the statement ...

Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, Windows 8 and Windows 8.1, Windows Server 2012, and Windows 10

Update: August 2015

Executive Summary

The Visual Basic team is committed to “It Just Works” compatibility for Visual Basic 6.0 applications on the following supported Windows operating systems: Windows Vista, Windows Server 2008 including R2, Windows 7, Windows 8 and Windows 8.1, Windows Server 2012 including R2, and Windows 10.
The Visual Basic team’s goal is that Visual Basic 6.0 applications continue to run on supported Windows versions. As detailed in this document, the core Visual Basic 6.0 runtime will be supported for the full lifetime of supported Windows versions, which is five years of mainstream support followed by five years of extended support ( http://support.microsoft.com/gp/lifepolicy). The support bar will be limited to serious regressions and critical security issues for existing applications.

Technical Summary

Visual Basic 6.0 is made up of these key deliverables:
Visual Basic 6.0 IDE [Integrated Development Environment]
Visual Basic 6.0 Runtime -- the base libraries and execution engine used to run VB 6.0 applications
Visual Basic 6.0 Runtime Extended Files – select ActiveX control OCX files, libraries, and tools shipping with the IDE media and as an online release

The Visual Basic 6.0 IDE

The Visual Basic 6.0 IDE is no longer supported as of April 8, 2008. However, Custom Support Agreements may be available from Microsoft. Additionally, both the Windows and Visual Basic teams have tested Visual Basic 6.0 IDE on Windows Vista, Windows 7, Windows Server 2008, Windows 8  and Windows 8.1 to understand and mitigate (if appropriate) compatibility issues on 32-bit versions of Windows (see the “64-Bit Windows” section below for further information about 64-bit systems). This announcement does not change the support policy for the IDE. This announcement does not change the support policy for the IDE.

The Visual Basic 6.0 Runtime

The Visual Basic 6.0 runtime is defined as the compiled binary files originally included in the redistribution list for Visual Basic 6.0. These files were marked as distributable in the original Visual Basic 6.0 license. Examples of these files include the Visual Basic 6.0 runtime library (msvbvm60.dll), controls (i.e. msflxgrd.ocx) along with runtime support files for other major functional areas (i.e. MDAC).
The runtime is divided into the three groups:
Supported Runtime Files – Shipping in the OS: Key Visual Basic 6.0 runtime files, used in the majority of application scenarios, are shipping in and supported for the lifetime of supported Windows versions. This lifetime is five years of mainstream support and five years of extended support from the time that a given version of Windows ships. These files have been tested for compatibility as part of our testing of Visual Basic 6.0 applications running on supported Windows versions. Note: All supported Windows versions contain a nearly identical list of files and the redist requirements for applications containing these files should be nearly identical. One key difference is TriEdit.dll was removed from Windows Vista and later versions.
Supported Runtime Files – Extended Files to Distribute with your application: extended list of key controls, libraries, and tools that are installed from the IDE media or from Microsoft.com to the developer machine. Typically the VB6 IDE installed these controls to the developer machine by default. The developer still needs to redistribute these files with the application. The supported version of the files is available online on the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkID=142927).
Unsupported Runtime Files: Some files have either fallen out of mainstream support or they were never included as a part of the runtime redist (e.g. they were included in \Tools folder on the IDE media to support legacy VB4/VB5 applications or they were 3rd party controls). These files are not supported on Windows; instead they are subject to whatever support agreement applies to the media they were shipped with. This implies no warranties around support and servicing. In some instances, later versions of these libraries are supported. Details on backward compatibility or migration to supported versions are provided below.
For specific details on the files included in each support group see the “Runtime Definition” section below.

Visual Basic 6.0 Support Lifetime

Supporting and/or shipping Visual Basic 6.0 runtime binaries on supported Windows versions does not change the support policy for the Visual Basic 6.0 IDE or Visual Studio 6.0 IDE as a whole. Those products will move out of extended support in April 8, 2008.
Further details on the support policy for the Visual Basic 6.0 and Visual Studio 6.0 products can be found at http://msdn.microsoft.com/en-us/vstudio/aa718686.aspx. Details on the support lifecycle of Microsoft products can be found at http://support.microsoft.com/gp/lifepolicy. As a part of this support lifecycle, Microsoft will continue to support the Visual Basic 6.0 runtime on supported Windows versions for the support lifetime of those operating systems. This means, for example, that the Visual Basic 6.0 runtime will be supported on Windows Server 2003 until June, 2008 for Mainstream Support and June, 2013 for Extended Support.
For more details on the support lifecycle or to find out about additional support options, please visit our support page at http://www.microsoft.com/support            

64-Bit Windows

Visual Basic 6.0 runtime files are 32-bit. These files ship in 64-bit Windows Operating Systems referenced in the table below. 32-bit VB6 applications and components are supported in the WOW emulation environment only. 32-bit components must also be hosted in 32-bit application processes.
The Visual Basic 6.0 IDE has never been offered in a native 64-bit version, nor has the 32-bit IDE been supported on 64-bit Windows. VB6 development on 64-bit Windows or any native architecture other than 32-bit is not and will not be supported.

Windows 7

Since the initial release of this support statement, the Windows 7 operating system has been announced. This document has been updated to clarify Microsoft’s support for VB6 on Windows 7.
VB6 runtime will ship and will be supported in Windows 7 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows 7 being the same as it is for Windows Vista.

Windows 8

Since the initial release of this support statement, the Windows 8 operating system has been announced. This document has been updated to clarify Microsoft’s support for VB6 on Windows 8.
VB6 runtime will ship and will be supported in Windows 8 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows 8 being the same as it is for Windows 7.

Windows 8.1

Since the initial release of this support statement, the Windows 8.1 operating system has been announced. This document has been updated to clarify Microsoft’s support for VB6 on Windows 8.1.
VB6 runtime will ship and will be supported in Windows 8.1 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows 8.1 being the same as it is for Windows 8.

Windows 10

Since the initial release of this support statement, the Windows 10 operating system has been announced. This document has been updated to clarify Microsoft’s support for VB6 on Windows 10.
VB6 runtime will ship and will be supported in Windows 10 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows 10 being the same as it is for Windows 8.1.

Windows Server 2008

Since the initial release of this support statement, the Windows Server 2008 operating system has been announced. This document has been updated to clarify Microsoft’s support for VB6 on Windows Server 2008.
VB6 runtime will ship and will be supported in Windows Server 2008 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows Server 2008 being the same as it is for Windows Vista.

Windows Server 2008 R2

Since the initial release of this support statement, the Windows Server 2008 R2 operating system has been announced. This document has been updated to clarify Microsoft’s support for VB6 on Windows Server 2008 R2.
VB6 runtime will ship and will be supported in Windows Server 2008 R2 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows Server 2008 R2 being the same as it is for Windows Server 2008.

Windows Server 2012

Since the initial release of this support statement, the Windows Server 2012 operating system has been announced. This document has been updated to clarify Microsoft’s support for VB6 on Windows Server 2012.
VB6 runtime will ship and will be supported in Windows Server 2012 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows Server 2012 being the same as it is for Windows Server 2008 R2.

Windows Server 2012 R2

Since the initial release of this support statement, the Windows Server 2012 R2 operating system has been announced. This document has been updated to clarify Microsoft’s support for VB6 on Windows Server 2012 R2.
VB6 runtime will ship and will be supported in Windows Server 2012 R2 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows Server 2012 R2 being the same as it is for Windows Server 2012.

Supported Windows Operating System Versions

This section provides additional information regarding the operating systems that offer some level of support for VB6. 
Windows Operating SystemHas support? 
VB6 Supported Runtime -Files Shipping in WindowsVB6 Supported Runtime – Extended Files to Distribute with Your ApplicationVB6 IDE
Windows 10, all 32bit editionsYes *Yes *No, but Custom Support Agreements may be available.
Windows 10, all 64bit editions (WOW only)Yes*
32bit apps running in WOW only
Yes*
32bit apps running in WOW only
No
Windows 8.1, all 32bit editionsYes *Yes *No, but Custom Support Agreements may be available.
Windows Server 2012 R2, all 64bit editions (WOW only)
Windows Server 2012, all 64bit editions (WOW only)
Yes*
32bit apps running in WOW only
Yes*
32bit apps running in WOW only
No
Windows 8.1, all 64bit editions (WOW only)Yes*
32bit apps running in WOW only
Yes*
32bit apps running in WOW only
No
Windows 8, all 32bit editionsYes *Yes *No, but Custom Support Agreements may be available.
Windows 8 all 64bit editions (WOW only)Yes*
32bit apps running in WOW only
Yes*
32bit apps running in WOW only
No
Windows 7, all 32bit editionsYes *Yes *No, but Custom Support Agreements may be available.
Windows 7, all 64bit editions (WOW only)Yes*
32bit apps running in WOW only
Yes*
32bit apps running in WOW only
No
Windows Vista, all  32bit editionsYes*Yes*No, but Custom Support Agreements may be available.
Windows Vista, all x64 editions (WOW only)
Yes*
32bit apps running in WOW only
Yes*
32bit apps running in WOW only
No
Windows Server 2008 R2, all x64 editions (WOW only)
Windows Server 2008, all x64 editions (WOW only)
Yes*
32bit apps running in WOW only
Yes*
32bit apps running in WOW only
No
Windows Server 2008, all 32bit editionsYes*Yes*No, but Custom Support Agreements may be available.
Windows 2003 server, all 32bit editions including R2Yes*Yes*No, but Custom Support Agreements may be available.
Windows 2003 server. all x64 editions including R2
Yes*
32bit apps running in WOW only
Yes*
32bit apps running in WOW only
No
* VB6 runtime support is limited by the OS support lifecycle.  E.g. if the target OS is in Extended support, VB6 cannot have a higher level of support than Extended support.   

Visual Basic 6.0 Runtime Usage Inside VBA and Office

Visual Basic for Applications, or VBA, is a distinct technology commonly used for application automation and macros inside of other applications, most commonly inside Microsoft Office applications. VBA ships as a part of Office and therefore the support for VBA is governed by the support policy of Office. However, there are situations where VBA is used to call or host Visual Basic 6.0 runtime binaries and controls. In these situations, Visual Basic 6.0 supported runtime files in the OS and the extended file list are also supported when used inside of a supported VBA environment.
For VB6 runtime scenarios to be supported inside VBA, all of the following must be true:
The host OS version for VB runtime is still supported
The host version of Office for VBA is still supported        
The runtime files in question are still supported

Visual Basic Script (VBScript)

VBScript is unrelated to Visual Basic 6.0 and this support statement. However, VBScript is currently shipping as a part Windows Vista, Windows Server 2008 including R2, Windows 7, Windows 8, Windows 8.1, Windows Server 2012 including R2, and Windows 10 and is governed by the OS support lifecycle.

Third Party Components

Microsoft is unable to provide support for third party components, such as OCX/ActiveX controls. Customers are encouraged to contact the original control vendor for details on support for those components.

Reporting Issues with VB 6.0 Application Running on Windows Vista, Windows 7, Windows Server 2008, Windows 8, Windows 8.1, Windows Server 2012, and Windows 10

Developers planning to use Visual Basic 6.0 with Windows Vista should install Windows Vista and begin application compatibility testing using original application acceptance testing.
If you find an issue with your Visual Basic 6.0 application running on Windows Vista, Windows 7, Windows Server 2008, Windows 8, Windows 8.1, Windows Server 2012, or Windows 10 please follow your normal support channels to report the issue.

Supported and Shipping in Windows Vista, Windows Server 2008, Windows 7, and Windows 8

atl.dll
asycfilt.dll
comcat.dll
compobj.dll
dbnmpntw.dll
dcomcnfg.exe
dllhost.exe
ds16gt.dll
ds32gt.dll
expsrv.dll
hh.exe
hhctrl.ocx
imagehlp.dll
iprop.dll
itircl.dll
itss.dll
mfc40.dll
mfc42.dll
mfc42enu.dll
msadce.dll
msadcer.dll
msadcf.dll
msadcfr.dll
msadco.dll
msadcor.dll
msadcs.dll
msadds.dll
msaddsr.dll
msader15.dll
msado15.dll
msador15.dll
msadrh15.dll
mscpxl32.dll
msdadc.dll
msdaenum.dll
msdaer.dll
msdaora.dll
msdaosp.dll
msdaprst.dll
msdaps.dll
msdasc.dll
msdasql.dll
msdasqlr.dll
msdatsrc.tlb
msdatt.dll
msdfmap.dll
msdfmap.ini
msjtes40.dll
msorcl32.dll
msvbvm60.dll
msvcirt.dll
msvcrt.dll
msvcrt40.dll
mtxdm.dll
mtxoci.dll
odbc16gt.dll
odbc32.dll
odbc32gt.dll
odbcad32.exe
odbccp32.cpl
odbccp32.dll
odbccr32.dll
odbccu32.dll
odbcint.dll
odbcji32.dll
odbcjt32.dll
odbctrac.dll
oddbse32.dll
odexl32.dll
odfox32.dll
odpdx32.dll
odtext32.dll
ole2.dll
ole32.dll
oleaut32.dll
oleaut32.dll
oledb32.dll
oledb32r.dll
oledlg.dll
olepro32.dll
olethk32.dll
regsvr32.exe
rpcns4.dll
rpcrt4.dll
scrrun.dll
secur32.dll
simpdata.tlb
sqloledb.dll
sqlsrv32.dll
stdole2.tlb
stdole32.tlb
storage.dll
vbajet32.dll
vfpodbc.dll

Supported Runtime Files to Distribute with Your Application

comct232.ocx
comct332.ocx
comctl32.ocx
comdlg32.ocx
dbadapt.dll
dbgrid32.ocx
dblist32.ocx
mci32.ocx
msadodc.ocx
msbind.dll
mscdrun.dll
mschrt20.ocx
mscomct2.ocx
mscomctl.ocx
mscomm32.ocx
msdatgrd.ocx
msdatlst.ocx
msdatrep.ocx
msdbrptr.dll
msflxgrd.ocx
mshflxgd.ocx
mshtmpgr.dll
msinet.ocx
msmapi32.ocx
msmask32.ocx
msrdc20.ocx
msrdo20.dll
msstdfmt.dll
msstkprp.dll
mswcrun.dll
mswinsck.ocx
picclp32.ocx
richtx32.ocx
sysinfo.ocx
tabctl32.ocx

Unsupported, But Supported and Compatible Updates or Upgrades are Available

dao350.dll
mdac_typ.exe
mschart.ocx
msdaerr.dll
msdatl2.dll
msexch35.dll
msexcl35.dll
msjet35.dll
msjint35.dll
msjt4jlt.dll
msjter35.dll
msjtor35.dll
msltus35.dll
mspdox35.dll
msrd2x35.dll
msrepl35.dll
mstext35.dll
msxbse35.dll
odbctl32.dll
oledb32x.dll

Unsupported Runtime Files

anibtn32.ocx
graph32.ocx
keysta32.ocx
autmgr32.exe
autprx32.dll
racmgr32.exe
racreg32.dll
grid32.ocx
msoutl32.ocx
spin32.ocx
gauge32.ocx
gswdll32.dll
ciscnfg.exe
olecnv32.dll
rpcltc1.dll
rpcltc5.dll
rpcltccm.dll
rpclts5.dll
rpcltscm.dll
rpcmqcl.dll
rpcmqsvr.dll
rpcss.exe
dbmsshrn.dll
dbmssocn.dll
windbver.exe
msderun.dll
odkob32.dll
rdocurs.dll
vbar332.dll
visdata.exe
vsdbflex.srg
threed32.ocx
MSWLess.ocx
tlbinf32.dll
triedit.dll

Localization Support Binaries

The following binaries are necessary for supporting Visual Basic 6.0 applications running on localized versions of the Windows operating system. They are supported but are not shipped in Windows. These files are required to be shipped with your application setup.

Supported Runtime Files to Distribute with Your Application

JPNKORCHTCHS
mfc42jpn.dll
scrrnjp.dll
vb6jp.dll
cmct2jp.dll
cmct3jp.dll
mscc2jp.dll
cmctljp.dll
cmdlgjp.dll
mscmcjp.dll
dbgrdjp.dll
dblstjp.dll
mcijp.dll
msadnjp.dll
adodcjp.dll
mschtjp.dll
msch2jp.dll
mscomjp.dll
datgdjp.dll
datlsjp.dll
datrpjp.dll
dbrprjp.dll
flxgdjp.dll
mshfgjpn.dll
htmprjp.dll
inetjp.dll
msmpijp.dll
msmskjp.dll
rdc20jp.dll
rdo20jp.dll
stdftjp.dll
mswcrjp.dll
winskjp.dll
pcclpjp.dll
rchtxjp.dll
sysinjp.dll
tabctjp.dll
mfc42kor.dll
scrrnko.dll
vb6ko.dll
cmct2ko.dll
cmct3ko.dll
mscc2ko.dll
cmctlko.dll
cmdlgko.dll
mscmcko.dll
dbgrdko.dll
dblstko.dll
mciko.dll
msadnko.dll
adodcko.dll
mschtko.dll
msch2ko.dll
mscomko.dll
datgdko.dll
datlsko.dll
datrpko.dll
dbrprko.dll
flxgdko.dll
mshfgkor.dll
htmprko.dll
inetko.dll
msmpiko.dll
msmskko.dll
rdc20ko.dll
rdo20ko.dll
stdftko.dll
mswcrko.dll
winskko.dll
pcclpko.dll
rchtxko.dll
sysinko.dll
tabctko.dll
mfc42cht.dll
scrrncht.dll
vb6cht.dll
cmct2cht.dll
cmct3cht.dll
mscc2cht.dll
cmctlcht.dll
mscmccht.dll
cmdlgcht.dll
dbgrdcht.dll
dblstcht.dll
mcicht.dll
msadncht.dll
adodccht.dll
mschtcht.dll
msch2cht.dll
mscomcht.dll
datgdcht.dll
datlscht.dll
datrpcht.dll
dbrprcht.dll
flxgdcht.dll
mshfgcht.dll
htmprcht.dll
inetcht.dll
msmpicht.dll
msmskcht.dll
rdc20cht.dll
rdo20cht.dll
stdftcht.dll
mswcrcht.dll
winskcht.dll
pcclpcht.dll
rchtxcht.dll
sysincht.dll
tabctcht.dll
mfc42chs.dll
scrrnchs.dll
vb6chs.dll
cmct2chs.dll
mscc2chs.dll
cmct3chs.dll
cmctlchs.dll
mscmcchs.dll
cmdlgchs.dll
dbgrdchs.dll
dblstchs.dll
mcichs.dll
msadnchs.dll
adodcchs.dll
mschtchs.dll
msch2chs.dll
mscomchs.dll
datgdchs.dll
datlschs.dll
datrpchs.dll
dbrprchs.dll
flxgdchs.dll
mshfgchs.dll
htmprchs.dll
inetchs.dll
msmpichs.dll
msmskchs.dll
rdc20chs.dll
rdo20chs.dll
stdftchs.dll
mswcrchs.dll
winskchs.dll
pcclpchs.dll
rchtxchs.dll
sysinchs.dll
tabctchs.dll
ITAFRAESPDEU
mfc42ita.dll
scrrnit.dll
vb6it.dll
cmct2it.dll
mscc2it.dll
cmct3it.dll
cmctlit.dll
mscmcit.dll
cmdlgit.dll
dbgrdit.dll
dblstit.dll
mciit.dll
msadnit.dll
adodcit.dll
mschtit.dll
msch2it.dll
mscomit.dll
datgdit.dll
datlsit.dll
datrpit.dll
dbrprit.dll
flxgdit.dll
mshfgit.dll
htmprit.dll
inetit.dll
msmpiit.dll
msmskit.dll
rdc20it.dll
rdo20it.dll
stdftit.dll
mswcrit.dll
winskit.dll
pcclpit.dll
rchtxit.dll
sysinit.dll
tabctit.dll
mfc42fra.dll
scrrnfr.dll
vb6fr.dll
cmct2fr.dll
mscc2fr.dll
cmct3fr.dll
cmctlfr.dll
mscmcfr.dll
cmdlgfr.dll
dbgrdfr.dll
dblstfr.dll
mcifr.dll
msadnfr.dll
adodcfr.dll
mschtfr.dll
msch2fr.dll
mscomfr.dll
datgdfr.dll
datlsfr.dll
datrpfr.dll
dbrprfr.dll
flxgdfr.dll
mshfgfr.dll
htmprfr.dll
inetfr.dll
msmpifr.dll
msmskfr.dll
rdc20fr.dll
rdo20fr.dll
stdftfr.dll
mswcrfr.dll
winskfr.dll
pcclpfr.dll
rchtxfr.dll
sysinfr.dll
tabctfr.dll
mfc42esp.dll
scrrnes.dll
vb6es.dll
cmct2es.dll
mscc2es.dll
cmct3es.dll
cmctles.dll
mscmces.dll
cmdlges.dll
dbgrdes.dll
dblstes.dll
mcies.dll
msadnes.dll
adodces.dll
mschtes.dll
msch2es.dll
mscomes.dll
datgdes.dll
datlses.dll
datrpes.dll
dbrpres.dll
flxgdes.dll
mshfges.dll
htmpres.dll
inetes.dll
msmpies.dll
msmskes.dll
rdc20es.dll
rdo20es.dll
stdftes.dll
mswcres.dll
winskes.dll
pcclpes.dll
rchtxes.dll
sysines.dll
tabctes.dll
mfc42deu.dll
scrrnde.dll
vb6de.dll
cmct2de.dll
mscc2de.dll
cmct3de.dll
cmctlde.dll
mscmcde.dll
cmdlgde.dll
dbgrdde.dll
dblstde.dll
mcide.dll
msadnde.dll
adodcde.dll
mschtde.dll
msch2de.dll
mscomde.dll
datgdde.dll
datlsde.dll
datrpde.dll
dbrprde.dll
flxgdde.dll
mshfgde.dll
htmprde.dll
inetde.dll
msmpide.dll
msmskde.dll
rdc20de.dll
rdo20de.dll
stdftde.dll
mswcrde.dll
winskde.dll
pcclpde.dll
rchtxde.dll
sysinde.dll
tabctde.dll

Sunday, August 28, 2016

If you are having difficulty with the concept ...

If you are having difficulty with the concept of .Net being compiled or a 'Virtual Machine' think of it like this:-

1) .Net languages compile to an intermediate language (CIL), this intermediate language is then compiled to machine code each time you run the application by a run-time compiler (or just-in-time compiler in marketing speak). This is similar to how an interpreter works, but is faster (though you get a start-up delay while it is compiling).
This is very like VB6 if you take the option of compiling to P-Code.The 'VM' in MSVBVM60.dll stands for 'Virtual Machine'. It is this that translates VB P-Code to machine code.

2) .Net also has options to fully compile (or 'pre-compile') using .Net Native or Ngen to machine code. This mainly just removes the start-up delay (see above). You still need the common language runtime to be present even if you have compiled with .Net Native.
This is very like VB6 if (as is normal) you take the option of compiling to Native Code, which compiles to machine code (and speeds up loops and math) while still needing MSVBVM60.dll for some services (such as startup and shutdown code and functionality for intrinsic controls).

3) A 'Virtual Machine' is simply a fancy name for whatever goes between your intermediate code (IL code or P-Code) and machine-understandable code at runtime. Whether that is a compiler, interpreter, or combination of the two.
It's just a matter of semantics whether you regard a just-in-time compiler as a virtual machine or not.


By Sten2005
Microsoft support VB6 programming on Windows 10 until at least 2025


Friday, August 26, 2016

15 programming languages you need to know in 2016 !

15 programming languages you need to know in 2016:


1 Visual Basic 6.0

2 Java

3 PHP

4 JavaScript

5 C#

6 Visual C++

7 Ruby

8 Python

9 C++

10 NASM

11 COBOL

12 Erlang

13 Fortran

14 R programming language

15 Visual Basic .NET


Sunday, August 21, 2016

Why Visual Basic 6 is the most popular now in 2016 ?

One of the main reasons VB6 developers didn't move to VB.Net was lack of backwards compatibility.
This lack of compatibility meant you had to continue to support legacy apps. There was no business case for rewriting them, just to have the identical application in a different language.
And if they did move from VB6, what VB6 developer would choose a Microsoft language knowing Microsoft had just abandoned them and would be likely to do so again ?
And if you developed for Office you would still need to use VB6's twin sister VBA.
As many VB6 developers said at the time, Microsoft were right to develop C#/.Net, but they made a mistake in abandoning backwards compatibility in VB.Net. A compatible VB7 would have retained VB6 developers, instead Microsoft lost the majority of these forever.
Sadly, Microsoft didn't learn the backwards compatibility lesson. Windows Phone 7 was quite promising. Then Microsoft launched the incompatible Windows Phone 8 and lost the mobile phone market forever.
Now that C# is rapidly losing popularity and VBdotNet is being abandoned it looks like VB6 users were right all along.
The replacement of VB6 with VB .NET lost many of its RAD aspects simply because it had to be hard line object oriented. That's why VB.Net never achieved the success of VB6.
I support VB6 programming, VBA programming and VBScript programming
paul commented  ·    

Friday, August 19, 2016

I would use an updated VB6 !

I would use an updated VB6 (VB7 ?)
It would need to:
1) Be compatible with VB6 (take any existing source code and be able to compile and run it)
2) Update the language to at least VBA7.1 standard (and therefore support 64 bit)
3) Ideally have the Microsoft ActiveX controls built-in rather than as ActiveXs (move away from ActiveXs)
4) Still support ActiveXs (for 3rd party/old controls)
5) Ideally not need a separate VB Runtime
6) Update the look and feel of both apps and the IDE (same as you can do in VB6 by adding a Manifest)
7) Option to compile to 64 bit (see 2 above), ideally supporting 32bit ActiveXs. If ActiveX support isn't possible then 64 bit compile with built-in controls only (see 3 above).
8) Include Multi-threading (as you can do in VB6 with a multithread DLL).
9) Be DPI-aware (as you can do in VB6 with replacement controls)
10) Possibly minor language enhancements, such as Try/Catch error handling.
"VB6 is not just a language. VB6 is a language, a runtime, a platform library, a tool/IDE, and an ecosystem tightly packaged together in a way that made all of them work well together. " - Paul Yuknewicz, Microsoft
MikeB commented  ·  

Thursday, August 11, 2016

Mastery is being able to obtain a simple elegant answer even while interfacing with a complex system. Stability is virtuous !

These are pertinent pieces of articles of Dave's from sandsprite.com/CodeStuff/. I advise you to take Dave's articles one by one (see here). Inside Dave's articles you will find incredible things, things that you can't imagine are possible in a programming language. Wizards like Dave make us proud to be a part of the VB6 community. This is what Dave says in one of his articles (and my words stop here):

Here is another thought why i love vb6. It was made by wizards of C++, COM and Windows GUI programming. They made a simple general use language that made GUI things a breeze. They kept it light and easy to use which made development fast and light. The intellisense lists were not overloaded with tons of crap. If you needed more power, it integrated easily with C and the entire world of COM. I really believe in programming in layers. The gui aspects are complex, the world of COM is super complex. VB6 was so perfect at these. And COM was a great match with Windows GUI. Fast, native, and works really well. .NET is everything and the kitchen sink and its a bloated turd. Holy crap..its been 15 frigging years now I still cant stop ranting about this.

Foreword:

In this series I am going to discuss some of the history, strengths and techniques used in Visual Basic 6 development. I will not cover basic techniques which can be found in abundance across the net. Instead I will focus more on advanced topics which are harder to find concise information on. I have been using VB6 continuously since 2000, and I still find new things about it as my knowledge of it deepens. My path with programming advanced from web technologies, to VB6, to C, and now on to COM. I do not feel like VB6 limits me in any way. I have achieved everything I have wanted with it and it is brilliant at what it does. After 16 years I am still working to understand the full software stack that VB is built on top of. I am not a fan of the modern programming landscape where technologies shift like the weather. My personality is such that I wish to master the ins and outs of a technology and know it right down to its roots. Even for VB6 this is a long slow process. As more and more layers of technology are built on top of one another and grow larger and larger I am not sure this intimate level of knowledge is even possible anymore. (as in having direct experience with not just theoretical knowledge of its operation).

Mastery is being able to obtain a simple elegant answer even while interfacing with a complex (or even chaotic) system. Stability is virtuous., says Dave !


Introduction:

VB6 was released in 1998. It is the 6th succession of the language and was the final version as we know it. VB.NET may be a variant of the basic language, but it is not VB6 and is built on an entirely different design. VB6 was once one of the most popular programming languages in the world. It was, and still is, a great general purpose programming language that made developing GUI windows apps fun and easy. One of the real strengths of vb6, is that it wrapped extremely complex functionality extremely well. With it developers didn't have to worry about (or even know) all the crazy details of what was going on behind the scenes. Seamlessly wrapping utter complexity, into a stable, intuitive, efficient package that even pre teens could utilize is a mark of mastery. Make no mistake, the minds behind classic visual basic were wizards of Windows and COM. Visual Basic 6 was also given good access to the underlying Windows API to interact with the system at a lower level. This mechanism allows it to easily interact with custom made DLLs in other languages such as C. If you couldn’t do something easily in VB6 language itself, you surely could add that capability by integrating with a C dll. VB6 also has excellent access to COM libraries. COM is a very complex technology in its raw form, but in VB, its integration is seamless.


What happened?

My take on this is that MS decided that they wanted an academically 'proper' language. They also got bit by the Java hype, or felt they had to keep up with it. First they tried to adapt Java with J++, but then they got sued and had to spin it off into C#. They wanted a framework that you could compile to intermediate code, and then have run on any device regardless of processor. They also wanted a language that had the capability to support more advanced constructs such as polymorphism. VB6, being built on top of COM technology could not meet the language complexity requirements of what they envisioned so stop developing it. To my sensibilities, needless complexity is a detriment. Things should be accomplished as simply and directly as possible. If you have a working system, that's the end goal. The more complexity involved, the more ways things can go sideways. Another real danger is, that people can get lost in the complexity and end up creating things that are way over complex for what really has to be accomplished. I just don't agree with it and have not found it useful. Another point I will make here, is that the extra complexity adds allot of noise. No longer is it a lite clean tool to use to solve problems. Now you have to wade through loads of possibilities and options to accomplish a task. I consider this a drain. One more thought, as .NET has grown and evolved, sometimes functions have been removed or depreciated. Opening and compiling an old project may require changes. You may have to recompile a project just because an old version of the run-time is no longer supported or installed by default on your OS of choice. VB6 being frozen, I can open a 20yr old project and still compile it perfectly fine without any changes and have it work.

Source:
http://sandsprite.com/CodeStuff/Why_I_Still_Use_VB6/