Is .NET less capable?

  • Thread starter Thread starter creamBoy
  • Start date Start date
C

creamBoy

In VB6 scaling a picturebox was done like this: Me.picturebox.scale
(0,25)-(25,0) How is it done in VB.NET ?

Also, I want to draw simple lines and circle in a coordinate system on
the picturbox. Something like a bull's eye.
Also, how do i save registry values on a system?

Thanx, Yemmy.
 
CreamBoy,

I have only an answer on your latest question. I am know almost nothing
anymore from VB6.

I remember me however the crime it was in VB6 to use the registry. In VBnet
it is simple, use the registry class, it can far much more than VB6 can
without direct invoking the API's.

http://msdn2.microsoft.com/en-us/library/microsoft.win32.registry.aspx

There exist also a class for drawing. That is in the drawing namespace.

Cor
 
Ok Cor, thanx,
but how do i draw a line, for example, or a circle, over the picture
box?
 
In VB6 scaling a picturebox was done like this: Me.picturebox.scale
(0,25)-(25,0) How is it done in VB.NET ?

Also, I want to draw simple lines and circle in a coordinate system on
the picturbox. Something like a bull's eye.
Also, how do i save registry values on a system?

Thanx, Yemmy.
Click to expand...

Less capable - no
Higher learning curve - yes

Anything you can do in VB6 can be done in Visual Basic .Net. It might
be harder at first to get the same results, but after you are used to
the methodology, it is pretty simple. Like Cor I can't really remember
why we used Scale - but I seem to remember it was just to set an
offset for drawing. In .Net instead of saying a certain point will act
as point (0, 0) you just specify the point you want to start drawing
at (such as (50, 50)). I could be wrong in my memory - I've left VB
classic in the past.

For drawing here is a simple windows form that will draw a bullseye
into a picturebox. Just add the code to the code behind of a new form
and run it.

/////////////////
Imports System.Drawing

Public Class Form1

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Dim pictureBox As New PictureBox()
pictureBox.Size = New Size(100, 100)
pictureBox.Location = New Point(25, 25)
pictureBox.BackColor = Color.White
AddHandler pictureBox.Paint, AddressOf pictureBox_Paint
Me.Controls.Add(pictureBox)
End Sub

Private Sub pictureBox_Paint(ByVal sender As Object, ByVal e As
PaintEventArgs)
Dim graphics As Graphics = e.Graphics
Using redCirclePen As New Pen(Color.Red, 10)
graphics.DrawEllipse(redCirclePen, 4, 4, 91, 91)
graphics.DrawEllipse(redCirclePen, 24, 24, 51, 51)
graphics.FillEllipse(Brushes.Red, 40, 39, 20, 20)
End Using
End Sub

End Class
/////////////////

Thanks,

Seth Rowe
 
"rowe_newsgroups" <rowe_emailATyahoo.com> wrote in message
[SNIP]
Less capable - no
Higher learning curve - yes

Anything you can do in VB6 can be done in Visual Basic .Net.
Click to expand...
[SNIP]

I don't mean to be a spoil-sport, but like say compiling an executable that
only the NSA could decompile? VB6 does that out of the box. If there is a
way VB2005 can do that, I'm all ears and so are a few other people on the
VB.com side of the fence I'm sure...

IP security is is what makes the absence of MSIL a prerequisite to ISV use
of .NET - in my books, it matters more than all the new features introduced
since VB4 put together. If I can't protect my IP from competitors, then
there is no point in me developing software, period.
 
Timothy,

You probably realize that your completely legitimate requirements rule out
the use of the 3 currently dominant development environments:

Java
..Net
Open Source

You should also realize that the vast majority of programmers do not need to
meet your requirements. This is obvious from the number of developers using
one of the environments listed above.

I think the solution for your needs is to stick with VB6 as long as that
platform offers a viable solution for your requirements and to move to C++ in
the future if VB6 no longer works for you.

Kerry Moorman
 
First off let me state that I do not disagree that it is easier to
decompile a .Net application than a VB6 one - you are right in that
regard.
I don't mean to be a spoil-sport, but like say compiling an executable that
only the NSA could decompile?
Click to expand...

VB6 doesn't make a assembly so difficult only the NSA could decompile
- I've heard (never used - I'm not a hacker) of decompilers for VB6
that could easily rip apart a VB6 executable. Besides, as far as
security goes, most attacks on VB6 executables were done with notepad
and grabbing any plain text strings - which often contained usernames
and passwords. Sure VB6 is more secure than dotNet as far as
decompilation is concerned, but being so secure it would take the NSA
to break it - no. Show me an experienced "hacker" with a hex editor or
a memory debugger and I'll show you a broken VB6 executable...

