Why VB 6.0??

Quote:

---

Originally Posted by WizBang

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.

---

No the question was WHY.

Quote:

---

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.

---

Performance is one metric out of many. And it really only matters at the "external" level. Consider a button click. The tightest specification I have ever seen for a response time is 100mS. So if one program takes 200mS and another takes 75mS it matters. But if one takes 75mS and another takes 7.5mS the difference is unimportant.

Quote:

---

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.

---

To some degree. But it is NOT a "wild guess" or arbitrary. If you have read my posts on other threads, I am a fig fane of re-use and of "isolation". As a result I have a set of VB6.0 classes in my archives that mbodied all of the API calls that I used over a 5+ year period of developing in VB. After excluding "speciality" cases (eg wrappers for a specific custom device), I countes 137 distinct API calls. I then looked at 4 projects that happened to still be online (each needed maintenance in the past 6 months). The number of distinct API invokactions ranger from 37 to 71.

Quote:

---

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.

---

I happen to have near eidetic memory (especially for technology, but lousy at names.. :eek: ). Clients will often contact me about details of a program I did well over a decade ago, and I can still recall the specific classes and methods. But it is not about how I or any other developer happens to work.

What I would use as an indicator in this area (for this topic), is how many times do you have to uses something outside the IDE (after all the "I" is for integrated) to get the information you use.

Quote:

---

Originally Posted by GremlinSA

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

---

Not a problem as long as it is recognized that performance
(including different sets of "usable technology") is simply one of many things that should make up an answer to "Why?"

And, as I posted a few minutes ago, that the impact of performance differences is used as the qualifying value and not the "raw" performance.

If I had $1 for every embedded system I have seen where a DEDICATED system has been written using obtuse had to understand (often buggy) code in the name of "performance", only to find that the main loop spends 30% of the time running the code...followed by a "sleep" that counts for the remainder of the time. :eek: :eek:

Quote:

---

Originally Posted by TheCPUWizard

Not a problem as long as it is recognized that performance (including different sets of "usable technology") is simply one of many things that should make up an answer to "Why?"

---

Sure, And it truly is, there are many aspects to this question, and also a lot more answers than available in the poll.

We just trying to expand a little on some of the reasons given, offer some proof, debunk some assumptions.

Quote:

---

Originally Posted by GremlinSA

Sure, And it truly is, there are many aspects to this question, and also a lot more answers than available in the poll.

We just trying to expand a little on some of the reasons given, offer some proof, debunk some assumptions.

---

Complete agreement here :wave: :wave: :wave: :wave:

I should have added two more (I dont think I can go back now, and even if I did, the results would already be skewed) choice of:

1) There is a TECHNICAL reason I continue to use my licensed (but unsupported) VB 6.0

2)There is a BUSINESS reason I continue to use my licensed (but unsupported) VB 6.0

The reason why you use the .net is because it works for you. Fine, but it won't work for all of us. Now let's not forget about security in the business field again. TheCpuWizard promised some sort of article or post on how to protect the exe.

Here is a funny hypothetical metaphor.
You people started speaking in parbals so I did one too.
Suppose I was 20,000 feet up and jumped out of a plane just to hit the ground. Does it matter what languaged I used?

Not unless it was *you* that were jumping.

Quote:

---

Originally Posted by Joeman

The reason why you use the .net is because it works for you. Fine, but it won't work for all of us. Now let's not forget about security in the business field again. TheCpuWizard promised some sort of article or post on how to protect the exe.

---

Yes I did, and I am working on it. Getting something that IS secure (at least as secure as any natively compiled C++ program) but does NOT reveal some of the details I actually use [and especially does not release NDA material] is proving to be more time consuming than I planned.

For those who are interested in the technique, look at http://etutorials.org/Programming/.N...CLR+Execution/

It nicely explains how to replace both the JIT compiler and the class loader.

With this a program (such as the sample I am working on) can function according to the following process

1) Write conventional .NET code in the language of your choice to create a managed assembly (.dll)

2) Use a translator/encryptor so that the byte patterns are NOT standard MSIL. This will completely block the use of any existing tool as the file is NOT MSIL.

3) Write a custom CLR Loader and JIT Compiler that knows about your encrypted/translated format.

4) When you run the program, the memory pages are locked down so that other "normal" processes do not have "READ" Permission and the Custom Loader/JIT compiler is used to process the assembly.

The result is that MSIL never exists.

A minor variation on this aproach IS commercially available. You can purchase a license for a "Custom IL" that only your program will use.

The commercial alternative is NOT cheap. But if you have a legitimate concern that someone reverse engineering your code may cause you serious financial problems, then it is certainly a viable way to go...

Quote:

---

Originally Posted by Joeman

Here is a funny hypothetical metaphor.
You people started speaking in parbals so I did one too.
Suppose I was 20,000 feet up and jumped out of a plane just to hit the ground. Does it matter what languaged I used?

---

That depends on two primary factors:

1) Are you jumping with someone (who intends to survive)
2) Do you have any "Last Wishes".

If both of the conditions above are met, then you should probably use a language the other person understands..... ;) :D

Have to know the language you speak, to both, get you to stop, and also, contact your next-of-kin...

very funny answers, but really when you go "splat" was the last few words you spoke mean anything? Now if someone show this happen, now that would be a horrible incident. It would mean nothing to the person the went "splat". Isn't that obvious? lol. He can't recall the moment.

Ok on the serious side.

