What do you think about the CShell?

[AltanJace19]

Well CShell is just leaked as a build and it looks pretty stable. How will this take Windows Mobile to the next level?:grin:

I've been reading so many stuff about CShell and how it'll become the future of Windows on mobile devices. Will it not really run on current generation WM10 devices? I hate the idea of having my 950XL unsupported only after ~2 years of buying it *sighs*

 

[JasonH81]

Landscape mode, buff said.

 

[Drael646464]

I've been reading so many stuff about CShell and how it'll become the future of Windows on mobile devices. Will it not really run on current generation WM10 devices? I hate the idea of having my 950XL unsupported only after ~2 years of buying it *sighs*

No one know whether it will be or not. No one knows how far cshell is even off. Personally I don't see why cshell wouldn't come to the latest Lumia devices, it is after all only a UI, and its clearly being written in 32 bit rather than 64 bit (otherwise it wouldn't run on the x3), but again not knowing how far is it off, or how far along the project is, nothing is certain.

We are due "enterprise" features sometime soon, and we'll get updates via app updates like timeline and skills, via Cortana, and files on demand via one drive no doubt. So that's not exactly unsupported.

 

[surya babu]

does it works on 640 xl ??????

 

[Panos Athanasiou]

Well technically MS did it first https://www.youtube.com/watch?v=PwZl0xYemF0

 

[LightenSkies]

As nice as this looks and im up for the new feature cshell if when if ever it comes to Windows Mobile. Though im not sure about the new Action center. ANd once more... Why must it be just black? On Desktop you can make action center look like the taskbar... Come on Microsoft get with the program. :S

 

[Wevenhuis]

I think Cshell was supposed to be windows 10 from day 1 of launch of windows 10. It was microsofts vision of a single common windows experience across devices philosophy. One familiar experience and sharing a single onecore windows across all devices.

It's a pity it is now only reserved for pc and tablet devices and won't be part of the current windows phone and mobile legacy. I think this technology could have be released far earlier and more itteratively. It is released 4 years too late.

I would really see it as a service and restablishing brand trust if they can support cshell as well for current and recent unsupported devices with this upgrade, much like what they did with windows phone 7.8.

I generally like Cshell, but I'm suprised that the UI is still somewhat different from the tablet and pc builds. Why go to so much effort to maintain the current mobile layout? I think it is less practical, and is not consequential with mcirosoft's philosophy of a common windows 10 experience across devices.

If Cshell for mobile is going to be the future UI, then why not go all the way with the UI. So ditch the current layout of the action center as a slider from the top, the applist from the right edge and omit functionatlity with no swipe from left edge features. Just make the experience similar as pc on a mobile screen and adopt the same UI elements. This means action center from the right edge, access the app list from the left edge and swipe apps down from the top edge to close them. With phones getting larger this layout makes more sense than having the action center from the top edge. Also having the quick action buttons at the bottom of the action center, instead of top, means it is end of days for quick onehanded peaking to shut of a radio, you now have to open the whole action center to do a quick action, very impractiacal in real world use. Accessing quick action buttons by simply sliding the action center from the side is a much more logical and practical onehanded action. It also won't potential conflict with the vertical scrolling of the startscreen.

 

[trmnrs]

Originally posted by CraigCole
My big question is why they didn't just do this from the get-go. If you're going to have one OS running on an array of form factors shouldn't the UI scale accordingly? I mean, duh.

......because they couldn't?

Windows wasn't at a state where it could be scalable to different form factors at its initial release. I'm sure if they could have done this earlier they definitely would have. There was a lot of work put into getting Windows ready for a shift like this, and considering it isn't even ready yet, there's still a lot more work to be done.

 

[ahumeniy]

I really hope they bring it to Android too since there won't windows mobile devices anymore. I just got a second device to test waters, but I'm already missing the tiles...

And no. The launchers mimicking Windows Phone won't cut it.

 

[Drael646464]

I really hope they bring it to Android too since there won't windows mobile devices anymore. I just got a second device to test waters, but I'm already missing the tiles...

And no. The launchers mimicking Windows Phone won't cut it.

Of course there will be windows mobile devices.

 

[Chancery]

I hope. They​ would rollout cshell support for lumia phones ASAP.

 

[a5cent]

Why is it written in 32 bit then, when new chipsets are all 64 bit?

CShell is not "written in 32 bits". Neither is it "written in 64 bits". It's just written. MS then presses a button to compile their source code. Based on a compiler setting, the compiler produces either 32 or 64 bit binary executables. MS can get either from the exact same source code with practically zero extra effort.

For non-system level software it's even less important than that. For example, anything written for the UWP platform using a .NET language is automatically both 32- and 64 bit, as bitedness is determined either at install- or at runtime.

You're placing far too much importance in this issue. Even when the difference in bitedness is explicit, binaries can be generated for either CPU architecture at the press of a button, and the average consumer will never be able to tell a difference either way.

In summary, whether the device being used to demonstrate CShell integrates a 32 bit or a 64 bit CPU is entirely meaningless.

 

[a5cent]

I've been reading so many stuff about CShell and how it'll become the future of Windows on mobile devices. Will it not really run on current generation WM10 devices? I hate the idea of having my 950XL unsupported only after ~2 years of buying it *sighs*

Further up in this thread I predicted that all current devices running W10M (like the 950XL) would continue to be serviced from the future2 branch, which generally serves as a maintenance branch, meaning the devices serviced from it will not receive any big feature updates, certainly nothing like CShell.

Four days later WMPU published an article confirming my prediction.

Still, Drael646464 is right. Nobody knows. Possibly not even MS. Even if MS fully intends to never update the 950XL now, there is no technical reason CShell couldn't run on the 950/XL, so MS can potentially still change their mind. I just wouldn't get my hopes up if I were you. That's the main message here. At the moment all indicators point towards it not happening.

 

[Drael646464]

CShell is not "written in 32 bits". Neither is it "written in 64 bits". It's just written. MS then presses a button to compile their source code. Based on a compiler setting, the compiler produces either 32 or 64 bit binary executables. MS can get either from the exact same source code with practically zero extra effort.

For non-system level software it's even less important than that. For example, anything written for the UWP platform using a .NET language is automatically both 32- and 64 bit, as bitedness is determined either at install- or at runtime.

You're placing far too much importance in this issue. Even when the difference in bitedness is explicit, binaries can be generated for either CPU architecture at the press of a button, and the average consumer will never be able to tell a difference either way.

In summary, whether the device being used to demonstrate CShell integrates a 32 bit or a 64 bit CPU is entirely meaningless.

Typically there are issues in .NET, unless the code is written platform agnostic (ie designed to be able to run on both). There are things like how floating point, and pointers are handled.

Why write platform agnostic and compile it (and clearly test it) on a 32 bit machine?

There are only 64 bit chips now, they have a 64 bit win10m, and they surely have reference hardware for 64 bit win10m otherwise they couldn't have a 64 bit win10m.

If then intention was to completely not-support 32 bit, I can't see any motive to even compile for it. Why do that at all? And why write it platform agnostic?

I don't agree that is 'entirely meaningless', as you say. At minimum it suggests that 32 bit is a possibility that they won't rule out. But more likely IMO, if they are using something like the x3 as reference hardware, they do actually plan to release it, on that reference hardware, or something like it.

You don't test and engineer on something you have no intention of releasing your product on. That doesn't make sense, you would just need to then re-test, and re-engineer for the actual release hardware.

 

[tale 85]

Well CShell is just leaked as a build and it looks pretty stable. How will this take Windows Mobile to the next level?:grin:

The next level. We've all got thoughts or hopes about "what's around the next curve" for Windows Mobile. A lot are wondering when/if Microsoft will rattle the world with a next generation device that makes Apple and Android obsolete. Personally I'm not holding my breath.

Recently we got to see CShell running Windows 10 on a mobile device. Not W10M, but Windows 10. As the story goes it will finally be one "Windows" easily running on any device size. So where does that leave Windows 10 Mobile? Surface?

Let's assume the Surface Group brings out a "Surface Phone", or more likely a mobile device to join the Surface family of devices. What exactly will it be in the market? My feeling is that it will be just that. Another device, not a competitor in the Smartphone market. It will have cellular capability, extremely mobile but thought of as small Surface, another tool. Just as we really don't look at the Elite x3 in the same way we look at most smartphones, it's more personal computer than smartphone. So the "Surface Phone" will just be another addition to the line of personal computing devices. Running CShell just like everything else.

 

[ravensec]

I can see new hardware being required for the "new" Windows phone thing. Lumia is done. Time to move on.

 

[mattiasnyc]

Microsoft has to confirm their commitment to their Mobile OS first, since several news discussed that Windows Mobile won't move to Redstone 3, which includes CShell.

How many times do they have to confirm their commitment though? How many times does a Microsoft representative have to say it? It's been said numerous times.

 

[prateek sadhana]

I like CShell.. B it seems very nice and brings home the point of universal windows. I would love to have a ms phone with CShell.. Whenever that phone releases.

 

[a5cent]

There are only 64 bit chips now, they have a 64 bit win10m, and they surely have reference hardware for 64 bit win10m otherwise they couldn't have a 64 bit win10m.

If then intention was to completely not-support 32 bit, I can't see any motive to even compile for it. Why do that at all? And why write it platform agnostic?

I don't agree that is 'entirely meaningless', as you say. At minimum it suggests that 32 bit is a possibility

If you're thinking that 32 bit builds of the Windows OS only make sense for existing smartphones running W10M (that's what it sounds like), then that would be incorrect. The entire W10 OS is available in both 32 and 64 bit "flavors" and must continue to be available in both. For example, many Atom laptops can only run 32 bit versions of Windows, so a 32 bit flavor must exist either way!

