Why VB 6.0??

Quote:

---

Originally Posted by WillAtwell

I guess the point I was trying to make is that the Dot Net framework is not the dot net language. It is an API that works with the dot net languages. Just because it has the same dot net in the name does not mean it is part of any of the languages.

---

More than an API, but I agree with you. It is the ENTIRE package that makes it compelling (at least for some).

Quote:

---

As for the language being supported by MS. I have never had any support issue rasied with MS on any program I have written supported or not. If a customer installs software on thier machine that causes something I wrote to stop working then they will be calling me for support and we will work through it.

It is very possible that I will begin to get support calls on Vista machines soon but it really does not matter if MS supports VB or not. The customer is going to look to me for the solution and I will provide it.

Believe it or not I may even write an occasional VBDos program or heaven forbid an old dos style batch file.

---

Different business models work for diferent people/companies, and if this works for you, then that is great. You are well aware of the issues involved.

For my company, it does NOT work. I simply can not afford to have a client's machine crash and cause over $1 million in lost revenue (this actually happened to me in 2002 - fortunately the source of the problem was NOT related to anything my firm did). Nor can I afford to have 3,000 field service engineers all calling me because of problems. The customer(s) will contact my firm, but I NEED the ability to get full support from Microsoft (or any other Vendor that I use) including having their personell willing and able to travel to a customers site (and getting paid well for it!).

My real concern (and the original reason I started this thread), is that I am convinced that the (vast?) majority of people are NOT aware of the "trade-offs" or are making their decisions on incomplete or even downright WRONG information.

The sample applies for people who are learning C++ based on VC++ 6.0. The information they learn is not ISO standard compliant and when they go to get a job it causes problems.

While ramping one of my current clients up earlier this year, I interviewed about 20 candidates for 5 job openings. Most of the positions were at the entry (to low-middle) level. About 25% of the candidates were eliminated specifically because they only had used VC++ 6.0, and had learned poor habits. The overhead of re-training them was sufficient to make other candidates who had a good working knowledge of the standard (e.g. STL TR1) much more desirable.

My heart went out to them, they spent 2-4 years of their life learning something, only to find that it was not a marketable skill....

BTW Last I checked it was possible to undo an update. I think the notion of suddenly being unable to make it work is very very far fetched to say the least. Even my old vb3 apps still work.

Quote:

---

Originally Posted by WillAtwell

BTW Last I checked it was possible to undo an update.

---

Almost all of the automatic (high priority) ones CAN. But a few can not. Also many Service PAcks can NOT.

(emphasis added)

Quote:

---

I think the notion of suddenly being unable to make it work is very very far fetched to say the least.

---