Interpretation for coders
This is to if your code is used by people that are living and your dead. Does what they do with your code matter to you now that you can't think/process anything? If you answer is yes it does, try thinking/processing nothing which is just impossible. Even when you sleep, your brain is processing.

My point is vb6 may seem old to you and isn't a wise ideal to use because it isn't supported and/or old, others may not even care about this. I don't because of 2 things:

1. vb6 still runs fine
2. it meets my needs just fine

While I understand you're trying to covert msil to a non-standard encrypted version, that only masks the real problem and that is msil does exist. If you can protect it, perhaps it is good enough, but why won't .net simply compile with no jit strings attached and let the distributor decide if he wants to use msil so he won't be forced to use it. This is what vb5 and vb6 done from my understanding. This is what I want/need in the .net. For performance issues, I could make work arounds. If the workarouds can't be done, that is a different story.

If you really want vb6 to fade away, you have to give people another language they find equivalent and the .net can be it if, and only if, these are met:

1. It is the same speed or faster
2. Compilable to native
3. Able to turn off error checking for performance
4. have 100% equivalent win32 apis built in the .net
5. be a very well known language used for their needs.

These are what is stopping vb6 users to go to the .net successfully in my opinion.

If I had to program in the .net, I would find it rude and offensive to have to call out of my own development environment(.net framework) to do something I needed/wanted to accomplish if that language recommends to stay in the development environment.

Quote:

---

Originally Posted by Joeman

1. vb6 still runs fine
2. it meets my needs just fine

---

As I have said (to WizBbang) if it works for you, and you understand the support situation, then there is no problem. Where I have a problem is where people (including you as in the replies above) make statements without having any facts to back them up.

Quote:

---

and that (the problem) is msil does exist.

---

I fail to see how that is a problem. A recent Gartner Group study indicated that the ration of MSIL to Native code in commercial programs is rapidly increasing. Without it, you simply can not do things like distribute a single version of your program and have it run as an x86, x86, or IA64 executable. Even within those families the JIT capability allows the program to use the optimal instructions automatically.

If you were programming back in the 1980's you would remember all of the problems dealing with mathematical programs that had to run on DX (hardware floating point) and SX (software only floating point). It was a bloody nightmare deciding to pick one (limiting your audience with HW, or limiting your performance (always using SW) or using an "auto-detect" mechanism which ran slower on both platforms since the decision was made at every floating point operation.

Having an intermediate language (FYI "IL" is an industry standard, "MSIL" is microsofts specific implementation of that standard), completely eliminates this as the generated executable code (by the JIT) would always be optimal for the platform is was running on.

Quote:

---

If you really want vb6 to fade away, you have to give people another language they find equivalent and the .net can be it if, and only if, these are met:

1. It is the same speed or faster
2. Compilable to native
3. Able to turn off error checking for performance
4. have 100% equivalent win32 apis built in the .net
5. be a very well known language used for their needs.

These are what is stopping vb6 users to go to the .net successfully in my opinion.

---

In the following comments the terms "nobody" and "anybody" include everyone I have dealt with in the past 7 years, including some of the worlds best VB programmers (one who helped form the language), VB user groups), etc...

1) Nobody has shown me a requirements document and a VB (4,5,6) implementation of that document that could not be implemented in .NET with equivilant performance.

2) If performance is not an issue, and there are security mechanisms for those cases (which I still believe to be fairly rare) where the incremental ease in reverse engineering matter, then there is no problem.

3) See #1. If the performance can be met WITH the safety checks (realize that over 80% of successful attacks are because of buffer overruns, stack faults, or other items that can not occur with the checks that .NEt provide), then this is a non-issue; unless you like to make your programs easier to infect...

4) This means that programming on Mac, Linux, Mainframes are all "useless"...They dont have "100% equivalent win32 apis". So far I have not found a case where a direct call to Win32API has been a necessity in implementing a program, but if I ever do, then PInvoke provides 100% identical functionallity to VB6 "declare".

Quote:

---

If I had to program in the .net, I would find it rude and offensive to have to call out of my own development environment(.net framework) to do something I needed/wanted to accomplish if that language recommends to stay in the development environment.

---

(emphasis added)
You never have to use the supplied libraries. If you want/need a specialized implementation you can always write it. If you want/need to access something from a different environment, you can. Of course this is just adding work for the vast majority of cases where the provided (extensive) library provides all of the functionallity..

Quote:

---

Originally Posted by Joeman

Here is a funny hypothetical metaphor.
You people started speaking in parbals so I did one too.
Suppose I was 20,000 feet up and jumped out of a plane just to hit the ground. Does it matter what languaged I used?

---

To be fair, for this comparison to work.. It depends on the type of parachute you used...

1) A old one, that the manufacturs will no longer maintain, and cannot supply replacement parts/repair when it breaks.

or

2) A new one, that the manufacturs have plenty of parts & staff to repair/modify it according to your specific needs..

In the comparison here it's not how fast you get back to ground, Its how safely you get down..

Its no good if the chute leaves you in a free fall until your a few meters from death and then sudenly decides to open fully, You land with out breaking any bones, but will you trust it next time ???

However a chute that opens when needed, and lets you land safely and in control, will be trusted for a long time (even perhaps with out service & repairs). Yes it took you longer to get down, but you got there safely...

--edit--
As i pressed submit i remembered a bumper sticker quote, if the parachute is not there when you need it, you'll probably never need it again .. ;)

Quote:

---

Originally Posted by TheCPUWizard

No the question was WHY.

