Is VB6 still in use of programmers?

about the first part:
so you actually agree with what i said,
you're just saying that the lower speed is not a problem for you.

this is probably not a problem, for many people who program in p-code langauges.


for the second part:
it's more complicated than vb6 ==> it is too complicated (at least for me).



for the third part:
this is obvious,
they don't need even to support it,
and not even need to publish the one dll that required for
vb6 applications to work (msvbvm60.dll), on 32b versions.

unless microsoft will make some very weired decision, and decide to block any program which use this dll.

The speed is different, but only slightly - I have a .Net program which does some quite complex work once per second on my computer, and in an entire day it takes about 10 minutes of CPU time, whereas the VB6 equivalent takes about 20 seconds less.

.Net is not more complicated, it is just different (and in various ways much easier, such as no code required for "on top" or "notification icon"). As chris128 implied, the problem is you want to keep using your existing skills and not learn new ones. There are some reasons that .Net is not right for everyone (such as esposito's almost unique situation, and a few others), but not wanting to learn is not one of them.

As for VB6 support on Windows, it has nothing to do with Windows being 32 bit (it works fine on 64 bit for me and others above). What it is about is being able to run 32 bit programs (which is likely for all 64 bit versions), and support of the VB6 runtimes (msvbvm60.dll and many other files), which is by no means guaranteed after Windows 7. If the runtimes are unsupported, it would arguably be foolish to include them (or allow them to be installed without warnings), as total failure of programs is likely to be better than them having a large amount of unknown bugs.


Whether you like it or not, the era of VB6 being a viable option is coming to an end - and as such it isn't nice to recommend that somebody should start learning it now.

i said i don't recommend to start learn it, but not because of the support
but because limitations it has.


about the support,
i think there is a strong connection between the
version, and the support.
if you see new 32bit versions comes out, it means, microsoft
continue give full support to this tech.
if you don't, it means they give only compatibility support,
which doesn't have to be full.


about the speed, it depends .
for real time audio processing for example, it's not good.

for console app for example, there is no need for it.

about the complication, it also depends.
maybe there are thing that less complicated than vb6,
but there are many, that much more.
for example, reference a simple form, and all the files you need for it.

Quote:

---

Originally Posted by si_the_geek

The speed is different, but only slightly - I have a .Net program which does some quite complex work once per second on my computer, and in an entire day it takes about 10 minutes of CPU time, whereas the VB6 equivalent takes about 20 seconds less.

.Net is not more complicated, it is just different (and in various ways much easier, such as no code required for "on top" or "notification icon"). As chris128 implied, the problem is you want to keep using your existing skills and not learn new ones. There are some reasons that .Net is not right for everyone (such as esposito's almost unique situation, and a few others), but not wanting to learn is not one of them.

As for VB6 support on Windows, it has nothing to do with Windows being 32 bit (it works fine on 64 bit for me and others above). What it is about is being able to run 32 bit programs (which is likely for all 64 bit versions), and support of the VB6 runtimes (msvbvm60.dll and many other files), which is by no means guaranteed after Windows 7. If the runtimes are unsupported, it would arguably be foolish to include them (or allow them to be installed without warnings), as total failure of programs is likely to be better than them having a large amount of unknown bugs.


Whether you like it or not, the era of VB6 being a viable option is coming to an end - and as such it isn't nice to recommend that somebody should start learning it now.

---

I can tell you from experience that someone who won't move from VB5 or VB6 to .Net hasn't used .Net for any length of time at all. I was, myself, one of those people who just kept "hanging on" to VB6 believing I could do "anything" with it that you could do in .Net.

True, VB6 is an excellent platform. Much of our code here is still written in it and I still enjoy working with it. However, as to creating anything new with it, no way. After using VB.Net (and now C#) for a couple of years, there is no turning back. Using the fully object-oriented techniques I've picked up over the last year has allowed me to construct code with far less effort than using old legacy techniques ever allowed. I've pulled things off in code with C# that would have taken me 5 times as long using VB6. As for code performance, the rules engine I've written is BLAZINGLY fast as a .Net assembly.

Of all the people around here I'm one of the most reluctant to upgrade unless it's absolutely necessary. (I.E. if it ain't broke, don't fix it). However after sitting on the learning curve with .Net for a year I have to call a spade a spade. It is worth upgrading to. I would liken using VB6 at this point to using a shovel to carve out the yard to replace the drain field when what I really needed was a front-end loader.

VB6 is sweet. I still love it. However it really is time to start thinking about moving on. If you have legacy code to maintain (as I do) fine, but writing new stuff in VB6 when you have a tool like .Net isn't particularly smart.

-Max :D

That sounds very familiar... I've probably heard the same kind of thing from hundreds of people by now! :D

Quote:

---

Originally Posted by whatsup

about the support, ...

---

Your comments about support are not valid, you do not seem to know about WoW (which allowed 16 bit apps to run on 32 bit versions of Windows [95 to XP], and 32-bit apps to run on 64-bit versions of Windows) being supported, and even with that whether or not support is given for the VB6 runtimes depends on a wide variety of other factors.

As for speed, I haven't used those things but I presume the speed could be fine if you are willing to put in a bit of extra effort. As always which tool is best depends on the circumstances - and the extra work in .Net might be less time than you save from the other things you need to do.

In terms of complication, I have no idea what your example is referring to... but as yet I haven't found anything that is more complicated, only lots of things that are much simpler, and several things that are just not quite the same as they were in VB6 (but take no extra effort, just different knowledge).

Quote:

---

Originally Posted by whatsup

for console app for example, there is no need for it.

---

Sorry but what an absolutely ridiculous statement. You can do pretty much anything with a console app... so how can you say that there is no need for it in a console app? I would love to see you try half the things that are possible in a VB.NET console app in a VB6 console app.

This is getting pretty... well more or less the way the discussion always goes.

There is no problem creating console applications in VB6, we do it all the time. I'm not sure the proves anything, assuming there is anything to prove.

What troubles me is how these .Net fans get agitated to the point of being rabid about it. What makes them so hostile?

If you're happy with .Net and don't want to use VB6 anymore that's fine. But why do you feel the need to beat up on everyone else?


The question here was whether VB6 is still of (in?) use by programmers. Sure it is. Not much else to say really.

No the question was essentially "is VB6 a good language to start learning programming with" - the answer being no, for all of the reasons mentioned in this thread and many more.

Quote:

---

If you're happy with .Net and don't want to use VB6 anymore that's fine. But why do you feel the need to beat up on everyone else?

---

If someone just told me they used VB6 I wouldn't care, its when people are recommending it to people that want to start programming that it annoys me.

Indeed, the actual question was this:

Quote:

---

Can anyone tell me that VB6 is still in use of programmers because I am going to learn programming as hobby also confused what version learn to start with whether VB6 or VB2008?

---

While VB6 still has a purpose and is still used by a reasonable amount of people, it is not a good option for somebody to start learning it now.

VB.Net is a very good option, despite the suggestion/implication from a few people who dislike .Net (often for unjustified reasons, which is where the "hostile" attitude is created).


Like chris128 I don't care what language(s) people want to use themselves, but I get annoyed when people try to persuade others to use (or not use) a particular language due to their own specific situation and/or lack of experience with the language.

No language is perfect, but VB.Net is one of the ones that is good to learn.

Ahh, yes.

Well given that question I'd almost certainly agree. For most people VB.Net would be a better choice than VB6.

Microsoft is doing a lot to get people up to speed from 0: http://msdn.microsoft.com/en-us/beginner/bb308758.aspx

Quote:

---

Originally Posted by dilettante

Ahh, yes.

Well given that question I'd almost certainly agree. For most people VB.Net would be a better choice than VB6.

Microsoft is doing a lot to get people up to speed from 0: http://msdn.microsoft.com/en-us/beginner/bb308758.aspx

---

Quote:

---

Originally Posted by that ebook you just linked

Software You'll Need
To develop Visual Basic programs, you’ll need :
1. The Microsoft .NET Framework 2.0, which is available, free, from
http://msdn.microsoft.com/netframewo...loads/updates/.

2. A .NET development environment. We recommend Microsoft Visual Basic 2005 Express Edition, which is available free from Microsoft at http://msdn.microsoft.com/vstudio/express/vb/ . The Visual Basic 2005 Express installation package includes the .NET Framework so you don’t need to worry about installing item #1 above separately.

....

It's important that you understand that this book is not about teaching you about the Visual Basic Express Edition software product - rather it teaches you about the Visual Basic language.

...
If you want to learn more about the Visual Basic Express development environment, go to the website at http://msdn.microsoft.com/vstudio/express/vb/ .

Writing a New Program Using Visual Basic Express
 To start Visual Basic Express, click START -> All Programs -> Microsoft Visual Basic 2005 Express Edition

---

Oh, Microsoft.... I'm speechless. Seriously! I can't breathe because I can't stop laughing.

Why whats funny about that :S It is simply saying that this book teaches you about the language not the IDE..

Quote:

---

Originally Posted by chris128

Why whats funny about that :S It is simply saying that this book teaches you about the language not the IDE..

---

The instructions are specific to Visual Basic 2005 Express Edition. No alternatives are mentioned, besides a text editor. It's clear the book is very much about teaching the reader Microsoft Visual Basic 2005 Express Edition.

Also, the "Visual Basic language" reference is laughable. It's not teaching you VB6 or prior compatible "Visual Basic". And who knows how long the "Visual basic language" it teaches will actually be applicable? Meaning, once they come out with whatever supercedes .NET(or even the next version), and there's a new "Visual Basic language", clearly that book will not entirely apply to a new "VB language".

Then there seems to already be differences between versions of VB.NET. This is the same as it was with previous versions(VB6 and prior). Always changing/adding/removing things making incompatibilities between versions.

That MS itself would refer to a "Visual Basic language" that's not version/IDE specific is just completely ridiculous! Don't you agree?

Regardless of version/IDE/software, they're teaching you "Microsoft's Visual Basic", and that more or less guarantees learners will be using their IDE.

Quote:

---

Originally Posted by FireXtol

The instructions are specific to Visual Basic 2005 Express Edition. No alternatives are mentioned, besides a text editor. It's clear the book is very much about teaching the reader Microsoft Visual Basic 2005 Express Edition.

---

So what? You're making a really big deal out of this.

Quote:

---

Also, the "Visual Basic language" reference is laughabe. It's not teaching you VB6 or prior compatible "Visual Basic". And who knows how long the "Visual basic language" it teaches will actually be applicable? Meaning, once they come out with whatever supercedes .NET(or even the next version), and there's a new "Visual Basic language", clearly that book will not entirely apply to a new "VB language".

---

OK, so again I say "So What?". There will be a manual out for the next version of Visual Basic.

Quote:

---

Then there seems to already be differences between versions of VB.NET. This is the same as it was with previous versions(VB6 and prior). Always changing/adding/removing things making incompatibilities between versions.

---

OK, so? They improve things from one version to another. As long as it doesn't continually break things then what's the big deal? Yeah, VB6 to VB.Net had to break a lot of things to go to a managed code environment but since VB.Net came out the changes haven't been destructive between versions. What ... would you like them to just stagnate the thing?

Quote:

---

That MS itself would refer to a "Visual Basic language" that's not version/IDE specific is just completely ridiculous! Don't you agree?

---

No, not really.

Quote:

---

Regardless of version/IDE/software, they're teaching you "Microsoft's Visual Basic", and that more or less guarantees learners will be using their IDE.

---

There's some problem with Microsoft writing documentation that's specific to their product? I don't get it.

Relax a little, you'll live longer.

-Max :D

Quote:

---

Originally Posted by FireXtol

The instructions are specific to Visual Basic 2005 Express Edition. No alternatives are mentioned, besides a text editor. It's clear the book is very much about teaching the reader Microsoft Visual Basic 2005 Express Edition.

---

What do you expect them to actually do instead of mentioning their own product? The choice they have is:
1. Use examples and instructions based on their own VB.NET IDE
2. Provide examples for every other VB.NET IDE out there and fill the book with "if you are using this IDE do this, if you are using this other IDE do this..." etc etc
3. Provide no information at all about the IDE and make the book pretty useless because the reader will learn about the language but not actually know where or how they can use the language

Surely you realise that option 1 is the only one that makes any kind of sense...

Quote:

---

Originally Posted by FireXtol

Also, the "Visual Basic language" reference is laughable. It's not teaching you VB6 or prior compatible "Visual Basic". And who knows how long the "Visual basic language" it teaches will actually be applicable? Meaning, once they come out with whatever supercedes .NET(or even the next version), and there's a new "Visual Basic language", clearly that book will not entirely apply to a new "VB language".

---

I'm sorry are you saying you expect Microsoft to publish books based on versions of the VB language that they have not yet created? :confused: No this book will not apply to every new version of VB... so when they release a new version of VB they will update or re-write this book.

Quote:

---

Originally Posted by FireXtol

Then there seems to already be differences between versions of VB.NET. This is the same as it was with previous versions(VB6 and prior). Always changing/adding/removing things making incompatibilities between versions.

---

Its called improvement. They very rarely actually remove anything, and the things they remove are removed for good reason... and yes they add things to every new version, to make it better. I really dont see what the problem is. Do you think they should have never changed a thing since the very first version of VB?

Quote:

---

Originally Posted by FireXtol

Regardless of version/IDE/software, they're teaching you "Microsoft's Visual Basic", and that more or less guarantees learners will be using their IDE.

---

How terrible of Microsoft to bring out a book that teaches you Microsoft Visual Basic. Why on earth would they do anything else? Microsoft is a business, not a charity that makes learning material to teach you about their competitors products.

-edit, never mind... -

Quote:

---

Originally Posted by FireXtol

The instructions are specific to Visual Basic 2005 Express Edition. No alternatives are mentioned, besides a text editor. It's clear the book is very much about teaching the reader Microsoft Visual Basic 2005 Express Edition.

---

I think this is a good argument as to why there should be an expiration date posted on all web pages. In some cases, the expiration date would be years out, or even never, but for lots of pages, there would be a finite, relatively short term, date after which the information should be disregarded, or considered historical. There are too many pages, on all kinds of subjects, which were relevant at the time they were produced, but are now just chaff.

Quote:

---

Originally Posted by Shaggy Hiker

I think this is a good argument as to why there should be an expiration date posted on all web pages. In some cases, the expiration date would be years out, or even never, but for lots of pages, there would be a finite, relatively short term, date after which the information should be disregarded, or considered historical. There are too many pages, on all kinds of subjects, which were relevant at the time they were produced, but are now just chaff.

---

Shaggy, I think FireXtol is objecting to the fact that they only mention the Microsoft IDE rather than the version of the Microsoft IDE that they mention.

Look, I'm not sure what you're expecting. It seems a couple of you want to go point for point and into some kind of futile argument/debate/he said she said BS. I'm not interested in answering terribly rhetorical questions that are insulting to even a moron's intelligence.

Shaggy, pretty much, nails it! It's simply a book that teaches you "Visual Basic language" in the exclusive and limited context of "Visual Basic 2005 Express Edition". No more. No less. No creation dates or expirations needed, necessarily.

I don't see how I'm making a big deal out of this. Make of it what you will. It's that plain and simple. Microsoft's transparent attempt to disassociate the two is laughable. I went from a good laugh to wondering what the hell is wrong with some of you.

Oh well, not my problem. :lol:

Quote:

---

Originally Posted by si_the_geek

you do not seem to know about WoW (which allowed 16 bit apps to run on 32 bit versions of Windows [95 to XP]

---

how can someone don't know about this, if this is the only way to run 16b apps on 32b os :)

the WoW is exactly what i was saying.

if you see that vb6 run only in WoW, because there are no more new 32 OS releases,
that means, 32b is dead.
and in that point, you can start worry about the support.

until then, i don't think you need to.

Quote:

---

As for speed, I haven't used those things but I presume the speed could be fine if you are willing to put in a bit of extra effort

---

it's still much slower
and even if you don't (put extra effort to) make it faster, it's just fine for all its users.

As another test of speed, I have a GA that takes a few days to complete. Due to the lengthy run time, a difference in performance between VB6 and .NET would be highly noticeable. If anything, .NET was slightly faster, probably due to better design, since GAs are highly suited to OO design. However, the difference in speed was only a few hours, at best.

If you are seeing a significantly slower performance for audio processing, there is probably a reason for that which is specific to that particular task. I would guess that VB6 was making use of a library that wasn't part of the language, in which case it is equally available in .NET.

Quote:

---

Originally Posted by Shaggy Hiker

However, the difference in speed was only a few hours, at best.

---

I wonder how the different coding methods manage to make a difference in speed when using the GA?

Quote:

---

Originally Posted by Shaggy Hiker

If you are seeing a significantly slower performance for audio processing, there is probably a reason for that which is specific to that particular task.

---

no.
it's not only with audio , it's with every task,
since the .net tech designed to run in an interpreter.

Quote:

---

Originally Posted by whatsup

how can someone don't know about this, if this is the only way to run 16b apps on 32b os :)

---

It isn't the only way. It is the built in and supported way - and also applies to 32 bit apps on a 64 bit OS.

Quote:

---

if you see that vb6 run only in WoW, because there are no more new 32 OS releases,
that means, 32b is dead.

---

No it doesn't. All it means is that the OS itself does not natively run in 32 bit mode.

I use a 64 bit version of Windows, and almost all of the software I use is 32 bit, including many things from Microsoft themselves.

Even if the OS is capable of running 32 bit software (which I expect to be true for the next few versions of Windows, and probably all 64 bit ones [based on Win95 to XP]), whether or not the VB6 runtimes will work properly is not predictable with any certainty - at best you can hope.

Quote:

---

no.
it's not only with audio , it's with every task,
since the .net tech designed to run in an interpreter.

---

It is definitely not every task, I have yet to find one case where it is significantly slower.

In the few cases where I have seen measurable speed differences, they have either been better with .Net, or I checked my code and found that I was using the wrong method - which after a little research was easily corrected to give roughly the same speed (some faster, some slower) as the VB6 equivalent.

In addition to that, Shaggy Hiker (in the post you quoted) gave an example where .Net is noticeably faster, albeit not by a massive percentage.

As such I tend to assume that you didn't put in enough effort to work out what you were doing wrong in terms of speed, and instead are just clutching at an unjustified excuse (have you really compared properly written code for every task?) to blame the tool you used. There is a real possibility that .Net is slower for the task you were doing, but the fact that you didn't get a comparable speed does not make it anywhere near certain.

Quote:

---

Originally Posted by Nightwalker83

I wonder how the different coding methods manage to make a difference in speed when using the GA?

---

What do you mean? Are you asking how a GA can be better implemented using OO such that it speeds up the operation? Frankly, I can't answer that very well, as it has been at least five years since I have dealt with the program in .NET, and even more since I dealt with it in VB6. What I can point out is that a GA is a series of obvious objects: Genes, genomes, and populations. Each level of the GAs that I write has arrays of these (I never use only one population anymore). A population contains at least two lists of genomes, which contain arbitrary numbers and length lists of genes. At the very least, the ability to serialize the whole map would be an advantage, but overall, it has really been too long to be specific.

The other thing that I have forgotten is what I am comparing. I initially moved the VB6 to .NET without turning Option Strict ON. I used LOTS of implicit conversions (the code is small, but a single run is hundreds of thousands of iterations). I believe that my comparison between the two is a comparison with those implicit conversions. When I turned Option Strict ON and fixed all those implicit conversions, it increased the speed by a significant amount (two days rather than three).

So, while I have not directly compared the VB6 implementation to the optimized version of the .NET implementation, it is entirely possible that the .NET is now considerably faster than the VB6. So I don't know if the .NET was about the same or MUCH faster than the VB6, but either way it is a concrete example that contradicts what whatsup was reporting.

Quote:

---

Originally Posted by Shaggy Hiker

What do you mean? Are you asking how a GA can be better implemented using OO such that it speeds up the operation?

---

I always have difficulty understanding how VB6 and .NET can make a difference in speed. However, I guess that it isn't just because of the amount of code there is but also the number of operations that need to be preformed as well as the amount of system resources that are available to be used?

It certainly isn't the amount of code used, since Option Strict ON requires more code, but executes faster. Another example would be that VB6 only allowed for arrays, and they were all essentially fixed size. VB.NET has lists, which are kind of like optimized doubly linked lists (they may actually BE that under the hood). For collections that change size often, static arrays are awkward. Redim, and Redim Preserve can be implemented with some efficiency, but they still make use of some of the slower operations (memory allocation and deacllocation) on the x86 architecture.

Quote:

---

Originally Posted by si_the_geek

All it means is that the OS itself does not natively run in 32 bit mode.

---

sure :D

Quote:

---

they have either been better with .Net

---

that's for sure.
and that's because when MS touches something,
it can even turn an interpreted code,
to run faster than native one.

(at least in some users mind :) )

EDIT: for those who compare speed beteen .NET and VB6,
it isn't relate at all to what i was saying about speed.

what i said is in general, that native code runs much faster than interpreted code.

about vb6, i didn't check.
but if it does run slower than .NET, it can be two reasons:
* you use optimization in .NET, and not in VB6
* VB6 really sucks. - even if this is true, what i don't think,
VB6 app optimized, can run faster than .NET app optimized.

the speed not in all cases, noticable for the user.

but always: .NET app, runs much slower than Native Code app.

NightWalker83:
vb6 app, and every Native Code app, runs much faster than P-Code app,
because P-Code does much more operations for single instruction.
it has to translate every P-Code instruction to machine (Native Code) instruction.

You really need to stop pretending that your assumptions are correct, and instead actually check your facts - because yet again you have made unjustified claims that had already been disproved to the point that you should have very serious doubts.

VB.Net does have shortcomings (as does VB6, and any other language), but it is foolish to make others up based on a lack of knowledge, and even more so to keep on pretending that they must be right because you don't actually know better.


As to the speed comparisons I mentioned, you know me well enough to be in no doubt that both versions were optimised, and they were timed accurately. I find it childish and rather insulting that you would pretend otherwise.

There are reasons for the .Net version being faster for some things (which certainly does not imply that VB6 sucks), and it isn't hard for an experienced programmer to work out what some of them are.

http://en.wikipedia.org/wiki/P-code_machine

Is there even any point in arguing? VB6 is past and .Net is [at least] recent and near future.
People really need to stop comparing two things at once - absolutely pointless.
If someone likes one language vs another go ahead and use but do it quietly.
There are lots of java lovers ... and haters too ... Get over it.

Regards.

ps, I would close this thread...

Quote:

---

Originally Posted by whatsup

http://en.wikipedia.org/wiki/P-code_machine

---

That link would be much more useful if it was relevant. It appears that you have looked at the documentation and missed a key point. .NET, along with some other languages, does create an intermediate language that fits the definition of pCode. However, when the JIT runs, it turns the pcode into machine code...then leaves it there. This means that the initial run of the app can be slower because the JIT is converting the pcode into machine code, but every run after that is faster because the conversion doesn't happen a second time unless the program is changed.

So a .NET program starts out as pcode and then is no longer pcode. That conversion can be performed by other tools such that you don't even take a performance hit the first time you run an app, but with some caveats.

Quote:

---

Originally Posted by Shaggy Hiker

This means that the initial run of the app can be slower because the JIT is converting the pcode into machine code, but every run after that is faster because the conversion doesn't happen a second time unless the program is changed.

---

I don't think that is true... or I'm just not understanding what you mean.

Maybe some of the JIT'd code stays in memory so subsequent runs are a bit faster but I'm pretty sure the actual EXE/DLL file does not get changed at all. For a start, how could programs like Reflector disassemble a .NET assembly even after you have run it a few times if the code is now assembly code? Plus - what on earth would be the point? If the assemblies can work perfectly fine as machine code then why wouldn't the compiler just compile them to machine code in the first place instead of compiling them to IL just for the very first time they are run...

EDIT: In fact the more I think about this the more I am confident that this is not what happens and I would be surprised if that is what you actually meant because it seems such a daft concept.

EDIT EDIT: See the quote in my next post.

Quote:

---

Originally Posted by Shaggy Hiker

However, when the JIT runs, it turns the pcode into machine code...then leaves it there.

---

here i understand that the JIT (which i have no idea what it is)
use cpu cache memory.
nice.

native app can also use it, i guess.

if this is true, (i didn't check this yet)
that only the first pass there is a translation,
.net app can run pretty fast.

unless the exe is a big one, and there's not enough cache for it.

did i understand you correctly ?

EDIT: i just read about this.
good to know that at least there are ways to improve speed.

http://en.wikipedia.org/wiki/Just-in-time_compilation

anyway native code is always better :)

Quote:

---

if this is true, (i didn't check this yet)
that only the first pass there is a translation,
.net app can run pretty fast.

---

As I said in my last post, I'm sure that is not what happens. The .NET code gets interpreted by the JIT compiler every time the program runs. You can use an MS tool called NGen to create a native image of a .NET assembly but very few .NET developers use it.

EDIT: Here's a quote from an MSDN article that clearly states that the code is JIT'd every time a .NET process is launched:

Quote:

---

Originally Posted by http://msdn.microsoft.com/en-us/magazine/cc163808.aspx

As you know, the just-in-time (JIT) compiler is used for compiling the Microsoft intermediate language (MSIL) code in a .NET assembly into native code for the local machine immediately before the code is executed. This is temporary code; it is created and stored in the running processes's memory space, which is reclaimed by the OS when the process dies. Thus, it will be regenerated each time a new process needs it.

---

Native code is not always better, which is why .NET was created. Keep in mind that back when .NET showed up, MS was concerned that Java would run on any platform. This is done by creating an intermediate byte code language, and providing a virtual machine that will take the byte code and turn it into machine language on the architecture of choice. In theory, this would mean that you could write a program that could run on Mac (this was pre-intel Mac, so it was a whole different processor architecture), Windows, Linux, or whatever, as long as there was a virtual machine that could convert the intermediate language to machine language. In practice, this has only been moderately successful for either .NET or Java, but the theory is sound. So .NET came about at least partly out of MS fearing competition from Sun in the dawning internet age. Perhaps one day the promise of "write once run anywhere" will bear out. Alternatively, every other OS might emulate Windows so that it can run Windows apps. Stay tuned.

Ultimately, though, MS did the right thing by having the JIT convert the IL (Intermediate Language) to native, and store it that way, or else the speed really would suffer. In theory, at least, the performance of the program after that first run is entirely dependent on the quality of the JIT. The IL looks very similar to x86 ASM, not in the instruction names, but in the steps taken. Modern C compilers can produce code that is better than all but the best hand optimizers can create, so hand optimization of C code seems to be a dying art. The same might prove true for higher level languages like .NET, as well, especially with the heavy emphasis on parallel processing that showed up in framework 4.0. After all, it is nearly impossible (though not quite) to make full use of multiple processors in a VB6 program. Nor does my GA make use of multiple cores, but if I re-wrote it so that it did, then it would run FAR faster than the VB6 version on my quad core processor, because it runs at least as fast on a single core, and could easily be spread to multiple threads.

Quote:

---

Originally Posted by chris128

As I said in my last post, I'm sure that is not what happens. The .NET code gets interpreted by the JIT compiler every time the program runs. You can use an MS tool called NGen to create a native image of a .NET assembly but very few .NET developers use it.

EDIT: Here's a quote from an MSDN article that clearly states that the code is JIT'd every time a .NET process is launched:

---

That doesn't quite square with the behavior I have seen. However, it is entirely possible that I wouldn't know. The key is that once the JIT has compiled the code to native, it is native code running. Therefore, if you are in a loop, the loop has been converted to native, and is not re-converted each time through the loop, as would be the case for a true interpreted language.

Ah well that's different to what you said originally ;) but yeah, I believe that if you run a method (so it gets JIT'd) then it wont get JIT'd again if you run that same method a minute later... unless you killed the app and launched it again in between.

Quote:

---

However, it is entirely possible that I wouldn't know

---

Yeah I'm afraid I believe MSDN over you :) nothing personal :D

Missed your earlier post entirely, by the way.

It is often the case, in my experience, that the first time I run a .NET program, it has a significant pause on startup that never happens after that. It is so common that it seemed to happen with ALL .NET programs, though I can't categorically make that statement. I always assumed that the JIT was caching the compiled code on disc, and that the pause was the initial JITing of the IL. If that is not the case, I will have to pay more attention to those pauses, to try to figure out why they happen.

If its the first time you have run any .NET application since booting the machine up then there will be a pause, as a lot of the core .NET DLLs (which are quite large) have to be loaded from the GAC for the first time. After that initial loading, some of them remain cached in memory so its quicker the next time you use a .NET app. Other than that its just the same as when you run any program - the first time it always takes longer to load than subsequent times because of the fact that data is cached from the previous run.

Quote:

---

Originally Posted by Shaggy Hiker

Missed your earlier post entirely, by the way.

It is often the case, in my experience, that the first time I run a .NET program, it has a significant pause on startup that never happens after that. It is so common that it seemed to happen with ALL .NET programs, though I can't categorically make that statement. I always assumed that the JIT was caching the compiled code on disc, and that the pause was the initial JITing of the IL. If that is not the case, I will have to pay more attention to those pauses, to try to figure out why they happen.

---

the answer for that is on my link above.

Getting back to the basic (sic) question:

Quote:

---

Originally Posted by ARB_Rauf

Can anyone tell me that VB6 is still in use of programmers because I am going to learn programming as hobby also confused what version learn to start with whether VB6 or VB2008?:)

---

Yes VB6 is still in use.

If you are a hobbiest then learn whichever version you want to. If you have no knowledge of Programming in Basic, then start with a .NET version since they are 'current' (one of the Express Editions which are free, VB6 and previous are not free) Google for examples as and when required or look in the Code Bank here.

Performance and speed are not relevent to a hobbiest, the key thing is the satisfaction of creating something that you have desgned and implemented to solve a given problem. Efficiency and things like speed can come later.

Your first few programs will be (technically) terrible, but as you learn more techniques they will get better.

Have fun, and enjoy yourself creating whatever programs you want to.

Quote:

---

Originally Posted by Shaggy Hiker

That link would be much more useful if it was relevant.

---

I reckon that link was in response to my question not the argument that seems to be taking place in this thread.

Quote:

---

Originally Posted by Nightwalker83

Yeah, but we still have about ten years of Win7 to look forward too.

---

I joined VBForums in 2008 and I had friends tell me it was on it's way out then, so how can it have been released in 2008? Please educate me.

http://support.microsoft.com/lifecyc...&y=10&p1=14498

Extended support date hasn't been published. If you're to go by Windows XP dates (http://support.microsoft.com/lifecycle/?p1=3223) then we can expect 7 to be supported until 2020.

As a side note, 7 went RTM on July 22nd 2009.

Quote:

---

Originally Posted by doramide7

I joined VBForums in 2008 and I had friends tell me it was on it's way out then, so how can it have been released in 2008? Please educate me.

---

I think I already answered the exact same question by Renovator! Anyway, reading post #20 onwards here may help you understand what I was referring to.