|
We still have many VB6 code around here (mostly batch and client legacy apps). The main reason behind is that the .NET framework is not installed on standard end user PC images.
The signature is in building process.. Please wait...
|
|
|
|
|
Doesn't .Net framework come with OS these days?
|
|
|
|
|
Depends on each image you create. Our System Admins just uncheck the .NET Framework option during install..
The signature is in building process.. Please wait...
|
|
|
|
|
vonb wrote: Our System Admins just uncheck the .NET Framework option during install..
You should then combat that with ClickOnce's prerequisite installers...
|
|
|
|
|
Like COBOL, VB6 is here to stay. More than 50% of business transactions are processed with COBOL and VB6. Some claim 70% and 80%.
|
|
|
|
|
I realise I may get flamed for this, and I am mentally prepared for it, but VB6 was not as bad as people make it out to be. Sure it was not the best language for much of anything, but it is not as bad as people make it out to be. .NET was far worse, and I would even go as far as to say that C# is more shoddy than VB6 ever was or ever will be.
Now before the flaming starts hear me out. I personally would class VB6 as an intermediary language, sure there was a lot more managed libraries than C++ will ever have, but the amount of managed code in VB6 pales in comparison to the amount of managed code in .NET or C#. As someone who has dabbled briefly into cryptography, managed code is the single largest bane of any language you can name. Unmanaged code also prods the coder to pay a hell of a lot more attention to what they are doing, to make sure they get things right, because getting anything wrong can lead to catastrophic failure, particularly in languages that have even less managed code libraries than VB6.
So is VB6 the best language ever? No, but there are certainly a significant amount of more "modern" languages around that are significantly worse.
Sure you could write some unsafe code in VB6, but if you are any good at it, you can write "unsafe code" that does the job it was written for, does it correctly, and is faster than the "managed code".
In short, before anyone starts ranting about how bad a language is, learn the compiler properly, learn the loop holes, the does and the don't. You'll be happier, more productive code monkeys. When speed and accuracy is of prime importance to your application, unmanaged code is king. Quit with the hand holding that are managed libraries and learn to code properly.
|
|
|
|
|
Seems like you wrote that trying to attract a flame. For most things managed code is 'coding properly', particularly with an intelligent garbage collection algorithm and large memory spaces. C#/.Net applications get very close in speed to a correctly coded C++ equivalent. An environment where "getting anything wrong can lead to catastrophic failure" is not better.
|
|
|
|
|
No it's not better, but it does teach you to be better coders because you are paying a lot more attention to what you are doing as opposed to letting the managed code do it for you. In many instances the managed code is also slower, see my cryptography example. But I do agree with you that managed code does suit most instances. I was being very specific with the example.
|
|
|
|
|
|
I see VB6 as an intermediary language, it's not as flexible as C or C++ , but in some instances it is superior to more modern languages such as C# because it does not enforce "best practices". Case in point is the following rant.
If you implement AES in VB6, using best coding practices, such as all local variables and the like, it is something along the lines of 45-50% slower than if it was implemented in C.
If however you implemented AES using code that does not fit "best coding practices", hand coding most things rather than using managed code, or doing things such as declaring all the variables as either global or static, you will notice that the VB6 code runs considerably faster, to the tune of 5-10% slower than if it were implemented in C.
There are 2 reasons for this. 1) VB6 is not ideal for cryptographic protocols, and 2) allocation of memory and then de-allocating it after you have finished running through a sub takes time, ok sure it's only a few microseconds, but when you are running through those subs several thousand times when encrypting a large file, you will definitely notice a significant difference in speed, even when compiled. The more computationally intensive those subs are, the worse the lag becomes. Point 2 is basic comp-sci. Having variables declared globally or as a static means the memory is allocated once, and is not released until the application has finished doing what it is doing.
Two of the core requirements in any cryptographic system is speed, and having the smallest memory footprint as possible so it can be used in multiple places, such as embedded systems or even smart cards which have an absolute minimum amount of resources available to it. You can have the most secure system in the world, but if it has a large footprint, you are limiting it's use. And if it's to slow no one will use it at all. So you have to make some compromises in your code to get that speed and minimal footprint.
The prime compromise is using code that is considered bad by most application developers. Bypassing most of the managed code, and hand tuning things yourself, and using intensely small subs, the more complex the sub the slower it will run. Even something as simple as turning off intrinsic compiler based error checking will effect the speed and footprint of your code.
Of course, using techniques that are not "best practice" can lead to catastrophic failure of the program in question, or the whole system if you are using a language that is capable of such a thing such as C. That is exactly why I made the statement of "it prods developers to pay a lot more attention" knowing where exactly a variable is being used, how it is being used, and when/if it can be reused. Without that close attention to detail, you're screwed. It goes back to the days when you had maybe one compile a week, when there was no real garbage collection, and resources were at a premium, so you must ensure that your code is pretty damn near spotless, particularly if you are writing code that is going to be used on a myriad of systems, where the resources available to that system is largely unknown.
Sadly most modern languages take away from the skill of the coder, because they rely to heavily on managed code that the coder can't see. Ok sure they know use this library and this happens, but they don't know how it happens, or wether it can be tweaked to get more speed or a smaller footprint.
This is why I, and most who have dabbled in cryptography on any serious level, prefer older languages that are not so polished, it makes for not only better coders, but better developers. Don't confuse the two, they are not one and the same.
I'll use an API that is in both VB6 and VB.NET to illustrate my case. The API is called copymemory, which exists in both VB6 and .NET, and is used in completely different ways in both languages.
In VB6 it is used in the following way:
copymemory(64, var1, var2)
What this does is takes 64 bytes from var2 and puts them in var1.
It is considered unsafe coding, but is significantly faster than an assignment which you will notice if you are writing code that is being called several thousand times before the application has completed, and using copymemory in .NET can't even do the required action properly.
So to close I will reiterate my initial statement. I see VB6 as an intermediary language, it's not as flexible as C or C++ , but in some instances it is superior to more modern languages because it does not enforce "best practices".
Now you go have a look at those code examples, how much of it fits "best application code practice" I'll wager that a large portion doesn't. Comparing application coding and cryptographic coding is like comparing oranges with mandarins, the only similarity is that they are both citrus fruits.
|
|
|
|
|
There was a time when it was a cool language, and I have made quite a bit money writing VB6 Applications. So I can't complain.
And on the other hand after using it for few years and earning money, I failed to understand that why my university taught me C++, or why we even need it. But then C# happen... 
|
|
|
|
|
When C# happened to me, I still preferred VB6. 
modified 31-Mar-14 20:35pm.
|
|
|
|
|
d@nish wrote: No. It is not. Just kidding.
You must be VB programmer! April Fool's day isn't until tomorrow.
Marc
|
|
|
|
|
I am a VB6 programmer and I hate when people do not make the difference between VB6 programmers and other VB programmers. What it is so funny regarding this post ?! care to explain ?!
|
|
|
|
|
ISpliter wrote: What it is so funny regarding this post ?! care to explain ?!
People in the past have made "VB[x] is the best programming language ever" in jest. I thought it was funny that you made such a post the day before April Fool's Day.
ISpliter wrote: I am a VB6 programmer and I hate when people do not make the difference between VB6 programmers and other VB programmers.
Uh...Isn't VB6 totally outdated?
From wikipedia: All versions of the Visual Basic development environment from 1.0 to 6.0 are now retired and unsupported by Microsoft.
Marc
|
|
|
|
|
Mark, VB6 is not outdated at all, it is supported by Microsoft until 2020 - 2023. On Wikypedia the information about some programming languages are false, no wonder that the world begins to have no confidence in the information written there (except for the scientific information which is well filtered). Thank you for the clarification
|
|
|
|
|
You may be joking but in it's day it really was. The technology spawned an entire industry.
|
|
|
|
|
Wasn't it created for those who could not code in real programming language? I would not know as I wrote my first program in year 2000. I used C++ for it. Proud.
|
|
|
|
|
d@nish wrote: Wasn't it created for those who could not code in real programming language? I would not know as I wrote my first program in year 2000. I used C++ for it. Proud.
Hey D@nish,
Well, sort-of, but it turned out to be a much richer programming system than I think even Microsoft expected. At the time the VB line was beginning to make itself front-and-center I had been writing in C/C++ and MASM for a long time. I had even gone so far as to have developed my own event-driven, color, mouse supported user-interface system for DOS by that time. (I had already been in the field about 20 years). The main thing keeping me (as a systems-level developer working in DOS) from embracing the Windows technology was the overly detailed manner in which applications had to be developed to run in Windows. I mean ... a "Hello World" application took something like 135 lines of code written in C/C++ once you constructed the main event loop, invalidation of the window rectangle, yadda yadda. I could see why someone with no other way might want to write Win32 level code (I read Petzold's book too) but to develop applications that way just seemed, to me, to be re-inventing the wheel. I was, at that time, getting tired of bare-metal programming.
At one point (back in 1998 or so) I was tasked with developing a credit-settlement application to run in the Windows desktop. The idea seemed daunting. However I had just discovered VB3 by that time and thought I'd see how that worked out. To my pleasant surprise I was able to focus on the application instead of the arcane details associated with trying to manage overlaid windows, custom controls and the rest. I had finally found the answer to developing for Windows.
In the ensuing years VB3 grew through VB4, VB5 and finally VB6. All during that time I found myself able to develop stuff for the Windows desktop with far more dispatch and design understanding than someone who was struggling with MFC programming. I was interested in getting RESULTS, not trying to prove I was a masochist. Snotty young C++ developers liked to get elitist about all the hotshot things they could do with C++ while those of us writing VB applications were getting business done. (I'm not saying ALL C++ developers are that way, nor am I saying the language doesn't have its place).
The firm I work with now still has a large base of code based on VB6 which has worked well for years. Sure, for new things we have moved onto .Net (I write mostly C# now) but the VB6 code cranks millions of dollars worth of employee time card data on a daily basis. With all of its extensions and 3rd-party support, VB6 has been a juggernaut that will not die easy. As I said earlier, we're moving on as developers to use a more recent technology such as .Net. However, don't let anyone talk you into the idea that VB6 is a "toy". True, a non-programmer can bang out a program with it pretty quickly, but what's wrong with that? Many developers take the elitist view that if it has a low entry-point that it's a "toy". Come into our shop ... I'll show you what a toy it is NOT.
VB6 not "real"? If you believe that I got a bridge out in Arizona I could sell you cheap! 
-CB
|
|
|
|
|
|
@dd@nish
Any intermediate VB6 programmer can put you in the corner of shame (hell, even I can do that). Do not believe me?! read this: Compilers Demystified: Function Pointers in Visual Basic 6.0[^]
I am very proud to be a part of the great VB6 community, where many intelligent programmers reside!
Best regards,
ISpliter
modified 31-Mar-14 20:37pm.
|
|
|
|
|
|
Doesn't surprise me a bit.
Most folks that want to "diss" the tool either haven't really used it or are listening to marketing talk. Yeah, it's old and been around for awhile but so has my Raleigh I ride 60 to 70 miles per week. (It's a 1987 model BTW - and more than one person has drooled over it.)
|
|
|
|
|
PHP too, PHP too.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
VB6 best programming language ever: Yes, but PHP is too  , true (however, PHP is a scripting language) , but I agree
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