---

Your question was why, to which one answer is performance. And that is still being explored.

Quote:

---

Originally Posted by TheCPUWizard

Performance is one metric out of many. And it really only matters at the "external" level. Consider a button click. The tightest specification I have ever seen for a response time is 100mS. So if one program takes 200mS and another takes 75mS it matters. But if one takes 75mS and another takes 7.5mS the difference is unimportant.

---

I'm guessing you are referring to the GUI. That is, as long as the program appears responsive to the user, then are you saying it doesn't matter if code is still being executed behind the scenes? To some extent, I would agree, but only when the lag is short enough such that the user isn't continuing to stack more and more jobs, believing the others have finished. There's only so much of that which can be managed before problems arise. Also, there are plenty of cases where the user is watching the progress of some time intensive operation. This can be by means of a progress indicator, or by the presentation of the results, such as rendering hi-res graphics. The performance really matters in these scenarios, especially when the program is targeted for wide distribution, and is just one out of a number of solutions which the user might choose. I cannot count the number of poorly written programs I used only once. Upon finding out how bad/slow they were, I promptly uninstalled them. Thank goodness for free demos!

It probably matters less when most of your work is for clients who've paid for custom stuff. It's not like they have so many choices, time/money to waste, so I'd have to guess they are less likely to request a refund and go someplace else.

Again I believe one of the differences between yourself and others is the specific market. It seems you have clients who pay loads of cash for a solution, where others will be selling (or trying to) X copies of a $50 program on the Internet. In the latter case, there are untold numbers of horridly bad, free software and shareware out there, which in the view of the consumer are your competition (even though they aren't worth the time to download). So it becomes vitally important to maximize performance, protect against crackers/hackers, minimize file size, etc.

Quote:

---

Originally Posted by GremlinSA

As i pressed submit i remembered a bumper sticker quote, if the parachute is not there when you need it, you'll probably never need it again .. ;)

---

LOL

Or, the chute with a satisfaction guarantee. Or the one which states: "opens upon impact".

Quote:

---

Originally Posted by TheCPUWizard

Yes I did, and I am working on it. Getting something that IS secure (at least as secure as any natively compiled C++ program) but does NOT reveal some of the details I actually use [and especially does not release NDA material] is proving to be more time consuming than I planned.

---

Very interesting. In earlier posts, when the conversation was about security, there were strong suggestions that those wanting to secure a .net app could just use obfuscation and/or ngen, and it was claimed to be good enough (I'm paraphrasing here, and referring to posts by more than one person, so I don't have to go back and try to find them).

Quote:

---

Originally Posted by TheCPUWizard

With this a program (such as the sample I am working on) can function according to the following process

1) Write conventional .NET code in the language of your choice to create a managed assembly (.dll)

2) Use a translator/encryptor so that the byte patterns are NOT standard MSIL. This will completely block the use of any existing tool as the file is NOT MSIL.

3) Write a custom CLR Loader and JIT Compiler that knows about your encrypted/translated format.

4) When you run the program, the memory pages are locked down so that other "normal" processes do not have "READ" Permission and the Custom Loader/JIT compiler is used to process the assembly.

The result is that MSIL never exists.

A minor variation on this aproach IS commercially available. You can purchase a license for a "Custom IL" that only your program will use.

The commercial alternative is NOT cheap. But if you have a legitimate concern that someone reverse engineering your code may cause you serious financial problems, then it is certainly a viable way to go...

---

This is very revealing. So it isn't so easy (or cheap) to really protect .net code after all. This makes me wonder how many people following this thread are now cringing, because they have been using obfuscation and ngen, believing their code is plenty secure. For you to say the commercial product isn't cheap suggests to me that the price has more zeros than most of us can afford.

Quote:

---

Originally Posted by TheCPUWizard

I fail to see how that is a problem. A recent Gartner Group study indicated that the ration of MSIL to Native code in commercial programs is rapidly increasing.

---

By "commercial", do you mean software for the home user?

Quote:

---

Originally Posted by TheCPUWizard

1) Nobody has shown me a requirements document and a VB (4,5,6) implementation of that document that could not be implemented in .NET with equivilant performance.

---

If you have rewritten my second example in .net, please do post the performance outcomes.

Anyway, Gremmy is working on it, so we'll see one way or the other.

Quote:

---

Originally Posted by WizBang

Your I'm guessing you are referring to the GUI.

---

I was actually just using a GUI event as a simple example and was considering the TOTAL time it took to completely perform an action. If the user clicks the button, looks at the screen and sees the result (100mS-250mS) then anything faster does not matter. An exeption might be a game function where the number of "clicks" in a second might impact the "attack" or other aspect.

Quote:

---

The performance really matters in these scenarios, especially when the program is targeted for wide distribution, and is just one out of a number of solutions which the user might choose. I cannot count the number of poorly written programs I used only once. Upon finding out how bad/slow they were, I promptly uninstalled them. Thank goodness for free demos!

---

No doubt there is alot of garbage out there. But if you remember the early days of C++, there were many C++ programs that were slower than their C counterparts. The primary reason was that developers did not know how to properly use the new paradigm. It crequired a completely different thought process and resulted in a radically different program structure. The exact same is true when comparing a native to managed program.

This is one of the reasons why I do not engage in "write the same code" exercises. It is the wrong approach. I will gladly engage in any "competition" where given a functional spcification (what the customer needs the program to accomplish) is used to implement a program specifically developed fom the very ground up to accomplish the goal, using the best features of the environment.

