5 ms·

Windows 8 for software developers: the Longhorn dream reborn?

extension 15y ago
Developers asked about Windows APIs. Then Windows builds leaked to the internet with the new APIs. Maybe they got their answer?
MetallicCloud 15y ago
How can there be so much in fighting within Microsoft? Surely there must be a manager somewhere that looks over both teams and makes sure they aren't trying to shaft each other.
- StrawberryFrog 15y ago
  I'd imagine that that manager is Steve Balmer, or only 1 level below him. The heads of WinDiv (http://www.microsoft.com/presspass/exec/ssinofsky/ http://www.microsoft.com/presspass/exec/ssinofsky/ ) and DevDiv (Not sure who that is - Scott Guthrie or his boss?) are pretty senior. Has the infighting gotten worse since Bill Gates handed over?
  - michael_dorfman 15y ago
    ScottGu's boss is Soma (http://www.microsoft.com/presspass/exec/somasegar/ http://www.microsoft.com/presspass/exec/somasegar/), if I am not mistaken.
    - StrawberryFrog 15y ago
      Ok. Still, I get the feeling that Balmer should be sorting this out and setting direction. or making sure that someone does. Doing the "vision thing". Leading, basically.
Blunt 15y ago
".NET would be the way to write Windows applications. Win32 would still exist for backwards compatibility, but it would be frozen and left static." OMG, Another non-technical person trying to write about technology again <sigh>
- z92 15y ago
  Just curious. How is it wrong?
  - artmageddon 15y ago
    In my opinion, it's very misleading because the .Net framework relies on the Win32 API to interact with the operating system. Without Win32, there's no .Net, so if Microsoft plans to make upgrades/updates to the OS, how can it do so when Win32 is "frozen and static?" While it's clear that they will eventually(hopefully) rewrite the main applications(Explorer, Calculator, etc) to use .Net, that last part didn't seem to make sense given the dependency of .Net on Win32. Edit: Please correct me if I'm wrong, as I'm looking to make sure I understand. I based my comment off of David Morton / nobugz's comments in the following thread: http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/ac6a20d5-3d18-4eb2-acd6-5bae1774f14a http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/a...
    - deleted 15y ago
      [deleted]
    - bad_user 15y ago
      The problem with .NET is that nobody knows what it is. .Net framework relies on the Win32 API to interact with the operating system You're saying it as if Java and Java Swing do not interact with Windows. It is true that (e.g.) Windows Forms is built with Win32 in mind and is using native widgets, but on the other hand nothing prevents you from porting it and you can check out the Mono implementation, which is functional and runs on Linux and OS X. Of course, Java Swing is a much more portable implementation of a GUI toolkit, but even Java Swing makes Win32 calls and it is also cursed with the common-denominator problem. the dependency of .Net on Win32 Other than a couple of instances where you can clearly see that the design of Windows had a clear influence on .NET, Win32 is certainly not a dependency of .NET Sure, most .NET apps won't run on Linux or OS X, but that's mostly because their developers have been interacting with native code that isn't easily portable, but P/Invoke is so kick-ass that writing new managed bindings to native modules is a piece of cake, so devs are inclined to do that when it makes sense for them, instead of (say) search for a portable alternative.
nhebb 15y ago
I sell a Windows application targeted toward business users. 57% of my site's visitors are still running XP. Of those who purchase, 50% are XP, 40% are Win 7, and 10% are Vista users. So forgive me for not getting excited about changes to any upcoming version of Windows because until the folks in Redmond design an OS that businesses are interested in, it's mostly moot.
- goalieca 15y ago
  The thing that kills me is that XP is basically 10 years old now. It still "adds a new device" every time i plug in a usb key.
  - melling 15y ago
    Why should this change? Microsoft has invested billions in Vista and Windows 7. It's time to upgrade. Supporting all the legacy costs Microsoft money that can be better spent on future enhancements.
    - cturner 15y ago
      Microsoft has invested billions in Vista and Windows 7. It's time to upgrade Non-sequiter. You can buy support for legacy versions of VMS, Unix and OS/2. Supporting all the legacy costs Microsoft money that can be better spent on future enhancements. It would be definitely be cost-effective to sell Windows XP support. The reason for withdrawing XP support are strategic, not cost-oriented (nor customer-oriented!!)
  - CamperBob 15y ago
    Technically that's the fault of the hardware vendor for not including a valid serial # in the device's EEPROM. Did they change the behavior in later Windows versions?
    - notatoad 15y ago
      no, they didn't. vista and 7 still have exactly the same behaviour as XP for initializing a new device, they just do a better job of hiding it from the users.
