By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,780 Members | 1,520 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,780 IT Pros & Developers. It's quick & easy.

managed vs. unmanaged question

P: n/a
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
Nov 21 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a

"doug" <ds****@pacbell.net> wrote
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'?


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/Ep...44/default.asp

HTH
LFS
Nov 21 '05 #2

P: n/a
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
"Larry Serflaten" <se*******@usinternet.com> wrote in message
news:O4**************@tk2msftngp13.phx.gbl...

"doug" <ds****@pacbell.net> wrote
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'?


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/Ep...44/default.asp

HTH
LFS

Nov 21 '05 #3

P: n/a
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

"doug" <ds****@pacbell.net>
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

Nov 21 '05 #4

P: n/a
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".
"Cor Ligthert" <no************@planet.nl> wrote in message
news:ev**************@TK2MSFTNGP09.phx.gbl...
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

"doug" <ds****@pacbell.net>
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


Nov 21 '05 #5

P: n/a
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/architectu...l/scalenet.asp

Maybe it helps something?

Cor
"doug" <ds****@pacbell.net>

....
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".
"Cor Ligthert" <no************@planet.nl> wrote in message
news:ev**************@TK2MSFTNGP09.phx.gbl...
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

"doug" <ds****@pacbell.net>
> 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



Nov 21 '05 #6

P: n/a
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".
"Cor Ligthert" <no************@planet.nl> wrote in message
news:ev**************@TK2MSFTNGP09.phx.gbl...
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

"doug" <ds****@pacbell.net>
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



Nov 21 '05 #7

P: n/a
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

"doug" <ds****@pacbell.net>
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".
"Cor Ligthert" <no************@planet.nl> wrote in message
news:ev**************@TK2MSFTNGP09.phx.gbl...
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

"doug" <ds****@pacbell.net>
> 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



Nov 21 '05 #8

P: n/a
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 Ligthert" <no************@planet.nl> wrote in message
news:uA**************@TK2MSFTNGP15.phx.gbl...
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

"doug" <ds****@pacbell.net>
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".
"Cor Ligthert" <no************@planet.nl> wrote in message
news:ev**************@TK2MSFTNGP09.phx.gbl...
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

"doug" <ds****@pacbell.net>

> 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



Nov 21 '05 #9

P: n/a
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

"Cor Ligthert" <no************@planet.nl> wrote in message
news:uA**************@TK2MSFTNGP15.phx.gbl...
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

"doug" <ds****@pacbell.net>
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".
"Cor Ligthert" <no************@planet.nl> wrote in message
news:ev**************@TK2MSFTNGP09.phx.gbl...
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

"doug" <ds****@pacbell.net>

> 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



Nov 21 '05 #10

P: n/a
"doug" <ds****@pacbell.net> wrote in news:#L0YKBL0EHA.3416
@TK2MSFTNGP09.phx.gbl:
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.


There J++ ; )

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

--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Nov 21 '05 #11

P: n/a
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" <ds****@pacbell.net>

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 Ligthert" <no************@planet.nl> wrote in message
news:uA**************@TK2MSFTNGP15.phx.gbl...
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

"doug" <ds****@pacbell.net>
> 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".
>
>
> "Cor Ligthert" <no************@planet.nl> wrote in message
> news:ev**************@TK2MSFTNGP09.phx.gbl...
>> 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
>>
>> "doug" <ds****@pacbell.net>
>>
>> > 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
>>
>>
>
>
>



Nov 21 '05 #12

P: n/a
Doug,

I am from Holland. We lost Java in 1948

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

:-)

Cor

"doug" <ds****@pacbell.net>
..
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

"Cor Ligthert" <no************@planet.nl> wrote in message
news:uA**************@TK2MSFTNGP15.phx.gbl...
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

"doug" <ds****@pacbell.net>
> 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".
>
>
> "Cor Ligthert" <no************@planet.nl> wrote in message
> news:ev**************@TK2MSFTNGP09.phx.gbl...
>> 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
>>
>> "doug" <ds****@pacbell.net>
>>
>> > 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
>>
>>
>
>
>



Nov 21 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.