Agreed. But there are cases where (usually minor) changes are required (look ad dglienna's recent issues with CAPICOM!). This can still be a hassle, or worse.

Quote:

---

Even my old vb3 apps still work.

---

99.99% of them will. But I know that VB4.0 fails the full set of QA tests on any XP machine with SP2 installed. The failures are "fringe cases" that are unlikely to impact the vast vast majority of programs, but technically is does not "work" and there were no plans to make any changes to that situation..

Quote:

---

Originally Posted by TheCPUWizard

Almost all of the automatic (high priority) ones CAN. But a few can not. Also many Service PAcks can NOT.

---

There is also a useful practice known as backing up ones system that proves to be quite handy from time to time. The point is that there is always a solution when proper steps are taken and if a company has an operation that could loose millions from a short time offline then they would be a fool not to have redunant systems and fully test any and all updates before installing them on a live system. Not to mention daily backups at the very least.

Quote:

---

Agreed. But there are cases where (usually minor) changes are required (look ad dglienna's recent issues with CAPICOM!). This can still be a hassle, or worse.

---

These minor issues can pop in with a supported language as well.

Quote:

---

99.99% of them will. But I know that VB4.0 fails the full set of QA tests on any XP machine with SP2 installed. The failures are "fringe cases" that are unlikely to impact the vast vast majority of programs, but technically is does not "work" and there were no plans to make any changes to that situation..

---

Yep.. but then again those apps were not written for XP, most were not even written for Win NT yet most of them still work.

On the other hand I developed several apps in dot net for Windows CE devices only to find that none of them work at all on the new version of CE. I had to purchase and install VS 2005 on a seperate computer, convert my apps, change several lines of code then learn the new build procedures just to get a simple app to work on the new OS. I also am forced to maintain the 2003 source and a full environment for it to support the CE 4.x apps which are still in the field.

So far this is the only major issue I have had with dot net but it is one that I have never had with prior versions of VS.

Imagine manager with a POS system that hides his fuctions from employees, that he can't log into anymore. He types any password, and the system crashes with an error. Don't know when they tried it before, though.

Except, the same thing happened to ME in the vb6 ide! Nobody ever heard of the problem, and it is not being supported.

If the employees wanted to break the system, they can, now. I had to support a product that I had quit updating, because of one client...

Here's one small issue with VB6 that i've personally cime across..

A Application that I developed and compiled on a WIN 98 system, failed to run on a XP system. (No API's, No external Dll's, Only a Access DB) However the same executable ran fine on a Win 2000 system..

I re-compiled it on a Win 2000 system (No alterations to the code), and it ran perfectly this time on the XP system (and on Win98)...

What this told me is that backwards compatibility is not guaranteed right back to ver 1..
Sure, almost 50 % of the methods originaly conceived for Windows Ver 1 (earliest windows i got was 3.0) May well still be in the mix, however with each version, they would have evolved to take advantage of the easier/better/faster capabilities of the newer proccessor's. Many simply fall away as they are no longer needed. (How many proc's have full support for 8bit assembly ??)

And soon 16bit will fall to the side too.. (if not already.)

There have been cases when a OS or system has a flaw or bug. Developers wrote there aplications to either get around this flaw, and even take advantage of it..

This biggest Flaw that was taken advantage of (in my opinion) was that of the SID chip on the Commodore 64. (the Audio chip) It has a small but critical flaw, under specific conditions (100% reproducable) the audio output was held High. However Final volume settings could alter this level. Not too long after this 'BUG' was discovered, many Game developers used this method to play a digitised voice.

when the later 'Better' C64 came out, this 'bug' was fixed and the digitised sound no longer worked, (Actually all you got now was a soft scratching sound)

This Flawed chip today is in high demand because is was heralded as a big step in sound technology. (BTW, the Chip designer later developed the sound Blaster cards for PC's)..

Back to topic...

Eventually backwards compatibility is lost, With MS now no longer supporting VB6, they will not make any effort to support it's runtimes in the OS, and no amount of tinkering on your side will enable it to run, as the DLL's, methods, and Functions used in the Runtimes will either not exsist or be altered in some small way that renders it useless to the runtime.

When this happens, All VB6 developers that did not at least learn .NET or other language, will be out of a job.

I agree that it will become unusable at some point but not in the very near future. It look slike at least for the time being Vista supports it and we know XP does.


I also have had at least one project that did not run properly under XP until I recompiled it on an XP machine. To me that is no big deal and the project still worked on win 98, NT, 2k after the recompile. In fact it was actually faster under win2k than it was before.

Quote:

---

Originally Posted by WizBang

OK, I threw together a quick sample. I make little claims as to the optimization, but it looks pretty good to me. I used API calls for most of it, so hopefully the rewrite and thus comparison to .net should be fair. It tiles a bitmap over the form when you click on it, and gives the number of ticks in the TitleBar. So the larger the form, the longer it takes. Since it would normally not take long enough to really be meaningful, I just used a loop to multiply the number of calls to BitBlt. The number of redundant calls is determined by the value in a TextBox, so it can easily be adjusted for the machine it runs on.

Whomever wants to rewrite it in .net, go right ahead, and post the results. Obviously the same machine is going to need to run both versions to make a comparison.

---

I didn't use any GDI with this, I simply did:

Code:

---

    Private Sub Form1_MouseClick(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles Me.MouseClick
            Me.BackgroundImageLayout = ImageLayout.Tile
        Me.BackgroundImage = PictureBox1.Image
    End Sub

---

And it was tremendously quick. Example Attached. With cases such as these, there is no need for API, as .NET already provides that functionality :)

Quote:

---

Originally Posted by Joeman

I suppose I did assume since you never talked about the draw backs on the .net, you just picked up any technology that had microsoft's name on it. I see why the .net is used for servers, but I don't see any app built from the .net that is used for personal computers. This maybe just a time gap, but I don't see most of my major applications built in it. I have a hard time believing that it is ready for my needs. Also your badge from microsoft for major contributions for their product(s) told me you basically will do anything for them. Microsoft Very Important Person. This badge is giving to people who have shown much contributions to their product(s). That only got me more thinking that you would say everything for micosoft even if microsoft was wrong.

---

Have a little respect won't you ¿ Read this again:
http://www.codeguru.com/forum/showpo...&postcount=186

Quote:

---

Originally Posted by TheCPUWizard

How about the fastest possible VB6.0 application that contains NO "declare" statements what so ever....

---

OK, then how about VC++ without any APIs :confused:
Don't understand the logic of that statement :)

Quote:

---

Originally Posted by HanneSThEGreaT

I didn't use any GDI with this, I simply did:

Code:

---

    Private Sub Form1_MouseClick(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles Me.MouseClick
            Me.BackgroundImageLayout = ImageLayout.Tile
        Me.BackgroundImage = PictureBox1.Image
    End Sub

---

And it was tremendously quick. Example Attached. With cases such as these, there is no need for API, as .NET already provides that functionality :)

---

http://forums.codeguru.com/images/ie.../2007/02/1.gif http://forums.codeguru.com/images/ie.../2007/02/1.gif http://forums.codeguru.com/images/ie.../2007/02/1.gif
Very nice Hannes, and you gave us a completely different side to this. there are hundreds of different ways to complete the same task. Each with different advantages, and disadvantages..

Your code thake this quest to a new level, you took the task and gave us a very literal solution. however i'm not sure how comparable this code is to the VB6 API one is..

Yes the set task is done, however your method drop's all the graphics work to the OS, and like CPUwizard said here "If you are going to have the work done by things that are not directly native to the language, then the tests become meaningless"

However I do applaud you for it, as it proves one more point, .NET incorperates a lot more of the OS's native fuctions in an almost invisible manner. VB6 forms and picturebox's dont have the 'Tile & Stretch' capability's built in (unless i never found it?), and require API call's to perform the same task...

Quote:

---

Originally Posted by HanneSThEGreaT

I didn't use any GDI with this, I simply did:

Code:

---

    Private Sub Form1_MouseClick(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles Me.MouseClick
            Me.BackgroundImageLayout = ImageLayout.Tile
        Me.BackgroundImage = PictureBox1.Image
    End Sub

---

And it was tremendously quick. Example Attached. With cases such as these, there is no need for API, as .NET already provides that functionality :)

---

Sure, but to make a comparison, it would need to be executed in a loop, just as in the VB6 code I posted. I can't run your example on this machine, but I'm sure others can, and am quite interested in how the two compare.

But if I chose to make the example draw some sort of unusual pattern, the same in any language would require the same sort of algorithm. However, that is a test of a different nature - where the speed is largely determined by the efficiency of the algorithm (and the runtime), and not so much by the API, or how fast those functions are called. Such comparisons might be a little trickier, since the algorithm will no doubt be more subject to the coding style of the person who writes it. A simple loop is pretty straight forward for any language.

As stated earlier, I'll be putting together something which relies more (if not entirely) on VB itself, rather than API calls.

Okay so i tested hannes' code ..

I had to loop it 1 000 000 times to get 172ms.

Code:

---

        Dim T As Integer
        Dim J As Integer
        Dim I As Integer
        T = GetTickCount

        J = CInt(TextBox1.Text)
        For I = 1 To j
            Me.BackgroundImageLayout = ImageLayout.Tile
            Me.BackgroundImage = PictureBox1.Image
        Next I
        Me.Text = GetTickCount - T

---

and my code looped 49 times to get a comparable time ...!!!!

thats in excess of 20400 times faster :eek: ...

Quote:

---

Originally Posted by GremlinSA

Okay so i tested hannes' code ..

I had to loop it 1 000 000 times to get 172ms.
and my code looped 49 times to get a comparable time ...!!!!

thats in excess of 20400 times faster :eek: ...

---

Well...partially... (without having looked at the full code or any other evaluation)...

The performance is probably based on two distinct factors.

1) The .NET routines are implemented significantly better and at a lower level.

2) The .NET libraries contain alot of "You are asking me to do something I have already done, so I am going to ignore you" optimizations. Better known as comparing existing state to requested state.

