What has managed code achieved?

[Cor Ligthert[MVP]]

Re: What has managed code achieved?


Tom,

>
With module level values, then in both VB6 and VB.NET you must explicitly
set
the object to nothing (or set it to a new reference) if you want the
object to
go away before the program terminates. Oops, in VB.NET you might have to
also
call dispose on that object.
>

You know that in VB.Net the object is not removed by either dispose or
setting it to nothing.

That is done by the Garbage Collector

As you really want to remove the object that has no references anymore then
you have to startl the GC.

I believe that this is only done by persons who still thinking in the style
of the 128Kb memory computers.

Cpr

[Juan T. Llibre]

Re: What has managed code achieved?

re:
!(if you selected isolated execution of course)

....which not everybody used.




Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
=============== =============== ========
"Ben Voigt [C++ MVP]" <rbv@nospam.nos pamwrote in message news:Ofi8nIHNJH A.5692@TK2MSFTN GP04.phx.gbl...

Paul Clement wrote:

>On Tue, 21 Oct 2008 07:36:44 -0400, "Juan T. Llibre"
><nomailreplies @nowhere.comwro te:
>>
>Hi Juan,
>>
>¤ re:
>¤ !But have we traded one kind of DLL hell for another?
>¤
>¤ Not exactly.
>¤
>¤ Did you ever develop in Classic ASP ? "Dll Hell" was quite evident
>there.
>¤
>¤ 1. Different dll versions *prevented* your application from running
>in IIS.
>¤ 2. Updating a dll meant manually stopping IIS, and all
>applications , so a single app could be updated
>>
>Of course with #2 you could actually kill the process that the web
>app was executing under (with Process Explorer) without needing to
>stop IIS, although that method isn't very clean in a production
>environment.

>
There was a convenient button for this in the IIS manager, to stop the hosting process for just that app (if you
selected isolated execution of course).
>

>>
>ASP always late bound to DLL libraries so it just used whatever was
>last registered. No binary compatibility enforcement there.
>>
>>
>Paul
>~~~~
>Microsoft MVP (Visual Basic)

>
>

[Juan T. Llibre]

Re: What has managed code achieved?

re:
!DLL hell has even been solved for unmanaged code using the Side-by-Side cache (SxS)

Have you ever implemented SxS for web applications ?

See :

http://msdn.microsoft.com/en-us/library/aa375155(VS.85).aspx

and

http://msdn.microsoft.com/en-us/library/aa374238(VS.85).aspx

Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
=============== =============== ========
"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.atwrot e in message news:uJUoBhKNJH A.4600@TK2MSFTN GP06.phx.gbl...

"Juan T. Llibre" <nomailreplies@ nowhere.comschr ieb:

>!What are the advantages actually achieved of managed code?
>>
>Imho, the greatest achievement for managed code is: it gets rid of "dll hell".

>
DLL hell has even been solved for unmanaged code using the Side-by-Side cache (SxS). It's not an advantage which
would not be possible without a managed code execution model.
>
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Tom Shelton]

Re: What has managed code achieved?

On 2008-10-23, Cor Ligthert[MVP] <Notmyfirstname @planet.nlwrote :

>
Tom,

>>
>With module level values, then in both VB6 and VB.NET you must explicitly
>set
>the object to nothing (or set it to a new reference) if you want the
>object to
>go away before the program terminates. Oops, in VB.NET you might have to
>also
>call dispose on that object.
>>

>
You know that in VB.Net the object is not removed by either dispose or
setting it to nothing.
>
That is done by the Garbage Collector
>

Yes, but it will never be collected as long at the reference remains active -
which is the point. Just as a VB6 object will never terminate under the same
circumstances.

--
Tom Shelton

[Cor Ligthert[MVP]]

Re: What has managed code achieved?

Tom,

As I often forgot(maybe I do this still) the question mark, this time it was
no question. I simply knew that you was knowing this.

:-)

Cor

"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne tschreef in bericht
news:_-2dndbT1vIrj53Un Z2dnUVZ_sbinZ2d @comcast.com...

