Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Thursday May 11 2017, @12:36PM   Printer-friendly
from the what-security-issue? dept.

Microsoft's only choice to move forward is to throw the Win32 baby out with the bathwater. And that brings us to the introduction of Windows 10 S.

Windows 10 S is just like the Windows 10 you use now, but the main difference is it can only run apps that have been whitelisted to run in the Windows Store. That means, by and large, existing Win32-based stuff cannot run in Windows 10 S for security reasons.

To bridge the app gap, Microsoft is allowing certain kinds of desktop apps to be "packaged" for use in the Windows Store through a tooling process known as Desktop Bridge or Project Centennial.

The good news is that with Project Centennial, many Desktop Win32 apps can be re-purposed and packaged to take advantage of Windows 10's improved security. However, there are apps that will inevitably be left behind because they violate the sandboxing rules that are needed to make the technology work in a secure fashion.

"A casualty of those sandboxing rules is Google's Chrome browser. For security reasons, Microsoft is not permitting desktop browsers to be ported to the Store."


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Thursday May 11 2017, @03:50PM (3 children)

    by Anonymous Coward on Thursday May 11 2017, @03:50PM (#508137)

    Do you even know what that is? No, you don't. It is a translation layer that rips apart x86 binaries and builds something that Alpha can sort of run. How well do you think that worked? Well enough for some big programs, but you could not expect it to work 100% of the time. It might choke on some weird piece of code, or the application might make some high level assumption abut an x86 environment that wasn't true here. Device drivers? Nope. Not to mention that from day one the Alpha was a pure 64-bit CPU, and translating crappy 32-bit code like this would not magically create code that took full advantage of the Alpha architecture. FX-32 was a band-aid at best.

  • (Score: 2) by tangomargarine on Thursday May 11 2017, @03:55PM (2 children)

    by tangomargarine (667) on Thursday May 11 2017, @03:55PM (#508142)

    Expecting a program compiled for one architecture to work on a completely different one is one of those things that laypeople may expect but is insane.

    I thought we had a lot of programmers here on SN? We're not seriously surprised about this, right?

    --
    "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
    • (Score: 0) by Anonymous Coward on Thursday May 11 2017, @04:37PM (1 child)

      by Anonymous Coward on Thursday May 11 2017, @04:37PM (#508161)

      Tell that to Linus Torvalds. The DEC stuff worked well enough that Transmeta thought they could succeed. As far as I know the cpus worked, they just didn't perform well enough.

      • (Score: 2) by tangomargarine on Thursday May 11 2017, @04:51PM

        by tangomargarine (667) on Thursday May 11 2017, @04:51PM (#508179)

        Sometimes chips have the ability to emulate other architectures built into their instruction sets (or at higher levels) but a native compilation of the program will always perform better.

        --
        "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"