To compensate for the second part (which is still a benefit since you dont have to even think about it) re-work BOTH programs to alternate between two different images inside the loop....

..very interested in seeing THOSE results....

Okay so a breakdown so far.

code loops 100 times, on same sized form (Critical)

VB6 - API (Wizbang) = 94ms
VB.NET - GDI (GremlinSA) = 640ms
VB.NET - Std Control (Hannes) = 1.38ms(back calculated from 10000000 loop)

Perhaps we could reopen the Codewar forum's for this task.. ???

Gremmy..

--Edit--
Updated scores..

Quote:

---

Originally Posted by TheCPUWizard

Well...partially... (without having looked at the full code or any other evaluation)...

The performance is probably based on two distinct factors.

1) The .NET routines are implemented significantly better and at a lower level.

2) The .NET libraries contain alot of "You are asking me to do something I have already done, so I am going to ignore you" optimizations. Better known as comparing existing state to requested state.

To compensate for the second part (which is still a benefit since you dont have to even think about it) re-work BOTH programs to alternate between two different images inside the loop....

..very interested in seeing THOSE results....

---

Okay initial testing has revealed you are 100% correct here...
I'm now calculating the results via comparisons..

Most interesting Gremmy :)

I agree that alternating images should give a better idea of performance.

Perhaps the attached sample will help, as it draws boxes rather than tiling an image. Now there's no built-in function of any language to skew results. Only a coded algorithm will do the job.

Quote:

---

Originally Posted by WizBang

Most interesting Gremmy :)

I agree that alternating images should give a better idea of performance.

Perhaps the attached sample will help, as it draws boxes rather than tiling an image. Now there's no built-in function of any language to skew results. Only a coded algorithm will do the job.

---

Gotta love it... YOU select an example.... YOU write the "best" (or at least "standard best practices") implementation.....

Then you say that it is not a good example of "performance".

Because Hannes was able to write a shorter version that did not require knowledge of anything outside the "included" material and performed orders of magnitude faster it is a clear indication that there are distinct benefits to developing in .NET (at least for certain cases).

Here is the results of my testing ...

Note all times are for 1000000 loops ...

Test 1 - Set tile mode only.. = 140
Test 2a - Set Center then stretch = 6942 (Control test)
Test 2b - Set Tile then Stretch = 7020
Test 2c - Set Tile then center = 6615
Test 3 - Set Image only = 78
Test 4a - Set image then nothing = 16849 (Control test)
Test 4B - Set Image 1 then Image 2 = 20998

From test 2 we can deduce a few things, Setting the layout to Stretch takes the longest however, Center and Tile have comparable times. hence setting tile layout time is 3307ms (1/2 of tile-center time)

From test 4 we can deduce that setting the image to nothing is faster than setting the image ( Dah, common sence), and by switching between two identical images (i used two pictureboxes with the same image), the time to set the image is 10499ms

so the time to set tile mode and the image is 13806ms.. (thats for 1000000 loops) do some maths and we get 1.38ms for 100 loops..

all tests done on same size form as the previous two, and as a control both previous sample tests were done before and after again to ensure simmular system responce. (with near identical results)

all the above tests were done a number of times and the best repetitive time was used..

IE: results for 8 runs of test 4 .. :21045,20920,20998,21060,20999,21135,20998,21045
20920 was the fastest however 20998 occured 3 times (20999 included as tick times are updated at 15 - 16ms intervals)

Gremmy..

looking back at the results i forgot why i did test 1 and test 3..

It was a control test to see the time used for the acctual looping..

Hmm so lets calculate it..

Total looptime all included =172ms (previous test)
Test 1 = 140ms
Test 3 = 78ms
Total = 218ms.

218 - 172 = 46ms ..

So the loop overhead is 46ms


However because of the calculations used the loop overhead was canceled out ..

Doing all the calculations over, removing the overhead time, then adding it to the end returns identical results. This was purely by luck, because both our times were halved and added to eachother we did not need to compensate..

Gremmy...

Quote:

---

Originally Posted by TheCPUWizard

Gotta love it... YOU select an example.... YOU write the "best" (or at least "standard best practices") implementation.....

Then you say that it is not a good example of "performance".

Because Hannes was able to write a shorter version that did not require knowledge of anything outside the "included" material and performed orders of magnitude faster it is a clear indication that there are distinct benefits to developing in .NET (at least for certain cases).

---