So yes, it's completely meaningless. It's always been clear (or should have been) that CShell must exist in both 32 and 64 bit "flavors", because the W10 OS CShell is being shipped with must also be available in both "flavors".

Typically there are issues in .NET, unless the code is written platform agnostic (ie designed to be able to run on both). There are things like how floating point, and pointers are handled.

Source?

I've consulted on literally hundreds of projects for both platform agnostic (which almost all .NET applications are) and platform specific projects (usually C++). I've neither seen myself, nor heard from anyone else, of issues related to the compiler targeting source code towards 32 or 64 bit systems. It's always behaved exactly as expected.

The Windows OS team works almost exclusively with C/C++. Transparently building 32 and 64 bit flavors of the Windows OS from the same source code is something they have been doing for over two decades now. The idea that CShell (a UI component that is as far removed from the low-level internals of the OS as anything can possibly be) is going to cause any issues related to bitedness sounds crazy to me.

Why write platform agnostic and compile it (and clearly test it) on a 32 bit machine?

Why write in a platform agnostic way? Ehm... because MS must. Almost the entire OS is written in a platform agnostic way and CShell is part of the OS (almost all chipset and CPU differences are encapsulated in the drivers). Besides, at this point it's actually easier to write in a platform agnostic way, as all the guidelines MS developers must follow basically force them to.

