Windows 10 on ARM and Microsoft rigidity about "that" decision..

v8 google's javascript engine. unlike microsoft's chakra javascript engine, open-source , provides granular abi/api access code-generation artifacts which a huge advantage on many javascript engines out there. example, node.js 1 out of brand application of v8 (icymi, better part of planet rely on node.js these days, hint: vs2015).

if history indicator, its foolish think microsoft open source ie , chakara etc. or make chakra comparable v8 in terms of api support and portability. time (if ever happened), late. so yay! have v8 support node.js , yet world better place regardless of microsoft planning.

so node.js relying on v8 something many people use day long , productive. node.js , ultrasonic variant io.js compile on windows ia32 , x64, not on arm. why? well its "complicated". first msbuild throw msb8022 and if you workaround it (changing arm\microsoft.cpp.arm.common.props file), v8 still not get compiled due preprocessor directive (#ifdef) google put in v8 code winrt because no-go. larry osterman has one-liner answer why so. looping original google v8 thread, says:

the difficulty not how allocate memory.

the limiting problem on winrt, memory cannot both writable , executable. design decision microsoft. means v8 either can't generate code, or can't execute it. since v8 built on idea of generating code, means there's no way v8 can work, unless microsoft changes rules.

in meantime, best bet use operating system. (not ios, though, has same artificial limitation.)

it further goes on:

i think restriction stricter: can't map readonly executable memory either.

i looked through:
http://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx

and far see there no analogues of virtualalloc, virtualprotect , createfilemappingfromapp (analogue of createfilemapping) allows page_readonly, page_readwrite, page_writecopy values pageprotection parameter. same mapviewoffilefromapp (analogue of mapviewoffile): desiredaccess can file_map_all_access (read/write), file_map_copy, file_map_read, file_map_write. in both cases executable options missing _entirely_.

one question, 3 variants:

• is microsoft sticking windows 8 decision of not letting dynamic memory allocation arch=arm?
• under marking gimmicky stunts, actual truth of windows 10 on arm: versatile dare dynamic memory allocation (something invented 60 years ago) or still playing defensive prevent users observing bloated os?
• will able use node.js on windows phone 10? <- innocent way of asking ;)

---

- citizen of microsoft developer network.

Windows 10 Insider Preview  >  Windows 10 Insider Preview Feedback