Longhorn, what does everyone think?

[Christoph Nahr]

No, not in any serious way. A new rendering engine is an OS feature, not a
framework feature. Just because its written for .NET doesn't mean its part
of the framework.

By the way, will it be possible to use that nifty XAML format for GUI
elements on older Windows versions, as long as the proper .NET
Framework version is installed? Minus all the new rendering stuff
like playing videos in the background -- just placing controls etc.

 

[Daniel O'Connell]

That I don't know, but if MS doesn't provide a way, I suspect someone will
write a XAML-to-Winform converter that generates a winform that is as close
as possible to the Avalon rendered XAML file, perhaps without all the nice
automatic flow-layout features. Time will tell on that one I suppose.

It would be nice tho, wouldn't it?

 

[JDeats]

So you play a video in

Think about it. Can you do that today how it was demo'd? Transparently?
Freely mixing form elements? Think about doing it today and how much effort
it would take. Now think about whipping it up in a couple seconds with a
couple lines of code.

....

Alvin,

We'll it's a vector based rendering engine for Forms that makes use of
DirectX features (such as real-time video playback). Having worked
with DirectX and Macromedia's Flash technology this is a hard thing to
get excited about. It's not revolutionary, but it is telling in that
it shows Microsoft is more or less building a Flash counterpart into
their core OS product. Since the IE version that ships with Longhorn
will also support XAML this has more potential for web based apps than
rich-client and the ability to do vector based graphics without
third-party tools will be nice.

Sorry.

If that doesn't amaze you, nothing will.

--

Not true, even if you're not a game player, check out Idsoftware's
upcoming Doom III, it's an example of revolutionary technology that
amazes me.

 

[JDeats]

No, not in any serious way. A new rendering engine is an OS feature, not a
framework feature. Just because its written for .NET doesn't mean its part
of the framework.

Well that depends. A rendering engine can sit on top of an OS quite
easily actually. From that demo and from what I've seen of XAML, it's
an XML language that defines user interface elements, it supports
vector based graphics and DirectX features. This is nice and all, but
Macromedia's Flash technology gives you the same features now. I don't
know if you can use XML to define your Flash applications (it's
probably still a binary format), so that is a big difference. But the
point in that reference is that if I wanted to create an application
like that I could. I could use DirectX 9 and build a rendering engine
that provides an XML parser, etc.. to do this sort of thing, it could
be written, it wouldn't be easy, but it could be done.

Could you design one that supports SOAP, SOAP1.2, Xml Serialization and all
the other bits that can travel over any communication mechanism in as many
days?
As for why its an OS component...that I can't say, except perhaps because ti
was written for Longhorn and is used in Longhorn.

No, I guess there's more to Indigo than I thought.

I don't know for sure if this is possible and I don't know if there really
is any point to that, in 98% of usage cases this would be extra code for no
use, and I bet you probably wouldn't even use it yourself.

The ability to query data from multiple non traditional sources would
be very useful.

That is what a
database is for and you could do it via ADO.NET easily(WinFS can be accessed
via ADO.NET). However, it has alot to do with the objects and schemas
designed into WinFS, there is NO way the system could understand every
possible file placed on it, and I suspect it would be more a matter of how
the schema works internally than WinFS itself.

Of course it couldn't understand every type of file, but an interface
standard could be adopted, for example a standard header for binary
files that points to a managed .DLL that would provide an interface
for the OS to understand how to get to that data. A few generic
handlers based on extension (e.g. .xml and ascii) could be provided
for non-binary types. If no header were present then the indexing
system could just ignore the contents of the file. Since WinFS is
based on Yukon I guess this would be something the core database would
have to support.

 

[Daniel O'Connell]

"Daniel O'Connell" <[email protected]> wrote in message


Well that depends. A rendering engine can sit on top of an OS quite
easily actually. From that demo and from what I've seen of XAML, it's
an XML language that defines user interface elements, it supports
vector based graphics and DirectX features. This is nice and all, but
Macromedia's Flash technology gives you the same features now. I don't
know if you can use XML to define your Flash applications (it's
probably still a binary format), so that is a big difference. But the
point in that reference is that if I wanted to create an application
like that I could. I could use DirectX 9 and build a rendering engine
that provides an XML parser, etc.. to do this sort of thing, it could
be written, it wouldn't be easy, but it could be done.

It can be done, but would it be effective? From what I've read about avalon,
it is basically ripping out GDI\GDI+ and replacing it with the Avalon
renderer and a GDI compatibility layer. In my opinion to port Avalon back to
previous versions of windows would likely be turning that version of windows
INTO longhorn on alot of fronts. I don't know how interlinked it is, but it
seems that GDI, in the classic sense anyway, is dead or dying in Longhorn.

XAML is a declaritive UI language, but it renders over Avalon. It could
obviously be done manually, but being able to write it and run it reliably
across machines is a bit harder. I doubt the video or alot of the other
effects would work as well on a machine running at 500mhz & 64 meg of
ram(which are still out there). I don't think writing all the crap to
achieve the UI's is worth it. Also, The automatic text wrapping and scaling
is alot more important than the video, for example, but that isn't easy to
do with classic winforms, having system level support for it is of value.
However to make it effective you may have to replace the rendering engines
of previous versions of windwos with the vector based avalon...thats ALOT of
testing, 10x or 20x what longhorn alone would be.

 

[news.microsoft.com]

and STILL, no serial communication

not

It can be done, but would it be effective? From what I've read about avalon,
it is basically ripping out GDI\GDI+ and replacing it with the Avalon
renderer and a GDI compatibility layer. In my opinion to port Avalon back to
previous versions of windows would likely be turning that version of windows
INTO longhorn on alot of fronts. I don't know how interlinked it is, but it
seems that GDI, in the classic sense anyway, is dead or dying in Longhorn.

XAML is a declaritive UI language, but it renders over Avalon. It could
obviously be done manually, but being able to write it and run it reliably
across machines is a bit harder. I doubt the video or alot of the other
effects would work as well on a machine running at 500mhz & 64 meg of
ram(which are still out there). I don't think writing all the crap to
achieve the UI's is worth it. Also, The automatic text wrapping and scaling
is alot more important than the video, for example, but that isn't easy to
do with classic winforms, having system level support for it is of value.
However to make it effective you may have to replace the rendering engines
of previous versions of windwos with the vector based avalon...thats ALOT of
testing, 10x or 20x what longhorn alone would be.
and for

 

[Daniel O'Connell]

Havn't you posted this question and recieved an answer like 5 times now? I
know I've answered it atleast 3 times now.

again, goto
http://longhorn.msdn.microsoft.com/lhsdk/ref/system.io.ports.aspx

 

[Jon Skeet [C# MVP]]

XAML is a declaritive UI language, but it renders over Avalon. It could
obviously be done manually, but being able to write it and run it reliably
across machines is a bit harder. I doubt the video or alot of the other
effects would work as well on a machine running at 500mhz & 64 meg of
ram(which are still out there).

<snip>

And this is an important point. IIRC, Longhorn will have three
rendering modes - one for slow machines, one for fastish machines which
can't quite afford to do *all* the swish stuff, and one which has the
works.

If Longhorn is released in 3 years' time (just a complete guess) then
according to Moore's Law, CPUs will have 4 times as many transistors -
and graphics cards at least *have* been obeying Moore's Law squared, so
they'll have 16 times as many transistors. That's a *lot* more power to
chuck stuff around the screen.

Computers which are now pretty cutting edge will be at *best* the low
end of what you can buy, and there'll be far fewer 500MHz machines out
there to contend with. (I doubt whether Longhorn will even claim to run
in 64Mb though.)

Basically, Microsoft can afford to make display stuff reasonably
expensive, because there'll be better hardware to chuck at it - the
balance of what's best for the developer vs what's best for the
hardware will have tilted significantly in favour of making it easier
for the developer.

 

[Daniel O'Connell]

<snip>

And this is an important point. IIRC, Longhorn will have three
rendering modes - one for slow machines, one for fastish machines which
can't quite afford to do *all* the swish stuff, and one which has the
works.

If Longhorn is released in 3 years' time (just a complete guess) then
according to Moore's Law, CPUs will have 4 times as many transistors -
and graphics cards at least *have* been obeying Moore's Law squared, so
they'll have 16 times as many transistors. That's a *lot* more power to
chuck stuff around the screen.

Computers which are now pretty cutting edge will be at *best* the low
end of what you can buy, and there'll be far fewer 500MHz machines out
there to contend with. (I doubt whether Longhorn will even claim to run
in 64Mb though.)

Basically, Microsoft can afford to make display stuff reasonably
expensive, because there'll be better hardware to chuck at it - the
balance of what's best for the developer vs what's best for the
hardware will have tilted significantly in favour of making it easier
for the developer.

Yes, I agree, however thats part of the argument against porting it back to
say, XP. I expect XP to run at 500mhz at 64meg(I have a machine running at
just that actually). This kind of rendering engine would be required to be
capable of working on all machines the target system supports, otherwise its
pointless, and properly ratcheting up or down depending on hardware adds
complexity to the design and increases the costs of development and testing,
which is what I was trying to get at. 3 modes * 3 systems(2k, xp, longhorn)
* minimum configuration sets is bound to grow quite a lot, increasing the
amount of testing(and probably code) required to get it working across
systems in a reliable manner. I don't think any system component should be
made that changes the system requirements, that is something best left up to
the next version, IMHO.

Anyway, the point is, what use is Avalon on a system that is too slow to use
Longhorn? If the user is willing to upgrade his machine, why not his OS,
which with new hardware is generally not too expensive? Even in corporate
environments, I doubt administrators would take a shine to Avalon any faster
than Longhorn itself, considering the amount of OS level modification
required to use it. Also, what use is Avalon on systems that don't have
WinFS or any of the other features. Avalon alone is not enough to make me
want to move to Longhorn, it is simply another piece of the puzzle. I don't
think I'll be developing for Longhorn using JUST Avalon, but I will be
attempting to leverage everything the platform offers. Suggesting that all
features should be backported seems absurd to me...it seems that people
would rather turn XP into Longhorn, which is, in my mind, exactly the
purpose of upgrading.

 

[Jon Skeet [C# MVP]]

Yes, I agree, however thats part of the argument against porting it back to
say, XP.

Indeed - sorry, that was a lot of my point, I just didn't make it very
explicitly

 

[Daniel O'Connell]

Indeed - sorry, that was a lot of my point, I just didn't make it very
explicitly

Ya, I wasn't sure if you were addressing me or if you were adding to my
point,
np