DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 25

Thread: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

  1. #1
    Mark Burns Guest

    DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    > William Cleveland wrote:
    >
    > Andy Chevin wrote:
    > >
    > > Ignoring the backwards compatibility, runtime implications and

    comparisons
    > > with C#, can anybody think of any areas where VB6 is better than VB.net?
    > >

    > DF would be nice, but I think I understand why they got rid of it, and
    > it's worth it.


    Actually, I've been having a bit of an eMail exchange with an MS employee,
    who I won't name, and we touched on that subject. I do NOT understand why
    they did away with DF _for VB_. The reasons stated for the lack of a
    workable DF solution for the .Net platform *as a whole* were primarily
    complications arising from the overhead of doing a good job of refcounting
    in a free/multi-threaded environment. OK, that's fine as far as it goes.

    However, I think they stopped thinking about the problem too soon because
    they were looking at the wrong perspective.

    In VB6 we did not have free-threading, and how much code was really written
    that took advantage of spawning multiple threads within the
    apartment-threading architecture that was made possible, but certainly not
    simple, in VB6? By %-age, I wager that is a very small number of the total
    VB6 code/codebase in place in business, although I am very willing to be
    shown I am wrong in thinking that way.

    If my assertion/assumption is anywhere near correct <and I'll grant that may
    be a very big IF>, then, as is the case for the property set/get question,
    VB.net lost VB6 functionality due to factors that were not directly related
    to carying it's current functionality and user codebases foreward.
    Anotherwords, if much/most of the VB6 code that could/would have been
    version-upgraded would not have run afoul of threading issues which would
    have caused DF refcounting problems in .Net, this codebase lost the DF
    functionality for no net<or, .Net> gain.

    Suppose it were possible to have the VB.Net compiler enforce a rule to the
    effect that DF - or a pseudo-DF & refcounting capability (and your current
    codebase's _Terminate events) operate - even at a performance cost, so long
    as the application used only one execution thread? Would that easier
    foreward-migration be worth the execution speed trade-off? I would think so.

    I attempted, many moons ago in the vb.vb7 newsgroup, to put a suggestion
    forward that could, possibly, have made that DF/pseudo-DF/refcounting
    semantic model possible to do (IMO, at least). At that time, I proffered
    that suggestion as a framework-wide solution, but if cast in this light, as
    VB-only single-threaded app possibility instead, I think it really would be
    a viable alternative for a large chunk of VB6 code moving forward...with all
    the benefits of easier foreward code-migration.

    Another comment that relates to this question - by direct extension - is
    that, in conversation with this MS person, it was thought that the many
    VB.Net "gratuitous incompatibilities" arose out of the "well, because of
    this DF thing we have to break the 100% backwards compatibility rule for VB,
    here"-thinking led to a dam-break of pent-up "urge to change things" <for
    whatever reason> and the raft of "gratuitous incompatibilities".

    If this alternate solution were to make a pseudo-DF capability _*possible*_
    <note I mean "possible", not likely/unlikely etc.,.> for VB.Net, then, the
    originating impetus for that dam-break of "gratuitous",
    backwards-compatibilty-compromising changes is lost...perhaps there might
    then be an impetus for MS to provide a "OPTION VB6Compatible"/"OPTION
    NETCompatible" syntax evaluation switch...?




  2. #2
    Jonathan Allen Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    > I do NOT understand why
    > they did away with DF _for VB_.


    DF requires a ref counting system like COM. Since GC systems have better
    (theoretical) performance and no memory leaks, they choose it for the CLR.
    In order for VB to become a serious language, it had to buy in to the whole
    CLI (read .Net) system.

    > Suppose it were possible to have the VB.Net compiler enforce a rule to the
    > effect that DF - or a pseudo-DF & refcounting capability (and your current
    > codebase's _Terminate events) operate - even at a performance cost, so

    long
    > as the application used only one execution thread?


    That wouldn't work because the rest of the framework would also have to use
    that method.

    > If this alternate solution were to make a pseudo-DF capability

    _*possible*_
    > <note I mean "possible", not likely/unlikely etc.,.> for VB.Net


    Either the whole system is reference counted, or none of it is. You can't
    build a reasonable system that mixes the two.

    ***********

    Remember, you don't necessarily need DF. Finalize will be called eventually,
    and you can always call a GC method to request immediate finalization of
    pending objects.

    --
    Jonathan Allen

    "When considering performance, one must rate accuracy over speed. No one
    cares how fast you can give the wrong answer." - Anonymous


    "Mark Burns" <mark@iolofpa.com> wrote in message
    news:3a7f2113@news.devx.com...
    > > William Cleveland wrote:
    > >
    > > Andy Chevin wrote:
    > > >
    > > > Ignoring the backwards compatibility, runtime implications and

    > comparisons
    > > > with C#, can anybody think of any areas where VB6 is better than

    VB.net?
    > > >

    > > DF would be nice, but I think I understand why they got rid of it, and
    > > it's worth it.

    >
    > Actually, I've been having a bit of an eMail exchange with an MS employee,
    > who I won't name, and we touched on that subject. I do NOT understand why
    > they did away with DF _for VB_. The reasons stated for the lack of a
    > workable DF solution for the .Net platform *as a whole* were primarily
    > complications arising from the overhead of doing a good job of refcounting
    > in a free/multi-threaded environment. OK, that's fine as far as it goes.
    >
    > However, I think they stopped thinking about the problem too soon because
    > they were looking at the wrong perspective.
    >
    > In VB6 we did not have free-threading, and how much code was really

    written
    > that took advantage of spawning multiple threads within the
    > apartment-threading architecture that was made possible, but certainly not
    > simple, in VB6? By %-age, I wager that is a very small number of the total
    > VB6 code/codebase in place in business, although I am very willing to be
    > shown I am wrong in thinking that way.
    >
    > If my assertion/assumption is anywhere near correct <and I'll grant that

    may
    > be a very big IF>, then, as is the case for the property set/get question,
    > VB.net lost VB6 functionality due to factors that were not directly

    related
    > to carying it's current functionality and user codebases foreward.
    > Anotherwords, if much/most of the VB6 code that could/would have been
    > version-upgraded would not have run afoul of threading issues which would
    > have caused DF refcounting problems in .Net, this codebase lost the DF
    > functionality for no net<or, .Net> gain.
    >
    > Suppose it were possible to have the VB.Net compiler enforce a rule to the
    > effect that DF - or a pseudo-DF & refcounting capability (and your current
    > codebase's _Terminate events) operate - even at a performance cost, so

    long
    > as the application used only one execution thread? Would that easier
    > foreward-migration be worth the execution speed trade-off? I would think

    so.
    >
    > I attempted, many moons ago in the vb.vb7 newsgroup, to put a suggestion
    > forward that could, possibly, have made that DF/pseudo-DF/refcounting
    > semantic model possible to do (IMO, at least). At that time, I proffered
    > that suggestion as a framework-wide solution, but if cast in this light,

    as
    > VB-only single-threaded app possibility instead, I think it really would

    be
    > a viable alternative for a large chunk of VB6 code moving forward...with

    all
    > the benefits of easier foreward code-migration.
    >
    > Another comment that relates to this question - by direct extension - is
    > that, in conversation with this MS person, it was thought that the many
    > VB.Net "gratuitous incompatibilities" arose out of the "well, because of
    > this DF thing we have to break the 100% backwards compatibility rule for

    VB,
    > here"-thinking led to a dam-break of pent-up "urge to change things" <for
    > whatever reason> and the raft of "gratuitous incompatibilities".
    >
    > If this alternate solution were to make a pseudo-DF capability

    _*possible*_
    > <note I mean "possible", not likely/unlikely etc.,.> for VB.Net, then, the
    > originating impetus for that dam-break of "gratuitous",
    > backwards-compatibilty-compromising changes is lost...perhaps there might
    > then be an impetus for MS to provide a "OPTION VB6Compatible"/"OPTION
    > NETCompatible" syntax evaluation switch...?
    >
    >
    >




  3. #3
    Phil Weber Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    > Remember, you don't necessarily need DF. Finalize will be
    > called eventually, and you can always call a GC method to
    > request immediate finalization of pending objects.
    > --
    > Jonathan Allen


    ....and everything from this point on could have been trimmed from your post.
    Please quote intelligently, everyone! (
    http://news.devx.com/newspolicy.asp )
    ---
    Phil Weber



  4. #4
    Bill McCarthy Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)


    "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
    news:3a7f2992@news.devx.com...
    >
    > Either the whole system is reference counted, or none of it is. You can't
    > build a reasonable system that mixes the two.
    >


    woooo !! Thanks for pointing that out !! There I was thinking you could
    call COM objects from VB.NET and interact/interop with them, but as you
    pointed out that can't be the case after all COM is reference counted !!
    (BTW: yes, that is sarcasm)


    >
    > Remember, you don't necessarily need DF. Finalize will be called

    eventually,
    > and you can always call a GC method to request immediate finalization of
    > pending objects.
    >


    Uh, huh. And the overhead involved in suspending all threads while a
    complete gc.collect is called on ALL generations ?? And let's not forget you
    have no control on the order of finalise events being fired for objects
    released between collections. IOW: no ordered teardown. This has been
    discussed in detail in the old vb7 ng, so search the archives if you need
    more details. Also refer to Brian Harry's post on DF. I think that discusses
    most of the major issues.











  5. #5
    Mark Burns Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)


    "Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
    news:3a7ff592@news.devx.com...
    >
    > "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
    > news:3a7f2992@news.devx.com...
    > >
    > > Either the whole system is reference counted, or none of it is. You

    can't
    > > build a reasonable system that mixes the two.
    > >

    >
    > woooo !! Thanks for pointing that out !! There I was thinking you could
    > call COM objects from VB.NET and interact/interop with them, but as you
    > pointed out that can't be the case after all COM is reference counted !!
    > (BTW: yes, that is sarcasm)


    Exactl;y, Bill.
    Due to COM interop, and it's DF/refcounting requirements, there _must_ be a
    means of having the two systems, refcounting/DF and gc-based, co-exist
    *simultaneously*.

    ....and since there _must_ be a means of doing this, I accuse the VB team of
    stopping thinking about the problem too soon, because they failed to
    accomplish what is clearly _POSSIBLE_.


    > > Remember, you don't necessarily need DF. Finalize will be called

    > eventually,
    > > and you can always call a GC method to request immediate finalization of
    > > pending objects.
    > >

    >
    > Uh, huh. And the overhead involved in suspending all threads while a
    > complete gc.collect is called on ALL generations ?? And let's not forget

    you
    > have no control on the order of finalise events being fired for objects
    > released between collections. IOW: no ordered teardown. This has been
    > discussed in detail in the old vb7 ng, so search the archives if you need
    > more details. Also refer to Brian Harry's post on DF. I think that

    discusses
    > most of the major issues.


    Yes, Brian's posted discusses these issues - but from a global .Net-wide
    perspective only. He mentioned that they did consider a VB-only solution,
    but they gave up on it. I think they erred in doing so, perhaps because they
    were trying to go for the whole ball of wax, rather than a more limited, and
    perhaps therefore approchable alternative <i.e. with the limits of my
    single-threadedness caveat/rule.>

    Bill, you're a smart guy, could you do me a favor and revisit my earlier
    post(s) <in the vb.vb7 group subjects: "I must not understand something
    here...reF & GC" and "DF and GC question" - subthread in there with Zane>
    containing my proposed solution and venture an opinion on if/why it would or
    would not work as I'm envisioning it - or better yet a derivative idea that
    might<g>?



  6. #6
    Mark Burns Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)


    "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
    news:3a7f2992@news.devx.com...
    > > Suppose it were possible to have the VB.Net compiler enforce a rule to

    the
    > > effect that DF - or a pseudo-DF & refcounting capability (and your

    current
    > > codebase's _Terminate events) operate - even at a performance cost, so

    > long
    > > as the application used only one execution thread?

    >
    > That wouldn't work because the rest of the framework would also have to

    use
    > that method.


    Would it? really? I can think of some approaches that might get us there -
    VB-only, but it would involve some compiler help to make it work (think:
    self-modifying code ala Lisp).

    > > If this alternate solution were to make a pseudo-DF capability

    > _*possible*_
    > > <note I mean "possible", not likely/unlikely etc.,.> for VB.Net

    >
    > Either the whole system is reference counted, or none of it is. You can't
    > build a reasonable system that mixes the two.


    two words: COM Interop. - kinda mixes the two doesn't it?
    You are either confirming my deep-seated fear of horrible things lurking
    here, or you are disproving the thesis of your statement. Which is it?

    > ***********
    >
    > Remember, you don't necessarily need DF.


    ....unless you are hoping to forward-migrate code that relies on that design
    pattern to work. HTH.




  7. #7
    Paul Vick [MSFT] Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    When you interoperate with a COM2 object, a wrapper is created to maintain
    the reference count on the COM2 object so it won't go away. That wrapper is
    then under control of the garbage collector. So the COM2 object won't go
    away until it's garbage collected. So there is no coexistance -- .NET makes
    every thing garbage collected.

    Paul Vick [MSFT]

    "Mark Burns" <mark@iolofpa.com> wrote in message
    news:3a804659@news.devx.com...
    >
    > "Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
    > news:3a7ff592@news.devx.com...
    > >
    > > "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
    > > news:3a7f2992@news.devx.com...
    > > >
    > > > Either the whole system is reference counted, or none of it is. You

    > can't
    > > > build a reasonable system that mixes the two.
    > > >

    > >
    > > woooo !! Thanks for pointing that out !! There I was thinking you could
    > > call COM objects from VB.NET and interact/interop with them, but as you
    > > pointed out that can't be the case after all COM is reference counted !!
    > > (BTW: yes, that is sarcasm)

    >
    > Exactl;y, Bill.
    > Due to COM interop, and it's DF/refcounting requirements, there _must_ be

    a
    > means of having the two systems, refcounting/DF and gc-based, co-exist
    > *simultaneously*.
    >
    > ...and since there _must_ be a means of doing this, I accuse the VB team

    of
    > stopping thinking about the problem too soon, because they failed to
    > accomplish what is clearly _POSSIBLE_.





  8. #8
    Mark Burns Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)


    "Paul Vick [MSFT]" <paulv@microsoft.com> wrote in message
    news:3a8049fe@news.devx.com...
    > When you interoperate with a COM2 object, a wrapper is created to maintain
    > the reference count on the COM2 object so it won't go away. That wrapper

    is
    > then under control of the garbage collector. So the COM2 object won't go
    > away until it's garbage collected. So there is no coexistance -- .NET

    makes
    > every thing garbage collected.


    OK, Paul, accepting that, then you can have COM<1> stuff
    "co-exist"</cooperate?> in GC-managed .Net memory-spaces by "wrapping" them,
    right?
    Why would the reverse not also work? ("wrapping" DF/refcounting semantics
    aroung a subset of .Net objects <with a subset of "carrier"-type wrappers
    for those nonDF-flagged objects that merely reference DF-flagged items> -
    using some self-modifying code tricks and some compiler help...? - even if
    there would be a bunch of overhead, as a stop-gap path forward for current
    DF-dependent code in VB5/6, I still maintain that the effort would pay for
    itself in eased <if only psychologically> upward app migrations to .Net.

    > Paul Vick [MSFT]


    BTW - nice to hear your voice here again/still... :-)




  9. #9
    Mike Mitchell Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    On Mon, 5 Feb 2001 16:54:10 -0500, "Mark Burns" <mark@iolofpa.com>
    wrote:

    >If this alternate solution were to make a pseudo-DF capability _*possible*_
    ><note I mean "possible", not likely/unlikely etc.,.> for VB.Net, then, the
    >originating impetus for that dam-break of "gratuitous",
    >backwards-compatibilty-compromising changes is lost...perhaps there might
    >then be an impetus for MS to provide a "OPTION VB6Compatible"/"OPTION
    >NETCompatible" syntax evaluation switch...?


    I cannot believe that all the people involved in VB.NET at Microsoft
    were as one behind the breaking of compatibility. I am sure that some
    of them would have been highly critical of the decision. Whether they
    were then persuaded over to the "break" camp, or bribed, or indeed
    left the company, who will ever know?

    But in a large body of men (and not a few female men) there will
    always be a subset who think the opposite.

    WHERE ARE THEY NOW???

    MM

  10. #10
    Mike Mitchell Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    On Mon, 5 Feb 2001 14:23:29 -0800, "Jonathan Allen"
    <greywolfcs@bigfoot.com> wrote:

    >DF requires a ref counting system like COM. Since GC systems have better
    >(theoretical) performance and no memory leaks, they choose it for the CLR.
    >In order for VB to become a serious language, it had to buy in to the whole
    >CLI (read .Net) system.


    If GC is so wonderful, why did Microsoft spend billions of dollars
    (and getting us to spend further billions) developing (using) COM and
    DF? And what's to stop them from changing it again in a few years'
    time? All you need is a new set of ex-Harvard 'geniuses', when the
    current lot have set off for pastures new, their millionaire's
    certifications in their pockets, and the new brooms will sweep in yet
    another new idea.

    Instead of changing just about the whole of Windows by dumping COM on
    its bloated little *** and sayin "You're on your own now, kid", they
    could have got it and ref counting and DF all to work properly.

    Ah, but perhaps they couldn't do that. Perhaps the fundamental design
    of COM was flawed from the outset. In which case, what's to say that
    ..NET and GC aren't flawed, too?

    If the whole of .NET had been a COMPLETELY new design, literally from
    the ground up, without *any* pre-existing code - no DOS, no Windows,
    no nuttin' at all, just a raw hard disk and a bunch of coders, then
    .NET could be the absolutely best thing to come out of Seattle since
    Starbucks. But as it is, I can only view it as a bolt-on goody, yet
    another layer on top of the core Windows code, like the browser layer,
    the ADO layer, and the other layers, which MS either doesn't want to
    touch or cannot risk touching for fear of bringing down the whole
    edifice.

    How much original DOS code is still in Windows ME?

    Otherwise, all I see for the next twenty years (or longer) is
    continued layering over the layers. This will result in the most
    massively bloated OS unimaginable. That's right, it's on a par with
    those equations where you just multiply by another number and it's one
    of those "more than the grains of sand in the universe" jobbies. If
    the size of Windows now is already humungous for what it's actually
    used for (writing documents, sending e-mails, doing calculations,
    downloading, playing music), how much bigger *can* it become?

    I wish Microsoft would have the foresight to pull its troops back into
    the laager for a few years, concentrate on producing excellent,
    bug-free code in the products they currently have, and plan - but
    thoroughly plan - the next browser-OS in minute detail.

    If companies are prepared now to put a completely different OS (e.g.
    Linux) on to their systems, then they would be just as willing to put
    a completely NEW Microsoft OS on instead. The trouble is, Microsoft
    wants jam today, every day, instead of eating bread now and
    anticipating lots of jam in a few years' time. I am sure that the
    functionality which Windows today is capable of could be condensed
    down to a 20 MB chip if the code wasn't so bloated. We are STILL ONLY
    MOVING BITS FROM A TO B !! That's ALL we are doing!

    MM

  11. #11
    Sjoerd Verweij Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    Mike,

    > If the whole of .NET had been a COMPLETELY new design, literally from
    > the ground up, without *any* pre-existing code - no DOS, no Windows,
    > no nuttin' at all, just a raw hard disk and a bunch of coders, then
    > NET could be the absolutely best thing to come out of Seattle since
    > Starbucks.


    That's actually one of the greatest opportunities that .NET provides, and
    I'm totally amazed that noone sees it. Assuming .NET-only applications,
    (okay, this will probably take 10 years for anything other than
    well-controlled corporate environments), what is to prevent Microsoft to
    finally get rid of Windows, or at the very least redo it, and do it right?

    > How much original DOS code is still in Windows ME?


    That's what Whistler (oops, XP -- I'm already seeing "smashed with a
    bonecrushing sound") is for. The truth is people will not move to an NT base
    if it doesn't run stupid old code. OS backwards compatibility is *hard*.

    Anyway, in lots of ways you're right. It's just business decisions that get
    in the way of really good products (sweet irony).

    Sjoerd




  12. #12
    Zane Thomas Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    On Tue, 06 Feb 2001 22:44:27 GMT, kylix_is@hotmail.com (Mike Mitchell)
    wrote:

    >If GC is so wonderful, why did Microsoft spend billions of dollars
    >(and getting us to spend further billions) developing (using) COM and
    >DF?


    You obviously haven't what I wrote about that in VBPJ.

    Summary: A system which creates and destroys lots of small objects
    frequently is better supported by GC than by RefCounting. And, designing
    around large long-lived COM objects is being left behind in favor of a
    more finely grained object system.

    You might not agree with the goal of supporting such a fine-grained
    system, but that doesn't negate the point re: GC.


    ---
    Ice Z - Straight Outta Redmond

  13. #13
    Bill McCarthy Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    Hi Paul,

    "Paul Vick [MSFT]" <paulv@microsoft.com> wrote in message
    news:3a8049fe@news.devx.com...
    > When you interoperate with a COM2 object, a wrapper is created to maintain
    > the reference count on the COM2 object so it won't go away. That wrapper

    is
    > then under control of the garbage collector. So the COM2 object won't go
    > away until it's garbage collected. So there is no coexistance -- .NET

    makes
    > every thing garbage collected.
    >


    The actual COM object itself though is not in the GC, only a wrapper that
    increments/decrements the COM object's ref count is in the GC.

    Also, not everything in .NET is garbage collected. A value type ( as opposed
    to a reference type including boxed value types) is not GC'd if it is at
    proc level. AFAIK, it even never gets to the GC heaps. Add to that you can
    used unmanaged memory blocks, either via unsafe code, or via marshal alloc
    methods.



  14. #14
    Paul Vick [MSFT] Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    What I was saying is that everything in .NET is garbage collected (and that
    garbage collection of COM2 objects is accomplished using wrappers). The
    opposite of that is that everything in .NET is reference counted. So still
    no coexistance.

    The subset idea was definitely considered but it doesn't really work. In the
    subset scheme is System.Object reference counted or garbage collected?

    Paul Vick [MSFT]

    "Mark Burns" <mark@iolofpa.com> wrote in message
    news:3a805b02@news.devx.com...
    >
    > "Paul Vick [MSFT]" <paulv@microsoft.com> wrote in message
    > news:3a8049fe@news.devx.com...
    > > When you interoperate with a COM2 object, a wrapper is created to

    maintain
    > > the reference count on the COM2 object so it won't go away. That wrapper

    > is
    > > then under control of the garbage collector. So the COM2 object won't go
    > > away until it's garbage collected. So there is no coexistance -- .NET

    > makes
    > > every thing garbage collected.

    >
    > OK, Paul, accepting that, then you can have COM<1> stuff
    > "co-exist"</cooperate?> in GC-managed .Net memory-spaces by "wrapping"

    them,
    > right?
    > Why would the reverse not also work? ("wrapping" DF/refcounting semantics
    > aroung a subset of .Net objects <with a subset of "carrier"-type wrappers
    > for those nonDF-flagged objects that merely reference DF-flagged items> -
    > using some self-modifying code tricks and some compiler help...? - even if
    > there would be a bunch of overhead, as a stop-gap path forward for current
    > DF-dependent code in VB5/6, I still maintain that the effort would pay for
    > itself in eased <if only psychologically> upward app migrations to .Net.
    >
    > > Paul Vick [MSFT]

    >
    > BTW - nice to hear your voice here again/still... :-)
    >
    >
    >




  15. #15
    Mark Burns Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    "Paul Vick [MSFT]" <paulv@microsoft.com> wrote in message
    news:3a80a932$1@news.devx.com...
    > What I was saying is that everything in .NET is garbage collected (and

    that
    > garbage collection of COM2 objects is accomplished using wrappers). The
    > opposite of that is that everything in .NET is reference counted. So still
    > no coexistance.
    >
    > The subset idea was definitely considered but it doesn't really work. In

    the
    > subset scheme is System.Object reference counted or garbage collected?


    Paul,
    That answer is easy, System.Object is Garbage collected, BUT, a smart-enough
    bit of self-modifying code could _also_ allow it to "wrap" itself with
    cascading Start-of-Scope/End-of-Scope calls as-needed reflecting itself as
    either a "DF-Object-container" or a "DF-required object", which in no way
    affects its eventual reclamation via the gc mechanism. All a pseudo-DF
    mechanism need do is execute the resource-releasing Dispose call on its
    refcount=0 <well, and maybe an automatic, trailing, Me=Nothing t'boot>. The
    self-modifying code <or, more correctly the CLR's object instantiation code>
    would let it automagically understand if any object it contains/references
    is DF-required-flagged and, as needed, and only when needed, automatically
    generate passthru code to the DF-required object, which itself generates the
    refcounting/DF code for itself. Thereby, strictly on an as-needed basis,
    taking the DF code overhead hit only when necessary, enable pseudo-DF
    capabilities ON TOP of the existing gc system. Yeah, it might seem kludgy,
    but I'm reasonably certain it could be implemented cleanly once those pesky
    details are all ironed out.

    Now, you guys had to have considered this, or something like it...you guys
    aren't stupid. Was the obstacle here the multi-threading, as Brian Harry
    indicated <and is a simplifying rule for apps/assemblies like "DF works only
    in a single-threaded app" even possible for a work-around/limitation?>, or
    was this option really somehow not considered?

    Why do this? well...<shooting from the hip mode = engaged>
    1) To permit the VB6-era code to migrate forward far more easily without
    _requiring_, right up front, a possibly significant redesign <as if you
    didnlt know that already...<g>>
    2) to permit developers the choice in controlling object tear-down in
    those...circumstances where it makes sense for them to do so <or...when
    they've coded themselves into a corner and that is the best^h^h^h^heasiest
    fix>.
    3) It may also allow some <more?> "direct" support of COM objects without
    the current wrapper method(s) and their consequent overhead on each/every
    call to/from them <kinda like the old 16-bit thunmking layer's overhead?>?
    </shooting from the hip mode = engaged>

    Regards,
    Mark Burns




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center