On 2008-10-23, Cor Ligthert[MVP] <Notmyfirstname @planet.nlwrote :

>>
>Tom,

>>>
>>With module level values, then in both VB6 and VB.NET you must
>>explicitly
>>set
>>the object to nothing (or set it to a new reference) if you want the
>>object to
>>go away before the program terminates. Oops, in VB.NET you might have
>>to
>>also
>>call dispose on that object.
>>>

>>
>You know that in VB.Net the object is not removed by either dispose or
>setting it to nothing.
>>
>That is done by the Garbage Collector
>>

>
Yes, but it will never be collected as long at the reference remains
active -
which is the point. Just as a VB6 object will never terminate under the
same
circumstances.
>
--
Tom Shelton

[Paul Clement]

Re: What has managed code achieved?

On Wed, 22 Oct 2008 14:11:59 -0400, "Juan T. Llibre" <nomailreplies@ nowhere.comwrot e:

¤ re:
¤ !Of course with #2 you could actually kill the process that the web app
¤ !was executing under (with Process Explorer) without needing to stop IIS
¤
¤ The process that the web app was executing under *was* the IIS process.
¤ The only way to update/change a dll in classic ASP was to kill the IIS process.

That's true if the application is configured to run with "Low" application protection. Otherwise,
you have a bit more flexibility when running a web application pooled (Medium) or isolated (High)
since they run in a shared or their own process.


Paul
~~~~
Microsoft MVP (Visual Basic)

[Juan T. Llibre]

Re: What has managed code achieved?

re:
!That's true if the application is configured to run with "Low" application protection

Yes, Ben had made the same observation...a nd the statement was qualified.



Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
=============== =============== ========
"Paul Clement" <UseAdddressAtE ndofMessage@sws pectrum.comwrot e in message
news:9av0g454f0 9jnldnt4r5q29r7 8sjm84n7e@4ax.c om...

On Wed, 22 Oct 2008 14:11:59 -0400, "Juan T. Llibre" <nomailreplies@ nowhere.comwrot e:
>
¤ re:
¤ !Of course with #2 you could actually kill the process that the web app
¤ !was executing under (with Process Explorer) without needing to stop IIS
¤
¤ The process that the web app was executing under *was* the IIS process.
¤ The only way to update/change a dll in classic ASP was to kill the IIS process.
>
That's true if the application is configured to run with "Low" application protection. Otherwise,
you have a bit more flexibility when running a web application pooled (Medium) or isolated (High)
since they run in a shared or their own process.
>
>
Paul
~~~~
Microsoft MVP (Visual Basic)

[Alex Clark]

Re: What has managed code achieved?

.Net goes a long way toward sandboxing all programmers

who are not MS or MS partners. Each new OS version
also continues in that direction. If MS goes the rest of
the way, blocking all "unsafe" code, they'll have the pieces
in place to achieve a radical transformation of the Windows
product, greatly increasing their own control over how the
product is used and enabling the full redefinition of Windows
as the brains of a service appliance rather than as a software
platform.

The chances of such a thing ever happening is marginal at best. MS implied
that the API in Vista would be primarily managed with unmanaged/COM as a
secondary route for programmers not willing to make the .NET leap - but it
never happened. The majority of Vista's API is still unmanaged, and I seem
to recall a variety of new bits were actually COM related (the supposedly
dead technology).

If MS had wanted to try something like this, they could've done so with
COM - and they made more of an effort with that IMO given some of the APIs
that were available back in the Win2K (and prior) days.

Not to mention that if the Euro courts go nuts over something as simple as
an Office XML standard, something tells me MS wouldn't have much luck
forcing a .NET-only programming model down anyone's throats either :-)

[mayayana]

Re: What has managed code achieved?

.Net goes a long way toward sandboxing all programmers

who are not MS or MS partners. Each new OS version
also continues in that direction. If MS goes the rest of
the way, blocking all "unsafe" code, they'll have the pieces
in place to achieve a radical transformation of the Windows
product, greatly increasing their own control over how the
product is used and enabling the full redefinition of Windows
as the brains of a service appliance rather than as a software
platform.

