managed vs. unmanaged question

  • Thread starter Thread starter doug
  • Start date Start date
D

doug

I understand the basics of what managed code offers and that you open
yourself up to security issues if you allow unmanaged code. We already have
a decent amount of VB6 code to include COM DLLs. If we put wrappers around
some of our code or leave some "asis" what makes our existing production
code 'evil' just because it is now considered 'unmanaged'?

It may seem like a simple niave question, but the definitions for managed
and unmanaged code from MS don't provide enough detail to explain why
unmanaged code, in and of itself is bad or evil.

I understand our existing group of programmers might become evil once we get
..Net installed and begin converting to managed code, but decide now is the
last time to be evil before all our code is converted and they do some
malicious things in the unmanaged portions...

I also understand any ill-behaved programs might still be ill-behaved if
they aren't rewritten in .Net compliant tools - like possible memory leaks
or whatever, things so infrequent or benign as to not even be on queue to be
researched/fixed - will still be ill-behaved.

But what is evil about unmanaged code....? Companies are phasing out
unmanaged code because it is unmanaged. Yet, prior to .Net this same code
was wonderfull.


regards,

doug
 
doug said:
I understand the basics of what managed code offers and that you open
yourself up to security issues if you allow unmanaged code. We already have
a decent amount of VB6 code to include COM DLLs. If we put wrappers around
some of our code or leave some "asis" what makes our existing production
code 'evil' just because it is now considered 'unmanaged'?
Click to expand...

Who said it was evil? MSFT has invested time and effort in mixing the old
with the new. It seems someone has lead you down a blind alley way...

For the MSFT perspective, you might want to sit through this:

http://msdn.microsoft.com/theshow/Episode044/default.asp

HTH
LFS
 
I'm being a little tongue-in-cheek, just a little. But everything I read
has these caveats about pro's/con's of managed code and running in a mixed
environment - security risks and whatnot, and as I stated, corporate
architecture policies are being upgraded to make unmanaged code obsolete.

If the only thing about 'managed code' is that it runs under the auspices of
the CLR and 'unmanaged code' doesn't - who cares.

doug
 
Doug,

When you do everything right with unmanaged code there is nothing wrong,
however programs become huger and huger.

Witch means that you have to handle with unmanaged code more and more dll's,
that the change on memoryleaks become higher and higher, that you have to
write a lot, only to do you memorymanagement. This are in my opinion some
benefits where managed code has "less" change on that. Not that managed code
does guarantee you that those problems will not exist, however it is easier
to handle.

So when you are with those who spent a lot of money solving things as I
wrote above and want to keep that like it is, just use your unmanaged code.

Just my thought,

Cor
 
Cor, Group

"Our" code behaves quite well, no problems, or at least no known issues. I
was just trying to broaden the scope to inclue little problems like minor
memory leaks that don't actually wreck anything. We don't even have those.
In fact, the code in one group was designed up front to run as an unattended
GUI with operators monitoring flow, but not needing to actually do anything
but observe, and they have run unchanged from VB3, VB4, VB5, VB6 without
need for ANY code modification due to new version - classes were added to
package common functionality and externalized, but that was it. They have
only had to recompile to keep running. And their apps support 1000's of
users.

It is only with .Net, which isn't really VB7, but a new language, and it
requires at least minimal code changes under .Net to even work. The upgrade
wizard catches a few things, but not all. They view .Net as a good thing,
but asked me what is so wrong with what they had, given their app now uses
"obsolete", unmanaged code... And I could offer up a good explanation
except the official "clr managed" or "not clr managed".
 
Doug,

Clear for me, however the most important thing you wrote in my opinion that
VBNet is not VB7.

I do not know which version you use, however for upgrading is the 2003
version much better than the 2002 version.

But as you wrote under the hood is everything changed from VB6 to VBNet,
however in my opinion not as much as from C++ to C#, because the use of the
language stayed basicly the same. However that language with VBNet uses new
componentens as Adonet, new controls, and all kind of other classes and
creates completly different endcode. The benefit above C++ to C# is as well
that there is a Microsoft.VisualBasic namespace, which uses the same methods
as done in VB6, where from some are very effective.

This is by the way a link to very explaining messages, however not why it is
but why you have to do things.

http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpag/html/scalenet.asp

Maybe it helps something?

Cor


"doug" <[email protected]>

....
 
Cor, Group