larsberg 15y ago
This article gets more than a smidge of its history wrong. For instance, it makes it seem as if WPF (nee Avalon) was written by DevDiv in isolation from Windows, where in reality the Avalon team was mostly made of the former IE team after its legal dismemberment. In fact, we moved my team (which was focused on developer tools on, for, and made with WPF) from DevDiv buildings into Windows buildings just so we could build apps and tools for Avalon to help test their platform. But, it was a big effort. And even coming from inside of Windows, getting the rest of the shell to run on a whole new stack -- from drivers, through C++ layers, through managed -- was a challenge, especially with all of the other things going on in Longhorn. Sometimes, you bite off more than you can chew, especially when you make the dependency stack too deep. Also, all of this happened long before Silverlight efforts started... XAML came out of the WPF work. Arguing Silverlight stole DevDiv focus from WPF during the Longhorn timeframe is temporally impossible. Certainly, you could argue DevDiv was being pulled in many directions with the concurrent efforts to placate the VB4 crowd, push out a new version of VS, figure out a new syntax for Managed C++, compete with the then-rapidly-expanding Java tools ecosystem, and support all of the internal and demanding partners (especially SQL and other Windows efforts). But a substantial portion of both the tools and .NET runtime team's efforts were spent making Avalon perform, and I don't think that even now anybody who was there would claim that more DevDiv resources could have made the "Windows Shell is now made from WPF" effort succeed in the desired schedule.
io 15y ago
This might be interesting in ten years, when virtually everybody's running Win8 or later and I can consider using the new API.
brudgers 15y ago
The article plays on the ambiguity in the phrase "Windows is not based on .NET." On the one hand, if "Windows" refers to the black box bits and pieces of code which make up the Windows operating system, then it is pretty much true that Windows is not based on .NET. On the other hand, if "Windows" refers to the interfaces to the black box with which software developers typically interact, then it is largely true that Windows is based on .NET because .NET provides control of the operating system for the vast majority of projects. Yes, there are exceptions - but from a practical standpoint, the working of the black box is irrelevant for most projects and it appears that Microsoft recognized this when Longhorn was shelved. The speculation that the javascript/HTML5 model indicates a fundamental architectural shift in the Windows OS core seems to be unjustifed - the meaningful evidence for such an architectural shift being underway is the demonstrated ability of Windows 8 to run on diverse architectures. Which is why the FUD being disseminated about the Javascript HTML model is so interesting. It is nothing new; merely another implementation of an idea Microsoft has been kicking around for years: i.e. HTA's (HTML Applications) have been a part of Windows for more than a decade. [http://en.wikipedia.org/wiki/HTML_Application http://en.wikipedia.org/wiki/HTML_Application] [http://msdn.microsoft.com/en-us/library/ms536496%28v=VS.85%29.aspx http://msdn.microsoft.com/en-us/library/ms536496%28v=VS.85%2...] In addition given that .NET can provide total control of the browser and that such a browser exists on the Windows platform in the form of IE, the whole javascript/html model Microsoft demonstrates can be seen as just another layer running on top of .NET.
- ern 15y ago
  refers to the interfaces to the black box with which software developers typically interact, then it is largely true that Windows is based on .NET because .NET provides control of the operating system for the vast majority of projects I agree that the vast majority of Windows thick client business projects developed in the last few years probably target .NET, but, looking at the start menu on my Vista laptop currently, apart from dev tools, PAINT.NET and Keepass 2.0 (which still maintains a 1.x Win32 release), every other end-user application installed on my machine does not run on .NET. EDIT: In fact, I only run Keepass 2.0 for Mono compatibility on Ubuntu. I also would guess that a default Ubuntu desktop install has more dependencies on Mono, than a default Windows install does on .NET.