>
The chances of such a thing ever happening is marginal at best. MS

implied

that the API in Vista would be primarily managed with unmanaged/COM as a
secondary route for programmers not willing to make the .NET leap - but it
never happened. The majority of Vista's API is still unmanaged, and I

seem

to recall a variety of new bits were actually COM related (the supposedly
dead technology).
>

The progress is going slow, but the direction is
unmistakable. I think the main holdup on Vista
was the problem that .Net is simply far too bloated:

http://www.microsoft-watch.com/article2/0,1995,1820607,00.asp

If MS had wanted to try something like this, they could've done so with
COM - and they made more of an effort with that IMO given some of the APIs
that were available back in the Win2K (and prior) days.
>
Not to mention that if the Euro courts go nuts over something as simple as
an Office XML standard, something tells me MS wouldn't have much luck
forcing a .NET-only programming model down anyone's throats either :-)
>

I don't think it's a matter of shoving it down anyone's
throat. It's a gradual transition, based on the idea that
selling software has seen its heyday and that services
are the way of the future. (Or at least it's the only idea
anyone has right now for keeping profits up.)

There have been great strides already made in the direction
of a services appliance. In 1999 people were outraged to find
that Windows Update was recording registration data from
visitors. MS promised to stop. By the time of WinXP we had
an OS that updates itself without asking, even if you tell it not to...
An OS that's basically spyware... An OS that reports home
periodically for various things, not least of which is WGA
software that challenges your ownership of the Windows install
every 2 weeks. As I understand it, on Vista even the "real"
admin. can't control the system folder. Only MS has rights there.
Meanwhile, any software that's not signed with MS authenticode
elicits security warnings. And with Vista the average Windows
user is being acclimated to having the same rights on their own
PC as a corporate employee has at work.

In all of those cases there are one or more valid reasons
for the changes made. Nevertheless, those changes are
all going in one direction. They all dovetail with Microsoft's
stated plans. And they're all serving to gradually acclimate both
programmers and end users to the notion that what happens on
their PC is not under their control. Meanwhile, people are
encouraged to pay for software by subscription and are being
acclimated to software that "needs" to check online for
updates on a regular basis....softwa re that blurs the line
between online and local.

MS doesn't need to shove anything down anyone's throat.
They can just gradually make it more and more awkward for
"unmanaged" code to run, while simultaneously increasing the
limits on what unmanaged code is capable of doing, and at
the same time expanding their online offerings.

[Cor Ligthert[MVP]]

Re: What has managed code achieved?

John,

I was yesterday as well looking to HKW his message, but he wrote it
completely correct. (It looks likes that he givis every year shorter, but as
well even more correct answers)

An object is only removed by the Garbage Collector, when it has itself no
reference anymore (that can simple be because it goes out of scope) and
which everybody forgets, no other object are pointing anymore to it (to use
another word).

This is in fact impossible to do by hand in complex situations and is
therefore one of the main advantages from managed code.

What HKW wrote about dispose in your follow up question is in my idea as
well the only correct answer about the Dispose methods.

Cor




"John Saunders" <no@dont.do.tha t.comschreef in bericht
news:OYb3QhKNJH A.2884@TK2MSFTN GP06.phx.gbl...

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.atwrot e in message
news:eWbhvYKNJH A.468@TK2MSFTNG P06.phx.gbl...

>"Scott M." <s-mar@nospam.nosp amschrieb:

>>The point being that in .NET, the developer doesn't write memory
>>management code, as was required in VB 6, and that is one advantage of
>>working in a managed environment.

>>
>Well, I have to disagree. Even in VB you have to remove references to
>objects if you do not need them any more. For sure, you do not have to
>clean up circular references, but it has even been possible to avoid
>circular references in VB (by chosing another architecture or by using
>weak references).