Not quite. The method Hannes implemented wasn't equivalent to what I wrote, since an object handled the actual tiling, not the code. Consider if it was the VB6 code which used such an object and you had to write the loop in .net. Needless to say it wouldn't be equivalent either, and you'd rightfully be pointing it out.

Now, my second example avoids this. Neither language can simply hand the task to something else to do the work in one shot. Both must loop through and so forth.

Quote:

---

Originally Posted by WizBang

Not quite. The method Hannes implemented wasn't equivalent to what I wrote, since an object handled the actual tiling, not the code. Consider if it was the VB6 code which used such an object and you had to write the loop in .net. Needless to say it wouldn't be equivalent either, and you'd rightfully be pointing it out..

---

No this is the FUNDAMENTAL POINT where we disagree. From a practical standpoiint the issue is to accomplish a goal, by what ever means the selected environment supports (identifying any EXGTERNAL components used) and using the BEST practice for that environment/language.

It is NOT about forcing a specific implementation.

If I gave two developers the task. Write me a program which fills a windows of a specific size with a tiled image, my concerns are (in order):

1) How robust is the program?
2) How maintainable is the program?
3) How long did the program take to write?
4) How long does the program take to run?

As a general rule (with plenty of exceptions) a cleanly written short program is more robust (less chance of bugs), more maintainable (less code to understand).

I also belive that it took Hannes less time to type in and debug the program than it took you to to do the same.

You also had to make use of other material to accomplish your goal.....

And ... oh yeah.... Your program was SIGNIFICANTLY slower...

I would find it very difficult to "sell" your program as a better alternative to Hannes".....

Quote:

---

Originally Posted by TheCPUWizard

No this is the FUNDAMENTAL POINT where we disagree. From a practical standpoiint the issue is to accomplish a goal, by what ever means the selected environment supports (identifying any EXGTERNAL components used) and using the BEST practice for that environment/language.

It is NOT about forcing a specific implementation.

If I gave two developers the task. Write me a program which fills a windows of a specific size with a tiled image, my concerns are (in order):

1) How robust is the program?
2) How maintainable is the program?
3) How long did the program take to write?
4) How long does the program take to run?

As a general rule (with plenty of exceptions) a cleanly written short program is more robust (less chance of bugs), more maintainable (less code to understand).

I also belive that it took Hannes less time to type in and debug the program than it took you to to do the same.

You also had to make use of other material to accomplish your goal.....

And ... oh yeah.... Your program was SIGNIFICANTLY slower...

I would find it very difficult to "sell" your program as a better alternative to Hannes".....

---

The very reason I used a loop was to get a measure of speed at which it would be executed. Even if VB6 had a tile mode, I still wouldn't have used it.

Similarly, if I had copied the image one pixel at a time, that's what I'd want to see done in .net. Using BitBlt is fine when you're writing for money, but it would hardly make for a good comparison in this case. What I (and others) really want to know is how VB6 and .net compare for speed, doing the same work. I'm all for using built-in stuff when appropriate, and IF all I wanted was to tile an image on the form in .net, I'd very likely do as Hannes did. But again, that's not the point. The point is to have some sort of simple code (so those rewriting don't have to spend all day) which takes a measurable amount of time to execute. Otherwise we really don't get a measure of the speed of execution of said code, but that of an object which is obviously operating at a lower level.

Let's see how the second sample goes. I'm sure you aren't going to suggest it isn't a fair test. And unless I miss my guess, .net doesn't have an object to do it all for us. So both implementations will need to actually loop though and do it one box at a time. And no, producing an image beforehand, and simply applying it to the form at runtime would also invalidate the test.

Quote:

---

Originally Posted by WizBang

Similarly, if I had copied the image one pixel at a time, that's what I'd want to see done in .net. Using BitBlt is fine when you're writing for money, but it would hardly make for a good comparison in this case. What I (and others) really want to know is how VB6 and .net compare for speed, doing the same work. I'm all for using built-in stuff when appropriate, and IF all I wanted was to tile an image on the form in .net, I'd very likely do as Hannes did. But again, that's not the point.

---

This is the sticking point with me.

As myself and others have suggested, it isn't about the coding in the same style between VB6 and .Net that matters, it's about getting the equivalent work done. Chances are if you code .Net using a VB6 approach you are likely taking the wrong approach, or at the very least you aren't taking full advantage of what the newer framework has to offer.

Quote:

---

Originally Posted by Arjay

This is the sticking point with me.

---

Exactly.

Quote:

---

Originally Posted by WizBang

... if I had copied the image one pixel at a time, that's what I'd want to see done in .net. Using BitBlt is fine when you're writing for money, but it would hardly make for a good comparison in this case. What I (and others) really want to know is how VB6 and .net compare for speed, doing the same work.

---

I suppose we could draw each tiled object a bit at a time, but we could also run each in a separate thread, which would be faster?

I think it's obvious.

Quote:

---

Originally Posted by dglienna

I suppose we could draw each tiled object a bit at a time, but we could also run each in a separate thread, which would be faster?

I think it's obvious.

---

Using one thread per pixel? ;)

per tiled object...

For deciding on a platform for application development you have to look at the EXTERNAL requirements and constraints, and then base it on the following (which is an enhanced version of my previous list)

0) Does it met the requirements?
1) How robust is the program?
2) How maintainable is the program?
3) How long did the program take to write?
4) How long does the program take to run?

Where "priority 0" HAS to be met.

ANY other approach is at best a "poor decision making process" and at worse malfeasance

Quote:

---

Originally Posted by TheCPUWizard

the EXTERNAL requirements and constraints

---

That depends on when they were written, and whether you intend to support the NEW project for xxx years...

Quote:

---

Originally Posted by dglienna

That depends on when they were written, and whether you intend to support the NEW project for xxx years...