Quote:

---

It probably matters less when most of your work is for clients who've paid for custom stuff. It's not like they have so many choices, time/money to waste, so I'd have to guess they are less likely to request a refund and go someplace else.

---

They are much more likely to file a lawsuit than to request a refund is the project specifications aqre not met. :eek: They will have lost not only the money they paid, but often months of time where they coukld not accomplish their goal. Also with the "many sales small dollar" model, there is the possibility that a percentage of saqles will result in a request for a refund. With "full custom - one shot" it is an all or nothing

Quote:

---

Again I believe one of the differences between yourself and others is the specific market. It seems you have clients who pay loads of cash for a solution, where others will be selling (or trying to) X copies of a $50 program on the Internet. In the latter case, there are untold numbers of horridly bad, free software and shareware out there, which in the view of the consumer are your competition (even though they aren't worth the time to download). So it becomes vitally important to maximize performance, protect against crackers/hackers, minimize file size, etc.

---

AlthoughI rarely get down to the $50/copy region, some of my products are designed for mutiple sales.

Even a very small program (done well in any environment) takes about 1 man-month. This includes the coding, debuging, documentation, beta-testing, etc. The average cost for this is about $15K-$20K (Salary, Office Expense, etc). This means that a minimum sale of at least 300 copies just to recover costs. To make a decent return on investment, that number becomes about $500 copies. Wtih the heavy saturation in that market place, I have seen a number of excellent programs that never gained enough traction to become a sustainable product.

Again, business models differ,and I am well aware that these numbers do not apply to everyone, especially someone who is writing their softare as a side-line.

Quote:

---

Originally Posted by WizBang

Very interesting. In earlier posts, when the conversation was about security, there were strong suggestions that those wanting to secure a .net app could just use obfuscation and/or ngen, and it was claimed to be good enough (I'm paraphrasing here, and referring to posts by more than one person, so I don't have to go back and try to find them).

---

Restricting security to "avoiding duplication" or "theft of intellectual property"....
It is a matter of degree of security. Obsfucation makes the code harder to read, and introduces lots of mis-directions (code injected specifically to make the algorythm's intent harder to understant).

For ANY program, at Time0 a thief has no knowledge of the internals, given sufficient time a qualified thief will that 100% knowledge and undrstanding. The difference between the models is the shape of the curve in between.

And this is where the topic becomes very subjective.

Quote:

---

This is very revealing. So it isn't so easy (or cheap) to really protect .net code after all. This makes me wonder how many people following this thread are now cringing, because they have been using obfuscation and ngen, believing their code is plenty secure. For you to say the commercial product isn't cheap suggests to me that the price has more zeros than most of us can afford.

---

Obsfucation puts the code on the same plain as a moderately optimized C++ program. For many that is sufficient. When you talk with security experts (again about theft/duplication and NOT about unauthorized alteration, the two topics MUST be seperated), the criteria that is used is always impact vs. cost.

Consider a (hypthetical) program that you develop. You are going to sell it for $100 (easy number). Your marketing plan calls for you to sell 500 copies over the next three months, then 50 copies a month for the remainder of the year. That is 950 copies at $100/copy or $95,000.

Statistically, during the very initial phase, thieves will not be aware of your product, so it will take some time before they consider stealing the implementation. Lets say two months. (So far nothing has involved the platform that program uses..)

Situation #1

The code is difficult to understand and takes 3 months to analyze. It then takes a month to "repackage" the code so it has a different look and feel to avoid an immediate lawsuit. When released to the market it takes away 25% of your sales. This is a net impact of 75 copies that you would have sold ($7,500)

Situation #2

The code is easier to understand and only takes 1 month. This increases the impact to 100 copies ($10,000).

...back to common effects.... When there are multiple programs that claim to achieve the same goals, there is an increase in awareness (potential customers). A significant factor in customers deciding (assuming all other things equal) is the reputation of the vendor. For small vendors, this is usually measured by feedback on download sites, number of downloads, and length of time the program has been available (longer=better).

Because of this effect, the customer base increases by 20%, of which your company gains 50%. In the first situation, this condition exists for 6 months, in the second it exists for 8 months. This results in an increase of 60 sales for the first situation vs. 80 sales for the second.

This results in net impacts of 15 sales vs. 20 sales. The total difference in your income is $500. In other words a 6% difference in revenue. It is a very rare marketing plan that can even predict actual revenues to within 10% for a mass market product concept.

While I do NOT do business in this space myself, I have been a supporter of "Fresh Minds" for about 20 years. This is a regional (New York) organization that guides people in developing a business or product. Of the people who have acutally launched low price software products (selling price < $250), the ones who did the appropriate research and analysis has mostly been successful, while the ones who just thought they had a good idea rarely succeed....

Quote:

---

Originally Posted by WizBang

By "commercial", do you mean software for the home user?

---

The study was of companies that developed "boxed" software, and did not indicate the targt audience. This would severely limit the number of "shareware" type vendors, but would include the companies that develop software you see on the shelves retailing for well undr $100...

Quote:

---

If you have rewritten my second example in .net, please do post the performance outcomes.

Anyway, Gremmy is working on it, so we'll see one way or the other.

---

As I stated before, I do not believe in "rewrite the code" approaches. Give me a specification for a (simple) actually useful program, and I will gladly take it in.

Also, I very rarely do any GDI type work. The few products which require it, I tend to outsource the work. [I am a lousy graphic artist, so even if I write "great" code, it still looks like S$#$".

I am looking forward to Gremmy's results....

Well i did a initial version of this code...

Code:

---

    Private Sub DrawStuff()
        Dim Rct As Rectangle, W As Integer, H As Integer
        Dim I As Integer, J As Integer, X1 As Integer, Y1 As Integer
        Dim X2 As Integer, Y2 As Integer
        Dim BmapBuffer As Image
        Dim BufferGObj As Graphics

        Dim T As Integer

        T = GetTickCount

        Rct.Size = Me.ClientSize

        W = Rct.Width
        H = Rct.Height

        BmapBuffer = New Bitmap(W, H)
        BufferGObj = Graphics.FromImage(BmapBuffer)

        X2 = 30
        Y2 = 40

        BufferGObj.Clear(Color.FromArgb(&H60, &H60, &H60))

        J = CInt(TextBox1.Text)
        For X1 = 0 To W Step X2
            For Y1 = 0 To H Step X2
                For I = 1 To J
                    Dim c As New Pen(Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256))
                    BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)
                Next
            Next
        Next
        Me.Text = GetTickCount - T

        Me.BackgroundImage = New Bitmap(BmapBuffer)

    End Sub

---

This round the time difference is closer, however vb6 still won..
I'll se what i can do to squeese some more performance out of .NET ( Remember i've only been working on .NET for about a year now..)
see attached image..