>
Would you mind being more specific? Do you mean that in VB.NET we have to
remove references to objects if we don't need them? Do you mean that this
is done by calling Dispose?
>
--
John Saunders | MVP - Connected System Developer

[Cor Ligthert[MVP]]

Re: What has managed code achieved?

Mayama,

Why don't you make it yourself and sell it, you become rich man, you should
not shout that here.

jmo

Cor

"mayayana" <mayaXXyana@rcX Xn.comschreef in bericht
news:etDV0dUNJH A.3496@TK2MSFTN GP04.phx.gbl...

.Net goes a long way toward sandboxing all programmers
who are not MS or MS partners. Each new OS version
also continues in that direction. If MS goes the rest of
the way, blocking all "unsafe" code, they'll have the pieces
in place to achieve a radical transformation of the Windows
product, greatly increasing their own control over how the
product is used and enabling the full redefinition of Windows
as the brains of a service appliance rather than as a software
platform.

>>
>The chances of such a thing ever happening is marginal at best. MS

implied

>that the API in Vista would be primarily managed with unmanaged/COM as a
>secondary route for programmers not willing to make the .NET leap - but
>it
>never happened. The majority of Vista's API is still unmanaged, and I

seem

>to recall a variety of new bits were actually COM related (the supposedly
>dead technology).
>>

The progress is going slow, but the direction is
unmistakable. I think the main holdup on Vista
was the problem that .Net is simply far too bloated:
>

http://www.microsoft-watch.com/article2/0,1995,1820607,00.asp

>

>If MS had wanted to try something like this, they could've done so with
>COM - and they made more of an effort with that IMO given some of the
>APIs
>that were available back in the Win2K (and prior) days.
>>
>Not to mention that if the Euro courts go nuts over something as simple
>as
>an Office XML standard, something tells me MS wouldn't have much luck
>forcing a .NET-only programming model down anyone's throats either :-)
>>

>
I don't think it's a matter of shoving it down anyone's
throat. It's a gradual transition, based on the idea that
selling software has seen its heyday and that services
are the way of the future. (Or at least it's the only idea
anyone has right now for keeping profits up.)
>
There have been great strides already made in the direction
of a services appliance. In 1999 people were outraged to find
that Windows Update was recording registration data from
visitors. MS promised to stop. By the time of WinXP we had
an OS that updates itself without asking, even if you tell it not to...
An OS that's basically spyware... An OS that reports home
periodically for various things, not least of which is WGA
software that challenges your ownership of the Windows install
every 2 weeks. As I understand it, on Vista even the "real"
admin. can't control the system folder. Only MS has rights there.
Meanwhile, any software that's not signed with MS authenticode
elicits security warnings. And with Vista the average Windows
user is being acclimated to having the same rights on their own
PC as a corporate employee has at work.
>
In all of those cases there are one or more valid reasons
for the changes made. Nevertheless, those changes are
all going in one direction. They all dovetail with Microsoft's
stated plans. And they're all serving to gradually acclimate both
programmers and end users to the notion that what happens on
their PC is not under their control. Meanwhile, people are
encouraged to pay for software by subscription and are being
acclimated to software that "needs" to check online for
updates on a regular basis....softwa re that blurs the line
between online and local.
>
MS doesn't need to shove anything down anyone's throat.
They can just gradually make it more and more awkward for
"unmanaged" code to run, while simultaneously increasing the
limits on what unmanaged code is capable of doing, and at
the same time expanding their online offerings.
>
>

[Herfried K. Wagner [MVP]]

Re: What has managed code achieved?

"Cor Ligthert[MVP]" <notmyfirstname @planet.nlschri eb:

An object is only removed by the Garbage Collector, when it has itself no
reference anymore (that can simple be because it goes out of scope) and
which everybody forgets, no other object are pointing anymore to it (to
use another word).

That's not what I said.

Consider the objects A, B, and C, and -denoting a reference:

A -B -C

If A can be reached from the "running code", B and C cannot be finalized.

However, when removing the reference from A to B

A B -C

