More Windows touchy friendly.
Oh hell. The removal of basic tools in the name of making Windows "more friendly" is already a pain in the butt. I, personally, could do with a less friendly but more powerful and flexible version of Windows.
Insert 'anonymous' MS hating rhetoric ...
Re: programming model is complicated
Funny how people latch onto different things. I came away from the article thinking it all sounded just like client-side Java, from about 15 years ago. At the time I thought that was a nice idea, but apparently the world disagrees and only a fule would sign up to the proposition that the network is the computer.
Oh, and beyond the literal reference, I couldn't see the connection to COM at all. COM was native mode code running within the security model of the OS, fully extensible by third parties. The principal (only?) innovations of .NET were to sandbox the whole thing and invent a fake processor architecture. They kept the third-party extensibility. Looks like they're now getting cold feet on that one too. At this rate, Windows 9 won't have an API because you won't be allowed to write apps for it.
Did you miss this bit?
"It is also obvious that Metro-style apps are not capable of everything Windows developers want to code, so desktop development will remain strong and largely .NET-based"
It amuses me that you're laughing at net developers, yet seem completely oblivious that problems like DLL hell were solved in .NET through strong names and signing.
Perhaps if you knew a bit about your .NET you wouldn't be harping on about a problem that was solved over a decade ago on Microsoft's platform.
Perhaps if you had this knowledge you wouldn't look like someone who might have known a bit about computers in the 90s but has become an obsolete waste of space in the decade since.
In some ways I would bloody well hope that MS aren't using .Net internally as they need to keep skills in that which exists below (C/C++ etc) as they're writing the frameworks and the OS.
You misread the article and/or are adding your own inferences. They are saying it's not happening on mobile - so what? The article states that it's going to be around for a very long time...
"What then are the implications for .NET on the client? It was obvious at BUILD that it is C# developers that dominate on Microsoft's platform – sessions on the language were packed to overflowing – and it is likely that more WinRT code will be written in C# than in any other language. It is also obvious that Metro-style apps are not capable of everything Windows developers want to code, so desktop development will remain strong and largely .NET-based.
Looking into the future as Microsoft envisages it, though, desktop Windows seems unlikely to evolve much beyond what we already have in Windows 7, which is set to become the new Windows XP in terms of its life on corporate desktops."
Do I or others in the enterprise (probably the largest user of .Net) give a shit about metro apps? No we don't. We will be using Windows 7 for quite some time, as indicated, and on it will be C#.
Are MS missing the point?
I'm sure I'm not in a minority in developing BUSINESS applications for Windows. What is Metro going to do for me when I need to write something for Purchase Order generation? What about that complex DB front-end?
Anything that I'd write for Metro I'd probably first develop as a browser-based application. If it's not suitable as a web app then I doubt Metro will cut it either.
Am I wrong?
I think you're right
As described, Metro appears to be effectively the same as running in a browser sandbox, just possibly a bit faster than Java.
In fact, it doesn't half look like Google Native Client by another name.
So I really doubt anyone will bother - better to simply develop for the browser if you can live inside those constraints, as then you're not limited to Windows 8 Metro, instead the majority of platforms can use your application.
As to "DLL Hell" - I think this approach actually eliminates DLL hell by ensuring that you can't share compiled code between applications anymore. The only shared installed code in this model is inside OS libraries!
To be fair, that does appear to be the primary approach is use these days anyway - Windows side-by-side actually works pretty well but almost everybody seems to install the DLLs inside the program folder anyway, removing any chance of sharing the installed code.
This eats HDD space for breakfast of course, but I suppose that doesn't matter too much on the desktop. However, I think it will matter on a tablet form factor as you have to use flash for that - which is still very expensive, especially as Apple have eaten most of it.
Are YOU missing the point? - Yes
Your PO generation or complex data input program will stay in the desktop unless you can envision a touch friendly interface. However, there's no reason you couldn't create metro apps that are companion apps to support your business app. Do you have users/roles that log into the app to do simple tasks? Move the simple tasks to your metro companion app.
However, I have seen examples of very complicated applications redesigned to run in Metro and do so very well. Some apps I've seen would have been a very complicated design in a traditional windows forms application, were actually very simple to use in a metro interface.
Re: Are MS missing the point?
Yes. But, what's new?
"Am I wrong?" -- No. I'd say you're certainly right.
And as Eadon before me so eloquently put it: "if you're a .NET developer - hahahahahaha"
Me, I think Metro weirdly reminds me of Unity too much (no, really). Although W8 boots amazingly fast and runs incredibly well on limited hardware.
Don't worry. That won't last. Final release will almost certainly be a horrific bloatfest and leave everyone, users and developers alike, blundering about in shellshock wondering "what the hell just happened?".
So you want some apps built for XP/7 and some for metro. If developing for both is going to be as seperated as it seems, then won't you have to build everything twice? What happens when a metro user is asked to help with work on a company's XP/7 system? They won't be used to the look or functionality so that's another impedence to productivity.
Not at all. There's still a desktop on Windows 8. I'm saying you can develop an app for the desktop if that's the right place for your app, then you can build companion apps that run in Metro (still part of windows 8) that compliment your desktop app.
I'm done designing/building apps for XP. The desktop app I build for Windows 8 will be the same desktop app used in Windows 7. The windows 7 users just won't get the companion metro app.
So, like I said, you'll be developing 2 sets of apps, one W8, one Metro
"I'm done designing/building apps for XP. "
You're not done yet as
"The desktop app I build for Windows 8 will be the same desktop app used in Windows 7. "
You're still building desktop apps and as W8 is just XP (and W95) with blurry edges around the windows ... :P
No real surprises
You don't see much love in MS's own applications for managed code, either .NET or Silverlight. Many of their previous attempts to wrap native libraries with managed code have been dire (System.Drawing, the awful wrapping around the turd that is GDI+ springs to mind) and the second go round (WPF and XAML) was slightly cleverer but still left a hell of a lot to be desired. Some of the Silverlight stuff (eg, the 3d graphics routines) was utterly, inexcusably slow and memory-inefficient, as if it had been written by an intern or something.
Third time lucky maybe? They'd better be... they've messed around their developers for far too long. I'm very glad I never took the trouble to use WPF for serious work; my concerns about its future were well founded and I've made much better use of my available brain space.
Dual Personality !
The last time MS tried that sort of stuff it was mixing W32 and 16 bit libraries into that awful OS called ME, this going to be painful.
GDI is horrid, but at least unlike DirectX it's designed for Window Icon Mouse Pointer interface, DirectX is a huge monster of an Adhoc interface invented to make porting DOS Games easy.
COM was stupid and it's offspring DCOM evil.
Is there no-one left in MS that can do real OS design or is it dominated by Xbox, Zune and Win95 games folks?
Re: COM was stupid and it's offspring DCOM evil.
COM was system-level support for Aspect Oriented Programming. DCOM was an obvious application of the underlying idea, to support aspects concerned with "who" and "where" code was running. MTS was another obvious application, making it easy to write fully transacted code.
It was a thing of beauty. You'd get security or ACID correctness enforced at the boundaries of your code simply by ticking the "yes, please" box in the registry for your code.
Microsoft once said they'd open up the API still further, with interfaces to let you define your own aspects (contexts, in COM-speak) and somewhere in the Vista SDK there are interfaces that suggest they eventually did so. Sadly, by that time, their marketing department had moved back to something vastly inferior.
And if COM also weeds out programmers who are too stupid to even count references or remember to register their code, then end-users are the better off for it.
no, all have been taken over by evil work of Visual Studio team and its chief architect Herb Sutter http://herbsutter.com/2011/09/19/my-two-build-talks-online/
... who just happens to be convener to C++ standard commitee, which only serves to prove that C++ is Evil Microsoft Invention , Lius was right to stick to plain old C and any attempt to patch over lack of ABI in C++ on Windows is PURE EVIL !
hm somehow "Joke Alert" icon got missing from my previous post. Moderator?
Our tech team has been working on a fix and icons should work now... we can't get those adorning comments from the last 24 hours back though...
Article does a great job of detailing more reasons to migrate to linux
They clearly succeeded in turning Windows 8's internals into even more of a dog's dinner.
I'm a Linux/C/my-own-stuff programmer myself (never used Windows much, but have done a bit of work with it in the past). But, I find what MS is doing here quite interesting. For example, the concept of not allowing full file paths to be used from inside the code, instead requiring them to come from the user, is an interesting idea. However, I'm pretty old fashioned (I *like* strong static typing), so I don't know how well some of this will go over with the latest generation of wizz kids.
I tend to sympathise with MS regarding file paths - lots of lazy programmers hard coding paths which include, for example, system32, is the reason we end up with 64bit DLLs having to be put into system32 on 64 bint machines. It was either that or MS break hundreds of programs, they were very much between a rock and a hard place on that one.
What's the fascination with making a desktop OS touch-friendly?!
Touchscreen interface is a compromise and a better alternative to pressing a button three times to get one letter.
I'm happy with a full-size keyboard and mouse 95% of the time.
Of course they were happy, they were all given a shiny new slate to play with. Who cares if the code will be easy, right now it's play time!!! Seriously, Windows 9 will have the missing bits added and will be awesome. And guess when Phone 8 comes out? At the same time Windows 8 is released! In lockstep from now on. And it will have WinRT as well, so that apps are portable.
I'm looking forward to it
Face it, there's going to be PLENTY of upgrade/refit work out there. Which suits me just fine.
See, that's the enterprising spirit.
...and the next step... open source .NET
Microsoft has already open-sourced F#, and whilst C# is an excellent language, it has not dislodged Java for Enterprise Applications because it was tied to Windows and Mono has failed to keep up.
The .NET story for MS is now about promoting Azure, and the best way to do that is to open-source the client and runtime.
"Microsoft has already open-sourced F#, and whilst C# is an excellent language, it has not dislodged Java for Enterprise Applications because it was tied to Windows and Mono has failed to keep up."
Not in the enterprises I've worked in - anything developed in-house on the desktop was .Net. Period. It's also moving into a lot of the server-side code previously the sole domain of Java principally, I would guess, because you're already employing C# on the desktop so why not just get some server guys too? Server OSes from MS have improved and it certainly doesn't hurt that Visual Studio is an excellent IDE even if it does come from MS.
It may not have dislodged it in that Java is still heavily used but the split seems pretty even in terms of employment prospects at present (Jobserve UK/Europe search). Be interesting to see what difference this announcement and Oracle's continued arsehole behaviour makes.
"Microsoft has already open-sourced F#, and whilst C# is an excellent language, it has not dislodged Java for Enterprise Applications because it was tied to Windows and Mono has failed to keep up."
This is wrong. You only have to look at any job site, or speak to any IT recruitment agency nowadays to see that companies want .NET developers way over and above anything else and that Java roles are becoming few and far between such that they're no more prominent than even PHP roles nowadays. Java has been dislodged without a doubt, and Oracle's meandering and failure to get Lambdas into 7 mean it's going to struggle to take it's crown back.
You know, it's not that I dislike Java or any such thing, it was my preferred development environment for business apps up until very recently. But it's just become so lacklustre that there's just no point doing new development in it, so all that's left are legacy apps. I'd like to see Java improve and become a strong competitor to keep Microsoft on their toes but it's just not doing that anymore.
Seriously? I live in one of the few Midwest cities that's been doing okay during the recent economic blahs, and I am getting people constantly calling me for Oracle, Java, PHP, RoR, Perl, etc. I'm getting calls from national recruiters. Hell, I even get questions about Objective C, which I haven't programmed in years. The .NET and C# guys I know and network with are looking over their shoulders and asking me to pass anything on to them; apparently more than a little enterprise work is moving from their technologies.
And this is in traditional, older companies in a somewhat conservative city in the Midwest. Anecdote <> global truth, but it's something that's caught my attention.
No big deal?
So for touch-devices, you get a new way of doing things, locked down APIs and so on... surely nobody expected much else.
And for 'regular' Windows things carry on as before... well there was not a whole lot that needed changing IMO.
Serious developers can continue with .NET, App developers can do HTML5/JS, and we're all happy.
Just stop thinking of W8 as one platform and view it as 2, linked ones, and what's the big deal?
Re: W8 as one platform
"Just stop thinking of W8 as one platform and view it as 2, linked ones, and what's the big deal?"
That's certainly how it looks to me. Microsoft's next phone OS is called Metro and runs on ARM, but they've built a Metro-box into Windows, which runs on x86. Therefore, any apps written for Metro can also be run in the box if you flick the switch and compile them as x86 code.
Now why couldn't MS have said that two weeks ago?
RE: No big deal
Because then you can't copy and paste pre-rolled "I hate M$" arguments from www.billgatesisthedevil.org
As a C#/ASP.Net developer this all sounds like moves in the right direction to me.
I'm too am not convinced by Metro for my apps but I suspect that it will be essential for tablets. Allowing a choice seems reasonable to me.
Having the apis described by metadata is good as well - I very much doubt it will be possible to have an out of sync metadata file (strong naming??) so DLL hell will be much less likely.
It should also be a lot easier to call "COM" APIs from C# since you don't need to write so much of the interop code.
I don't see the problem here..
Note: I'm now solely trying to approach this from a developer pov; /not/ that of an end user or sysadmin. Within the last contexts I think the whole Metro environment stinks.
Seriously; this news is not as bad as being portrayed IMO. First the fears that .NET might be replaced turned out to be fictional, as anyone thinking about it could have assumed (maybe even predicted). Instead of replacing .NET they added to the basic functionality and extended upon it with their HTML5 adoption in Metro. Now you can't only use .NET but HTML5 as well.
Second; wasn't this a little bit foreseeable? I mean; only last week did MS announce that they'd be dropping plugin support for their Metro styled browser. Which on its own would automatically imply to be an increase of risk. But if you set something like that up within an environment which is restricted on its own then the risk factor will significantly drop again as well.
Its no secret that MS has some massive catching up to do when it comes to OS security. They've come a long way, sure, but there is still a lot of work.
And the whole "contract approach" also seems to address another issue; with the current RPC model its not possible to apply access control (separation on a per-application basis). Yet with such a contract model I could imagine that a client would need to setup a contract session with a server after which the server will determine if the client gets access to the required services.
That could benefit their new server environment as well. So I don't see the problem here to be honest.
Wow - how much further detached from reality can this article get.
If you want to write a metro app (in any language) then you have to hit the WinRT; if you are not doing a Metro app then you don't have to hit WinRT, you can do whaever you want as you would do now in Win7.
I think some here have confused what the metadata is and when/how it is created. Developers will only have metadata created form them if they are creating a WinRT library for others to consume.
That Microsoft is again (with .NET) going from some Microsoft technology of the week being "the wave of the future" to now being "some thing we might support for a while longer." I'm just going to say now: "I told you so", so when a bunch of people spend the time and effort to learn WinRT, or Metro, or whatever they decide to call it, and Microsoft scraps it in a few years for the *next* new thing.. well.. "I told you so."
Yes, that's great Henry. You keep telling them so, in the meantime those developers who are agile enough to move between technologies will keep earning the big bucks.
It doesn't really matter what you told anyone so, the fact is whether an intentional tactic or not, it works for Microsoft, it works for talented and flexible developers, and it works for companies exploiting these technologies whilst they're hot. You told them so yes, but they don't care, but it doesn't hurt them or anyone, it benefits them, if you haven't clued onto that then I feel sorry for you. Times change, sucks that you're living in the past and still probably think C++ is the right tool for every job or whatever, but that's okay you sit there with your lack of career progression using obsolete technology because that's okay, I mean, you told them so.
Apparently it's called progress. Same as how we generally don't use ASM much these days and even most penguin-fanciers have coped with upgrading to C++ from C!
"nd even most penguin-fanciers have coped with upgrading to C++ from C!"
What utter, utter fucking balls.
Re: utter balls
Because they haven't coped?
Because they haven't upgraded?
Because "upgrade" isn't the correct word?
No I think he's saying you have some serious balls for standing up to grey bearded obsolete C++ FOSS zealots, because they're the biggest trolls on the internet and if you dare to suggest that sometimes, just sometimes, developers need to update their skills, then you can expect these grey bearded trolls to come storming at you with their oh so fearsome downvote button.
I bet you're shitting bricks, but at least the other AC thinks you have balls.
View from the inside
... was just as scary as from the outside. I joined the WPF team when it looked like it was the Next Big Thing ... Learned that "products" that don't have paying customers behave according to their own rules, which are more often based on the VPs angling for relevance/continued employment than on the needs of users or even differentiation between competing products.
Silverlight was a horrible little parasite in DevDiv's colon, built on 3 things: copying other group's work (badly), bragging about how much quicker it could generate output, and stealing resources. Watching it's style spread to other MS groups depresses me.
.NET architecture is not suitable for online apps..