If you want the old UI, you're almost universally better sticking to the older OS, until such point that the overall business benefits of upgrading outweigh any training costs. I certainly wouldn't ever go down the route of "upgrading" and then try to fudge the old UI back with an almost-clone bit of third party software like Stardock's offering. It's fine as a one-off solution for those who really can't let go, but not really a business solution.

51 minutes ago, Bass wrote

*snip*

I am aware of the concept "statistically insignificant", but I assume my understanding is different than yours. I am not a pro-statistician by any means, so please free to explain how this study is statistically insignificant. Feel free to use to mathematical concepts in your argument. That would make it more enjoyable for me. I like Greek letters, they look very pretty in my font set.

740 companies. There are more than that in my local Yellow Pages, for a single city in Britain (not a particularly large city as it happens, in by no means the largest country in the world). Do you really need me to do the maths for you?

And, FWIW, I've spent most of my working life in the higher education sector, which has always been far more heavily skewed in favour of *nix and one of the breeding grounds of FOSS. I've not lived a life in some Microsoft funded cocoon, as you seem to imagine.

2 hours ago, blowdart wrote

*snip*

The restrictions put in place by the phone security model on CLR classes will still be there though. WP7 wasn't really the Compact Framework.

Well I was thinking more in terms of proper generational garbage collection etc, rather than having unlimited access to the framework, per se.

1 hour ago, Bass wrote

@AndyC:

I don't know where you get your 99% number from? Some kind of study or something you could link to please? if I used my own observations when working for various organisations, I would say something like 100% of all companies have software developers.

If you honestly think most companies employ software developers, have any interest in software development or indeed even the slightest desire in diverting resources into something that isn't a core competency of their business, you're massively deluded I'm afraid.

1 hour ago, Bass wrote

@figuerres:

"""

Of the 740 companies surveyed, 42 percent said adoption in the non-technical segments was the No. 1 trend driving open source in 2012.

"""

Hmmm... so it's not just technical segments. This is interesting to me, because I never even worked in a non-technical segment before. Good to know.

And how much of that adoption was outside of the "big name" projects like Apache or Linux, both of which would fall under the category of having substantial commercial backing from known names. Nobody has argued that people avoid FOSS, rather that there is an inclination to prefer "known" products from reliable names far more then some random project started by your average Joe.

Also interesting, "Lack of formal commercial vendor support" was not the biggest barrier to open source adoption. Rather, it was simply unfamiliarity with open source solutions.

Interesting stuff indeed. FOSS is more popular than some people realise here, I suppose.

More interesting

"Number of Survey Respondents in 2011: 455

Number in 2012: 740"

Are you aware of the concept "statistically insignificant"?

16 hours ago, Bass wrote

The whole tangent of "big companies vs Joes" is kind of ridiculous and nonsensical in a way.

No, that's actually the only thing that matters. Being FOSS is basically meaningless for 99% of companies out there that have no software developers nor the desire to employ them. For them, software backed by reliable "big name" companies is a much safer investment than software which doesn't have that sense of stability (whether justified or not).

15 hours ago, JohnQPublic wrote

*snip*
I mean publicly open and supported APIs that non-microsoft devs have access to.

The way SuperFetch have been explained tells me it might not be possible to write it from scratch by a using publicly documented api's.

A SuperFetch-like could trivially be implemented using a file system filter driver. I'd put money on that being how it actually is implemented.

42 minutes ago, fanbaby wrote

So today Microsoft added yet ANOTHER transpiler. Great. News at 9. You see, in this new world, the fact that it's Microsoft, or Google, or Apple or anyone, means nothing.

LOL, only in fanboy dreams. FOSS projects without substantial backing are high risk options and always will be. Nobody wants to bet heavily on something that disappears overnight because the kid responsible for it got a real job/bored/went to college etc.

2 hours ago, JohnQPublic wrote

This reminds me of Charles calling people for trolls just because they ie give negative feedback.

*sigh* if you're going to sign up for a new account pretending to be someone new to the community, it helps not to mention a comment from the end of an obscure thread pretty much only a handful of people would have read. </freeadvice>