VB6 left , VB.Net right..

That's very interesting Gremmy! And thanks for doing these tests.

Wouldn't API help .net just as it does VB6? Or are you purposely not using API?

This could be run in a thread, and draw each independent of the others.

Code:

---

              For I = 1 To J
                    Dim c As New Pen(Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256))
                    BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)
                Next

---

with DrawLine(J) as a new thread. For imagination, they could alternate directions. I'll try to dig up the code sample that we worked on here a while back.

I saw a 400x improvement running 26x26 in separate threads doing web requests.

Quote:

---

Originally Posted by wizbang

That's very interesting Gremmy! And thanks for doing these tests.

Wouldn't API help .net just as it does VB6? Or are you purposely not using API?

---

Like I stated. People in the .net shouldn't go outside the "box". If they had to, they are missing the point in the .net.

For games running slow because they were built out out of the c++ is wrong. Everyone knows that games run slow if you have a slow video card and not the cpu typically.

I like the answers about jumping out of the plane ;)

Managed to shave a few ms by moving the DIM outside of the loop, and fixing the pen.color slightly for another 50ms.

Code:

---


Public Class Form1

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        TextBox1.Text = 100
        DrawStuff()
    End Sub

    Private Sub DrawStuff()
        Dim Rct As Rectangle, W As Integer, H As Integer
        Dim I As Integer, J As Integer, X1 As Integer, Y1 As Integer
        Dim X2 As Integer, Y2 As Integer
        Dim BmapBuffer As Image
        Dim BufferGObj As Graphics

        Dim T As Integer

        T = Environment.TickCount

        Rct.Size = Me.ClientSize

        W = Rct.Width
        H = Rct.Height

        BmapBuffer = New Bitmap(W, H)
        BufferGObj = Graphics.FromImage(BmapBuffer)

        X2 = 30
        Y2 = 40

        Dim formGraphics As System.Drawing.Graphics
        formGraphics = Me.CreateGraphics()

        J = CInt(TextBox1.Text)
        Dim c As New Pen(Color.Black)
        For X1 = 0 To W Step X2
            For Y1 = 0 To H Step X2
                For I = 1 To J
                    c.Color = Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256)
                    BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)
                Next

            Next
        Next
        Me.Text = Environment.TickCount - T
        Me.BackgroundImage = New Bitmap(BmapBuffer)
    End Sub

End Class

---

Doesn't dot net also have the ability to take advantage of the multi core processors? Would be interesting to see how much faster it goes when offloading some of the work to a second core or 3rd and 4th.

http://msdn.microsoft.com/en-us/magazine/cc163340.aspx

Quote:

---

Originally Posted by WizBang

That's very interesting Gremmy! And thanks for doing these tests.

Wouldn't API help .net just as it does VB6? Or are you purposely not using API?

---

Yes.. I'm pupoisely avoiding using API's as .NET has the Graphics Object that is suposed to be the API Equivelent..

The more I'm using it the more I'm thinking that it may be a wraper class for the API's, and you will get a little lag from the wrappers...

Gremmy..

Quote:

---

Originally Posted by GremlinSA

Yes.. I'm pupoisely avoiding using API's as .NET has the Graphics Object that is suposed to be the API Equivelent..

The more I'm using it the more I'm thinking that it may be a wraper class for the API's, and you will get a little lag from the wrappers...

Gremmy..

---

You are correct. One big issue with you implementation was that you are creating the Pen inside a loop. Pen implements IDisposable, and you were not calling Dispose.

This means that each time through the loop, the PEN (effectively) has to get added to the finalizer queue, which introduces serious processing overhead.

While I have not tested it. I would expect adding a Dispose() call would give you nearly the identical performace dglienna gets by moving the Pen call out of the loop.

When you use any object that implmenents IDisposable, you MUST insure that Dispose() is called on a reliable basis. One quick way to check, is to use PerfMOn to watch how many finalizers are ocuring. Unless there are exceptions occuring (which should also be minimized) this count should remain at 0 for the entire life of the program.

Run PermFom and look at the GC counters both with and without the Dispose(). You will see a drastic difference.

Quote:

