My view of the world

[Rob Teixeira]

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

[Mike Mitchell]

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

[Mike Mitchell]

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

[Mike Mitchell]

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

[Mike Mitchell]

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"

[Mike Mitchell]

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

[Mike Mitchell]

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

[Rob Teixeira]

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

[Rob Teixeira]

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

[Karl E. Peterson]

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]

[W.E.(Bill) Goodrich, PhD]

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

[Jay Glynn]

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

[Kathleen \(MS MVP\)]

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

[Kathleen \(MS MVP\)]

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

[Patrick Troughton]

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