Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Microsoft Programming

The Longhorn Dream Reborn 254

Posted by timothy from the longhorn-dream-is-enlarging-barton-springs dept.
gbjbaanb writes "Early this month, Microsoft dropped something of a bombshell on Windows developers: the new Windows 8 touch-friendly immersive style would use a developer platform not based on .NET. Cue howls of outrage from .NET developers everywhere, but here Ars Technica describes what's more likely to have been going on and why Microsoft is finally getting its act together for developers."
This discussion has been archived. No new comments can be posted.

The Longhorn Dream Reborn More

The Longhorn Dream Reborn

Comments Filter:

  • Standard modus operandi (Score:3, Interesting)

    by mrsam ( 12205 ) on Thursday June 23, 2011 @06:05PM (#36548556) Homepage

    If anything, we should be surprised that anyone's surprised. Whether or not TFA's theory is true, one thing is absolutely clear: .NET, like any Microsoft technology, has an expiration date.

    Anyone remember COM, VBX, and other MS-Windows technologies of yesteryear? Or the Visual Basic debacle of more recent vintage. For as long as I can remember, there's been a steady churn of Microsoft technologies, coming and going.

    Microsoft makes a lot of money from selling its development tools, documentation, etc... to its developer base. Microsoft simply runs the whole show. They are in full control, and call all the shots. And they understand perfectly well that if they keep the same technology platform in place, over time, they lose a good chunk of their revenue stream. That's why they have to obsolete their technology platforms, time and time again. They need revenue. It makes perfect sense. If you are a Microsoft Windows developer, one of your primary job functions is to generate revenue to Microsoft. Perhaps not from you, directly; maybe from your company. Whoever pays the bills for Visual Studio, MSDN, and all the other development tools. Maybe it's not you, personally, but it's going to be someone, that's for sure.

    So, perhaps this is the death knell for .NET. Perhaps not. If not this time, maybe next year. But it's inevitable. It's a certainty. If you are a .NET developer, your skills will be obsolete. If you were a COM developer, or a VB6 developer, your skills became obsolete a long time. I see no reason why .NET developers will escape the same fate. It's only a matter of time, but that's ok: all you have to do is invest some time and money to retrain yourself on the replacement Microsoft Windows technology, whatever it's going to be, when its time comes. But, it'll come.

    Originally I came from a Unix background. Many, many moons ago I explored the possibility of boning up on the MS-Windows ways of doing things. But, after a bit of some exploratory peeks and pokes, this became painfully clear to me; that whatever I learned, all of it was going go to waste, in its due time. And that was pretty much the end of my venture into the Windows landscape.

    Well, I'm happy to report that read(2), write(2), and all the other syscalls that make up POSIX, and its derivatives, still work the same as they did decades ago. Everything I have learned, as the sands of time have rolled on and on, I still put to good use today, and I make a pretty good living using them. Nothing has gone to waste. Honestly, this is more than I could say for my peers who practice their craft on MS-Windows. A lot -- not everything but a lot -- they learned decades ago is now completely and totally worthless to them, and to anyone else.

    So, whether Windows 8 is Longhorn reborn, as TFA says, or not, one thing can be said for certain. .NET is dead. It's just a matter of time. Good luck learning its eventual replacement. Of course, you understand that it'll be dead too, some years after that, of course; just keep that in mind, as you make your long term plans.

    • Re:Standard modus operandi (Score:5, Insightful)

      by exomondo ( 1725132 ) on Thursday June 23, 2011 @06:19PM (#36548766)

      I'm happy to report that read(2), write(2), and all the other syscalls that make up POSIX, and its derivatives, still work the same as they did decades ago.

      Great, so it's dead too since it hasn't changed for decades? Same as with COM, there's nothing stopping you from using it and it still works the same as it did many years ago. You can still use all the old technologies and they still all work just the same as they used to.

      • Re: (Score:3, Interesting)

        by antifoidulus ( 807088 )
        Your confusing implementation with interface. read and write's implementation has kept up with the times while maintaining the same interface. So to the programmer it doesn't matter if you are doing a read on a floppy or a wide scale distributed file system via the FUSE interface*, logically it's all the same. Furthermore, although the read and write interfaces haven't changed, there is absolutely nothing stopping you from developing new interfaces that run on top of these functions.

        Now compare that t

        • Your confusing implementation with interface. read and write's implementation has kept up with the times while maintaining the same interface.

          Kept up with the times? So has Win32.

          Now compare that to Microsoft who constantly deprecates interfaces which means no new features are ever back ported

          Oh come on don't be obtuse, look at MFC, it's nearly 20 years old yet it still gets new features, it even got the new ribbon APIs.

      • Of course the technologies still work, but does Microsoft support them? Does Microsoft update them to fit modern needs? Can you get as many jobs writing in them? Can you get jobs other than maintenance jobs in them?

        • Of course the technologies still work, but does Microsoft support them?

          Well ancient things like COM and MFC are still available in the latest VS and are still supported.

          Does Microsoft update them to fit modern needs?

          MFC is nearly 20 years old and got all the recent ribbon updates.

          Can you get as many jobs writing in them?

          I don't know.

          Can you get jobs other than maintenance jobs in them?

          Of course, you can't find any?

      • I'm happy to report that read(2), write(2), and all the other syscalls that make up POSIX, and its derivatives, still work the same as they did decades ago.

        Great, so it's dead too since it hasn't changed for decades?

        Why would you think that? We still have files with bytes in them, pipes, sockets, and all the other things these system calls work on. And since we're still working with the same concepts, and we have a good API for them, why would we want to change the API?

        Same as with COM, there's nothing stop

    • Re:Standard modus operandi (Score:5, Interesting)

      by David Gerard ( 12369 ) <{ku.oc.draregdivad} {ta} {todhsals}> on Thursday June 23, 2011 @06:27PM (#36548844) Homepage

      Fortunately, free software means that Windows developers can use Win32 approximately forever! On WINE.

      I have a theory: like backups, no-one ever really gets the idea of free software until the lack of it has bitten them in the arse, good and hard.

    • Re:Standard modus operandi (Score:4, Informative)

      by obarthelemy ( 160321 ) on Thursday June 23, 2011 @06:30PM (#36548884)

      You're kinda comparing apples and oranges: on the one hand, MS is trying to provide APIs, libraries features and tools for advanced, maybe even "innovative" features (maybe in misguided ways, but that's not my point), on the other hand, you list almost bare-metal APIs.

      As far as I know, these haven"t changed in Windows much either, but most devs simply don't use them.

      I'm fully aware that COBOL isn't dead either... It's just not where most of the jobs/money/action is, though I'm sure quite a few people are quite happy working in that space.

    • Originally I came from a Unix background. Many, many moons ago I explored the possibility of boning up on the MS-Windows ways of doing things. But, after a bit of some exploratory peeks and pokes, this became painfully clear to me; that whatever I learned, all of it was going go to waste, in its due time. And that was pretty much the end of my venture into the Windows landscape.

      I have to disagree, as anything learned is an advantage you can leverage in future learning.. Also, during the time that 'xyz tech' is in vogue, you are employed and making money from it.. that's not a waste in my book..

    • Re:Standard modus operandi (Score:5, Interesting)

      by WrongSizeGlass ( 838941 ) on Thursday June 23, 2011 @06:32PM (#36548914)
      I have a client that has been dragging their feet about leaving their VB6 codebase running on an Access DB and migrating to .NET on MS SQL. Last week one of them saw the Microsoft announcement about 'HTML5 & JavaScript' and now they're afraid transitioning to .NET will be a dead end. Now they want to wait to see how Windows 8 will run their VB6/Access code. They have a lot of time invested in Office 2003 macros & Access code modules, but their DB is nearing the 2GB Access limit and their programmer is retiring in 6 - 12 months. They'll be running XP, Office 2003 & VB6 until they have no other options.

    • Re:Standard modus operandi (Score:5, Insightful)

      by Jahava ( 946858 ) on Thursday June 23, 2011 @06:37PM (#36548950)

      Microsoft makes a lot of money from selling its development tools, documentation, etc... to its developer base. Microsoft simply runs the whole show. They are in full control, and call all the shots. And they understand perfectly well that if they keep the same technology platform in place, over time, they lose a good chunk of their revenue stream. That's why they have to obsolete their technology platforms, time and time again. They need revenue. It makes perfect sense. If you are a Microsoft Windows developer, one of your primary job functions is to generate revenue to Microsoft. Perhaps not from you, directly; maybe from your company. Whoever pays the bills for Visual Studio, MSDN, and all the other development tools. Maybe it's not you, personally, but it's going to be someone, that's for sure.

      So your argument is that Microsoft intentionally periodically obsoletes languages in order to make money? Am I reading this correctly?

      You do understand that:

      • Pretty much every commercial MS developer already has an MSDN license, which (minimally) gives them access to the latest development languages, SDKs, and tools.
      • Developing a new language that is at least as compelling as a current one is an expensive and non-trivial feat.
      • Obsoleting a language costs Microsoft a ton of money in rewriting their own software to create new APIs and then use them.
      • Each API and system rewrite introduces new bugs, costing Microsoft even more money identifying, patching, and being held accountable for.
      • One of the oldest MS-supported development languages, C++, has not been obsoleted.
      • One of the major issues with MS development is the legacy APIs that bias towards C++ functionality.

      I think your theory has some holes. Now, Microsoft has definitely obsoleted languages - Visual Basic for one (and good riddance) - but they did that because the language had shortcomings. I'd detail them but we have a nice article that already does that. The .NET framework and language stack, C# in particular, is on the same general level as Java: it is a language that more or less suits the needs of every platform developer. Why the hell would they want to obsolete that?

      No, languages aren't the issue with MS development, nor are they the theme of the article; frameworks are. A perfectly good language can be horrendous to use if it is unable to properly interact with its host environment to accomplish what it needs to accomplish. In this case (once again FTFA) C++ could interact worlds better with Windows than .NET could, and so .NET use suffered. This was an implementation failure on Microsoft's part. The article stipulates that Windows 8 intends to bring .NET back on-par with C++ as a development language, which (if true) means that it will be stronger than ever.

      It's also worth mentioning that in terms of accumulated skills and experience, learning a new language is trivial compared to truly learning a new framework. How you interact with the system and cause it to give you the resources and services that you want in the manner in which you want them is the heart of all modern systems programming, regardless of language. If Microsoft emphasizes .NET in their APIs, then .NET will be a viable Windows development platform; if not, then who knows? None of that reflects on the language itself, but rather on its appeal over other languages.

      Now, eventually every language will be obsoleted ... probably? I suppose we haven't been through that many generations of languages to know for sure, but that seems to be the case so far. There are various reasons languages die ... they suck, better ones come out, nobody likes them, no frameworks support them, or their target developer group gives up on it. .NET's main backer is cu

      • Keep in mind, MSDN licenses are annual subscriptions - so MS developers pay for the dev tools EVERY YEAR, and they keep on paying .......

      • However, the article makes the point that Microsoft's .NET framework capabilities are increasing substantially, not decreasing. This speaks positively for its future.

        That's true if the desktop stays dominant. With C++, you can write desktop, iPhone, and Android apps (well, you need to learn enough Java/Objective C to do the interfaces)... so I guess if non-windows platforms take off, you might still see .NET wain.

      • The .NET framework and language stack, C# in particular, is on the same general level as Java: it is a language that more or less suits the needs of every platform developer. Why the hell would they want to obsolete that?

        No, languages aren't the issue with MS development, nor are they the theme of the article; frameworks are. A perfectly good language can be horrendous to use if it is unable to properly interact with its host environment to accomplish what it needs to accomplish. In this case (once again FT

        • Re: (Score:2)

          by Jahava ( 946858 )

          PS - If not obvious, this is all my own armchair analysis of the situation and it's probably way off base.

          Not at all; I totally agree, and the problem is systemic and probably not a bad thing. It's a simple consequence of choice and variety. Different people and companies will take different approaches to solve problems, while several developers may want to solve the same problem for all platforms. Everyone has to meet in the middle.

          There are several approaches to the problem. Some involve comprehensive frameworks (QT, Java/Swing, Java/SWT, .NET, Mono, and tons of others), there are attempts to enhance one lang

      • So your argument is that Microsoft intentionally periodically obsoletes languages in order to make money? Am I reading this correctly?

        You do understand that:

        Pretty much every commercial MS developer already has an MSDN license, which (minimally) gives them access to the latest development languages, SDKs, and tools.

        You do understand that:

        MSDN licenses cost a lot of money. Were it not for the constant churn, developers wouldn't need MSDN subscriptions, and could save a a lot of money.

        • Re: (Score:2)

          by Jahava ( 946858 )

          So your argument is that Microsoft intentionally periodically obsoletes languages in order to make money? Am I reading this correctly?

          You do understand that:

          Pretty much every commercial MS developer already has an MSDN license, which (minimally) gives them access to the latest development languages, SDKs, and tools.

          You do understand that:

          MSDN licenses cost a lot of money. Were it not for the constant churn, developers wouldn't need MSDN subscriptions, and could save a a lot of money.

          Companies pay for MSDN licenses for a lot more than the latest language. They provide the latest SDKs, documentation, tons of tools, exemplar operating systems, future betas and product (to test and build against), and, of course, a gigantic repository of forum knowledge and a means of engaging Microsoft. Obviously the MSDN / developer model that Microsoft has established is for profit and cash. No shit.

          The point I was making is that they don't have to phase out .NET to keep that stream going. Sure, you may

          • Hm. Well, .NET isn't a language, of course.

            I think the basic point is that Microsoft is constantly obsoleting development tools, requiring upgrades to remain relevant, just like they obsolete software like Office and Windows itself, requiring upgrades, all of which forces the purchasing of new licenses for minor upgrades and changes--some of which aren't even improvements.

            Compared to FOSS, which, by and large, doesn't force costly upgrades to remain useful and relevant and secure, and is much more self-sus

    • It wouldn't kill you to actually read the article, you know.

    • Re: (Score:2)

      by Raenex ( 947668 )

      Microsoft makes a lot of money from selling its development tools, documentation, etc... to its developer base. [..] That's why they have to obsolete their technology platforms, time and time again. They need revenue.

      Tinfoil hat ranting. Do you have references to back this up? Microsoft makes the bulk [businessinsider.com] of their money by selling Windows and Office. Do you think they actually want to drive developers away? Note that "Tools" sales are bundled into "Server and Tools", which includes things like SQL Server, so only a tiny portion of Microsoft's profit comes from selling tools, if any.

    • I think your sort of missing where .NET was targetted. In my view .NET was never intended to be a replacement to the native C interfaces (MFC, COM, etc) but rather as a way of taking on the Java market for servers and Delphi/VLC market for desktop development, and succeeded in it because Java (at least at the time) was utterly unsuited to agile high turnover development, and Delphi was being tragically mismanaged, priced out of the market and being ignored in favor of utterly wierd "middleware" frameworks t

      • Re: (Score:3)

        by bored ( 40072 )

        Many coders to this day hold Delphi 4 to be one of the most productive environments of all time

        I will buy that, in fact I would probably put it ahead of current .net platforms as well. Then there was C++ Builder which was basically delphi with ugly syntax. Either way, M$ started switching their API's to COM even before .net. That was the first major change in the M$ API churn. When that happened I pretty much started to write the native platform off because there wasn't any reason that those API's couldn't

      • Dude. It's VCL, not VLC. And Delphi (and it's retarded cousin, C++ Builder) were nice tools, but suffered from a major flaw. The component model was brittle, and required recompilation to change anything. COM and .NET have ways to extend components with multiple interfaces. VCL did not.

        This is why, when you look at Delphi and BCB components, you have to buy them for a specific version. This is not true of COM and C++ components.

    • Re: (Score:2)

      by cecom ( 698048 )

      No, no, you don't understand. Microsoft does this because they care! Ask any Windows developer :-)

      Seriously though, objectively speaking, no matter how ridiculous this technology churn seems to us looking from outside of the Microsoft universe, it does keep people perpetually employed. It feeds not only Microsoft but a huge ecosystem of businesses, consultants, IT experts, MCEs, support stuff, technical book authors, administrators, etc. It is great!

      It may look inefficient, but if it was really inefficient,

    • Comparing posix read() and write() to the shifting sands of MS APIs is pretty silly. If you're going to make a comparison to Unix, at least compare apples to apples. So once upon a time I wrote code in C++ with Qt 1.0. Then Qt 2.0 came along, which was mostly compatible, but introduced new features. Then Qt 3, then Qt 4. Some things were deprecated, some things added. Developers had to adapt. Same with Gtk+ 1 to Gtk+ 2. That was a pretty painful leap for developers with several important (but unders

    • Anyone remember COM, VBX, and other MS-Windows technologies of yesteryear? Or the Visual Basic debacle of more recent vintage. For as long as I can remember, there's been a steady churn of Microsoft technologies, coming and going.

      Well COM is still used as the basic programming interface today. Look at one of the most recent additions to the Windows UI - the Ribbon. According to the Ribbon introduction on MSDN [microsoft.com]:

      "The Ribbon framework provides this flexibility by separating functionality from presentation with two distinct development structures: an Extensible Application Markup Language (XAML)-based markup language to declare controls and the visual layout of a Ribbon implementation, and C++ COM-based interfaces to initialize the fram

    • Re: (Score:2)

      by Spykk ( 823586 )
      If Microsoft can come out with something new that is as big an improvement over .NET as .NET was over VB6 then I will happily spend the time required to learn it. Writing forms applications in C# is downright pleasant.

    • Re: (Score:2)

      by afabbro ( 33948 )

      Everything I have learned, as the sands of time have rolled on and on, I still put to good use today, and I make a pretty good living using them. Nothing has gone to waste.

      Yeah, it's a snap finding those jobs supporting UUCP on Irix. Well, as long as they're COFF binaries and I can telnet or rsh into the box, it's not too bad. I just look at the K&R source with pcat.

    • It's a certainty. If you are a .NET developer, your skills will be obsolete.

      I disagree. Having been in development for some time now, I've had ample opportunity to observe the various trends in programming and software development. The churn that was more characteristic of many previous technologies, going all the way back to the early mainframes from IBM and others, stemmed in large part from the close association between software and the hardware on which it ran. However, beginning with the rise and popularity of Java and continuing with .NET we see the increasing virtualization

    • Re: (Score:2)

      by smash ( 1351 )
      If you think .net is going anywhere, you've got rocks in your head.

    • Re:Standard modus operandi (Score:5, Interesting)

      by bmajik ( 96670 ) <matt@mattevans.org> on Friday June 24, 2011 @01:49AM (#36552068) Homepage Journal

      I am a Microsoft employee in DevDiv.

      (PS: Buy Visual Studio LightSwitch when it comes out! It rocks!)

      I will not comment on the accuracy of what is in the ars article, other than to say: I know the answers to some of the questions they are worried about, and the answers do not worry me and shouldn't worry you either (unless you're a competing non-MS technology, perhaps :))

      Regarding your post: I don't see how you'd conclude that .net is going anywhere from the article you supposedly read.

      First and foremost, you would need to be specific about what you mean by ".net" for your statement to even make sense. Are you claiming that C#, the language, is on an EOL path? Or the .NET runtime will no longer be a supported way of writing userland apps?

      Your claim that we intentionally obsolete developer technologies as some sort of money making scheme is hillarious. Have you worked in the commercial software industry before? Let me explain how it works.

      1) we spend a ginormous amount of money paying engineers to make something that we hope developers use.
      2) we figure out if its something we can even charge money for, or if we need to give it away so more people will develop for our huge money making platforms (Windows, SQL, Office, Sharepoint)
      3) when we have something we can give away / sell for a pittance, we start doing so
      4) this is when we might actually start getting money for our efforts.

      Now then, if our strategy was to make money at any cost, you'd think that we'd fire all of the engineers and keep selling licenses at the same price indefinitely.

      But as you've noted, our engineering staff moves on to new things and eventually the old things get phased out.

      We don't start working on new platforms because we need to figure out how to get more money out of existing customers. We work on new platforms because we think they'll be better than the old ones; that customers will like them more; that they'll provide more value to everyone. There are all kinds of features and products we'd LIKE to put out there in the real world but they all cost us more money to do. And as you've noted, everything we release causes someone to get upset if we want to stop supporting years later. For every one of these developer technologies we ship, we end up supporting it for years after we're not selling it (and thus not getting new revenue). Our support life cycle is a hell of a lot longer than Apples, or any of the for-pay Linux distros, for instance.

      Finally, regarding what a huge revenue stream deveopers tools are for us... I've never come across anyone in Windows or Office who is worried their project is going to be killed and their staff moved onto a _real_ money making project like the F# compiler :)

      Sure, DevDiv does great revenue compared to a lot of entire companies. But look who we're competing against. I'm not sure we've ever sold 300 million seats ever, counting everything we do. Windows does that _every release_.

      (nothing against the F# compiler guys. I just picked something :))

    • Re: (Score:2)

      by Malc ( 1751 )

      What are you talking about? COM is far from dead, and still represents a very important core technology on Windows. It's very mature now, even though it doesn't get nor need much hype or attention. It's a language neutral binary spec that has lasted the test of time. In fact I've used it on two projects this year already because it seemed the easiest and quickest solution to either exposing a .Net assembly to a native C++ app, and for providing a 64-bit app access to a 32-bit DLL that can't currently be

  • RTFA (Score:5, Informative)

    by darkwing_bmf ( 178021 ) on Thursday June 23, 2011 @06:52PM (#36549070)

    The article says windows is getting a new API, WinRT, which is a modern version of Win32. .NET and C++ development will both be updated for WinRT and have the same capability as each other so you can work in the environment you choose. Silverlight is supported, updated and renamed (codenamed?) Jupiter. Some other new things were added. In summary, .NET developers, you're getting new functionality. C++ developers, you're getting new functionality. Plus it will be easier than ever to go back and forth between the two because, underlying it all, is a new unified API.

  • Peter Bright, an Ars Technica contributor, writes that [arstechnica.com]

    Early this month, Microsoft dropped something of a bombshell on Windows developers: the new Windows 8 touch-friendly immersive style would use a developer platform not based on .NET, which Microsoft has been championing for the past decade. Instead, it would use HTML5 and JavaScript.

    But he doesn't believe the alarmist hype:

    Windows developers want to be able to build immersive applications, and they don't want to have to use HTML5 and JavaScript to do it.

    They won't have to. Want to write an immersive application in native C++? That's cool. Want to use C# and Silverlight? That's cool too. Both will be supported. Far from being left behind on the legacy desktop—which was the impression that many took from the presentation—native C++ and managed C# will both be first-class, supported ways of developing immersive, touch-first, tablet-friendly Windows 8-style applications.

    (Feel free to write another, better summary. The one given is just completely inadequate for such a long article.)

    • For that matter Peter Bright is wrong, whether he believes the hype or not, because there was no bombshell to begin with. At no point it was said that "the new Windows 8 touch-friendly immersive style would use a developer platform not based on .NET". The only thing that was said is that you will be able to develop for Windows 8 using HTML5 & JS. A few people took the latter to imply the former, and published stories where said implication was treated as plain fact - like the one mentioned in TFA - and

  • Microsoft fanfiction. (Score:3, Funny)

    by Alex Belits ( 437 ) * on Thursday June 23, 2011 @07:24PM (#36549404) Homepage

    The article is something that I have never seen before -- Microsoft fanfiction.

    What creates an interesting problem -- since Microsoft fanfiction exists, according to the rule 34 there must be Microsoft slash fanfiction. But since there is only one instance of Microsoft fanfiction and it is not slash, someone on the Internet must write Microsoft slash fanfiction.

    Go, Internet, go!

    • Re:Microsoft fanfiction. (Score:4, Informative)

      by VortexCortex ( 1117377 ) <VortexCortex AT ... trograde DOT com> on Friday June 24, 2011 @05:11AM (#36552846)

      There are official MS OS Anime personifications, and there have been for quite some time.

      I see that although you are not new to the net, you are new to this topic, so I'll link you to one list of the OS-tans. [ostan-collections.net] I'm sure you'll have no problem finding the other less NSFW places yourself to see more and better quality pics/fics, if you are so inclined...

      There is indeed slash fiction. I read one not too long ago about XP-tan [imageshack.us] having an affair with Windows7-tan [photobucket.com], Vista-tan [muryou-ani...lpaper.net] was quite upset (her abandonment issues surfacing yet again); The always compassionate Linux-tan [ostan-collections.net] tried to console her, but it made the needy OSX Leopard-tan [deviantart.net] very jealous (apparently consoling a rival is a grave transgression on her home planet).

      There are OS-kuns (males) as well... My girlfriend told me of the new yaoi slash she was reading where OSX-Kun [ostan-collections.net] fell in love with the heroic and savage XP-kun [fotolog.com] who had rescued him from the lair of the evil scientist Dr. Mac-Defender. In the heat of their passion OSX-kun had unknowingly infected XP-kun with a virus; Thus, both OS-kuns were soon on their way to see the comically bungling Dr. Norton-kun [ostan-collections.net].

      Fear not my friends, Rule 34 can not be denied.

  • Maybe the response from .net developers is more rooted in the fact that a JS/HTML5 based application development language brings a whole lot more developers to the party with less of a learning curve.

    • No, I'm pretty sure the (erroneous) reaction is just "I'm getting paid because .NET development works on Windows, and you're dropping support?!!!!". It's unclear how much web developer experience with JS/HTML5 will translate to whatever desktop app system Microsoft cooks up. You bring up a good point, but I doubt it's the root of any reaction.

  • The last time they promised that, Vista.

Slashdot Top Deals

Technology is dominated by those who manage what they do not understand.

Close