Re: Goodbye and Best Wishes
From: Craig Stuntz [TeamB] (cstuntz_at_nospam.please)
Date: 02/17/04
- Next message: Craig Stuntz [TeamB]: "Re: Legitimate D4 copy"
- Previous message: Joe Grein: "Re: Idea for Borland"
- In reply to: Eric Grange: "Re: Goodbye and Best Wishes"
- Next in thread: Eric Grange: "Re: Goodbye and Best Wishes"
- Reply: Eric Grange: "Re: Goodbye and Best Wishes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 17 Feb 2004 08:57:38 -0800
Eric Grange wrote:
> > You have since modified your position to include use of features
> > not in the N+1 framework and dynamic selection of CLR versions
>
> This is not a modification, here is an excerpt from one of the
> examples I gave:
>
> "I have code than can use any gds32.dll or fbclient.dll versions
> to access InterBase/FireBird, or have OpenGL applications that
> work
> with 1.1, but still be able to make use of the 1.5 functions and
> extensions when they are available"
That's separate from the point I replied to, which was the purported
(and incorrect) inability to so much as show a dialog box. But you
*can* do this, anyway. The simplest method is to write two assemblies
-- use the same source code, but IFDEF it, and compile for each
platform -- and ship them for side by side execution. The correct
assembly for the framework version you'd like to support will be loaded
automatically. Unlike Win32, you don't have to write so much as a line
of code to make this work.
But that's not the only way. You can call methods with reflection,
for example, if you suspect that a method may not exist in the version
on the user's system.
> That isn't different. If you developped against 2.0, having only 1.0
> installed won't be of much use (unless you can call "developping
> against 2.0 but using only 1.0 stuff" as "developping against 2.0",
> which seems to be how you understand it...).
I understand "developing against" as a vague term. I prefer to say
"compiled with a 2.0 compiler" or "uses 2.0 features" (or both). I
don't agree that if you use 2.0 features having only 1.0 installed
won't be of much use -- even if most of your code is completely
dependent on 2.0 -- because, as you point out, you might want to
display a dialog box to explain the situation to the user, or, better
still, direct them to where they can get 2.0.
> > It is not necessary to take advantage of features available in a
> > newer version in order to display a dialog box.
>
> But it is necessary to have a compatible EXE, meaning you must have
> multiple EXEs, or be stuck in 1.0.
This is not correct. I have suggested a couple of different methods
for doing just this above: Compile a separate assembly (not EXE) for
the "older" framework which displays the dialog (or whatever) or use
reflection to call the newer methods.
> *That* I wouldn't call a 2.0 app, and even in that case, I'll add
> that this is NOT guaranteed (remember the "no forward compatibility"
> mention in the article?).
The article did not say "no forward compatibility" -- that's your
phrase, not theirs -- it said no *guarantee* of forward compatibility,
something which I think applies to Win32 as well, unless you can point
me to a guarantee (in which case I think I'm entitled to damages from
MS).
As it happens, forward compatibility *is* a feature of the .NET
framework; from the documentation:
"The .NET Framework supports both backward and forward compatibility.
In the context of the .NET Framework, backward compatibility means that
an application created using an early version of the .NET Framework
will run on a later version. Conversely, forward compatibility means
that an application created using a later version of the .NET Framework
will run on an earlier version.
"The .NET Framework provides a high degree of support for backward
compatibility. For example, most applications created using version 1.0
will run on version 1.1. The .NET Framework also supports forward
compatibility. However, for forward compatibility you might need to
modify an application so that the application runs as expected. For
both backward and forward compatibility, a change to the .NET Framework
that improves security, correctness, or functionality might also raise
compatibility issues."
> > Nor is this restriction in any way unique to .NET. [...]
>
> In which way does it happen in Win32?
You cannot use 2.0 features when a machine has only a 1.0 library,
even if you load it dynamically. You can, however, detect the problem
and inform the user.
> Could you f.i., write a .Net assembly (a single assembly, not
> a collection of assemblies and applications) that uses Avalon's GDI+
> if it is installed, or otherwise stick to WinForm's when run on
> an 1.0 install?
You might be able to do such a thing with reflection, but I would
never even attempt such a thing; the implementations would be alomst
completely different. It's analogous to Marco Cantu's (joke)
TEverything component, and is IMHO wrong for the same reason fat
classes are bad design. Instead I would write two assemblies with a
common interface, and let the framework automatically select the right
assembly to use when the (single) EXE is run.
[Off topic: Avalon doesn't use GDI+; WinForms does.]
> > You do understand that this is referring to *the framework itself*
> > rather than assemblies you write, correct?
>
> Yep. You also surely understand that the MSIL can evolve between
> versions, and the JIT or interpreter may not be able to understand
> the new assembly at all.
This speculation conflicts with the .NET documentation, which lists
forward compatibility as a feature. Breaking forward compatibility so
badly that the new JITter wouldn't even recognize the assembly is IMHO
about as likely as Microsoft abandoning the Win32 API in Longhorn --
theoretically possible, but so speculative and unnecessary that I
wouldn't want to bet money on it. If you're concerned about this then
I think you should also be concerned about Microsoft abandoning Win32
RSN -- something I won't lose any sleep over.
> > [...] as both the article and the framework documentation link I
> > gave explicitly demonstrate, this is wrong.
>
> Please, quote the paragraph in the article.
For example:
"Targeting an application built using .NET Framework version 1.1 to run
on .NET Framework version 1.0 requires a significantly larger entry in
the application configuration file. Each assembly that makes up the
.NET Framework must be redirected to use .NET Framework version 1.0."
This is a bit misleading out of context since the big manifest is
required only to force the app to run on Framework 1.0 *even if 1.1 is
installed.* If 1.1 is not installed then the only thing you have to do
is to add the supportedRuntime to manifest and isolate use of the 1.1
features in one of the ways suggested above.
> > You're changing the subject -- again!
>
> Still the same. Your code is in an EXE eventually, isn't it?
Your code is (run in the context of) an EXE, yes, but that doesn't
mean you have any need to dynamically load the framework. You want to
use the most compatible framework installed on the machine, period. If
that framework version won't work for your code you want to inform the
user and quit, not try and load an older version.
> > We were discussing the ability of an assembly compiled with
> > an N+1 compiler to use an N framework
>
> If you're so sure of it, are you ready to write it down and eat your
> hat should it be proven wrong? hint: choose a small hat ;)
The links I gave give examples of how to do this. You've referenced
nothing, and supplied no concrete examples. It is a supported feature
that assemblies compiled with a 1.1 compiler will work on a 1.0
framework if you don't use 1.1 features, and if you do want to use 1.1
features there are means of isolating that code, such as providing
separate assemblies which will be automatically loaded.
> > Are you saying you consider the comctl32 library to be guaranteed
> > backwards compatible?
>
> If there ever were, I never bumped into them, maybe I was lucky ;)
If you never bumped into an incompatibility then you were either lucky
or isolated from this by the VCL; there's a BDN article somewhere about
the amount of work Eddie Churchill had to do to make the VCL work with
all 20+ versions of this library. With Windows XP Microsoft has given
up even the pretense of compatibility and opted for a scheme which is
very similar to .NET -- use a manifest to tell Windows which version of
the library you prefer, and multiple versions can exist on the system
concurrently.
> Though I did bump into issues of their wrapper components in the VCL
> (which were solved by sticking to components derived from older code,
> components that are still working nowadays, and even support sorting
> and XP styles in non-themed D7 app).
>
> > Or that you don't consider it to be a part of the API?
>
> They are part.
If you consider comctl32.dll to be a part of the API (and I agree that
it is) then there is no guarantee of backwards compatibility in Win32
-- comctl32 is a counterexample. Hence, .NET and Win32 are in a
similar boat -- Microsoft tries and mostly succeeds at backwards and
forwards compatibility, with some annoying exceptions here and there.
> You still dodged my question: have you ever used any of MS's
> "new compatibility philosophy" APIs like DirectX, over the course
> of a few revisions?
I've used .NET in both 1.0 and 1.1. I don't use DirectX, and from
what I understand its "compatibility" is different than the .NET
framework. If you want to discuss DirectX, you'll have to do it with
someone else, as it's outside my personal interests.
-Craig
-- Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH Delphi/InterBase Weblog : http://delphi.weblogs.com InterBase Performance Monitor -- Analyze and control your IB7 server: http://delphi.weblogs.com/IBPerformanceMonitor
- Next message: Craig Stuntz [TeamB]: "Re: Legitimate D4 copy"
- Previous message: Joe Grein: "Re: Idea for Borland"
- In reply to: Eric Grange: "Re: Goodbye and Best Wishes"
- Next in thread: Eric Grange: "Re: Goodbye and Best Wishes"
- Reply: Eric Grange: "Re: Goodbye and Best Wishes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