---

Agreed... :wave:

I would presume that the requirements were written shortly before the selection of a platform, and that any non-"throw away" program will be in use for at least 1-3 years.....

Quote:

---

Originally Posted by Arjay

This is the sticking point with me.

As myself and others have suggested, it isn't about the coding in the same style between VB6 and .Net that matters, it's about getting the equivalent work done. Chances are if you code .Net using a VB6 approach you are likely taking the wrong approach, or at the very least you aren't taking full advantage of what the newer framework has to offer.

---

What about the indication made earlier about not using apis in VB, using only the native VB6 functions and only the VB6 documents vs all of the dot net documents and framework.

This would result in an unfair test. VB.net is one component of VS dot net just like VB6 is one component of VS6. If we were to use all the documention for dot net then we should also be able to use all the documentation for VS6 which includes the apis.

Also testing for speed in graphics as the primary test is more slanted toward dot net. This was never the strong point in VB unless apis are used.

Quote:

---

Originally Posted by WillAtwell

What about the indication made earlier about not using apis in VB, using only the native VB6 functions and only the VB6 documents vs all of the dot net documents and framework.

This would result in an unfair test. VB.net is one component of VS dot net just like VB6 is one component of VS6. If we were to use all the documention for dot net then we should also be able to use all the documentation for VS6 which includes the apis.

---

Some valid points there, no question. There are MANY different comparision sets that are available and different ones apply to different situations.

So far, this thread has been about versions of Visual Basic, and NOT about Visual Studio. (I have had similar threads with VC++ 6.0 - but that is primarily about the fact that that compiler was notoroiusly non-compliant with the ISO standard)

So, I would put forth that the valid comparision is to either install a VB specific SKU, or to do a FULL install of just the VB Component of Studio onto a "fresh" Windows Install. The capabilities of this configuration would be an "apples-apples" compare.

A comparision of what you can accomplish using Visual Basic as your primary tool, but leveraging additional material (for both versions) is also a valid comparision, but I think we can all agree that it is a DIFFERENT comparision.

The same is true for comparing implementations. It is important to know that certain techniques which are optimal for one environment are poor for a different environment. But this is a difference in HOW you accomplish a goal, and is almost never a good measure of how EFFECTIVELY the goal CAN be implemented (using the metrics from my previous posts.

Quote:

---

Also testing for speed in graphics as the primary test is more slanted toward dot net. This was never the strong point in VB unless apis are used.

---

I was never the one to propose graphics as a primary of even seconday test. With the exception of Game Development, the majority of applications use very little graphics, and where graphics are used, the performance demands are typically very low. I would guess-timate that of all the (non-game) programs written (commercially) in the past decade that well under 10% of them had graphics capability as the primary focus.

Looking back over this thread (after removing the diatribes and diversions) there is actually A LOT of very good information.

Yes, vb6 wasn't about graphics speed. Even if you were wanting graphics speed, you would have known to use apis, opengl, or directx( in any language ). Using bitblt is fine when you only doing simple 2d stuff, but I would used getdibits if you render it more than once.

Vb6 fully supported apis. It even came with an api viewer just for vb6. So that tells me that vb6 supports the use of apis.

The .net is your "api" and although it does have the ability to use "external" apis, this is not what the .net is used for and it is discouraged. It is "bad" programming unless you have to do such a thing and which case you shouldn't have to.

All the .net examples are cheap shots. Perhaps I will come up with a more qualified program, but this can't be done in one day or one setting :(.

Perhaps I will write it in c++ and vb6. I now what one will win from those two ;)

I suppose I will get started, but I don't know how much I will get done :(. I will use some of my previous work to get more done faster.

Quote:

---

Originally Posted by Joeman

Vb6 fully supported apis. It even came with an api viewer just for vb6. So that tells me that vb6 supports the use of apis.

---

No one has ever said that VB6.0 (and 5.0 and 4.0 and ) didn't SUPPORT external API's. But using them is not "programming IN VB"

The API Viewer was a direct result of this (I used it often). Since VB did not know that the proper parameters were for an external API, it was quite common to have bugs (often missing or overusing ByVal). And EXTERNAL tools was required to get this information.

Another way to look at it is to take a machine which has NO VB on it and another which has NO .NET on it.

Now install VB6.0 on the first and look at the items that were added to the machine.

Then install VB.NET on the second and look at the items that were added to the machine.

These file lists make up a very reasonable definition of "what is included with the language".

Instead of trying to come up with comparisions (especially since you have previously posted that you have only limited experience ( <6,000 hours or 3 years full time) with both C++ and .NET, why dont you just come up with a "requirements document" for a sample operation. Then let people who are at all different skill levels with with each environment implement the requirements using the best techniques. Let the results be rated based on the qualifications I gave earlier.

This is really the ONLY way to do truely valid comparisions of the overall advantages that are achieved with a given platform.

It would be really great if this could be done at (or near) some major conference. Make it a competition with each environment having teams in four different experience levels. Set it up so that the task must be worked on by a team of 3-5 people, and the results subjected to both performance and quality reviews.

I am resonably confident (would place a decent amount of money) on the following two results:

1) On average for a given skill set level, the .NET teams would turn in higher scoring solutions

2) On average there would be a smaller gap in scores between novice and expert for .NET, with VB 6.0 being a fairly close contender. C++ would have the largest differential.

Quote:

---

Originally Posted by TheCpuWizard

No one has ever said that VB6.0 (and 5.0 and 4.0 and ) didn't SUPPORT external API's. But using them is not "programming IN VB"

---

That is incorrect. You can use any api that language gives you with libraries, activex files, dlls or whatever. If you can type it in vb6 and it compiles, you wrote that in vb6. Now if you want to say otherwise, fine.