and neither B nor C can be reached from the "running code", both objects can
be destroyed by the GC although there is a reference from B to C. This even
works if there are circular references between these objects.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Gregory A. Beamer \(Cowboy\) - MVP]

Re: What has managed code achieved?


"Ben Voigt [C++ MVP]" <rbv@nospam.nos pamwrote in message
news:elKpPJHNJH A.276@TK2MSFTNG P02.phx.gbl...

Gregory A. Beamer (Cowboy) - MVP wrote:

>Less Blue Screens by junior developers. ;-)

>
Blue screens result from kernel-mode bugs. Always. .NET doesn't change
anything in kernel mode.

There was a smiley, but my statement still holds. He asked for advantages of
CLR. As you have stated, I cannot get that deep in the CLR, so no blue
screens. ;-)

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog

http://feeds.feedburner.com/GregoryBeamer#

or just read it:

http://feeds.feedburner.com/GregoryBeamer

*************** *************** **************
| Think outside the box! |
*************** *************** **************

[Cor Ligthert[MVP]]

Re: What has managed code achieved?

Herfried,

It is friday evening, and you know as one of the few exactly what that means
for me, I give you an answer in the weekend.

:-)

Cor

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.atwrot e in message
news:e1558kdNJH A.1148@TK2MSFTN GP05.phx.gbl...

"Cor Ligthert[MVP]" <notmyfirstname @planet.nlschri eb:

>An object is only removed by the Garbage Collector, when it has itself no
>reference anymore (that can simple be because it goes out of scope) and
>which everybody forgets, no other object are pointing anymore to it (to
>use another word).

>
That's not what I said.
>
Consider the objects A, B, and C, and -denoting a reference:
>
A -B -C
>
If A can be reached from the "running code", B and C cannot be finalized.
>
However, when removing the reference from A to B
>
A B -C
>
and neither B nor C can be reached from the "running code", both objects
can be destroyed by the GC although there is a reference from B to C.
This even works if there are circular references between these objects.
>
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Alex Clark]

Re: What has managed code achieved?

The progress is going slow, but the direction is

unmistakable. I think the main holdup on Vista
was the problem that .Net is simply far too bloated:

Something being "far too bloated" has never been a deal-breaker for
Microsoft before, and I doubt it ever will be. One could argue that Windows
and its various subsystems is far too bloated as it stands. Making .NET an
embedded component of the OS and using managed libraries as the only API
method would hardly change that.

I don't think it's a matter of shoving it down anyone's
throat. It's a gradual transition, based on the idea that
selling software has seen its heyday and that services
are the way of the future. (Or at least it's the only idea
anyone has right now for keeping profits up.)

What you're talking about isn't related to embedding the framework into
Windows and using that as the primary API method, you're talking about
software as a service - an idea which MS has been touting and selling (to
varying degrees of success) even before .NET was around.

<largely irrelevant snip>

MS doesn't need to shove anything down anyone's throat.
They can just gradually make it more and more awkward for
"unmanaged" code to run, while simultaneously increasing the
limits on what unmanaged code is capable of doing, and at
the same time expanding their online offerings.

Then they gradually transited in completely the wrong direction with Vista,
didn't they? Aero is completely unmanaged. Why wasn't that .NET based,
seeing as how it was a totally new component of the OS?

I think MS realise that the CLR still hasn't reached the state it needs to
be in to be such an integral part of the OS itself. In future we might see
a change, but I don't see that harming anyone. I don't see it as MS
enforcing their will onto users either. So long as performance doesn't
suffer and we don't lose anything, I'd happily see unmanaged APIs and
(particularly) COM get flushed down the drain in favour of something more
secure, more easily governed, and a whole lot less archaic.

As it stands, I think they'll have to work very hard to kill off unmanaged
code and the C++ gurus that swear by it - after all, they employ a large
number of them. There are also a lot of things that managed code simply
cannot and will never be able to do, namely low level operations. I'd much
rather see a clear distinction where all high level APIs are managed and low
level hardware access is kept unmanaged and raw for performance reasons.