Longhorn and backward compatibility

[darwen]

I've been hearing some disturbing stuff about Longhorn not being compatible with existing MFC/Win32 applications.

I've heard that WinFX is their new underlying "Windows" graphics engine, and is a direct replacement for Win32 rather than just something built on Win32.

Will Win32 calls be available under Longhorn ? Is this such a dramatic change ?

I've been reading lots of stuff on the net and it all seems to contradict itself.

With respect to Windows development : are we talking about throwing away MFC all together (no bad thing in my book, but there you go) and being FORCED to work with .NET ?

Darwen.

[Arjay]

Microsoft would be crazy to forego backward compatibility in Longhorn. Imagine all those existing applications not being able to run on LH? Ain't going to happen.

[darwen]

Yeah, that's what I hoped... however it sounds like Microsoft are throwing caution to the wind more and more about backwards compatibility and favouring 'side by side' execution...

Consider what has happened in the .NET field over the last 2 years.

.NET 1.1 has controls etc which are incompatible with .NET 1.0

.NET 2 has advanced toolbars (button bars) etc which are direct replacements (not enhancements) for .NET 1.1 controls.

Visual C++ 2005 : loads of incompatibilities, changes in the .NET syntax. If you've spent the last 2 years writing .NET code in C++ "oh sorry, all the syntax has changed so your X thousand lines of code are going to have to change to keep up."

I think VB6 is a classic example of the new Microsoft philosophy. If you're using VB6, sorry you're going to have to do a practical rewrite of everything you've ever written. (Or rather "sorry we got it wrong, we should never have released VB6 in the first place, we only did it for the money"). I'd like to go back in time and stop the first release of VB but there you go.

I read an article on the net about this today, but I'll be damned if I can find it again.

I just want someone who's read all the Longhorn documentation to say yes or no - is Win32 dead ?

Darwen.

[Arjay]

Yeah, that's what I hoped... however it sounds like Microsoft are throwing caution to the wind more and more about backwards compatibility and favouring 'side by side' execution...

Consider what has happened in the .NET field over the last 2 years.

.NET 1.1 has controls etc which are incompatible with .NET 1.0

.NET 2 has advanced toolbars (button bars) etc which are direct replacements (not enhancements) for .NET 1.1 controls.

Visual C++ 2005 : loads of incompatibilities, changes in the .NET syntax. If you've spent the last 2 years writing .NET code in C++ "oh sorry, all the syntax has changed so your X thousand lines of code are going to have to change to keep up."

I think VB6 is a classic example of the new Microsoft philosophy. If you're using VB6, sorry you're going to have to do a practical rewrite of everything you've ever written. (Or rather "sorry we got it wrong, we should never have released VB6 in the first place, we only did it for the money"). I'd like to go back in time and stop the first release of VB but there you go.

I read an article on the net about this today, but I'll be damned if I can find it again.

I just want someone who's read all the Longhorn documentation to say yes or no - is Win32 dead ?

Darwen.There's a big difference about changing Compiler support for a languages vs. no longer supporting compiled executables. Most VB6 compiled apps still run on XP and higher in spite of the fact that code written in VB6 doesn't compile in .net.

Looking at the .net1.0, 1.1, and 2.0 ctrls... This is similar to VB - apps that make use of a particular runtime version will run on an OS providing the OS has the correct .net runtime (which the app setup program should install).

Btw, from what I understand, MS has been wanting to drop support for 16-bit apps for years, but their large corporate clients won't let them because they still have legacy 16-bit IT apps around they don't want to rewrite. My point here is that if 16-bit support hasn't been dropped, and considering how much more pervasive Win32 is over 16-bit apps, what are the chances that Win32 will be dropped in LH?

The impact of dropping existing support for Win32 would be devastating - it won't happen in LH. [I'd wager that LH will continue to support 16-bit apps as well].

You know early in your reply you mention that "Microsoft are throwing caution to the wind more and more about backwards compatibility and favouring 'side by side' execution..."

Doesn't this answer your own question since 'side by side' implies backward compatibility support?

[Brad Jones]

I've heard that WinFX is their new underlying "Windows" graphics engine, .


WinFX is more than just the graphics engine. It is the new Windows API. This will include features for Avalon, Indigo, and WinFS as well as a number of fundamental routines.


WinFS is the code name for the new type-aware, transactional, unified file system and programming model that will be a key part of Longhorn. WinFS allows various kinds of data and information stored on your machine to be associated and categorized. You can associate relationships between information and these associations can be used to access what is stored on your machine.

Avalon is the code name for for the graphical subsystem (User Interface framework) of Longhorn.

Indigo is the code name for the communications portion of Longhorn that is built around Web services. This communications technology focuses on providing spanning transports, security, messaging patterns, encoding, networking and hosting, and more.

With the use of XAML being added for interfaces, things about develping Windows applications are going to change with Longhorn.

[Kevin McFarlane]

See these
http://www.windowsdevcenter.com/pub/a/windows/2004/07/13/winfx.html
http://www.ondotnet.com/pub/a/dotnet/2003/11/24/longhorn_01.htm

Win32 will eventually appear to WinFX like DOS does to Win32.

[darwen]

Thanks for those links. Very useful.

Darwen.