Developers asked about Windows APIs. Then Windows builds leaked to the internet with the new APIs. Maybe they got their answer?

MetallicCloud 15y ago

How can there be so much in fighting within Microsoft? Surely there must be a manager somewhere that looks over both teams and makes sure they aren't trying to shaft each other.

StrawberryFrog 15y ago
I'd imagine that that manager is Steve Balmer, or only 1 level below him. The heads of WinDiv (http://www.microsoft.com/presspass/exec/ssinofsky/ http://www.microsoft.com/presspass/exec/ssinofsky/ ) and DevDiv (Not sure who that is - Scott Guthrie or his boss?) are pretty senior. Has the infighting gotten worse since Bill Gates handed over?
- michael_dorfman 15y ago
  ScottGu's boss is Soma (http://www.microsoft.com/presspass/exec/somasegar/ http://www.microsoft.com/presspass/exec/somasegar/), if I am not mistaken.
  - StrawberryFrog 15y ago
    Ok. Still, I get the feeling that Balmer should be sorting this out and setting direction. or making sure that someone does. Doing the "vision thing". Leading, basically.

Blunt 15y ago

".NET would be the way to write Windows applications. Win32 would still exist for backwards compatibility, but it would be frozen and left static." OMG, Another non-technical person trying to write about technology again <sigh>

z92 15y ago
Just curious. How is it wrong?
- artmageddon 15y ago
  In my opinion, it's very misleading because the .Net framework relies on the Win32 API to interact with the operating system. Without Win32, there's no .Net, so if Microsoft plans to make upgrades/updates to the OS, how can it do so when Win32 is "frozen and static?" While it's clear that they will eventually(hopefully) rewrite the main applications(Explorer, Calculator, etc) to use .Net, that last part didn't seem to make sense given the dependency of .Net on Win32. Edit: Please correct me if I'm wrong, as I'm looking to make sure I understand. I based my comment off of David Morton / nobugz's comments in the following thread: http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/ac6a20d5-3d18-4eb2-acd6-5bae1774f14a http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/a...
  - deleted 15y ago
    [deleted]
  - bad_user 15y ago
    The problem with .NET is that nobody knows what it is. .Net framework relies on the Win32 API to interact with the operating system You're saying it as if Java and Java Swing do not interact with Windows. It is true that (e.g.) Windows Forms is built with Win32 in mind and is using native widgets, but on the other hand nothing prevents you from porting it and you can check out the Mono implementation, which is functional and runs on Linux and OS X. Of course, Java Swing is a much more portable implementation of a GUI toolkit, but even Java Swing makes Win32 calls and it is also cursed with the common-denominator problem. the dependency of .Net on Win32 Other than a couple of instances where you can clearly see that the design of Windows had a clear influence on .NET, Win32 is certainly not a dependency of .NET Sure, most .NET apps won't run on Linux or OS X, but that's mostly because their developers have been interacting with native code that isn't easily portable, but P/Invoke is so kick-ass that writing new managed bindings to native modules is a piece of cake, so devs are inclined to do that when it makes sense for them, instead of (say) search for a portable alternative.

nhebb 15y ago

I sell a Windows application targeted toward business users. 57% of my site's visitors are still running XP. Of those who purchase, 50% are XP, 40% are Win 7, and 10% are Vista users. So forgive me for not getting excited about changes to any upcoming version of Windows because until the folks in Redmond design an OS that businesses are interested in, it's mostly moot.

goalieca 15y ago
The thing that kills me is that XP is basically 10 years old now. It still "adds a new device" every time i plug in a usb key.
- melling 15y ago
  Why should this change? Microsoft has invested billions in Vista and Windows 7. It's time to upgrade. Supporting all the legacy costs Microsoft money that can be better spent on future enhancements.
  - cturner 15y ago
    Microsoft has invested billions in Vista and Windows 7. It's time to upgrade Non-sequiter. You can buy support for legacy versions of VMS, Unix and OS/2. Supporting all the legacy costs Microsoft money that can be better spent on future enhancements. It would be definitely be cost-effective to sell Windows XP support. The reason for withdrawing XP support are strategic, not cost-oriented (nor customer-oriented!!)