So why not compile it on a 32 bit machine? That would be the far better question. There is no difference for the CShell team either way. Whatever they write must be transparently translatable by the compiler to both 32 and 64 bit "flavors". The people working on the desktop composition of CShell will likely build 64 bit versions and test on their W10 developer machines, while the people working on the CShell composition for smaller devices will likely build 32 bit versions and test on something with a small screen, like the x3.

In fact, if anybody on the CShell team is caught developing code that specifically targets the x3 or ANY OTHER hardware, they'd likely get into a lot of trouble (if not fired). Sprinkling hardware related issues into the UI layer would quickly become a maintenance nightmare. Any developer worth their salt knows that. CShell must be hardware agnostic! Bitedness is part of that.

Whether MS ends up testing CShell on the x3, the 950/XL, or some other continuum enabled device is completely irrelevant. If that were at any point not true, then that would only point towards the team having unearthed a bug that must be fixed somewhere at a lower level in the OS' software stack, for example in a driver. Testing this on a more mature platform, like the x3 (rather than on reference hardware that is still in development), is a good way of avoiding that sort of thing.

Anyway, how many other devices exist that are:

• mostly stable
• support continuum
• not subject to NDA and can be shown to the public
• allow MS to test CShell on a small screen

I can't think of many devices that fit that description. Since bitedness really doesn't matter, and literally isn't allowed to, it makes perfect sense to use the x3 for that purpose. That just doesn't imply that MS is planning to release CShell for the x3. It only means that MS intends for CShell to also run on small screen's. That's all it means.

 