I suppose I can't get an opengl control for vb6, use it and say I built it in vb6? What did I build in it? If you want to restrict users that use vb6 from what is giving to them by mircosoft to use so they can do what they want with them because you want to say that your not programming in vb with apis is weird. Anyone knows that if the language support these so called apis, you are programming with those apis in that language.

Now for my experience part. So what. I have to learn somehow and I personally think I am making good progress. Sure my code isn't special, but noones is when they are just starting.

I guess I will post my work. I will create another new project if I feel like it.

I am sure you will bash it in the .net if you keep calling using apis in the vb6 not vb6.

There are 2 methods:
1 is using point by point
2 is using apis which you probably not going to beat unless you use some 3d accelerated app. We will see.

I will port this to c++ if I want to. I suppose I can't use apis in c++ since it willl make my c++ code turn into another language.........

I included the exe that is compiled for people who do not have vb6. If you don't trust running it, dont.. just recompile it. Also really do compile it and don't run it in p-code. The first method is the slowest.. you have to wait.

So now you know what I want you to do in c#

One more thing about my project. I didn't get finished with the last method. I was going to send all the rotated images back into an array of 360 so the processing of rotations are finished and rotate the finished images again to compare the difference.

for ex in peusdo code

images = rotate360()
for i = 1 to 360
render(image[i])
next i

Well, my only comments at this point are:

Suppose two people are to race around the block on foot. Part way through, one guy hops on a bike, just because it was there. He gets to the finish line and declares himself the winner.

Was the race fair? After all, he got to the finish line first, and that's what counts, right?

Obviously, to truly know which person is faster, both need to take the same course by the same means. They may not have the same footwear, but both will be on foot. No performance-enhancing drugs, no cutting across lawns. It is after all a contest, so simply getting to the finish line isn't the point. Contests aren't about real-world scenarios, otherwise they wouldn't make those runners in the Olympics jump over a bunch of hurdles or make the skiers zig-zag around flags. Hitting a golf ball into a hole or knocking down bowling pins are intentionally challenging. The constraints are by design, and nobody is supposed to cheat.

Some recent comments suggest that VB6 isn't particularly suited for heavy graphics. I never claimed it was, but I wonder what it means that the .net rewrite Gremmy posted was far slower. But enough about that...

My second code sample should be a fair test, so I'm very interested in seeing the results any rewrites of it in .net.

Still missing the point.

The race isn't about racing on foot, it's about getting to the destination (i.e there are no limits on the mode of transportation used).

If you were racing on foot, and there was a bicycle, an automobile or a taxi available to help you get to your destination, wouldn't you want to use one?

Maybe for a small race (i.e a small utility application), you would choose to still remain on foot.

What about a larger 1500 mile race (a large application that interacts with other applications)?

Would you still remain on foot?

Perhaps in some specialized cases, like racing up a wooded area, racing on foot would be faster; however most of the time (and especially on longer races) a bicycle or automobile will get you to your destination faster.

Quote:

---

Originally Posted by Arjay

Still missing the point.

The race isn't about racing on foot, it's about getting to the destination (i.e there are no limits on the mode of transportation used).

---

So I take it that you disagree with the restriction that was placed on VB6 about using apis?

Quote:

---

If you were racing on foot, and there was a bicycle, an automobile or a taxi available to help you get to your destination, wouldn't you want to use one?

---

No. If I was racing on foot then that would indicate that I was supposed to remain on foot. If I got on a bike I would be cheating and would get disqualified.

Quote:

---

Maybe for a small race (i.e a small utility application), you would choose to still remain on foot.

What about a larger 1500 mile race (a large application that interacts with other applications)?

Would you still remain on foot?

---

Who would enter a foot race of 1500 miles?

Quote:

---

Perhaps in some specialized cases, like racing up a wooded area, racing on foot would be faster; however most of the time (and especially on longer races) a bicycle or automobile will get you to your destination faster.

---

The point is that if you let one racer use a race car and force the other to run on foot in wooden shoes it is not a valid contest.

Quote:

---

Originally Posted by Arjay

Still missing the point.

The race isn't about racing on foot, it's about getting to the destination (i.e there are no limits on the mode of transportation used).

If you were racing on foot, and there was a bicycle, an automobile or a taxi available to help you get to your destination, wouldn't you want to use one?

Maybe for a small race (i.e a small utility application), you would choose to still remain on foot.

What about a larger 1500 mile race (a large application that interacts with other applications)?

Would you still remain on foot?

Perhaps in some specialized cases, like racing up a wooded area, racing on foot would be faster; however most of the time (and especially on longer races) a bicycle or automobile will get you to your destination faster.

---

By that reasoning, they should let participants in the Tour de France drive cars, just because it's faster.

By that reasoning, someone attempting to solve a Tower of Hanoi game should just pick up all the disks at once and set them on another rod.

By that reasoning, when playing Monopoly, players should put aside the dice and just move their pieces wherever they want to go.

By that reasoning, both teams in a football game should have their own ball, so they don't have to fight over it. That way both teams can each make as many touchdowns as they want. It's easier that way.

Is this code:

Code:

---

X = 0
For I = 1 To 10
  X = X + 1
Next

---

Equivalent to this code?

Code:

---

X = 10

---

The end result is the same, but the work they do is most certainly not. So if we use a loop such as that to test the speed, you can't just set the value of X and claim it did the same thing faster.

Quote:

---

Originally Posted by WizBang

By that reasoning, they should let participants in the Tour de France drive cars, just because it's faster.

By that reasoning, someone attempting to solve a Tower of Hanoi game should just pick up all the disks at once and set them on another rod.

By that reasoning, when playing Monopoly, players should put aside the dice and just move their pieces wherever they want to go.