The tools are not as complicated and specific as SuperFetch (afaik the api's needed to write a superfetch open source version is missing).

If the APIs were missing, how would SuperFetch work? It's entirely possible to write a replacement for it, although the phrase "reinventing the wheel" would seem to apply.

They use block based caching of all the requested data from the hard drive. So the access time would be sped up no matter what data the programs regularly used not just the launch speed.

As does SuperFetch, it's all about what it decides to pre-fetch that makes it apply to launch times rather than anything else.

I was testing ramdisk a few days ago and it got me thinking. The speed up was huge. Using a caching solution might be good both for performance and the longevity of the hard drive.

You're trading performance in one area (disk caching) for another (absolutely everything else that requires RAM). It might appear faster in isolated benchmarks or over short periods of time, but under real world usage ramdisk type approaches sacrifice far more performance than they gain.

Microsoft still make more profit than Google and across a much more diverse portfolio of products too. Buying their stock probably won't make you rich, but it's unlikely to go bust anytime soon either.

30 minutes ago, DeathBy​VisualStudio wrote

*snip*

web apps are "all the rage" with HTML5 and all.

Huh? have I slipped back in time to the mid 2000s again? Web apps were all the rage, those days are gone, have been ever since the introduction of apps on the iPhone/iPad.

13 minutes ago, DeathBy​VisualStudio wrote

The only thing confused here is you Andy.

• Stylus: acts like a mouse today, high precision -- show "x"
• Kinect: low precision -- don't show "x" (Pretty disingenuous of you to throw this in your list of "concerns")
• Mouse with touch: high precision & low precision -- show "x" if the bar is brought up with the mouse, don't show the "x" if the menu is brought up by touch.

You see, you're missing the subtleties. Let's say I'm holding a tablet in my left hand and using the stylus in my right. I swipe from the corner to bring up the switch list and want to swap to an app in the list near to where my left hand is resting. It's much, much easier to use my thumb to click than to contort your arms to do it with the stylus. Except now you've put these close buttons there and we're back to accidental closures. And that's assuming you're using a tablet-style direct-to-display stylus, as opposed to a separate desktop one where there is a visual disconnect - you're now forcing the user to employ a degree of accuracy otherwise unnecessary to switch tasks (the Taskbar doesn't do that, for example)

Similarly with the mouse with touch, the whole point is to allow quick gestures which can bring up system or app UI, but your hand is still on the mouse and you still might want to use that to actually point/select. Except now you've made the close function you wanted more accessible disappear, so the user either has to give up the touch gestures or go back to the right-click menu that is apparently too difficult. More exotic devices like Kinect only increase the number of UI combinations, none of which are necessarily going to be used in isolation any more than you'd use the mouse in isolation from the keyboard.

The W8 desktop taskbar already implements this differentiating between mouse, pen, and touch currently. When touch is being used it displays the "x" for all thumbnails. The only change required would be to avoid the latter when touch is in use -- you know to avoid accidental closures by Microsoft apologists.

And it just doesn't do it well. Trying to fudge touch support onto a UI designed wholly around the idea of being mouse driven is inevitably going to fail. That's kind of the whole reason why Windows 7 touch devices aren't ubiquitous already. It's why Steven Sinofsky said in the Building 8 blog all those months ago: "Going back to even the first public demonstrations of Windows 7, we worked hard on touch, but our approach to implementing touch as just an adjunct to existing Windows desktop software didn't work very well. Adding touch on top of UI paradigms designed for mouse and keyboard held the experience back."

And let's not forget that the W8 desktop taskbar can be oriented vertically on the left or right side of the screen...

I have absolutely no idea what point you're trying to make with that.

51 minutes ago, DCMonkey wrote

*snip*

There's also infinite screen width courtesy of Fitts' Law if you keep the mouse against the edge of the screen.

As for the rest, making close buttons only appear for the mouse would solve the fat finger problems from touch use.

But your mouse starts against the edge of the screen, so any unintended travel is naturally going to be away from the edge, so you can't really rely on Fitts to help.

I'm also not convinced that you having close buttons appear/disappear depending on what input device your using would work particularly well in practice either. Aside from being potentially confusing, it starts to introduce oddities with differing input devices (Should a stylus act more like a mouse or touch? What about Kinect? What about a mouse that supports Touch gestures?)

22 hours ago, DCMonkey wrote

*snip*

The Windows 8 App list requires you to put the mouse in the top left corner and then move it vertically along the left edge of the screen to activate. It would be nowhere near the close button of the thumbnails.

With a large display there is quite a bit of scope for mouse travel sideways if you're aiming near the bottom of the list. And it's much worse with touch because aiming is a lot less precise, particularly if you're stretching your finger to reach one of the more extreme ends of the list. Ironically the IE tabs suffer less here because you've pretty much got to take your hand away from it's natural position in order to click them.

PS: I noticed that Windows 8 App Store App Internet Explorer 10 has permanently displayed close buttons on its thumbnail shaped tabs. 

Yeah, those I the ones I've already got annoyed by hitting occasionally when use the trackpad on my laptop, because in that case you right-click somewhere and then make a (potentially) large mouse movement to hit the tab. It's probably not quite as bad if you've got a mouse plugged in, but trackpads have never been nearly as easy to be precise with as a mouse (despite Windows treating them identically).

