Devs getting stuck into Windows 10X on Surface Neo will have to tussle with UWP Microsoft has gone public on a new range of Surface hardware, the most intriguing being two foldable devices – one an Android phone and the other running a new variant of Windows, Windows 10X. The devices are prototypes, with general availability planned for late 2020. Windows 10X is not exclusive to Surface. Microsoft's own …
Twenty years in and Microsoft still hasn't been able to reign in that abomination of an excuse to put DRM into the OS. For that matter, it hasn't even included any tool to search for orphaned keys and list them for deletion. You still have to use 3rd-party tools to clean up your Registry efficiently.
For shame, Microsoft. For shame.
Calm down dear. Those third party tools are simply unnecessary. The ENTIRE fallout of a "bloated" registry is that up to 1MB of your disk will be consumed. It's a complete non-issue that only those with severe OCD are bothered by. Your PC won't run slower or faster regardless of what's in the registry, it's just a database of settings.
But I start to be afraid by the %appdata% bloat left by applications ported from Linux that looks utterly unable to clean up their mess when uninstalled - and which litter what should be "root" directories with their files - and "." won't hide them in Windows...
Registry cleaners are not only unnecessary but often extremely hazardous. [Citation]
The format would be perfect for an e-reader, although I agree, eInk is vital.
Amazon really missed a trick with a "double kindle" allowing you to e.g:
Read a double page spread
Refer to an index (or illustration) and the text at the same time
Compare 2 separate books
Lots more Use Cases spring to mind
Ah well, I can but dream
But that will presumably be a different set of applications to the ones that Windows on ARM will run. Microsoft needs to pick a strategy before it confuses its market into extinction.
Indeed, it's practically MS's modus operandi. Release their latest new technological hotness for their own self-serving reasons (#), promote it as the next great thing to the public while expecting developers to drop everything and get onboard with it then- when as usually happens- it doesn't deliver the desired results within short order, drop it and leave owners stranded and developers having wasted their time as MS move on to the next thing. The detritus from all this half-baked crap, however, will continue to clutter and obfuscate the Windows/MS ecosystem for years to come.
Typical examples include Silverlight, Zune, Windows RT, etc etc etc....
Or alternately they'll rebrand the same product- or successive versions- with a constantly-changing- and confusing- succession of names that non-experts would be forgiven for thinking were completely different things. (That example's over seven years old and referred to stuff that went back a decade before even that, proving that this behaviour isn't something that has only recently arisen in MS).
"Windows 10X" appears to be the latest in an endless and confusing mess of variants and offshoots of Windows that are either sort-of-compatible, half-baked compatible or not compatible at all with the "real" x86 versions of Windows. Windows CE, Windows Phone, Windows 10 Mobile (which Wikipedia reminds us isn't to be confused with Windows Mobile, which is, of course, something completely different), Windows RT, Windows Embedded (which has been rebranded Windows IoT, because of course it fucking has)...
Where was I? Oh yes, Windows 10X. This is the cut-down Windows 10 which is sort-of compatible with "proper" Windows. Which, of course, shouldn't be confused with the other half-baked cut-down version, Windows 10S. Obviously.
(#) e.g. A me-too of someone else's already-a-hit, or an attempt to coerce people down a path that suits them (e.g. Windows 8's tablet-style interface unsuited for desktop use because they thought if people were used to it they'd be more likely to buy MS-based tablets and phones).
The U in UWP is for Universal, and when presented it was meant to write applications able to run on different platforms and CPUs, including mobile ones. So it could run on ARM as well - but I think different groups in MS should talk to each other at least once a year and coordinate strategies....
Of course if an application is not written specifically for the double screen it should run as a normal applicaioin.
Anyway in the article is not clear what Win32 means in that context. Win32 may mean the standard, older Windows API used by both 32 and 64 bit applications (the API functions come in both flavours) - AFAIK there was never a "Win64" API named as such. Or it can refer to 32 bit versions of Windows.
If Windows 10X is a 64-bit OS running on a 64 bit Intel CPU, and not a 32 bit one, I can't see why it shoudn't run Win32 64 bit applications. Actual application can be already packaged using Desktop Bridge to be run "sandboxed" as UWP-like application (although no UWP-only API is used but by the installer). Emulating Intel CPU on ARM may be easier with 32 bit ones than 64.
Thanks - it could be they only added the 32 bit AP to this "core system"I and removed the 64 bit ones, so the "container" can only run 32 bit desktop applications - but it looks a strange move after they announced they are trying to close the gap between UWP and "old-style" desktop applications.
Not being able to run 64 bit applications could be a no-no for many business with in-house ones, and for many users as well. Forcing again developers to deliver UWP applications may fail again, if it's limited to a subset of devices which may not gain a large user base.
But it could be a result of the split-brain situation which have been running at Redmond for years.
"Win32" is the previous name for what is now called "Windows API". It is *both* a 32bit and 64bit api.
https://docs.microsoft.com/en-us/windows/win32/apiindex/windows-api-list
"Using the Windows API, you can develop applications that run successfully on all versions of Windows while taking advantage of the features and capabilities unique to each version. (Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)"
Now please correct the article's misleading claims.
There is no reason to believe that Windows containers on a 64bit Windows OS will only be able to run 32 bit Win32 (Windows API) applications. In fact, knowing how containers merely are a virtualization of the host OS, it would be *hard* and require extra effort to constrain the container to 32bit applications.
A 64bit Windows is able to run 64bit Win32(Windows API) applications *and* 32bit Win32(Windows API) applications.
There is no such thing as Win64. Some has used Win64 as a short for 64 bit Windows. This confusion er why MS has tried to "rename" the API from Win32 to Windows API. With limited success, it seems.
The U in UWP is for Universal, and when presented it was meant to write applications able to run on different platforms and CPUs, including mobile ones. So it could run on ARM as well
I've thought it would be amusing to take that "Universal" moniker and develop a UWP runtime to run them under Linux (I am going on the presumption none of the code in Wine would be usable for it).
"Windows 10X is primarily designed to run UWP (Universal Windows Platform) applications, but will run Win32 desktop applications in a container. UWP applications use WinUI visual components and are based on the Windows Runtime, first introduced in Windows 8."
I read this as UWP apps will require a runtime, while Win32 will run natively inside a container. Why then, does TFA repeatedly use the word native the other way around? Have I missed something important somewhere about the word native being used for a new purpose?
The Windows Runtime, despite the name, isn't really a "runtime" in the sense of something like the .net CLR or Java JVM, i.e., it's not a kind of VM running intermediate bytecode. It's just a set of APIs exposed by Windows that use newer patterns designed to be used by multiple languages, including C++ apps which are compiled to native machine code like any C++ program, whether they're using WinRT APIs or not.
I feel dirty but with the little keyboard on I quite like that. But I wouldn't care about the rest of the screen
TBH a bit like a mini version of the Asus Zen Duo. I nearly bough one of them but then found I could get a workstation with a proper keyboard for hundreds less. The engineer in me went for functional over shiny.
It appears that author conflates Win32 and 32 bit applications. Win32 the the *name of the API*, not a reference to the bitness of the machine*. The legacy API on Windows x64 is *still* referred to as Win32 - even though it is used by 64 bit applications on a 64 bit OS.
Certainly, Windows containers (yes, that is a thing) are 64bit on a 64bit OS, and will run both 64bit Win32 and 32bit Win32 applications.
Win64 - which author mentions - is not a thing.
Admittedly, Microsoft has not helped with their naming scheme. I suspect that the name obfuscation dept. of Microsoft takes up an entire building on their campus.
*) Ok, it was once, when MS needed to distinguish the new API in Windows 95 from the old 16bit API of Windows 3.x.
This is a relict from Sinofsky's "One strategy, One OS, One organization..." (OneDrive... renamed after Vista's Windows Live SkyDrive, Windows Live Folders, Windows Live Mail... such a buzzwords... One, Live, Neo... where is Morpheus btw?).
https://en.wikipedia.org/wiki/Steven_Sinofsky#Book
Which in turn was adaptation of "Ein Volk, ein Reich..." that is quote from much less funnier author.
Sinfosky was fan of Tolkien too, obviously ("One ring to rulle them all": x86, ARM; 32-bit, 64-bit; mobile, desktop...)
You know SS? MS CEO that turned SurfaceRT into the skateboard... At least, Megiddo will not have the opportunity to make the same with SurfaceNeo. Not because he is so much more serious guy then SS (look at his statements @yt about Win10S, where chatbox described himself as a "mobile warrior"), but just because of dimensions of SurfaceNeo. But you never know. He is mobile warrior, after all; don't underestimate him.
adding to previous commentards, I concur that API and codebase fragmentation is destructive to adoption. Secondly, times are toughening and new products, especially from M$ dont seem to be solving end users problems (if any). Few have cash for shiney shiney. Perhaps a two page layout might have uses but for now I prefer my reading using tree carcase. It has digital interface, requires no batteries and lasts decades if stored well.
Lastly, judging from the sludgy speed of Win10 x64 on my devices compared to *BSD or Linux, M$ would make a more salable product if it was much faster. It seems insane to need an i5 or better plus SSD to get nearly the same performance as a 486 with a 2 Gb spinning rust and windows 3.1
The litmus test having read the article,
Do I understand what MS device is running what MS OS and what MS OS can run what MS software, am I confused? Hell, yes.
Can I be bothered reading more to understand what each device does? Absolutely Not.
Seamless this ain't. It's an absolute abomination in terms of the marketing strategy.
I'll just come right out with it.
MS need to sack Chris Capossela.
" In this documentation, Microsoft in fact says Win32 and COM APIs "are part of the Universal Windows Platform", noting that they are implemented only "by some Windows 10 devices" so developers should check for their presence before calling them."
That must be the dumbest thing I've ever read. a "Universal" Windows Platform that is not in fact universal*? I mean, it'll let some executive at Microsoft brag about how many more UWP apps they have (maybe), but will make UWP completely pointless when you have so-called universal apps that aren't actually universal.
*I mean, it never was "universal" but at least was supposed to run on all editions of Windows 8 or 10.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