---

Originally Posted by dglienna

This could be run in a thread, and draw each independent of the others.

---

The redundant loop is being used to exaggerate the total time that the function takes to execute, in order to get meaningful numbers for the comparison. Using separate threads would mess that up.

So in the interest of exploring this, I've modified the function to eliminate the need for a redundant loop. What I did is to use the value entered into the TextBox to determine the size of the rectangles. Obviously, it takes a much smaller rectangle to slow the whole thing down enough, but I think it works good enough to get numbers we can use.

I have just been running Gremmys code.

Because I have a "poor" video environment (I told you I do not generally do graphics :D ), I am seeing numbers about 8x what others are reporting, regardless of environment. However I am seeing the same RATIONS (approx). As a result, I will NOT post numbers, just observations.

1) As I indicated in a previous reply, NOT Disposing the Pen that is created inside the loop is a major ovehead. Adding the Dispose() or moving the Managd Pen creation out of the loop yields statistically equivilant results.

2) Comparing the Pen setup (Pen.Color = ) to the Draw. Indicates that 2.28 time units are used for each change to the pen. 6.16 time units are used for each call to rectangle. So the pen is about 25% of the time the draw about 75% of the tims.

3) Release Builds are Measurable Faster (about 25%) than Release Builds. The differential between DEbug and Release is typically larger with Managed Code than with other environments. It is important that all timing tests be run as Release Builds, and WITHOUT Visual Studio (or any other debugger) active on the System. (Having a debugger loaded in memory - regardless of if you are actually debuging your application MAY have significant impact on program excution).

I am continuing to break down #2. For those interested, I am using the ANTS profiler (www.red-gate.com). There is a 14 day free evaluation available for anyone interested in finding out where time is spend in their managed applications.

The differential in Time on

Code:

---

    c.Color = Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256)
    BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)

---

Is spent in parameter validation and result verification before calling the Native GDI. These are both important elements in having a program which behaves in a well defined manner, and is secure (many code native routines can only do limited validation on parameters), but it does come at a price.

I agree that for a graphics intensive application that this can present a problem. Regardless of language optimizing your drawing to minimize the number of discrete calls will result in a performance improvement, but this is especially true for managed code.

If the goal was to have identical functionallity for the above two lines, then the VB6.0 code needs to check all parameters for validity and also check the return status of all API calls.

Quote:

---

Originally Posted by TheCPUWizard

The differential in Time on

Code:

---

    c.Color = Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256)
    BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)

---

Is spent in parameter validation and result verification before calling the Native GDI. These are both important elements in having a program which behaves in a well defined manner, and is secure (many code native routines can only do limited validation on parameters), but it does come at a price.

I agree that for a graphics intensive application that this can present a problem. Regardless of language optimizing your drawing to minimize the number of discrete calls will result in a performance improvement, but this is especially true for managed code.

If the goal was to have identical functionallity for the above two lines, then the VB6.0 code needs to check all parameters for validity and also check the return status of all API calls.

---

What this acknowledges, is that part of the difference we see in performance is due to the fact that the .net code is managed. Should we purposely cripple the VB6 code just to compensate for an intrinsic difference in the languages? It's part of how the two differ, just as VB6 doesn't have a DrawRectangle function.

However, since the VB6 code is using the RGB() function, there IS some checking being done on that anyway. That's just part of the language too.

Quote:

---

Originally Posted by WizBang

What this acknowledges, is that part of the difference we see in performance is due to the fact that the .net code is managed. Should we purposely cripple the VB6 code just to compensate for an intrinsic difference in the languages? It's part of how the two differ, just as VB6 doesn't have a DrawRectangle function.

---

It has nothing to do with the "managed" aspect. I have been trying to measure that aspect specifically (the pinning of the objects and the marshelling), but it is so small a part of the difference (hand calculating it by looking at the executed code indicates it accounts for less than 1% of the difference).