12 hours ago, DeathBy​VisualStudio wrote

*snip*

You know they can't design a UI that protects idiots from every mistake they make.

I suppose you have that problem with the W7 taskbar thumbnails too. Do you run with scissors? Be careful!

No, but that's probably because the mouse pointer is naturally very close to the thumbnail by the time it appears (because it had to hover over the button to trigger it). As a result you're typically making a shorter, slower movement and are thus more likely to accurately hit the correct target. By contrast the IE tabs or the W8 app list potentially require a much longer range movement and thus accurately targeting quickly becomes more difficult. You may have heard of this before, it's called Fitts Law.

*snip*

You're also throwing out the notion (again) that desktop PCs will exist in this new world and if they do they won't have a mouse & keyboard. Devices like tablets and phones don't have the luxury of large screen sizes or mouse & keyboards so they need a simpler interface.

Am I? Or did I explicitly state:

5 days ago, AndyC wrote

*snip*

What you're missing is that if you were designing an OS from scratch today with absolutely no legacy cruft whatsoever, even if you went with a "desktop" style paradigm with overlapping windows etc, you still wouldn't design it in a way that requires users to "open" or "close" applications.

What you're ignoring is that just because you take an app-centric view or move the application lifecycle to one that is more system managed - it doesn't mean you have to give up a desktop environment. Nobody is (or at least nobody should) say that all future applications will exist in a Metro-like environment.

If you look at the last 15-20 years of OS development you'll see this is exactly the way everyone has been trying to go. It's precisely why the Apple Dock was created originally in a way that barely distinguished between running and non-running apps and why Apple at the time were often trying to explain the "with OS X you won't need to close apps" line (admittedly they someone pre-empted their OS being truly ready to take that approach. It's what things like Restart Manager and the OS X equivalent were meant to enable. Even your much loved Window 7 Taskbar is about blurring the distinction between launching and switching apps, albeit within the confines of what traditional Win32 apps could do.

The only way in which Metro represents a shift in thinking is that Microsoft have learnt the hard way that they simply can't introduce bits and pieces into the OS and expect apps to embrace them in the same way that Apple can. The amount of software out there today that supports Restart Manager, for example, is statistically insignificant - because the sheer weight of developers wanting legacy OS support steers them all away from using new features (no matter how many times the idea that apps can "light up" by using new functions on a new OS, it's just a bit too rare in reality). In contrast all the big OS X apps are first party, so new OS functionality gets embraced fast, which in turn pushes third party developers to keep up. The end result is taking a much bigger, more holistic approach to bringing Windows up to date and dragging developers along with it and focusing that effort on the sector of the developer market (that which is predominantly consumer focused and thus carries less back-compat baggage).

*snip*

Sounds like you're inferring that any app that isn't connectionless is written wrong. Another "you're holding it wrong" response. Very clever.

It's not "wrong", it's just dated. There are many good reasons that moving in favour of a RESTful approach is preferred these days, the fact that such designs work better in suspend/resume scenarios is by no means the biggest.

*snip*

Current PC's having problems resuming from sleep? Say it isn't so! Oh yeah it is...

Oooh look, the goalposts move again. What do driver and hardware issues that cause resume to fail have to do with the speed by which a working PC can resume?

The Atom processor in the ThinkPad make me a little nervous since we all know who well netbooks perform but I'll give it the benefit of the doubt because it's next-gen and dual core. So what are you willing to give here Andy?

Clover Trail is the Intel SoC design. It may use x86 instructions, but otherwise it's a lot closer to the ARM chips you'll find in iPads and Android tablets. SoC, aside from supporting newer power modes like "connected standby" are far easier to handle from a driver PoV, because there is obviously a lot less variation in the support hardware than in a traditional PC.

*snip*

I was there smart guy. That's how I got my tablet. Heard every word he said

Hearing != Listening.

*snip*

Andy has an interesting sense of reality; one where the mouse and keyboard don't exist.

Au contraire, I fully expect mouse and keyboard to be used for a very long time.

9 hours ago, Bas wrote

*snip*

Oh the terrible irony.

15 hours ago, DCMonkey wrote

*snip*

It doesn't seem to have caused much of a problem with Windows 7's taskbar thumbnails, which show a close button when you hover over the tile.

Try using those on a touch screen.

3 hours ago, DeathBy​VisualStudio wrote

*snip*

So you're going to give the Windows Store app IE guys a pass then huh? Nice.

I've already managed to accidentally close IE tabs instead of switching to them precisely because of this, it's a bit of UI I really don't like. I'd have gone for a more Semantic Zoom type approach, maybe arranging the pages like the old Quick Tabs functionality from IE8.

*snip*