[Drael646464]

If you're thinking that 32 bit builds of the Windows OS only make sense for existing smartphones running W10M (that's what it sounds like), then that would be incorrect. The entire W10 OS is available in both 32 and 64 bit "flavors" and must continue to be available in both. For example, many Atom laptops can only run 32 bit versions of Windows, so a 32 bit flavor must exist either way!

So yes, it's completely meaningless. It's always been clear (or should have been) that CShell must exist in both 32 and 64 bit "flavors", because the W10 OS CShell is being shipped with must also be available in both "flavors".

Qualcomm only make 64bit chips now.

Source?

I've consulted on literally hundreds of projects for both platform agnostic (which almost all .NET applications are) and platform specific projects (usually C++). I've neither seen myself, nor heard from anyone else, of issues related to the compiler targeting source code towards 32 or 64 bit systems. It's always behaved exactly as expected.

https://msdn.microsoft.com/en-us/library/ms973190.aspx

https://msdn.microsoft.com/en-us/library/windows/desktop/ee418798(v=vs.85).aspx

Why write in a platform agnostic way? Ehm... because MS must. Almost the entire OS is written in a platform agnostic way and CShell is part of the OS (almost all chipset and CPU differences are encapsulated in the drivers). Besides, at this point it's actually easier to write in a platform agnostic way, as all the guidelines MS developers must follow basically force them to.

Well actually that's a fair point. Cshell on win10m is the same cshell that will be used in other parts of the platform, even if its coming first.

So why not compile it on a 32 bit machine? That would be the far better question. There is no difference for the CShell team either way. Whatever they write must be transparently translatable by the compiler to both 32 and 64 bit "flavors". The people working on the desktop composition of CShell will likely build 64 bit versions and test on their W10 developer machines, while the people working on the CShell composition for smaller devices will likely build 32 bit versions and test on something with a small screen, like the x3.

Perhaps I should rephrase all this in view of your fair point above, about cshell being for the whole platform:

It appears the x3 was used for reference hardware (that cshell build doesn't run on the 4s, or any of the current lumias). Why use something for reference hardware that is not intended as a rollout target? Wouldn't a rollout target make more sense as reference hardware?

In fact, if anybody on the CShell team is caught developing code that specifically targets the x3 or ANY OTHER hardware, they'd likely get into a lot of trouble (if not fired). Sprinkling hardware related issues into the UI layer would quickly become a maintenance nightmare. Any developer worth their salt knows that. CShell must be hardware agnostic! Bitedness is part of that.

Well in the state we saw it, it isn't, it doesn't run on the Lumia 950/xl. So it isn't yet platform agnostic.

Whether MS ends up testing CShell on the x3, the 950/XL, or some other continuum enabled device is completely irrelevant.

I don't feel like you've made reference hardware selection irrelevant. People do IMO test on hardware that they want the software to be capable of running without bugs. If they didn't want any current phone to be able to do this, there wouldn't be much point in testing it there IMO.

If that were at any point not true, then that would only point towards the team having unearthed a bug that must be fixed somewhere at a lower level in the OS' software stack, for example in a driver. Testing this on a more mature platform, like the x3 (rather than on reference hardware that is still in development), is a good way of avoiding that sort of thing.

If that's true, they haven't fixed it yet, because it doesn't run on all current hardware.

Anyway, how many other devices exist that are:

• mostly stable
• support continuum
• not subject to NDA and can be shown to the public
• allow MS to test CShell on a small screen

There's 3 or 4 in total. 5 actually I think, although I wouldn't call 4s as stable.

I can't think of many devices that fit that description. Since bitedness really doesn't matter, and literally isn't allowed to, it makes perfect sense to use the x3 for that purpose. That just doesn't imply that MS is planning to release CShell for the x3. It only means that MS intends for CShell to also run on small screen's. That's all it means.

They have other options for that. HP's proto x3 refresh, and their own proto they used for making win10m 64 bit. They don't just want to release it for small screens, according to leaks, that's where its coming first. Ie, that's the domain they want to work first.

I think probably we should just agree to disagree. It doesn't appear like we are going anywhere much with this discussion. Hope you have a nice day