It has everything to do with writing ROBUST code. Consider (completely language/platform independant if you are going to write a sub-routine that will call the following (hypothetical) function:

Quote:

---

Method: int DoSomeThing(int param)

DoSomething will return a poisitive "calculated value" based on the passed parameter and "some external condition".

The behaviour is defined for 100<param<1000. Values outside this range result in undefinded behaviour.

If the "external condition" is in an invalid state, the result will be -1.

---

Writing code that does not check the parameter and the return value, has inherent risks. Accidently passing 1002 as a parameter could return meaningless results, cause and exception to be thrown, cause your computer to crash, ......

This would simply be iresponsible. Again, this is independant of any specific techniology.

By calling API's directly (again from any environment) it becomes the developers responsibility to manually code the correct "safe" behavior.

By using the .NET framework, the checks are automatically in place, and the developer CAN NOT be ir-responsible.

For the two lines in question:

Code:

---

Public Shared Function FromArgb(ByVal red As Integer, ByVal green As Integer, ByVal blue As Integer) As Color
    Return Color.FromArgb(&HFF, red, green, blue)
End Function

 Public Shared Function FromArgb(ByVal alpha As Integer, ByVal red As Integer, ByVal green As Integer, ByVal blue As Integer) As Color
    Color.CheckByte(alpha, "alpha")
    Color.CheckByte(red, "red")
    Color.CheckByte(green, "green")
    Color.CheckByte(blue, "blue")
    Return New Color(Color.MakeArgb(CByte(alpha), CByte(red), CByte(green), CByte(blue)), Color.StateARGBValueValid, Nothing, DirectCast(0, KnownColor))
End Function

 Private Sub New(ByVal value As Long, ByVal state As Short, ByVal name As String, ByVal knownColor As KnownColor)
    Me.value = value
    Me.state = state
    Me.name = name
    Me.knownColor = CShort(knownColor)
End Sub

 Public Sub DrawRectangle(ByVal pen As Pen, ByVal x As Integer, ByVal y As Integer, ByVal width As Integer, ByVal height As Integer)
    If (pen Is Nothing) Then
        Throw New ArgumentNullException("pen")
    End If
    Dim status As Integer = Gdip.GdipDrawRectangleI(New HandleRef(Me, Me.NativeGraphics), New HandleRef(pen, pen.NativePen), x, y, width, height)
    Me.CheckErrorStatus(status)
End Sub

 DllImport("gdiplus.dll", CharSet:=CharSet.Unicode, SetLastError:=True, ExactSpelling:=True)> _
Friend Shared Function GdipDrawRectangleI(ByVal graphics As HandleRef, ByVal pen As HandleRef, ByVal x As Integer, ByVal y As Integer, ByVal width As Integer, ByVal height As Integer) As Integer
End Function

Private Sub CheckErrorStatus(ByVal status As Integer)
    If (status <> 0) Then
        If ((status = 1) OrElse (status = 7)) Then
            Dim num As Integer = Marshal.GetLastWin32Error
            If (((num = 5) OrElse (num = &H7F)) OrElse (((UnsafeNativeMethods.GetSystemMetrics(&H1000) And 1) <> 0) AndAlso (num = 0))) Then
                Return
            End If
        End If
        Throw Gdip.StatusException(status)
    End If
End Sub

---

The two bold statements are the ONLY aspect that is induced because the code is "managed".

If you plug these methods (with adjustments) into your VB6.0 implementation, then you will have programs with equivilant levels of reliability.

This would then be a fair comparision (ie meeting the same requirements using two different languages).

Woot !!!!!

Now we got something that working !!!!!!

Code:

---

  Private Sub DrawStuff()
        Dim Rct As Rectangle, W As Integer, H As Integer
        Dim I As Integer, J As Integer, X1 As Integer, Y1 As Integer
        Dim X2 As Integer, Y2 As Integer
        Dim BmapBuffer As Image
        Dim BufferGObj As Graphics
        Dim T As Integer
        T = GetTickCount
        Rct.Size = Me.ClientSize
        W = Rct.Width
        H = Rct.Height
        BmapBuffer = New Bitmap(W, H)
        BufferGObj = Graphics.FromImage(BmapBuffer)
        BufferGObj.Clear(Color.FromArgb(&H60, &H60, &H60))
        Dim c As New Pen(Color.White)
        J = CInt(TextBox1.Text)
        If J < 1 Then J = 1
        X2 = J
        Y2 = J * 1.4
        For X1 = 0 To W Step X2
            For Y1 = 0 To H Step X2
                'For I = 0 To J
                c.Color = Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256)
                BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)
                'Next
            Next
        Next
        Me.Text = GetTickCount - T
        Me.BackgroundImage = New Bitmap(BmapBuffer)
    End Sub

---

CG has a 100k limit on image files, so the image was clipped, however i can promise that they are the same size... (Full size viewable here)

Again VB6 left, .NET right..

Quote:

---

Originally Posted by TheCPUWizard

I have just been running Gremmys code.

Because I have a "poor" video environment (I told you I do not generally do graphics :D ), I am seeing numbers about 8x what others are reporting, regardless of environment. However I am seeing the same RATIONS (approx). As a result, I will NOT post numbers, just observations.

---

Not a problem, we do need some one to interpret the number's, and give sound observations..

Quote:

---

Originally Posted by TheCPUWizard

3) Release Builds are Measurable Faster (about 25%) than Release Builds. The differential between DEbug and Release is typically larger with Managed Code than with other environments. It is important that all timing tests be run as Release Builds, and WITHOUT Visual Studio (or any other debugger) active on the System. (Having a debugger loaded in memory - regardless of if you are actually debuging your application MAY have significant impact on program excution).

---

In VB6 i have seen this same differential, and 25% is about the same i've noticed..
However in VB.NET the number is a lot smaller, If any, in working on these examples running the build and running in Debug has yeilded identical numbers..

So, the times look identical. That's cool!

EDIT: Hope you saw David's post from 10 minutes before...

Quote:

---

Originally Posted by dglienna

So, the times look identical. That's cool!

EDIT: Hope you saw David's post from 10 minutes before...

---

Ooops nope ...

Acctually now the PM i got makes a little more sence ...

Add that code to the vb6 side and run the test again, if you get time.

That's really interesting Gremmy! Since the execution times seem to be going down for each revision in the program, how about trying it with the TextBox value at 2 rather than 3, or make the form larger? The longer the execution time, the better we can see the differences.

