> -----Original Message----- > From: [email protected] [mailto:owner-openssl- > [email protected]] On Behalf Of Andy Polyakov > Sent: Wednesday, September 19, 2012 4:52 PM > To: [email protected] > Subject: Re: winrt random > > > 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. 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).
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).
Several larger consumers of Windows even require their in-house software to
meet the same set of requirements, which would mean several non-ISVs can't
use OpenSSL without some changes (sorry, NDA says I can't name any of the
ones I personally know about).
> 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.
Only if you don't consider MS's various #pragmas to be magic. I do. :)
Very, very evil magic. :) Of course, some of my colleagues love the ones I
dislike. :)
> 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.
> 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?
I would think "porting openssl to run on winrt" means ensuring that OpenSSL
doesn't use any of the disallowed functions, and that applications which
link OpenSSL libraries can successfully pass the validation tests ("can" not
"will" -- there's nothing the OpenSSL team can do about failures not
directly related to OpenSSL :) ).
> Is it actually necessary?
Absolutely -- unless you're working on a project that's only for x86/x64 and
only for uses that don't have requirements for passing validation tests.
I'd be very surprised if that will describe the majority of cases where
OpenSSL would be very useful on Windows.
> 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)?
The validation tests don't check what's actually called at runtime, but
what's linked into the application, so as long as there's a reference to
MessageBox, for example, the validation tests will fail (of course, if you
compile in such a way the compiler can eliminate the reference for you,
it'll be OK).
> 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. :)
TOM
smime.p7s
Description: S/MIME cryptographic signature