Your working under the premise that an app centric world is the preferred. That premise is flawed. People want to get to their data as quick as they can and don't give a rat's arse if that's by opening the data from a menu from the shell or from within the application itself so long as it's the fastest. Of course you'll always prefer the apologist's position.

App-centric seems to be working rather well. It's been embraced by every smartphone, tablet etc ever since Apple proved it made life easier. Of course you think anyone who doesn't agree with you thinks there is something that needs apologising for.

*snip*

With what -- only 2000 apps in the store? Maybe? Are you sure you want to go there? Looks like Citrix has a release out. I bet that's going have some pain points just like remote desktop. Can't wait for the others...

I didn't say it had to be a store app. Could be anything.

Come to think of it I have an app that would suck as a Windows Store app because of this very issue. It's an app that displays real-time weights from multiple scale heads. It's a WPF app that uses WCF with WSDualHttpBinding for communications providing both the real-time weight values from the scales and a control interface for the scales.

Having an app that's not written in a way that's connectionless isn't the same thing as an app that can't be.

*snip*

It's sad to see you make up lame excuse after lame excuse for Microsoft. You really think a full blown Windows Pro tablet is going to be so much more optimized than the Build tablet that it will meet or exceed the iPad or an Android tablet on startup times? From sleep even? Dude, put down the crack pipe. It's not helping you.

I think Windows SoC devices (whether ARM or Intel) will be a lot more comparable to other SoC devices than traditional old-school PCs. I think the UEFI systems will startup faster than BIOS-based machines. And from sleep? Do you honestly think even current PC's have trouble resuming from sleep?

Do you honestly think the BUILD tablet was even nearly representative of the hardware that will be launched alongside Windows 8?

"W8 grade hardware". Sounds like you're calling Sinofsky a liar considering he said we'd have 450 million customer available to us as launch day -- you know those upgrading from "W7 grade hardware."

I think you should go listen to what Sinofsky actually said at BUILD. Or, you know, keep making stuff up that fits your argument better.

Hey I hear Apple is looking for a new PR guy for their mapping app. I think you'd be perfect for it. You can use me as a reference; you'll get nothing but high marks from me.

Nah, they need someone who lives in his own little world, ignores what most people want from computers and will endlessly shift arguments every time it becomes obvious what he says makes no sense.

I'll pop your reference in the post, then.

14 minutes ago, DeathBy​VisualStudio wrote

*snip*

If the concern is that the "x" may be easily (not confusedly) selected then they could hide the "x" until the mouse hovers over the tile. Oh but that would go against the great Sinofsky who once said "Write for touch, F the mouse & keyboard".  I think that's what he said anyway.

Yes, that is the concern. And the absolute most ridiculous way to try and prevent it is to have that button be hidden until you mouse over where it is, because then you're almost certainly going to have the situation where someone moves the pointer over what looks like the switch target and has already clicked the button before realising the magic close button has suddenly appeared beneath their cursor and they've just quit the application they wanted to use.

Of course you could alleviate that problem by having the user explicitly right click with the mouse to make the close option appear...

*snip*

Um no... It's providing a quick route to a file I had recently created.

In what sense is that not file centric? And it still ignores the way Jump Lists are implemented, which is fundamentally around providing launch parameters to apps.

*snip*

I'd think that any type of terminal app would fall into the same category as remote desktop. That would also go for any admin tool that monitors and reports health of web sites, server, etc. Oh here it comes...I can feel it: those kind of apps are holding it wrong.

So that's a definitive "No." to the question, can you name anything other than a Remote Desktop (or equivalent) application then?

And yes I'm ignoring admin tools that monitor sites, because most of the widely used ones in existence (such as the excellent Nagios), are already implemented as web pages and so clearly capable of operating in an entirely connectionless fashion.

*snip*

Also I'll just ignore the delay it takes for me to power up my W8 tablet from sleep and get to the app I want vs. doing the same on an Android or iPad too.

I'm impressed you have W8 grade hardware, given that none has been released yet.

I suppose the last possibility is that it's an agreement with existing WP7 supporting carriers to try and prop up availability of new WP7 compatible apps up to and beyond the launch of WP8 (after all, they are still selling those handsets right now). I think that's a little too short term to be a viable justification though.

1 hour ago, evildictait​or wrote

*snip*

I'm not sure Turing says that at all.

In fact, I think it is entirely possible to have a virtual memory system that never page faults.

For example: The non-paged pool. Also Win32k's shared session data.

I assume he was making the common mistake of confusing "virtual memory" with "swap file", which is so ubiquitous these days that it's rarely worth correcting. It's obviously possible to have virtual memory without page faults, Windows CE for example does it across the board (it doesn't even support swapping).