TheCPUWizard: As far as I can see, the only thing that could be added (with those two lines you've referred to) is to pick up the return from FrameRect. If it was to fail, the only thing that would happen is the rectangle wouldn't get drawn. The variables passed are of the same type, and it doesn't care what values they are. The RGB() function would raise an error if the values were out of range, which is why I used Mod - restricting the range to valid values.

I was wanting to run some tests myself but can't seem to find the VB6 code that is being used. Could someone point me to it... please :rolleyes:

However, because you are using "mod" (which is a signed calculation), the performance is significantly lower (at least for .NET) than if you used "and".

Code:

---

                    Dim red As Integer = X1 Mod 256
00000118  mov        edx,ebx
0000011a  and        edx,800000FFh
00000120  jns        0000012A
00000122  dec        edx 
00000123  or          edx,0FFFFFF00h
00000129  inc        edx 
                    Dim green As Integer = Y1 Mod 256
0000012a  mov        eax,edi
0000012c  and        eax,800000FFh
00000131  jns        0000013A
00000133  dec        eax 
00000134  or          eax,0FFFFFF00h
00000139  inc        eax 
                    Dim blue As Integer = (X1 + Y1) Mod 256
0000013a  mov        ecx,ebx
0000013c  add        ecx,edi
0000013e  jo          00000219
00000144  and        ecx,800000FFh
0000014a  jns        00000154
0000014c  dec        ecx 
0000014d  or          ecx,0FFFFFF00h
00000153  inc        ecx 

00000154  push        eax 
00000155  push        ecx 
00000156  lea        ecx,[ebp-68h]
00000159  call        778D94E0
0000015e  lea        eax,[ebp-68h]
00000161  push        dword ptr [eax+0Ch]
00000164  push        dword ptr [eax+8]
00000167  push        dword ptr [eax+4]
0000016a  push        dword ptr [eax]
0000016c  mov        ecx,esi
0000016e  cmp        dword ptr [ecx],ecx
00000170  call        7799CF58

=========================

                    REM Dim c As New Pen(Color.FromArgb(X1 Mod 256, Y1 Mod 256, (X1 + Y1) Mod 256))
                    Dim red As Integer = (X1 And 255)
00000114  mov        edx,ebx
00000116  and        edx,0FFh
                    Dim green As Integer = (Y1 And 255)
0000011c  mov        ecx,edi
0000011e  and        ecx,0FFh
                    Dim blue As Integer = ((X1 + Y1) And 255)
00000124  mov        eax,ebx
00000126  add        eax,edi
00000128  jo          00000206
0000012e  and        eax,0FFh
                    c.Color = Color.FromArgb(red, green, blue)
00000133  push        ecx 
00000134  push        eax 
00000135  lea        ecx,[ebp-6Ch]
00000138  call        778D94E0
0000013d  lea        eax,[ebp-6Ch]
00000140  push        dword ptr [eax+0Ch]
00000143  push        dword ptr [eax+8]
00000146  push        dword ptr [eax+4]
00000149  push        dword ptr [eax]
0000014b  mov        ecx,esi
0000014d  cmp        dword ptr [ecx],ecx
0000014f  call        7799CF58

---

See the difference?

Okay at '2' the time difference creeps to 'NET now.

Full screen size (1280 * 768) test..

VB6 = 1232ms
VB.NET = 1092ms (with build or in debug) ..

HOWEVER, there is one fundamental difference that has crept in, with a value of 1, vb6 gives a fine color spectrum, in .NET i get grey.

and it comes down to these two lines

Code:

---

VB6
      SetRect Rct, X1, Y1, X1 + Y2, Y1 + Y2

---

AND

Code:

---

VB.NET
      BufferGObj.DrawRectangle(c, X1, Y1, Y2 - 1, Y2 - 1)

---

SetRect uses Top, Left, Bottom, Right for input....
DrawRect uses Top, Left, Height, Width for input....

SetRect can accept inputs that essentially gives you a rect that is 0 width, however DrawRect will do nothing if the rect is 0 width..

fundamental differences in implimentation ?????

It cannot use And, because the values have to "cycle around". That is, a value of 257 results in a value of 1.

Never expected that DrawRectange wouldn't draw even when the API can do it. Are there any other functions that you could use to get equivalent output?

I'm not sure if I am using the right files or not but I am seeing a huge difference between VB6 and dot net on this pc.

VB6 Code running at an average of 300

Dot Net 2005 avg 2230

Both running 1280x768 set to 3 on a X2 4400+ 2g 7300GT

Quote:

---

Originally Posted by WillAtwell

I'm not sure if I am using the right files or not but I am seeing a huge difference between VB6 and dot net on this pc.

VB6 Code running at an average of 300

Dot Net 2005 avg 2230

Both running 1280x768 set to 3 on a X2 4400+ 2g 7300GT

---

The file is attached to post 279.

Quote:

---

Originally Posted by TheCPUWizard

However, because you are using "mod" (which is a signed calculation), the performance is significantly lower (at least for .NET) than if you used "and".

---

Hmmm this does offer a new perspective. with the 'AND' instead of 'Mod', the previous test (at '3') the .NET time droped to 110ms and full screen at '2' droped to 1060ms..

Quote:

---

Originally Posted by WizBang

It cannot use And, because the values have to "cycle around". That is, a value of 257 results in a value of 1.

---

Hmm Wiz, i think you may be up late..

257 AND 255 = 1
257 MOD 256 = 1

Dbl checked it too ..

Ooops...you're right Gremmy...I was still using 256 instead of 255.

<EDIT>
Just tried it, and didn't see a lot of difference. What do you get for the comparison with this Gremmy?

Just tested on another computer. This time running the exe files without the designers loaded. Last tests were with both designers running during the test and in debug mode. I also did 2 builds of the dot net exe one under VS2005 and one under VS2008

Set at 2 seems to be the lowest setting that still gives us some color on the dot net exe.

VB6 453
VB2005 593
VB2008 593

These tests at 1280x768 on a E7200 @3.0438gHz 2g 9600GT