"Our" code behaves quite well, no problems, or at least no known issues. I
was just trying to broaden the scope to inclue little problems like minor
memory leaks that don't actually wreck anything. We don't even have those.
In fact, the code in one group was designed up front to run as an unattended
GUI with operators monitoring flow, but not needing to actually do anything
but observe, and they have run unchanged from VB3, VB4, VB5, VB6 without
need for ANY code modification due to new version - classes were added to
package common functionality and externalized, but that was it. They have
only had to recompile to keep running. And their apps support 1000's of
users.

It is only with .Net, which isn't really VB7, but a new language, and it
requires at least minimal code changes under .Net to even work. The upgrade
wizard catches a few things, but not all. They view .Net as a good thing,
but asked me what is so wrong with what they had, given their app now uses
"obsolete", unmanaged code... And I could offer up a good explanation
except the official "clr managed" or "not clr managed".
 
Doug,

The answer to your client is simple, however I cannot say it is a fact. Only
my opinion.

The more generic environment from dotNet will give the customer in future
more possibilities, while with that the learning time for new applications
will probably be shorter.

That needs that the tools are made for that and old tools do not fit
completly anymore.

(The skill of the developer does not change that has only to be upgraded)

As sample cars, the first did look almost as (horse) carriages. They used
the same tools as in for that for motorcars as horsecars. More and more we
got motorcars with other behaviour so that it was for more people possible
to drive those. With that as well the tools to build them changed.

With this sample I do not mean that VB6 is from the first time, however we
are not yet on the end of this evolution in my idea.

(Before you think it because you wrote that so often, the generic
environment is in my opinion not the CLR, however all the classes in the Net
and Microsoft.VisualBasic namespaces and those you can make yourself or make
by using inheriting from the base classes.)

However just my opinion as I said before,

I hope this give for you some ideas?

Cor
 
Cor,

I don't intend this discussion to go in circles, but I haven't read anything
that support the managers contention that his apps are not anything but
sound, safe, and such, even though they be unmanaged code in this new .Net
world.

We don't deny .Net is a better path going forward. We appreciated the CRL
20 years ago when IBM introduced it to mainframes with the promise of
resolving linkage issues between Cobol/PL1/ASM. Everything about .Net is
appreciated except the learning curve, and that only because of limited
training time. And that influences WHEN they convert.

The exception being raised is just that of why, by way of example, Friday
their VB6 apps were GREAT, yet on Monday after some obtuse architutecture
group publishes their new standards, VB6 cobe has been depreciated and
obsoleted because it is NON-MANAGED code. That is the only excuse given.
And when you read about this, you get the impression I originally raised
being "Why is non-managed cobe and/or mixed environment code bad?". And MS
states managed code runs under the CLR, non-managed code doesn't, and there
is the risk of security issues in non-managed code.

You don't need to convince anyone to move to .Net. They want to. They just
want to know the issues on why their old code is now instantly obsoleted,
and they don't want to have stupid comments stated as "facts" (such as you
HAVE to migrate now, your code is UNMANAGED) used to bully them into an
early migration where they do just the bare minimum (due to not knowing .Net
or the FrameWork as well as they prefer to prior to migrating. They don't
want to do 2 conversions - a sloppy half *ss one then a better one later).

doug
 
Cor,

The "architecture groups" are biased java groups. They hate MS and resent
any MS based solution. They have structured the architectural standards to
finally accept .Net., but at 2nd class status.

Now MS VS6 apps are obsoleted because they are "unmanaged".

IBM's WebShere product. I took an 18 day class in this product and was
amazingly underwhelmed.

Now I KNOW Java doesn't run under the auspices of the CLR so it doesn't
qualify as "managed" code according to the MS definition. Yet WebShere
hasn't been depreciated or obsoleted.

Does this shed more light on the issue?

doug
 
Now I KNOW Java doesn't run under the auspices of the CLR so it doesn't
qualify as "managed" code according to the MS definition. Yet WebShere
hasn't been depreciated or obsoleted.
Click to expand...

There J++ ; )

Java is a managed language. The CLR is called JRE. Same stuff, different
name.
 
Doug,

What can I add to this, we agree.

However I am impressed by Microsoft that it seems that they will succeed in
what is as you as well write so often told, however
.............................

But there is no need to go now to dotNet when your VB6 applications are
doing well.

Moreover I think you can better go tomorrow when there is no need to go
today.

Although some small learning applications will in my opinion not be a bad
idea.

Maybe I should have written this earlier, in this newsgroup is often written
by people comming from VB6. First I found it all difficult and useless,
however when they order me to go back to VB6 than they have to pull me by my
hairs.

Cor
 
Doug,

I am from Holland. We lost Java in 1948

And probably only some very old nostalgic people want it back.

:-)

Cor
 
Back
Top