So the new (soon to be released) Surface Pro X runs 64-bit (ARM64) apps, 32-bit (ARM32) apps, or 32-bit (x86) apps but will not run 64-bit (x64) apps. Although I’ve traditionally done my writing on a Mac, Apple is determined to kill of the MacBook Pro with design changes that leave us with a keyboard that is virtually unusable (but that is a whole 'nuther topic). I’m thinking of purchasing a Surface Pro X for mobility but can’t figure out whether Scrivener will run on it.
I’ve written directly to L&L to ask the question and so far no info has come back. Anyone here know whether Scrivener for Windows is 32-bit or 64-bit?
The theory is, yes the 32bit versions should work, though being through emulation the performance may be less than sparkling.
My concern would be ending up with an orphan if this attempt be MS to do an ARM based Surface ends as badly as the last.
The Surface Go even though it’s a pretty poor spec device might be a better bet, or save the pennies for a bottom of the line Surface Pro or used device. On the other hand, MacBook Air?
I have owned 2 of the butterfly keyboard MacBook Pro’s and find the keyboard great after a brief adjustment to the travel. With a 4 year warranty on the keyboards should any issues arrive it will be long after I replace my current one.
The RT experiment failed not because of the hardware, but because of the complete break with backwards Win32 compatibility combined with developers being understandably nervous about porting to the new dev environment given Microsoft’s past history. Not the case this time. Emulated x86 might use more power than a native ARM compile, and like you said, performance may suffer, but on the other hand, as the dev chain is built sooner or later Qt will support it, and then we can have a native Scrivener on Windows ARM build.
There are enough other manufacturers out there building Windows 10 on ARM that Microsoft isn’t trying to go it alone on that front, and even if the Surface model doesn’t go well, this won’t be the end of that platform.
Call me super cautious but I have memories of other platforms that enjoyed widespread manufacturer support and were going to be the ‘next thing’ and crashed and burned (netbooks anyone?)
I hope you are right as it would bring in a whole super battery life option,
Given Apple’s amazing performance results with their version of ARM processors I fully expect ARM powered Mac notebooks in the next year or two. Intel could be seeing whole market segments disappearing.
There I don’t think so. If the market was really demanding battery life that is far extended beyond what we have now, I think we’d see it. We have the sweet spot right now between performance and usability, and they keep adding transistors to the chips to eat up the power savings they get from improved processes. Until there’s some fundamental advance in physics that can get engineered out to be cost-effective, I think we’re seeing the plateau. Call it the flip side of Moore’s Law.
I think Apple has been learning all sorts of lessons about their supply chain, and I will be very surprised if they (in the long term) don’t end up in control of all their own silicon. That’s not to say that Intel isn’t going to see whole market segments go by the wayside, but I personally think that has less to do with power consumption and more to do with their sloppy engineering habits catching up with them. AMD got their act together at just the right time to capitalize on all the chip-level security issues; I have friends and co-workers throughout IT who are refusing to purchase Intel for servers for the next couple of purchasing rounds. I think that’s part of the other reason why Windows on ARM is here to stay – there are plenty of places where people put up servers that don’t need the same raw CPU horsepower, especially if they have storage and graphics processors to offload specialize workloads to. Between some of the advances in Linux and Windows on ARM, I think we’re going to see a whole new generation of lightweight servers. Combine that with technologies like Docker, etc., and it could be cheap to build clusters of these to run a handful of containers with enough capacity to rapidly move them around rather than the full-on heavy duty virtualization clusters today.