- CamperBob 15y ago
  Technically that's the fault of the hardware vendor for not including a valid serial # in the device's EEPROM. Did they change the behavior in later Windows versions?
  - notatoad 15y ago
    no, they didn't. vista and 7 still have exactly the same behaviour as XP for initializing a new device, they just do a better job of hiding it from the users.

larsberg 15y ago

This article gets more than a smidge of its history wrong. For instance, it makes it seem as if WPF (nee Avalon) was written by DevDiv in isolation from Windows, where in reality the Avalon team was mostly made of the former IE team after its legal dismemberment. In fact, we moved my team (which was focused on developer tools on, for, and made with WPF) from DevDiv buildings into Windows buildings just so we could build apps and tools for Avalon to help test their platform. But, it was a big effort. And even coming from inside of Windows, getting the rest of the shell to run on a whole new stack -- from drivers, through C++ layers, through managed -- was a challenge, especially with all of the other things going on in Longhorn. Sometimes, you bite off more than you can chew, especially when you make the dependency stack too deep. Also, all of this happened long before Silverlight efforts started... XAML came out of the WPF work. Arguing Silverlight stole DevDiv focus from WPF during the Longhorn timeframe is temporally impossible. Certainly, you could argue DevDiv was being pulled in many directions with the concurrent efforts to placate the VB4 crowd, push out a new version of VS, figure out a new syntax for Managed C++, compete with the then-rapidly-expanding Java tools ecosystem, and support all of the internal and demanding partners (especially SQL and other Windows efforts). But a substantial portion of both the tools and .NET runtime team's efforts were spent making Avalon perform, and I don't think that even now anybody who was there would claim that more DevDiv resources could have made the "Windows Shell is now made from WPF" effort succeed in the desired schedule.

io 15y ago

This might be interesting in ten years, when virtually everybody's running Win8 or later and I can consider using the new API.

brudgers 15y ago

The article plays on the ambiguity in the phrase "Windows is not based on .NET." On the one hand, if "Windows" refers to the black box bits and pieces of code which make up the Windows operating system, then it is pretty much true that Windows is not based on .NET. On the other hand, if "Windows" refers to the interfaces to the black box with which software developers typically interact, then it is largely true that Windows is based on .NET because .NET provides control of the operating system for the vast majority of projects. Yes, there are exceptions - but from a practical standpoint, the working of the black box is irrelevant for most projects and it appears that Microsoft recognized this when Longhorn was shelved. The speculation that the javascript/HTML5 model indicates a fundamental architectural shift in the Windows OS core seems to be unjustifed - the meaningful evidence for such an architectural shift being underway is the demonstrated ability of Windows 8 to run on diverse architectures. Which is why the FUD being disseminated about the Javascript HTML model is so interesting. It is nothing new; merely another implementation of an idea Microsoft has been kicking around for years: i.e. HTA's (HTML Applications) have been a part of Windows for more than a decade. [http://en.wikipedia.org/wiki/HTML_Application http://en.wikipedia.org/wiki/HTML_Application] [http://msdn.microsoft.com/en-us/library/ms536496%28v=VS.85%29.aspx http://msdn.microsoft.com/en-us/library/ms536496%28v=VS.85%2...] In addition given that .NET can provide total control of the browser and that such a browser exists on the Windows platform in the form of IE, the whole javascript/html model Microsoft demonstrates can be seen as just another layer running on top of .NET.

ern 15y ago
refers to the interfaces to the black box with which software developers typically interact, then it is largely true that Windows is based on .NET because .NET provides control of the operating system for the vast majority of projects I agree that the vast majority of Windows thick client business projects developed in the last few years probably target .NET, but, looking at the start menu on my Vista laptop currently, apart from dev tools, PAINT.NET and Keepass 2.0 (which still maintains a 1.x Win32 release), every other end-user application installed on my machine does not run on .NET. EDIT: In fact, I only run Keepass 2.0 for Mono compatibility on Ubuntu. I also would guess that a default Ubuntu desktop install has more dependencies on Mono, than a default Windows install does on .NET.