Also, you might find this article by Jon Skeet an interesting read:

http://www.yoda.arachsys.com/csharp/obfuscation.html

Thanks,

Seth Rowe
 
MS has recently (August 07) released a VB 2005 add-in that supports lines
and such. I haven't looked at it, but I suspect it was in response to VB 6
developers who used a lot of the VB 6 graphic capabilities.

Mike.
 
rowe_newsgroups said:
First off let me state that I do not disagree that it is easier to
decompile a .Net application than a VB6 one - you are right in that
regard.


VB6 doesn't make a assembly so difficult only the NSA could decompile
- I've heard (never used - I'm not a hacker) of decompilers for VB6
that could easily rip apart a VB6 executable. Besides, as far as
security goes, most attacks on VB6 executables were done with notepad
and grabbing any plain text strings - which often contained usernames
and passwords.
Click to expand...

To be sure, you can do some really stupid things with VB6 like not rewriting
the data environment from scratch or, as a number of university professors
have done, use a method where a statement or a subroutine would do it 30
times faster - and then base the claim that C is faster than VB on this kind
of coding...

The crack about the NSA is more related to level of difficulty. I am careful
with my code, and I don't mind government types taking a peek. However, I
would prefer it to be too expensive for competitors to try. The problem is
that obfuscation makes it hard enough to keep the script-kiddies and small
corporations out, but too inexpensive to deter larger concerns. I stopped a
leak five years ago. I won't mention the very large corporation that nicked
my multi-tier error management system, but incidents like this strngeley
stopped when I stopped being careless with my source code.
Sure VB6 is more secure than dotNet as far as
decompilation is concerned, but being so secure it would take the NSA
to break it - no. Show me an experienced "hacker" with a hex editor or
a memory debugger and I'll show you a broken VB6 executable...
Click to expand...

All you have to do to stuff these guys up is set multiple secutiy process
triggers with no bottlenecks or common variables. They have the time to hunt
for one, but when this doesn't work after tracing one strand of spaghetti,
it has a wonderful effect on the state of mind! :^)
Also, you might find this article by Jon Skeet an interesting read:

http://www.yoda.arachsys.com/csharp/obfuscation.html

Thanks,
Click to expand...

For me it's a matter of raising the bar. I like VB2005 and I also think MSIL
is a great idea considering the cross plaform compatibility potential. If I
can think of IP protection stronger than my business strategy wrt putting
MSIL just out of reach of the script-kiddies, this could be just the
ticket - but I don't believe that obfuscation makes the code any harder to
decompile. Maybe systematised spaghetti with a couple of n-dimension
indefinite recursion traps might do the trick - but I'll the jury's still
out on that one...

In the meantime, I just want to do what the folks at eziriz have been doing
and pull the MSIL out altogether until I decide how I want to manage the
MSIL issues...
 
Kerry Moorman said:
Timothy,

You probably realize that your completely legitimate requirements rule out
the use of the 3 currently dominant development environments:

Java
.Net
Open Source

You should also realize that the vast majority of programmers do not need to
meet your requirements. This is obvious from the number of developers using
one of the environments listed above.

I think the solution for your needs is to stick with VB6 as long as that
platform offers a viable solution for your requirements and to move to C++ in
the future if VB6 no longer works for you.

Kerry Moorman
Click to expand...
[SNIP}

Pity. I like VB2005. I can see why obfuscated MSIL is attractive being
cross-platform compatible but you don't need MSIL to run cross platform -
all you need to do is access CLR via the native code. I wonder if/why a
dominant environment does not exist to service ISVs? I would think there are
a lot of people developing shareware...
 
Hi,

You know that your problem is very old stuff for us, beside that it is seen
as a very rude method to break in on a thread with a question from somebody
else to start trolling.

Cor
 
Timothy,
Click to expand...
You probably realize that your completely legitimate requirements rule out
the use of the 3 currently dominant development environments:
Click to expand...
Java
.Net
Open Source
Click to expand...
You should also realize that the vast majority of programmers do not need to
meet your requirements. This is obvious from the number of developers using
one of the environments listed above.
Click to expand...
I think the solution for your needs is to stick with VB6 as long as that
platform offers a viable solution for your requirements and to move to C++ in
the future if VB6 no longer works for you.
Click to expand...
Kerry Moorman
Click to expand...

[SNIP}

Pity. I like VB2005. I can see why obfuscated MSIL is attractive being
cross-platform compatible but you don't need MSIL to run cross platform -
all you need to do is access CLR via the native code. I wonder if/why a
dominant environment does not exist to service ISVs? I would think there are
a lot of people developing shareware...
Click to expand...

Have you seen this, perhaps this will interest you:

http://www.softwarepotential.com/code-protection.html

Chris
 
Back
Top