Windows 10 Snapdragon Longtime Batt


#1

Microsoft plans windows10 notebooks with up to 29 h


#2

I’m very interested to see how windows on Arm pans out, I’m quietly confident that it’ll be a massive success. TBH its Microsoft’s last chance to get ‘mobile’ right.

taken together with Andromeda OS and c-shell, the future of windows is looking promising, but then again this is Microsoft we’re talking about, so I’m sure they’ll find a way to mess it all up.

I’d be very interested in a Windows On ARM product from Eve. Maybe a 12inch detachable or convertible.


#3

maybe if the screen is switched off for most of the time… :smirk:
(there isn’t too much difference between the CPU used and the ones in the V at configurable TDP-down in terms of efficiency… plus emulation for x86 apps will take it’s toll)


#4

Apparently some testers reported a bug that the battery charge wasn’t displayed correctly until they found out that it isn’t a bug, but just has insanely long battery life. Could be some marketing story though :sweat_smile:


#5

Omg, that is ridiculous… Ridiculously awesome!

I’m no techy, but I wonder why they haven’t tried this until now.

Last time I checked phones don’t have fans either, so these type of laptops could be a major competitor to V if they do touchscreen as well


#6

Sponsored content

I really want this to be true, but I’m feeling sceptical… The fact that the article was sponsored is one thing, it happens all the time. But why isn’t every gadget site having articles about this? This is big news! :confused:


#7

Sure.
They stated an incredible battery life. Reusing spent energy may be :crazy_face:


#8

The big question is how big is the battery. It’s good if can use your laptop for 29 hours on a single charge but if you need a forklift to transport it, it’s not to fun.


#9

I think we can almost guarantee that Windows on an ARM chip will be restricted to some version of Windows 10 S, which can only run apps from the Windows Store (no installing 3rd party programs).


#10

Not true. Microsoft themselves demoed Windows 10 on ARM running the full version on photoshop and doing some stuff like adding filters to show that it works properly.


#11

I think a Snapdragon 835 is plenty powerful to run Windows 10 with low-to-medium resource demanding tasks. Plus the fact that Microsoft already attempted a stripped-down version of windows with Windows RT on their first gen Surface (I even bought one of those) and it did not work out. So I think it’s safe to assume that they will not try it again.


#12

Lol, tell that to Windows 10 S.


#13

Because the performance sucks.You have to emulate everything.


#14

I’m no expert by any means but if you have to ‘emulate’ or convert the code only on first run. And then cache the converted instructions or whatever does that mean that on second run it would be a lot faster (because of no real time conversion)?


#15

Well, it’s not as simple as that. There are major architectural differences between ARM and x86 that make it much harder to convert code than to emulate it. You could theoretically convert x86 ma ine code to ARM machine code, but that would require a very clever algorithm that nobody has written, and it would still be no match for natively compiled code. You see, it’s not as simple as translating from one language to another. You don’t just translate sentences, you translate every possible combination in all possible conditions (user pressed key, system time is different, received packet from the internet and so on) that affect the program’s behaviour. Furthermore, sometimes there isn’t a word to say what you want in the language you’re translating to. And since x86 and ARM are so different, this happens very often. So you have to explain it in different words.


#16

Not everything. (most of) Windows itself has been ported to run natively on ARM. Many of API calls will be executed natively, without any sort of emulation occurring at all. Obviously you hit a pretty hard wall once you get into apps that specifically leverage the hardware (either through x86 SIMD sets or DirectX). Even there, though, Attiq is also correct that there will be a heavy level of caching involved in the translations.

I mean, probably.
I think perspective is needed here. We’re talking about Windows running on a lowly Snapdragon, not the kind of gigantic monster that Apple have been putting into their iPads recently. It’s targeting devices that used to use Atom. As such, relatively poor performance in professional apps is irrelevant. I do wonder about the performance of media players and browsers - I’m guessing Microsoft will want users of such devices to stick to Edge and that default Windows 10 media player. Which is hilarious. But I assume there will be no performance penalty in doing that at least.

As I mentioned in the other thread, legacy is a curse. The Win32 API is anathema for today’s needs. We need apps that are:
Sandboxed
Easy to deploy and administer from a Domain
Unable to access certain hardware (such as webcams or memory sticks) or system information without explicit user (or admin) authorisation
Barred from direct access to the file system or memory
Able to be automatically updated from a trusted source
Hibernated on minimise, with background multitasking limited to explicit worker threads (which might in turn expect to be throttled or controlled in some way by the OS - like having its network requests batched with those of other apps, for example)

I can see Microsoft pushing an environment where Win32 is emulated regardless of your processor at some point. Whether it’ll be successful is another question. Apple successfully managed a transition, but they were a much smaller player with almost no corporate presence.


#17

Maybe you do. I don’t. I need development tools, gaming platforms, and other things that are deeply integrated with the OS and with each other. That’s what makes Windows really powerful, much bettr than any other OS out there. Except Linux, but that’s a whole different can of worms. If they decide to do what you say, I and most power users will just stay on whatever is the latest version of Windows that functions the proper way. That means another Windows XP, which they worked so hard to solve.


#18

There needs to be a way to create those experiences without just leaving the door wide open and saying to developers, “Behave yourselves”.
I think the past thirty years of Windows has shown that, for the majority of people, that approach hasn’t worked out. COM is terrible imo and sloppy programming results in both insecurity and instability.

I understand that the APIs that allow cross-application integration probably aren’t great as of yet. I’ll be honest - I have no idea. But web apps have a good model of this. You can do some pretty cool stuff with Microsoft Flow or Zapier or whatever, without compromising the security of the services you’re linking up. More importantly, the people who build these web services build it from the mindset of, “We need to make an API to expose most of our functionality to external services”. Modern app development should be handled the same way. Even beyond the scenarios you mention, it would allow easier scripting and automation, which is a pain point in Windows already when compared to Linux AND MacOS. Win32 being so GUI-centric was in itself a mistake.


#19

something something intel not allowing x86 on arm something…


#20

Nope. For the majority of people it worked out very well, and as a result you see Windows as the dominating OS. There is a reason it’s preferred over Android, for example. This approach results in much wider choice of programming languages and tools, better interaction between apps, and the ability to “think outside the box” for developers and create something new. Basically your imagination is the limit. With sandboxed approach, the limits are defined by the sandboxed environment.
Just look at some multitouch applications like GestureSign, TabletPro… Sure, UWP is slowly becoming capable of these things, but look: what did they originate from? It all started with some ambitious developer who did something that Microsoft hadn’t thought about. I can’t predict what will be the next “innovative” thing that someone will want to program, but I can tell you for sure it won’t be supported by UWP because Microsoft hasn’t thought about it. Nobody has thought about it.

And what if the developer doesn’t want to expose that functionality? See, that’s how great things are born. Someone uses something in a way it wasn’t intended. But that doesn’t mean a “bad” way, just an unintended way.

No, it was the best decision ever. That way developers had it clear: the user DOES NOT LIKE command prompt. So develop your apps with a proper UI. You have good tools for that, and those tools are not linked to command line in order not to encourage you to go the wrong way. For power users, go ahead and add keyboard shortcuts. If you really want to use command line, the tools are still there. But they’re detached from the UI and that’s PERFECT because that means the FULL program functionality is encouraged to be exposed in UI.
If you want a command line-centric OS, you can choose Linux. But the majority chooses Windows, because they want a GUI-centric OS.
I know, it’s best to have both, but let’s face it: developers are lazy, and the most lazy thing to do is use command line for their apps. So being UI-centric is a good thing, it motivates them.