My view of the world - Page 3


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 4 FirstFirst 1234 LastLast
Results 31 to 45 of 56

Thread: My view of the world

  1. #31
    Rob Teixeira Guest

    Re: My view of the world



    There's another fairly good tool that nobody's been talking about either.
    As a machine admin, you can coerce an assembly to use a version of another
    assembly (the CLR in this case) that was not the one that was originally
    bound to. So, let's take a look at a scenario:

    1) vendor creates new app and binds to CLR 1.0
    2) user installs app + CLR 1.0
    3) MS creates CLR 2.0 18 months down the road (hypothetically)
    4) user installs CLR 2.0 (now has 1.0 and 2.0 on system)
    5) user coerces app to use 2.0 (setting in an XML file)
    6) if app works with no problem (2.0 really turns out to be compatible),
    uninstall 1.0
    7) if not, set the binding to a version that does work

    Can't do that in VB6!

    -Rob


    "Kathleen \(MS MVP\)" <someone@nomail.com> wrote:
    >Mike,
    >
    >Which assuming you have more copies of applications than you have versions
    >of the CLR (a likely assumption) you are far more wasteful with your
    >suggestion.
    >
    >Kathleen
    >
    >



  2. #32
    Mike Mitchell Guest

    Re: My view of the world

    On Mon, 18 Feb 2002 18:32:14 -0700, "Kathleen \(MS MVP\)"
    <someone@nomail.com> wrote:

    >Which assuming you have more copies of applications than you have versions
    >of the CLR (a likely assumption) you are far more wasteful with your
    >suggestion.


    How so? Even if I had 10 apps running continually (which hardly anyone
    does), that would only be the *same* ten apps, not 10 apps plus
    "several" runtimes, some of which could be redundant and just "sitting
    there".

    Also, each app would only need to include the functionality *it*
    actually uses, not the entire kitchen sink and all utensils, so each
    app would be an incredibly compact way of packaging the logic for the
    app in question. If I have an app to do, say, FTP sending, why should
    it need to call upon support for a hundred and one other bits of
    framework functionality it ain't never gonna use?

    When the framework BECOMES the operating system, sure, you can address
    the situation again. As of now, our "runtime" is really Windows, under
    the hood, and .NET is just another layer of abstraction to plonk on
    top of it. How many tiers should the wedding cake have, for God's
    sake?

    MM

  3. #33
    Mike Mitchell Guest

    Re: My view of the world

    On Tue, 19 Feb 2002 02:04:20 GMT, zane@mabry.com (Zane Thomas [.NET
    MVP]) wrote:

    >
    >>We have laws now for dealing with rubbish.

    >
    >Which explains why you're posting on an american news server.


    Heh heh! Could that last comment of yours be the pit bull that turns
    on its owner?

    MM

  4. #34
    Mike Mitchell Guest

    Re: My view of the world

    On Mon, 18 Feb 2002 16:28:15 -0700, "Kathleen \(MS MVP\)"
    <someone@nomail.com> wrote:

    >Mike is correct


    of course I am <g>

    > that they both "clutter" the users machine. COM GUID stuff
    >came to pass because the relative size of components (ours and MS's)
    >relative to the available memory and hard disk space required sharing. Those
    >days are gone. What user machine notices 20Mb. So now MS gives you complete
    >control, which means (thank goodness) you don't have to trust future acts by
    >anyone.


    The more I think (again) about having a single Exe the more I am
    warming to the idea. They do say that all great ideas sound strange to
    begin with, and this could just be the Next Big Thing. Think about it:
    No more DLL **** - there ain't no DLLs! No more massive downloads: You
    just incorporate ONLY the functionality the app needs. No versioning
    problems: Either you have the app or you don't, and that is the sum
    total of versioning problems.

    To prove the worth of this idea of mine, just count up the number of
    Exe's on your drive C, and then count up the *total* number of files!

    MM

  5. #35
    Mike Mitchell Guest

    Re: My view of the world

    On 18 Feb 2002 17:44:14 -0800, "Kevin Moore" <Kevin@MooreSSI.com>
    wrote:

    >I would have thought that the folks at MS could have enabled a linker that
    >was smart enought to include all used components of an app instead of the
    >full 20 Mb.


    Heh! It was *my* idea first! <g>

    MM
    "Home of the Next Big Idea"

  6. #36
    Mike Mitchell Guest

    Re: My view of the world

    On Tue, 19 Feb 2002 02:16:47 GMT, zane@mabry.com (Zane Thomas [.NET
    MVP]) wrote:

    >including large image size and the inability to get automatic updates as
    >component pieces change.


    Large image size isn't a problem now that memory is so cheap and hard
    disks are so large. Well, that's what people here keep saying, anyway.
    So even if my 10 monolithic apps are going to be somewhat larger than
    if they were standard Windows apps calling upon numerous DLLs, each
    app would *only* need its particular logic.

    As for getting automatic updates as component pieces change, that
    problem would not exist. Think about it: There you have your hard disk
    with an Exe sitting on it. Let's say, the Exe's purpose is calculating
    the national debt. It uses a grid. The app works. It worked yesterday,
    it's working today, and it will work tomorrow.

    Now the grid vendor changes the grid. Who cares?!! My app, the Exe
    sitting on my hard disk, isn't going to alter. It will still keep
    running. However, when the time comes to update the grid in my Exe,
    why, I just download the Exe again and XCOPY it over! My software
    supplier has the hassle of incorporating the revised grid into the
    Exe, but it's not a problem for Mr. User. No installs, no updates, the
    new Exe just overwrites the current one, I have the new grid, the new
    Exe...life couldn't be sweeter.

    MM
    "I went up the stairs, and when I got to the top, there were no more
    stairs, so I thought I should stop."

  7. #37
    Mike Mitchell Guest

    Re: My view of the world

    On 19 Feb 2002 07:10:56 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    wrote:

    >Can't do that in VB6!


    Maybe not. But the runtime for VB6 is tiny compared to the 20 MB for
    .NET, so it's not such a significant problem. And in any case, the VB6
    runtime *does* get overwritten when a newer version is installed. Not
    much waste there, I guess.

    MM

  8. #38
    Rob Teixeira Guest

    Re: My view of the world



    Clue: That's not the issue here.
    If/when the VB6 runtime (or pick your COM library) gets updated on your client's
    machine, and something happens to break in your app because of that, *you
    are hosed*, and your customer must choose between apps that run with the
    new version or your app - until such time as you decide to change your code
    and recompile on the new version - which, if your lucky when you push it
    out, won't break somebody else's install.

    -Rob

    kylix_is@yahoo.co.uk (Mike Mitchell) wrote:
    >On 19 Feb 2002 07:10:56 -0800, "Rob Teixeira" <RobTeixeira@@msn.com>
    >wrote:
    >
    >>Can't do that in VB6!

    >
    >Maybe not. But the runtime for VB6 is tiny compared to the 20 MB for
    >.NET, so it's not such a significant problem. And in any case, the VB6
    >runtime *does* get overwritten when a newer version is installed. Not
    >much waste there, I guess.
    >
    >MM



  9. #39
    Rob Teixeira Guest

    Re: My view of the world



    It's a good thing people like you don't design operating systems and development
    environments.

    First of all, let's look at some scenarios:

    You decide to statically link a number of libraries (runtime files + controls,
    etc) to your exe. Let's say that increases your application by 2000 KB (2
    MB). If you have 10 apps that use the same libraries, you now have roughly
    20 MB more stuff on your drive. But hey, 20 MB is cheap, so you decide to
    break with your former position and say who cares, for the sake of your argument.

    On the other hand I have one giant runtime of 20MB. All my apps link dynamically
    (not statically) to it. So each of my apps is 2MB smaller than yours. When
    I deploy 10 apps, we're even. However, I can deploy infinately after that,
    and not eat up any additional space for shared binaries, whereas in your
    model, you'd have no choice but to eat that space up.

    Furthermore, if one of my libraries gets updated, assuming there's solid
    compatible code, i can redistribute just *one* file, which may be on average
    64Kb - 500Kb. You on the other hand, would have to recompile *all* your apps,
    and distribute all 10 2.5Mb+ applications to have the updated features/bug
    fixes. Now who's got the massive downloads?

    Then, we get to the interesting part. Because my apps make use of DLLs, a
    large part of the DLLs are paged in memory mapped files - which means that
    even in RAM, most of the DLL code is shared by any app running that requires
    it. So, leaving runtime heap storage space aside, let's say that my apps
    are roughly 500K each, and I end up using 9 MB of the 20 MB library files,
    my 10 apps may only take 18 MB of RAM.
    Since all your code is statically linked, and your apps are apprx. 2.5 MB
    each, you'd be eating up at least 25 MB RAM.
    And again, if my apps all make use of roughly the same 11 MB of the library
    files, I can keep adding more running apps that consume shared memory, while
    you have no choice but to linearly consume about 2.5 MB with each app you
    run.

    -Rob

    kylix_is@yahoo.co.uk (Mike Mitchell) wrote:
    >On Mon, 18 Feb 2002 16:28:15 -0700, "Kathleen \(MS MVP\)"
    ><someone@nomail.com> wrote:
    >
    >>Mike is correct

    >
    >of course I am <g>
    >
    >> that they both "clutter" the users machine. COM GUID stuff
    >>came to pass because the relative size of components (ours and MS's)
    >>relative to the available memory and hard disk space required sharing.

    Those
    >>days are gone. What user machine notices 20Mb. So now MS gives you complete
    >>control, which means (thank goodness) you don't have to trust future acts

    by
    >>anyone.

    >
    >The more I think (again) about having a single Exe the more I am
    >warming to the idea. They do say that all great ideas sound strange to
    >begin with, and this could just be the Next Big Thing. Think about it:
    >No more DLL **** - there ain't no DLLs! No more massive downloads: You
    >just incorporate ONLY the functionality the app needs. No versioning
    >problems: Either you have the app or you don't, and that is the sum
    >total of versioning problems.
    >
    >To prove the worth of this idea of mine, just count up the number of
    >Exe's on your drive C, and then count up the *total* number of files!
    >
    >MM



  10. #40
    Karl E. Peterson Guest

    Re: My view of the world

    Hi Kathleen --

    > Well, I got back to town to find I agree and disagree.


    You conciliator, you. <g>

    > > moving to .NET *is* learning a language.

    >
    > Agree.


    Okay.

    > > You've no doubt found many instances where identical code produces
    > > different results, or where previously valid designs now execute in random
    > > order.

    >
    > You know this is what I fought for. Migrated code should fail or produce
    > nothing.


    Right.

    > But I really didn't think we were that far off. I know there are
    > tons of places the code won't run, and I know Integer/Long is going to cause
    > problems.


    Very big problems.

    > But where else does the code run and give different results.


    Does DateDiff give you identical results in both languages? Dim? How long a list do
    you want?

    > Also, there are places that events fire differently,
    > but where have you heard it is random other than DF?


    The loss of DF will cause lots of random execution, no doubt, no point in minimizing
    that. How about random non-execution? Thinking here of a form's Load event.

    Later... Karl
    --
    [Microsoft Basic: 1976-2001, RIP]


  11. #41
    W.E.(Bill) Goodrich, PhD Guest

    Re: My view of the world

    In article <3c7240fb@10.1.10.29>,
    "Jay Glynn" <jlsglynn@hotmail.com> writes:

    > > There already *are* 3, thanks to all the "early adopters" who
    > > coded apps and fragments in B1, B2, and V1.


    [...]

    > Those would be beta, in case you haven't noticed.


    That would be about the stupidest thing anyone in this group has said
    to date. It wasn't all that long ago that you and some of your fellow
    cheerleaders (not to mention Micro$oft itself) were crowing about the
    number of components and apps that were being put into production
    *using* those betas. And now the fact that some/most of them will not
    work with the "gold" CLR is not an issue?

    All of the producers and users of those are in the position of either
    *already* using two (or 3) side-by-side CLRs or converting them and
    repeating the entire test/acceptance process.

    The lack of backward compatibility for those Micro$oft-encouraged
    bodies of code speaks volumes about the future.

    --

    W.E. (Bill) Goodrich, PhD

    *-----------------------*--------------------------------------------*
    * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    * * *
    * Without Aversive * ctgcentral@earthlink.net *
    * Behavior Modification * Creative Technology Group *
    * or Drugs * PO Box 286 *
    * * Englewood, CO 80151-0286 *
    *-----------------------*--------------------------------------------*

  12. #42
    Jay Glynn Guest

    Re: My view of the world

    >
    > That would be about the stupidest thing anyone in this group has said
    > to date. It wasn't all that long ago that you and some of your fellow
    > cheerleaders (not to mention Micro$oft itself) were crowing about the
    > number of components and apps that were being put into production
    > *using* those betas. And now the fact that some/most of them will not
    > work with the "gold" CLR is not an issue?
    >


    There wasn't a single one of them that did not know the "issues" of using
    beta software. To use a beta release in this discussion is insane, something
    I would think you would know about.

    > All of the producers and users of those are in the position of either
    > *already* using two (or 3) side-by-side CLRs or converting them and
    > repeating the entire test/acceptance process.


    They knew going in that side by side would not be an option and that when
    final bits were released that they would more then likely have some work
    ahead of them. It is(was) clearly stated in this in the docs.

    > The lack of backward compatibility for those Micro$oft-encouraged
    > bodies of code speaks volumes about the future.


    This has to be the lamest argument you have put up to date. Even you should
    know better then to make this argument. MSFT made no bones about the fact
    that things will change by the time RTM appears. If you have a cite that
    states otherwise, I encourage you to provide it.



  13. #43
    Kathleen \(MS MVP\) Guest

    Re: My view of the world

    Mike,

    The cost of the disk space for the .NET runtime is a fraction of the cost
    for the disk space for the VB runtime when VB3/4/5/6 came out.

    This is a silly argument, except where people have to install over slow
    connections.

    Kathleen



  14. #44
    Kathleen \(MS MVP\) Guest

    Re: My view of the world

    Bill,

    > > Those would be beta, in case you haven't noticed.

    >
    > That would be about the stupidest thing anyone in this group has said
    > to date. It wasn't all that long ago that you and some of your fellow
    > cheerleaders (not to mention Micro$oft itself) were crowing about the
    > number of components and apps that were being put into production
    > *using* those betas. And now the fact that some/most of them will not
    > work with the "gold" CLR is not an issue?


    I have something running in beta1 in the real world. Has been happily since
    last summer. The payback is there, even if we have to rewrite completely.
    The payback is that good for some problems. Get it, people went to .NET
    because it is better.

    Kathleen




  15. #45
    Patrick Troughton Guest

    Re: My view of the world


    Thank you! That's exactly what I was thinking. I haven't done the math yet,
    but given the huge size of hard drives today, I wouldn't doubt that the .NET
    runtime may actually be *smaller* than the older VB runtimes when they came
    out.

    /Pat

    "Kathleen \(MS MVP\)" <someone@nomail.com> wrote:
    >Mike,
    >
    >The cost of the disk space for the .NET runtime is a fraction of the cost
    >for the disk space for the VB runtime when VB3/4/5/6 came out.
    >
    >This is a silly argument, except where people have to install over slow
    >connections.
    >
    >Kathleen



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