Our future with Longhorn?

Started by
81 comments, last by kinglink 19 years, 1 month ago
I think the real question should be, will it be as sexy as this?:

http://www.sun.com/software/looking_glass/details.xml
Advertisement
Too many of those Looking Glass screenshots simply ask, "imagine how useful *this* would be!?" and leave me, the user, really wondering if its just for show, or if it actually helps improve my productivity. Contrast this to Apple's presentation of new UI features -- they actually seem to be useful, even at a quick glance. The most glaring example is the CD collection screenshot - using real-world metaphors isn't always appropriate, (what if you have a lot of albums? Would they then be stacked and you'd have to thumb through them?) The 'panning desktop' looks kind of neat, but then the caption asks, "imagine if this desktop were live video?" What would a live video of Stanford's campus on my desktop offer me? (Excepting the opportunity to watch hot chicks walk around?)
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
Quote:Original post by sjelkjd
Quote:Original post by flangazor
Longhorn has no market share. In fact, if I remember correctly, there will be significant backwards compatibility issues. I guess it's ok to tow the line if you don't think your product is important enough to convince potential customers to adopt your chosen platform.


I don't think backwards compatibility issues is the right term.

Let's review the facts:
old software will work fine on longhorn.
new software written for longhorn's new apis won't work on xp

In other words, software written against new apis won't work with old apis...which is not too surprising.
That was the theory behind the move from Win16 to Win32. Reality was significantly different.
This is a quote from the Gartner grouop

Gartner believes that WinFX represents a significant step forward in Microsoft application design, but progress will come at a cost. While established Win32 applications will continue to run, a new application that takes full advantage of Avalon, Indigo and WinFS will not be backward portable to platforms other than Longhorn; although, the .NET Framework will be a backward portable subset of WinFX classes.


I'm not really old enough to remeber the win16 to win32 move perefectly, but I do recall that almost all major software applications for windows 3.1 workd on windows 95.

Cheers
Chris
CheersChris
Microsoft has more Win32 software, and relies on more Win32 code than any other software company. That alone almost ascertains that Longhorn will run much of Win32 software out there with little problem, imo.
No, it was major software the had the problems. They were huge systems that, in many places, relied on certain behaviour of Win16 that they shouldn't have. Undocumented APIs, etc.

Stuff like Novell had a Novell32. WS_FTP had WS_FTP32. Et cetera.


[1][2]
Aye, I know what you mean Antareus, I'm just a sucker for shiny things ;) Whereas rotateable windows has questionable use I think the whole panoramic desktop is superb, no more limited to this single screen that is easily cluttered with multiple windows the whole panoramic element is very useful. There's a project called sphereXP which is next to useless at the moment but it gives you a feel of some of the potential that this type of desktop offers.
flangazor, I think the big difference is that Win16 was ported to run on top of Win32. With Longhorn no such porting is being done. Win32 remains where it is in the architecture of things, and WinFX is being added to run side-by-side with it (see "Does Avalon sit on top of Win32 or replace it"). This'll probably result in less compatibility problems than the Win16->Win32 shift.

Stuff from those links:



Quote:
WinFX is neither a wrapper around Win32 (because most of the API is written from scratch, though it does use some Win32 functionality that's not being replaced) nor is it an actual replacement, in the sense that we aren't removing Win32 from the OS. WinFX and Win32 will coexist side-by-side, but parts of Win32 will be considered "legacy" starting with Longhorn, just like Win16 was "legacy" with Windows 95.


Yes, I realize the diagram is of NT4, but I'm quite sure this was the case with most of Win16 in Windows 95 as well, meaning that Win16 sat on top of Win32, not the other way around.

Quote:Original post by sjelkjd
I don't think backwards compatibility issues is the right term.

Let's review the facts:
old software will work fine on longhorn.
new software written for longhorn's new apis won't work on xp

You forgot one fact:

Software developers want to write their software for the largest market possible.

XP is going to be like 50% of the windows installations even 2 years after longhorn is released, and will remain significant for perhaps then next decade. People don't need to upgrade as often as they once did.

So, developers can't write software using new apis, unless they want to give the finger to half their users or write the software twice.

I think I'm philisophically required to mention that linux distros don't have these problems. There's this little thing called upgrading that can happen in 30 minutes without user intervention, if necessary. It also doesn't cost $150.
mutex, from your second link:

Quote:Will my existing Win32 and .NET apps continue to run under Longhorn without modification?

The goal is that apps written against the documented Win32 APIs and the .NET Framework will absolutely run well without any modifications under Longhorn when it ships.

Chris Sells, MSDN, October 2003 #


Quote:Can I use C++ to develop for Longhorn?

I can't find any document about programming model for C++ in Longhorn. Where can I find documentation about this?

If you mean the C++ that targets the MS CLR by producing IL, then the program model is the same for C++ as it is for any .NET language and you can find a set of C++ samples on the LHSDK samples page.

If you mean Standard C++ that targets a specific chip by producing assembly code, you're going to be doing a lot of .NET interop to make it work. I recommend the other thing.

Chris Sells, MSDN, 11 May 2004 #


That seems like a big discrepency. Things will just work without modification - but to get C++ that compiles to binary, you're going to have to do a lot of .Net interop.

Does that scan with you because it doesn't scan with me.

This topic is closed to new replies.

Advertisement