By that reasoning, both teams in a football game should have their own ball, so they don't have to fight over it. That way both teams can each make as many touchdowns as they want. It's easier that way.

---

Again the point is missed.

We are talking about a contest where the only rule is that you have to arrive at the destination and the one who arrives fastest is the winner.
How you get there is up to the contestent.

In a contest like this, the details of the method of transportation are not important.

Quote:

---

Originally Posted by WillAtwell

So I take it that you disagree with the restriction that was placed on VB6 about using apis?

No. If I was racing on foot then that would indicate that I was supposed to remain on foot. If I got on a bike I would be cheating and would get disqualified.

Who would enter a foot race of 1500 miles?

The point is that if you let one racer use a race car and force the other to run on foot in wooden shoes it is not a valid contest.

---

I'm not talking about racing on foot - THIS IS THE POINT.

Don't restrict yourself to racing on foot.

The contest is wide open - if you have another mode of transportation, use it if it helps.

Don't bother comparing the details of the transportation in a contest like this. Does a preference of nylon laces on running shoes matter if the contest allows the use of automobiles?

I don't care if one framework uses api's (either internally or externally). What I do care about at the end of the day is how much code I need to write and how much knowledge I need to have to write the code. I'm going to take the easiest way to get to the destination - every time.

Quote:

---

Originally Posted by Arjay

Again the point is missed.

---

That's my line!

Quote:

---

Originally Posted by Arjay

We are talking about a contest where the only rule is that you have to arrive at the destination and the one who arrives fastest is the winner.
How you get there is up to the contestent.

---

Does this mean that rather than tiling the image via code, I can tile an image in an image editor, and simply apply the results of it to the form at runtime?

Does this mean we should set X = 10 rather than incrementing it up to ten in a loop, and claim it is equivalent?

Quote:

---

Originally Posted by Arjay

I don't care if one framework uses api's (either internally or externally). What I do care about at the end of the day is how much code I need to write and how much knowledge I need to have to write the code. I'm going to take the easiest way to get to the destination - every time.

---

Don't you mean the way which results in the fastest execution? If so, then how do you know it's faster unless it also does the same work along the way?

No matter. I can see the last several posts are getting us no closer to what we want to know. We can post back and forth forever, but actual test results on a .net rewrite of my second code sample are still forthcoming.

Feel free to rewrite my second example in .net. As of yet, nobody has stepped up to the challenge.

There are all sorts of different comparisions. And they all indicate different things. (As I have said before).

The main reason I have taken the standpoint I have is, that if you were to port VB 6.0 to another platform (non-Windows), the API's are specific to Windows, and therefore any code which used the API's would not function on the new platform.

On the other hand, when .NET HAS been ported to other platforms, the entire framework is ported. So any C# or VB.NET program (that does not use PInvoke) WILL function on the new platform.

THe same principal applies even for upgrades. When a new version of an OS is released (and potentially at any Service Pack), new functions may be added (with the old ones still available).

If you coded in VB6.0 (using "declare") then you have to MODIFY YOUR PROGRAM.

If you coded in .NET, the new version of the framework can include these changes (this happened between 1.1 and 2.0 and again at 2.0 to 3.0). This means that your new program makes use of the new OS functions WITHOUT MODIFICATION (or even re-compilation!!!).

THIS IS A HUGE DIFFERENCE.

So the only way to factor this out is to restrict usage to those items that SHIP WITH the item being evaluated, and for VB6.0 this effectively eliminates the use of external API calls.

Okay I step out for the day, and the conversation goes to s***.

The whole point here is to compare the VB6 CORE to the VB.NET CORE..

I.E. the foot race, lets put two guy's at the start line, One uses 'Nike' trainers, the other 'Adidas' trainers. Now jumping onto a bike or into the car does not help us to see what pair or shoes are better..

This test is not about finding the fastest way to complete the given task, its not about best practice, it's about CORE speed. We want to see how does VB6 and .NET compare on identical methods, or near identical code..

@Wizbang: I'm a little busy, however i will be doing some code during the weekend to compare to the new VB6 Code..

@CPUWizard: You are right in saying using API's is not programming IN VB, Using API's is passing the task's back to the OS. However this subject is very touchy..

@Joeman: When writing a App in VB, using any external DLL, API, Library is not 'TRUE' VB code and is acctually a hybrid. If the DLL was written in C then your proggy is VB & C mix, Not 'True' VB..

@Arjay: If the point of this test was about getting the equivalent work done, then .NET won it hands down. However this same code, did not do the equivalent work, It did no work, it passed ALL the work to the OS.

Quote:

---

Originally Posted by TheCPUWizard

The main reason I have taken the standpoint I have is, that if you were to port VB 6.0 to another platform (non-Windows), the API's are specific to Windows, and therefore any code which used the API's would not function on the new platform.

On the other hand, when .NET HAS been ported to other platforms, the entire framework is ported. So any C# or VB.NET program (that does not use PInvoke) WILL function on the new platform.

---

