Solve : Visual Basic 6.0 Enterprise?

1.	Solve : Visual Basic 6.0 Enterprise?
Answer» Is VB6 Enterprise a recent version of Visual Basic? I can't find a good answer anywhere. Hmmmmmmmmmmmmmmmmmmmm. Good question. I use Visual Basic .NET, which is h'awesome. (Visual Studio)Quote VB6 has entered Microsoft's "non-supported phase" as of March 2008. ... . .. Current version of Visual Basic is largely the same language as VB6. Quote from: monkeytime on February 25, 2010, 05:07:23 PM Is VB6 Enterprise a recent version of Visual Basic? I can't find a good answer anywhere. No. Visual Basic 6 Learning, Professional, and Enterprise Editions were all released in 1998 both stand-alone and as part of Microsoft Visual Studio 6, which also consisted of Visual C++, Visual FoxPro, Visual InterDev, and Visual J++. The Enterprise Edition doesn't really add a whole lot compared to the professional edition at all- it basically boils down to, If you don't know what it adds, you don't need it; mostly things like the APE (Application Performance Explorer) And Visual SourceSafe, Microsofts rather ostracized source code control tool. I'm not sure if you can get VB6 Enterprise separate from Visual Studio, come to think of it. Anyway, gather round for a short history... there were BASIC versions before it, but BASICA was the first one that was readily available on PCs. this was included with MS-DOS version 3 (and maybe 2 and 1, dunno). this continued until DOS 5, which included QBASIC. During all this, Microsoft also had a BASIC compiler/IDE called "QuickBasic", which was modelled after it's other successful QuickC and... well actually I'm not sure if they had any other "quick" products.... anyway... With the release if Windows 3.0, the desktop environment was getting popular, but programming it still required an intimate knowledge of C. So, some genius came up with the idea of an easy to use tool that can make designing the User interface a process of dragging buttons and textboxes and so forth on a representation of a form, rather then messing around with CreateWindow() and other calls in the WM_CREATE message in a Window Procedure. To make things even more beginner-friendly, they made the code behind these objects a dialect of Basic. The prototypes were called "Ruby"... (or maybe it was Thunder.. I forget... Ruby was a name used to describe the system by Alan Cooper... so I think the MS worked prototypes might have gone by a different name. Now, anyway, Visual Basic 1.0 was a godsend to hobbyists everywhere. First off, already versed BASIC programmers needed to only copy paste their code into VB1. with a few changes- the code was 100% compatible save a few select procedures that were more or less DOS-specific. It met with rather astounding success. With each new release, features were added making it less of a toy language and more of a industrial plaything; For example, Visual Basic Version 2.0 introduced the "Variant" Data type, which became rather prevalent. (with VB.NET there is no "Variant" type, but rather boxed Object types, which work just as well). It also introduced a host of other features, and the professional version included an assortment of "professional" controls like animation buttons and the "ssribbon" control, which by today's standards would be called a toolbar. (and a weak one at that). It also added internal support for databases through Object techniques- the first glimpses of database code were seen: Code: [Select]Dim dset as DynaSet Dim DBName as String,DBConnect as String DBName = "\\SALES\PUBLIC\NEW\CUSTDB_1" DBConnect="UID=JAN;PWD=CD" Set db = OpenDatabase(DBName,False,False,DBConnect) Set DS = db.CreateDynaSet("Select * From Customers") Do While Not DS.Eof Print "First Name:";DS("First_Name") Print "Last Name:";DS("Last_Name") Ds.MoveNext() Loop Anyway, so VB2 brought forth the idea that maybe VB would make a good database access type language as well. VB3 rolled around, and the OLEClient Control, which used to be a separate VBX (Visual Basic eXtension) was now part of the run-time. On the other hand, nobody uses the bloody thing... not sure what made them decide to do that. Not sure what Else VB3 offered, since I didn't have to use it seriously. It did add the CreateObject() Function, if I recall, which has become nearly ubiquitous in VBScripts, at the very least. It might have had GetObject... but I don't think so. VB4 brought two major things to the table. First- it was able to create both 16-bit, and 32-bit applications, and came with a 16-bit and a 32-bit version of the IDE (and also the runtime). the second major addition was the creation of Class Modules, which could be used to create your own objects; and VB now supported the creation of OLE servers in both DLL and EXE form (OLE is pretty much synonymous with ActiveX... in fact, ActiveX is really just a fancy name for OLE) Visual Basic 5.0 added a whole new facet: the IDE was completely redesigned, additionally the crappy Extensibility framework that VB4 offered was thrown away and a new one was written that didn't SUCK quite so badly. the Interface itself now used the common MSOffice CommandBars, and used a MDI interface rather then the SDI interface that VB1-4 used. (the SDI interface was still accessible via the Options dialog). The main things VB5 added were support for the creation of ActiveX DLL and EXEs as well as ActiveX Controls. These features in addition to the newfound ability for Interface inheritance were a boon for developers. Additionally, the language added in rich improvements to User Defined Type limitations. VB6- by all appearances, seems the same as VB5 in nearly every facet. they added a good number of useful features, fixed a lot of annoying VB5 bugs, and for some reason you can give VB6 a XP/Vista/7 Manifest and let it use Luna/Aero themes but for some reason VB5 balks. Also most of the common controls were a million times better with VB6 (ALTHOUGH I don't use them anymore, having found VBaccelerator, which hosts similar controls that are a million times better then those... there's .NET stuff there now, too, I think). Oh wait, I lied. VB6 added Webclasses. crickets chirping My thoughts exactly. Quote from: Geek-9pm on February 25, 2010, 08:47:57 PM Current version of Visual Basic is largely the same language as VB6. Um... no... Visual Basic .NET is a fine language, and the .NET framework has almost everything you could ever need; heck, it provides stuff that TAKES months to get working in VB6. However- while the syntax is similar, it isn't the same language. For example, you could use an "Instr" function in VB.NET, but that's just a compatibility kludge. the actual way would be to use appropriate method of the string object. The great thing about .NET is everything is an object... you can do something like: "This is a string".Reverse() (well, I think, not sure if the String object has a Reverse Method, but you get the idea.) with VB6, that same code gives you: Expected: line number or label or statement or end of statement It removed a lot of "cruft" from the language, but it made migrating existing programs - you know, the millions of core business objects and applications developed in VB6 - impossible without a complete rewrite. the "migration tools" were a complete joke- they should have admitted from the start that it was a completely different language rather then try to hold on to the delicate fiber that was their credibility at the time and say "oh, it's mostly compatible" since they were secretly saying "for a hello world program" after that. I'm not too sure about the differences between the original .NET 2001, 2003, 2005, or 2008... well, I recall that they added the "my" namespace to 2005... which is like a punch in the gut. it's like saying, "oh, here, we know this framework is confusing, here, let us do the hard work for you by creating a global namespace that you can suckle from" last, you cannot say a language is "largely the same" when a keyword has a completely different name. "Static" had meant the same thing from QuickBasic to VB6; and yes it was a stupid procedure modifier that all local variables persist between calls... (same for declaring a variable with "Static" rather then "Dim".) However- and really, I have no probelm with this myself- the keyword Static changed entirely- now it meant that a method was a method of the class rather then the instance. Which is actually a great thing since class methods were simply impossible to create before .NET. But they still redefined the meaning. Once you redefined a keyword that has been in the language for years, your no longer working on a same language. Like I said, VB.NET is a fine dialect of Basic, but it is not friendly to developers who are used to previous versions (well, to be more precise, I should say developers who want to migrate code from previous versions). Anyway... err, there you are, a short history of Visual Basic.BC_Programmer, Thank you for the lecture. Your check is in the mail. On point you may have overlooked. At one point in time the MS BASIC software was a classic line by line language. Then when it went visual it also became event-driven. That means that the program might not do anything if there is no event. It just sets there. And you cold create a from with some text in it with no code to speak of. It was now a template language. Just fill in the blanks. Quote from: Geek-9pm on February 25, 2010, 10:12:47 PM BC_Programmer, Thank you for the lecture. Your check is in the mail. On point you may have overlooked. At one point in time the MS BASIC software was a classic line by line language. Then when it went visual it also became event-driven. That means that the program might not do anything if there is no event. It just sets there. And you cold create a from with some text in it with no code to speak of. It was now a template language. Just fill in the blanks. good point, that would be with VB1 the change to an Event Driven language was made. Really you cannot fault it; I mean, even C when used to write a windows program is purely event driven, but you have to parse the messages yourself. Sure, your winmain() routine was still executing (in a message pump) but this was rather insignificant- you process messages and respond to them, just as you do to events in VB (or really nearly every language nowadays). Also you can write console applications with VB6, so it's not a strict requirement to be event driven. Quote It was now a template language. Just fill in the blanks. Now this is evidently a cold observation; Is removing the mundane task of Windows Message Loops and Accelerator Translation and Resource editing really that bad? Is it in any way different to the way people will write a program template and use that from then on? Not really. Just takes away the monotony. Quote Now this is evidently a cold observation; Is removing the mundane task of Windows Message Loops and Accelerator Translation and Resource editing really that bad? Is it in any way different to the way people will write a program template and use that from then on? Not really. Just takes away the m What I wanted to say was that it got to the point that the code was hidden from the person that did the application. Yes, you did have to put in something in a little box for OnMouseOver or OnEventWhatever and it world invoke something you had to identify. But the application programmer would not ever see a full line-by-line source code of his project, unless he made a real effort to get it. This was a sea change from traditional languages. And yes, you could do console programs, but the GUI interface changed forever the way a working programmer would conceive an idea.It's no different then it used to be... you generally didn't modify printf() or sscanf() or other run-time functions... The scope of what encompasses the framework itself changed. Actually, come to think of it, my customized "New Project" in VB consists of 3 classes as well as a form with several controls, and it doesn't even do anything... Nowadays for programming XP/Vista/Win7 Properly with VB Classic you need a of extra stuff, too. Like manifests and API declarations for the common controls library and so forth. Oh, and that whole "you cannot see the code" thing changed with .NET. you can see the code that generates the form and it's controls and hooks them to the event procedures. (not the ASM code, of course, since the ASM for IDL will be different on different processors, silly)Quote from: BC_Programmer on February 25, 2010, 09:28:23 PM Microsoft also had a BASIC compiler/IDE called "QuickBasic", which was modelled after it's other successful QuickC and... well actually I'm not sure if they had any other "quick" products.... QuickPascal Quote from: Salmon Trout on March 07, 2010, 03:31:13 PM QuickPascal NO. QP is only for MS-DOS. Quote D:\BIN\qb>QP WARNING: Microsoft QuickPascal has been tested for use only with the MS-DOS and PC-DOS operating systems. Your use of this product with another operating system may void valuable warranty protection provided by Microsoft on QuickPascal. ...Press any key to continue Quote from: Geek-9pm on March 07, 2010, 04:13:33 PM NO. QP is only for MS-DOS. Where did I say otherwise? Quote from: Salmon Trout on March 08, 2010, 12:09:28 AM Where did I say otherwise? Sorry, you did not say that. Both QBASIC and QB can run as command line programs in most windows versions with no nag messages. But QP gives a error message. This might indicate that MS was not too confident about their Pascal. There was a Quick C. Quote Microsoft QuickC was a commercial integrated development environment (IDE) product engineered by Microsoft for the C programming language, superseded by Visual C++ Standard Edition[1]. It main competitor was Turbo C[2]. http://en.wikipedia.org/wiki/QuickC But there was never a quick PL/1 (sigh) QuickBASIC 2.0 gives the same message... And None of them work in the recent 64-bit versions of windows Also I find it ironic that you would mention that message, since it's probably originally designed to show for non MS-DOS or PC-DOS operating systems, such as DR-DOS.

Answer»

Is VB6 Enterprise a recent version of Visual Basic? I can't find a good answer anywhere. Hmmmmmmmmmmmmmmmmmmmm.
Good question.

I use Visual Basic .NET, which is h'awesome.
(Visual Studio)Quote

VB6 has entered Microsoft's "non-supported phase" as of March 2008. ... . ..

Current version of Visual Basic is largely the same language as VB6.
Quote from: monkeytime on February 25, 2010, 05:07:23 PM

Is VB6 Enterprise a recent version of Visual Basic? I can't find a good answer anywhere.

No.

Visual Basic 6 Learning, Professional, and Enterprise Editions were all released in 1998 both stand-alone and as part of Microsoft Visual Studio 6, which also consisted of Visual C++, Visual FoxPro, Visual InterDev, and Visual J++.

The Enterprise Edition doesn't really add a whole lot compared to the professional edition at all- it basically boils down to, If you don't know what it adds, you don't need it; mostly things like the APE (Application Performance Explorer) And Visual SourceSafe, Microsofts rather ostracized source code control tool.

I'm not sure if you can get VB6 Enterprise separate from Visual Studio, come to think of it.

Anyway, gather round for a short history...

there were BASIC versions before it, but BASICA was the first one that was readily available on PCs. this was included with MS-DOS version 3 (and maybe 2 and 1, dunno). this continued until DOS 5, which included QBASIC. During all this, Microsoft also had a BASIC compiler/IDE called "QuickBasic", which was modelled after it's other successful QuickC and... well actually I'm not sure if they had any other "quick" products.... anyway...

With the release if Windows 3.0, the desktop environment was getting popular, but programming it still required an intimate knowledge of C. So, some genius came up with the idea of an easy to use tool that can make designing the User interface a process of dragging buttons and textboxes and so forth on a representation of a form, rather then messing around with CreateWindow() and other calls in the WM_CREATE message in a Window Procedure. To make things even more beginner-friendly, they made the code behind these objects a dialect of Basic. The prototypes were called "Ruby"... (or maybe it was Thunder.. I forget... Ruby was a name used to describe the system by Alan Cooper... so I think the MS worked prototypes might have gone by a different name.

Now, anyway, Visual Basic 1.0 was a godsend to hobbyists everywhere. First off, already versed BASIC programmers needed to only copy paste their code into VB1. with a few changes- the code was 100% compatible save a few select procedures that were more or less DOS-specific. It met with rather astounding success.

With each new release, features were added making it less of a toy language and more of a industrial plaything; For example, Visual Basic Version 2.0 introduced the "Variant" Data type, which became rather prevalent. (with VB.NET there is no "Variant" type, but rather boxed Object types, which work just as well). It also introduced a host of other features, and the professional version included an assortment of "professional" controls like animation buttons and the "ssribbon" control, which by today's standards would be called a toolbar. (and a weak one at that). It also added internal support for databases through Object techniques- the first glimpses of database code were seen:

Code: [Select]Dim dset as DynaSet
Dim DBName as String,DBConnect as String
DBName = "\\SALES\PUBLIC\NEW\CUSTDB_1"
DBConnect="UID=JAN;PWD=CD"

Set db = OpenDatabase(DBName,False,False,DBConnect)

Set DS = db.CreateDynaSet("Select * From Customers")

Do While Not DS.Eof
Print "First Name:";DS("First_Name")
Print "Last Name:";DS("Last_Name")
Ds.MoveNext()

Loop

Anyway, so VB2 brought forth the idea that maybe VB would make a good database access type language as well.

VB3 rolled around, and the OLEClient Control, which used to be a separate VBX (Visual Basic eXtension) was now part of the run-time. On the other hand, nobody uses the bloody thing... not sure what made them decide to do that. Not sure what Else VB3 offered, since I didn't have to use it seriously. It did add the CreateObject() Function, if I recall, which has become nearly ubiquitous in VBScripts, at the very least. It might have had GetObject... but I don't think so.

VB4 brought two major things to the table. First- it was able to create both 16-bit, and 32-bit applications, and came with a 16-bit and a 32-bit version of the IDE (and also the runtime). the second major addition was the creation of Class Modules, which could be used to create your own objects; and VB now supported the creation of OLE servers in both DLL and EXE form (OLE is pretty much synonymous with ActiveX... in fact, ActiveX is really just a fancy name for OLE)

Visual Basic 5.0 added a whole new facet: the IDE was completely redesigned, additionally the crappy Extensibility framework that VB4 offered was thrown away and a new one was written that didn't SUCK quite so badly. the Interface itself now used the common MSOffice CommandBars, and used a MDI interface rather then the SDI interface that VB1-4 used. (the SDI interface was still accessible via the Options dialog). The main things VB5 added were support for the creation of ActiveX DLL and EXEs as well as ActiveX Controls. These features in addition to the newfound ability for Interface inheritance were a boon for developers. Additionally, the language added in rich improvements to User Defined Type limitations.

VB6- by all appearances, seems the same as VB5 in nearly every facet. they added a good number of useful features, fixed a lot of annoying VB5 bugs, and for some reason you can give VB6 a XP/Vista/7 Manifest and let it use Luna/Aero themes but for some reason VB5 balks. Also most of the common controls were a million times better with VB6 (ALTHOUGH I don't use them anymore, having found VBaccelerator, which hosts similar controls that are a million times better then those... there's .NET stuff there now, too, I think).
Oh wait, I lied. VB6 added Webclasses.

*crickets chirping*

My thoughts exactly.

Quote from: Geek-9pm on February 25, 2010, 08:47:57 PM

Current version of Visual Basic is largely the same language as VB6.

Um... no...

Visual Basic .NET is a fine language, and the .NET framework has almost everything you could ever need; heck, it provides stuff that TAKES months to get working in VB6.

However- while the syntax is similar, it isn't the same language. For example, you could use an "Instr" function in VB.NET, but that's just a compatibility kludge. the actual way would be to use appropriate method of the string object. The great thing about .NET is everything is an object... you can do something like:

"This is a string".Reverse()

(well, I think, not sure if the String object has a Reverse Method, but you get the idea.)
with VB6, that same code gives you:

Expected: line number or label or statement or end of statement

It removed a lot of "cruft" from the language, but it made migrating existing programs - you know, the millions of core business objects and applications developed in VB6 - impossible without a complete rewrite. the "migration tools" were a complete joke- they should have admitted from the start that it was a completely different language rather then try to hold on to the delicate fiber that was their credibility at the time and say "oh, it's mostly compatible" since they were secretly saying "for a hello world program" after that.

I'm not too sure about the differences between the original .NET 2001, 2003, 2005, or 2008... well, I recall that they added the "my" namespace to 2005... which is like a punch in the gut. it's like saying, "oh, here, we know this framework is confusing, here, let us do the hard work for you by creating a global namespace that you can suckle from"

last, you cannot say a language is "largely the same" when a keyword has a completely different name.

"Static" had meant the same thing from QuickBasic to VB6; and yes it was a stupid procedure modifier that all local variables persist between calls... (same for declaring a variable with "Static" rather then "Dim".)

However- and really, I have no probelm with this myself- the keyword Static changed entirely- now it meant that a method was a method of the class rather then the instance. Which is actually a great thing since class methods were simply impossible to create before .NET. But they still redefined the meaning.

Once you redefined a keyword that has been in the language for years, your no longer working on a same language. Like I said, VB.NET is a fine dialect of Basic, but it is not friendly to developers who are used to previous versions (well, to be more precise, I should say developers who want to migrate code from previous versions).

Anyway... err, there you are, a short history of Visual Basic.BC_Programmer,

Thank you for the lecture. Your check is in the mail.

On point you may have overlooked. At one point in time the MS BASIC software was a classic line by line language. Then when it went visual it also became event-driven. That means that the program might not do anything if there is no event. It just sets there. And you cold create a from with some text in it with no code to speak of. It was now a template language. Just fill in the blanks.

Quote from: Geek-9pm on February 25, 2010, 10:12:47 PM

BC_Programmer,

Thank you for the lecture. Your check is in the mail.

On point you may have overlooked. At one point in time the MS BASIC software was a classic line by line language. Then when it went visual it also became event-driven. That means that the program might not do anything if there is no event. It just sets there. And you cold create a from with some text in it with no code to speak of. It was now a template language. Just fill in the blanks.

good point, that would be with VB1 the change to an Event Driven language was made.

Really you cannot fault it; I mean, even C when used to write a windows program is purely event driven, but you have to parse the messages yourself. Sure, your winmain() routine was still executing (in a message pump) but this was rather insignificant- you process messages and respond to them, just as you do to events in VB (or really nearly every language nowadays).

Also you can write console applications with VB6, so it's not a strict requirement to be event driven.

Quote

It was now a template language. Just fill in the blanks.

Now this is evidently a cold observation; Is removing the mundane task of Windows Message Loops and Accelerator Translation and Resource editing really that bad? Is it in any way different to the way people will write a program template and use that from then on? Not really. Just takes away the monotony.

Quote

Now this is evidently a cold observation; Is removing the mundane task of Windows Message Loops and Accelerator Translation and Resource editing really that bad? Is it in any way different to the way people will write a program template and use that from then on? Not really. Just takes away the m

What I wanted to say was that it got to the point that the code was hidden from the person that did the application. Yes, you did have to put in something in a little box for OnMouseOver or OnEventWhatever and it world invoke something you had to identify. But the application programmer would not ever see a full line-by-line source code of his project, unless he made a real effort to get it. This was a sea change from traditional languages. And yes, you could do console programs, but the GUI interface changed forever the way a working programmer would conceive an idea.It's no different then it used to be...

you generally didn't modify printf() or sscanf() or other run-time functions...

The scope of what encompasses the framework itself changed.

Actually, come to think of it, my customized "New Project" in VB consists of 3 classes as well as a form with several controls, and it doesn't even do anything... Nowadays for programming XP/Vista/Win7 Properly with VB Classic you need a of extra stuff, too. Like manifests and API declarations for the common controls library and so forth.

Oh, and that whole "you cannot see the code" thing changed with .NET. you can see the code that generates the form and it's controls and hooks them to the event procedures. (not the ASM code, of course, since the ASM for IDL will be different on different processors, silly)Quote from: BC_Programmer on February 25, 2010, 09:28:23 PM

Microsoft also had a BASIC compiler/IDE called "QuickBasic", which was modelled after it's other successful QuickC and... well actually I'm not sure if they had any other "quick" products....

QuickPascal
Quote from: Salmon Trout on March 07, 2010, 03:31:13 PM

QuickPascal

NO. QP is only for MS-DOS.
Quote

D:\BIN\qb>QP

WARNING: Microsoft QuickPascal has been tested for use
only with the MS-DOS and PC-DOS operating systems.
Your use of this product with another operating system
may void valuable warranty protection provided by
Microsoft on QuickPascal.

...Press any key to continue

Quote from: Geek-9pm on March 07, 2010, 04:13:33 PM

NO. QP is only for MS-DOS.

Where did I say otherwise?
Quote from: Salmon Trout on March 08, 2010, 12:09:28 AM

Where did I say otherwise?

Sorry, you did not say that.
Both QBASIC and QB can run as command line programs in most windows versions with no nag messages. But QP gives a error message. This might indicate that MS was not too confident about their Pascal.

There was a Quick C.

Quote

Microsoft QuickC was a commercial integrated development environment (IDE) product engineered by Microsoft for the C programming language, superseded by Visual C++ Standard Edition[1]. It main competitor was Turbo C[2].

http://en.wikipedia.org/wiki/QuickC

But there was never a quick PL/1 (sigh)

QuickBASIC 2.0 gives the same message...

And None of them work in the recent 64-bit versions of windows

Also I find it ironic that you would mention that message, since it's probably originally designed to show for non MS-DOS or PC-DOS operating systems, such as DR-DOS.

Solve : Visual Basic 6.0 Enterprise?

Discussion

No Comment Found

Related InterviewSolutions

Reply to Comment