Salakhetdinov Shamil
mcp2004 at mail.ru
Mon Dec 17 00:35:40 CST 2012
Hi Hans -- Thank you for the link. AFAIU the only issue is that WOA (Windows On ARM AKA WindowsRT for ARM) doesn't allow FireFox (or other third party) developers (who BTW were the only ones to raise that issue?) to compile JavaScript on run-time into an executable machine code and to run that machine code from within their own browser application. As several commentators to the article, which link you have posted, proposed FireFox developers can use MS Trident engine - http://en.wikipedia.org/wiki/Trident_(layout_engine ). If that is true then I do no see the real reasons for FireFox developers to complain. Especially taking into account the following reasoning coming from Steven Sinofsky (that time - FEB 2012 - Windows 8/Windows RT design "main person"): http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-processor-architecture.aspx <<<<<<<<<< Our focus on delivering a new level of security for consumers using WOA is paramount. In one public event, we were asked if we would “make it easy for existing viruses and malware to run.” Now you can see the answer is decidedly, “no.” In fact, WOA only supports running code that has been distributed through Windows Update along with the full spectrum of Windows Store applications. As we all know, security is an industry-wide, multi-dimensional challenge and no system or platform can make broad claims without considering many factors. >>>>>>>>>> <<<<<<<< Previously we have detailed that WOA will not support any type of virtualization or emulation approach, and will not enable existing x86/64 applications to be ported or run. Supporting various forms of emulation runs counter to the goal of delivering a product that takes a modern approach to system reliability and predictability—by definition, existing code has not been optimized for the platform the way WOA has. Virtualized or emulated software will consume system resources, including battery life and CPU, at unacceptable levels. Emulation and virtualization of existing x86/64 software also require the traditional PC environment of mouse and keyboard, which is not a good assumption for WOA PCs. If we enabled the broad porting of existing code we would fail to deliver on our commitment to longer battery life, predictable performance, and especially a reliable experience over time. The conventions used by today’s Windows apps do not necessarily provide this, whether it is background processes, polling loops, timers, system hooks, startup programs, registry changes, kernel mode code, admin rights, unsigned drivers, add-ins, or a host of other common techniques. By avoiding these constructs, WOA can deliver on a new level of customer satisfaction: your WOA PC will continue to perform well over time as apps are isolated from the system and each other, and you will remain in control of what additional software is running on your behalf, all while letting the capabilities of diverse hardware shine through. >>>>>>>>> <<<<<<<<< Of course, we recognize that many developers at Microsoft and elsewhere rely on existing programming techniques, and that a transition to WOA will require an investment. Developing apps based on WinRT addresses these and many other challenges from the start—WinRT is designed to provide the full expressive power required for modern software while avoiding the traps and pitfalls that can potentially reduce the overall experience for consumers and does so with a deep commitment to tools, languages, and developer support. >>>>>>>>> Thank you. -- Shamil Воскресенье, 16 декабря 2012, 13:43 от Hans-Christian Andersen <hans.andersen at phulse.com>: > >This concerns the Win32 API in more detail, from the horses mouth: >http://weblogs.mozillazine.org/asa/archives/2012/05/why-windows-classic-.html > >If this isn't sufficient for you, then you might need to explain what kind of facts you are looking for. > > >- Hans > ><<<< skipped >>>