>>> 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. > > That's not true, at least if you're using the VS 2012 compiler.
What's not true? That it's not an independent framework or that you can't call MessageBox? I am using VS2012... > There's > more than a simple #if in the headers; there are a number of #pragmas that > affect link time, too. Additionally, those functions are not available for > ARM processors at all (some might be, but OpenSSL uses some that are not -- > I speak not from a guess, but actually trying it). Once again (as mentioned in clarification), I'm not suggesting to adhere to Win32. My goal is rather to understand the goal better and maybe find a way to consolidate the effort. Nor do I dispute the fact that ARM might be missing some interfaces, but just for reference I seem to be able to compile and link WinRT application with MessageBox for ARM. Can't execute it though, no hardware... There is no emulator, is there? > Additionally, if you're an ISV, you care greatly about being able to pass > the validation tests, even if you don't want to sell it through MS's store > (which you can't do if it doesn't pass the validation tests). Fair enough. >> Is there anything preventing >> WinRT application developer from including OpenSSL headers and linking >> with OpenSSL libraries compiled the usual way? > > Yes -- such an application will not pass the validation tests. Such an > application won't link for ARM at all (it should be noted that OpenSSL won't > compile for ARM without some changes, like faking prototypes, anyway). And > yes, I've tried it. It does not work. Care to elaborate? Maybe some other time, no pressure... >> Eliminating dependency on >> MSCRT is even more sensible, and not only in WinRT context [though it >> can't be done in 1.0.x]. > > There's no need to do that in a WinRT context -- the C runtime in general is > allowed to be used, you're just extremely limited on what you can call from > the runtime. :) This I don't understand. I mean that they banned Win32, but not MSVCRT. Just doesn't make sense to me. But my comment was rather about long standing problem with mixing code compiled with different compilers. I see value in eliminating dependency on MSVCRT regardless the WinRT context. Well, hardly related... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