I agree with this, but wouldn't I likely know ahead of time if I'm going to be porting it? So let's just say for the sake of argument, that the examples I posted are not intended to be ported to any other platform. Since windows seems to have such a large market share anyway, I figure I can focus my efforts there, giving up a few extra customers in favor of an app that is more appealing, because I can get that added performance using API. If my app is better optimized, that'll bring in more sales too. Besides that, if I'm using VB6, then by default I'm not porting (though there's Mono and other stuff out there to make it possible, not to mention RealBasic, which imports VB6 code, and is portable).

Just the same, I am planning to put together an example of something which just runs some time-intensive algorithm or something like that. Maybe even just a big loop. But first I want to see the .net rewrite of my second example. No sense uploading a bunch of stuff nobody is willing to test.

Quote:

---

Originally Posted by GremlinSA

The whole point here is to compare the VB6 CORE to the VB.NET CORE

---

As the starter of the thread, dont I get any input in what MY intentions were for starting it??? :confused: :confused: :confused: :confused: :confused: :confused: :confused: :confused:

At best, "core speed" is a 4th order concern. Even when I am doing "true real time" (Missle Guidance, Ion Beam Control, etc), as long as the code runs fast enough to meet the specification (+ a safety margin), then I do NOT do anything to optimize the performance.

What has kept my company in business since 1984 (and having used nearly EVERY language/platform combination over that time) is being able to write the most COST effective code. This means reliability, maintainable, and ease of development.

Now if it could be shown that VB.NET has significant (orders of magnitude) performance issues over VB 6.0 then it would potentially indicate that it would not be a "good choice" for many situations. However, this is not the case. In fact, the performance article I am writing (links previously posted to a partial first draft) show that (properly used) VB.NET can and does achieve performance metrics suprisingly close to native C++.

Since mearusring development effort between people working remotely and asynchronously is virtually impossible, the best one can typically do is to use an approximation of code complexity. In general a larger more complex program took longer to write than a (much) shorter counterpart. Also when person Y has to maintain code written by person X, the size of the program can roughly correleate to the amount of time Y will have to spend analyzing the program before there is good understanding.

Along the same lines, using multiple technologies is indicative of a program being "more complex". If I were to poll 25 "super expert VB6.0 developers", I am sure that all of them would have used external API's to some degree. If I then asked them to list the top 20 they used, I am equally confident that there would be some calls that some of the other developers had never even heard of.

If I have a custom program that uses (arbitrarily) 50 API calls, I will almost certainly have to engage multiple "expert VB 6.0" programmers (who individually know 100% of VB 6.0 itself.

On the other hand, if I have a program written in .NET, and have 1 person who knows 100% of .NET, then that ONE person will have a working knowledge in everything used in the program.

Now I am the first to admit, that finding someone who has actually studied the Framework libraries from start to finish is difficult. It took me about 2 years (part time) to go through EVERY class in 1.x, about 9 months for 2.0, and about 3 months for 3.5.

I agree that this subject is "touchy" and does raise peoples emotions. I also enjor vigorous (informed) debate. But I do find it very fustrating (and anoying) when people pontificate on a subject (not just .NET or even computers) when they have not personally made a detailed study of the subject.

Quote:

---

Originally Posted by GremlinSA

This test is not about finding the fastest way to complete the given task, its not about best practice, it's about CORE speed. We want to see how does VB6 and .NET compare on identical methods, or near identical code..

@Arjay: If the point of this test was about getting the equivalent work done, then .NET won it hands down. However this same code, did not do the equivalent work, It did no work, it passed ALL the work to the OS.

---

Very succinctly put.

Quote:

---

Originally Posted by Arjay

I don't care if one framework uses api's (either internally or externally). What I do care about at the end of the day is how much code I need to write and how much knowledge I need to have to write the code. I'm going to take the easiest way to get to the destination - every time.

---

(Emphasis added)
If you had Two people with NOT knowledge of VB (and flavor), .NET (any language), or WINDOWS....


Person #1
You go to a class where they teach you EVERYTHING about VB6.0. This would obviously include the usage of "declare" statements, but it would be a different course that taught you all about the Windows API's (and even more courses for other API's, possible by different training organizations)

Person #2
You go to a class where they teach you EVERYTHING about .NET (using only VB.NET s the programming language - no mention of C#, C++/CLI, etc)


Now you have a requirement for a custom program. You need to quickly, you need it to be very reliable. And you need it to meet some (fairly tight) performance specifications....

Which developer would you choose????

Quote:

---

Originally Posted by TheCPUWizard

As the starter of the thread, dont I get any input in what MY intentions were for starting it??? :confused: :confused: :confused: :confused:

---

Sorry this is the part of the thread that Wizbang and myself hijacked, when it came to point of Speed comparison.. ;) :p :wave:

Quote:

---

Originally Posted by TheCPUWizard

At best, "core speed" is a 4th order concern. Even when I am doing "true real time" (Missle Guidance, Ion Beam Control, etc), as long as the code runs fast enough to meet the specification (+ a safety margin), then I do NOT do anything to optimize the performance.

What has kept my company in business since 1984 (and having used nearly EVERY language/platform combination over that time) is being able to write the most COST effective code. This means reliability, maintainable, and ease of development.

---

Fine for you, and your business. I'm glad you've got a model that works for you. But again it isn't about cost here, nor ease of development, but it IS about comparing performance. That is one of the issues raised in response to your question of why VB6. So yes, expect the code posted to do more than just get by, since it is performance which is being compared.

Quote:

---

Originally Posted by TheCPUWizard

If I have a custom program that uses (arbitrarily) 50 API calls, I will almost certainly have to engage multiple "expert VB 6.0" programmers (who individually know 100% of VB 6.0 itself.

---

That is assumption, not fact. Plus you aren't going to know how many API calls (nor which ones) the program will use until it's completed.

Quote:

---

Originally Posted by TheCPUWizard

On the other hand, if I have a program written in .NET, and have 1 person who knows 100% of .NET, then that ONE person will have a working knowledge in everything used in the program.

Now I am the first to admit, that finding someone who has actually studied the Framework libraries from start to finish is difficult. It took me about 2 years (part time) to go through EVERY class in 1.x, about 9 months for 2.0, and about 3 months for 3.5.

---

I'm sure you still look things up from time to time, just like a VB6 programmer who uses API. Just like any programmer, period. With experience, the time it takes to refresh one's memory, or look something up is probably greatly reduced.