I've been porting openssl to run on winrt(metro).
What does it mean more specifically? Even though some assert that WinRT is totally independent framework directly on top of NT Kernel Services, it doesn't seem to hold true. The only things that prevents WinRT programmer from calling any particular function, be it Win32, User32, MSCRT or any other interface, is *declaration* of the function of interest. Microsoft has hidden most of Win32 and alike in #if !METRO in its headers, but it doesn't mean that functions won't work if you call them. For example, you *can* call MessageBox from Metro application if you declare it yourself and explicitly link with user32.lib. It makes lesser sense to do so, because you have to switch to desktop in order to interact with dialog, but it *is* possible. Which means that WinRT is *not* independent framework running on top of NT Kernel Services. Well, there is extra limitation, namely WinRT applications are commonly started with lower integrity level, which impedes the application, but there is no super special WinRT magic. Is there anything preventing WinRT application developer from including OpenSSL headers and linking with OpenSSL libraries compiled the usual way? I can't think of any (modulo potential side effects caused by lower integrity level). And having said that, let's go back to original question, what does "porting openssl to run on winrt" mean? Is it actually necessary? Wouldn't making "standard" build work with lower integrity level be more sensible thing to do? Perhaps detecting that application is WinRT and acting accordingly (e.g. abstaining from calling MessageBox and instead logging fatal failures to even log)? Eliminating dependency on MSCRT is even more sensible, and not only in WinRT context [though it can't be done in 1.0.x].
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
