What has managed code achieved?

[Scott M.]

¤ The fact remains, sloppy coding or not, that managing memory in VB 6 was

the
¤ responsibility of the developer and in .NET the CLR manages this for us
to a
¤ much larger degree.

In most instances that's true. That is, unless COM is involved, then all
bets are off.

And, that's all I've been trying to say.

 

[Scott M.]

Inline...

Well, what can I say ... it's all plain wrong, simply.

Oh! Well, thanks for that analysis.

It's not, and never was. As soon as the last object reference is
released, the object gets distroyed.

That is not in dispute. The conversation is about how to make that happen
in VB 6 as opposed to .NET and the consequences of not doing it in both
environments.

I honestly never heard about that in all those years.

Well, then you must be right because that in-depth rebuttal can't possibly
stand scritiny.

If I don't need a particular object instance anymore then I'll set all
references to Nothing or let them run out of scope. If however I still
need it, then I don't. You can call that an "issue" or "memory leak".
I don't. I wonder how the system should know about my plans if I don't
state them?!

You've just made my point (the one that you said was wrong). In VB 6.0, you
had to state your intentions by either destroying your object references or
not. In .NET, you don't.

Strange that I never noticed any difference in all those years. In
fact, by checking whether the Terminate event is executed I can assure
that there *is no difference*.

Again, "all your years" isn't an argument. What COM automation work have
you done that relates to this?

I'm pretty sure it will be hard to find *one*, except Scott, of
course. *g*

Wolfgang

Ask yourself why Microsoft would abandon reference counters in favor of
Garbage Collection and ask yourself if, perhaps, others with "years of
experience" have possible done things you haven't.

 

[Scott M.]

That's not at all what I've said and your reply just indicates that you'd
rather have an argument than understand someting.

Did I ever say that anything was magic? Did I ever say that we don't worry
about object lifetimes?

No and no. That makes the rest of your diatribe moot.

The fact remains that in .NET, you should never have to explicitly set an
object reference to Nothing and doing so can in fact hurt application
performance.

-Scott

 

[Ken Halter]

Again, "all your years" isn't an argument. What COM automation work have
you done that relates to this?

The question should be.... What COM automation work have *you* done that
causes memory leaks? It wasn't the fault of VB6, that much I guarantee. The
COM objects you were using may've not been setup correctly for use with VB6,
but that's not VB's fault.

Ask yourself why Microsoft would abandon reference counters in favor of
Garbage Collection and ask yourself if, perhaps, others with "years of
experience" have possible done things you haven't.

LOL... Let's get Microsoft in here to explain that, eh? There've been many
flamewars over that exact "abandonment" issue... and possibly, others with
"years of experience" could've helped with those memory leak problems you
seemed to have problems with, because they've done things *you* haven't.

There's no reason to Set x = Nothing if x falls out of scope. If you
disagree, provide some proof.

In the case of circular references (which VB6 absolutely does not allow,
between projects, if loaded as a group project), you're on your own. Still,
not the fault of VB6 and "years of experience" gives you the tools required
to cure problems like that. A simple Debug.Print in Class_Terminate will
tell the world when the reference count = 0 for any object.

 

[mayayana]

What are the advantages actually achieved of managed code? I am not
talking

of theory but in reality.

Something that most people don't seem to notice, in
all this talk of the pros and cons of memory management,
is the achievement from Microsoft's business perspective.

.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.

As a service appliance a Windows PC can have unhackable
DRM, hosted advertising, subscription software - and limited,
high-level, Java-style programming options. That direction holds
the possible promise of better stability, security and profits
for MS in the long term... Or at least they seem to think so.

Whether or not it's a positive achievement is in the eye of
the beholder.

 

[Herfried K. Wagner [MVP]]

In VB 6, if you didn't explicitly destroy your object references, you not
only wasted memory, but also potentially tie up external resources. So,
to solve those two problems the developer HAD to dereference objects.

In most cases this was not necessary because references were removed
automatically when the (local) variables went out of scope (for example,
when leaving a procedure). The only fundamental difference is IMO the
automatical cleanup of circular references in .NET, which is a valuable
advantage.

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).

 

[Herfried K. Wagner [MVP]]

You've just made my point (the one that you said was wrong). In VB 6.0,
you had to state your intentions by either destroying your object
references or not. In .NET, you don't.

It's still similar (but different) in .NET: You have to remove references
to the objects you want to be destroyed to make them unreachable from the
current points of execution. Otherwise the CLR does not know that these
objects should be destroyed either.

 

[Herfried K. Wagner [MVP]]

!> 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.

 

[John Saunders]

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?

 

[Cor Ligthert[MVP]]

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:
!> (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/
======================================

 

[Juan T. Llibre]

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/
======================================

 

[Cor Ligthert[MVP]]

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

 

[Paul Clement]

¤ 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:
!> That's true if the application is configured to run with "Low" application protection

Yes, Ben had made the same observation...and 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/
======================================

 

[Alex Clark]

.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]

.Net goes a long way toward sandboxing all programmers

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....software 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]]

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?

Yes and no. All references which could be used to access the object must be
removed in order to enable the garbage collector to destroy it.

Do you mean that this is done by calling Dispose?

No, this is not done using 'Dispose'. 'IDisposable.Dispose' is used to
deterministically release unmanaged resources the CLR is not aware of.

 

[Cor Ligthert[MVP]]

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

 

[Cor Ligthert[MVP]]

Mayama,

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

jmo

Cor