Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: winrt random
6 views
Skip to first unread message
Andy Polyakov
Sep 19, 2012, 4:51:43 PM9/19/12
to
> 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 opens...@openssl.org
Automated List Manager majo...@openssl.org
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 opens...@openssl.org
Automated List Manager majo...@openssl.org
Andy Polyakov
Sep 19, 2012, 5:17:56 PM9/19/12
to
> 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.
Just to clarify. I'm not suggesting to keep using Win32 interface in
> 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.
WinRT application. I'm only using this example to demonstrate that it's
possible to use "standard" OpenSSL build even in WinRT application
context. So why don't you? If something doesn't work or it's
inappropriate to do so for some reason, let's identify the problem, it
might be possible to address it in "standard" build. I mean there is
more value in maintaining single source suitable for multiple contexts
than to split the effort.
Charlie Lenahan
Sep 19, 2012, 6:01:47 PM9/19/12
to
You can build and link using banned API's , but when you run the app
certification kit , it will give you a fail, and list of all the
function calls you making that you can't make. If you use the .dll's ,
its even worse because it fail you for functions that your not using
but because that dll is included it checks all functions.
So for the most part is was configuring w/ no sockets / no dgram ,
etc, since we just use mem bio's.
The patches I'm putting together are in 2 flavors , stuff that doesn't
compile cleany when that feature is turned off.
And the other is the winrt/metro specific patch where it adds a new
compile target and a couple of alternate implementations for functions
that fail the certification tests.
The areas that where using banned API's where some calls to windows
event logger, catastrophic error, and random seed stuff.
--
Charlie Lenahan
certification kit , it will give you a fail, and list of all the
function calls you making that you can't make. If you use the .dll's ,
its even worse because it fail you for functions that your not using
but because that dll is included it checks all functions.
So for the most part is was configuring w/ no sockets / no dgram ,
etc, since we just use mem bio's.
The patches I'm putting together are in 2 flavors , stuff that doesn't
compile cleany when that feature is turned off.
And the other is the winrt/metro specific patch where it adds a new
compile target and a couple of alternate implementations for functions
that fail the certification tests.
The areas that where using banned API's where some calls to windows
event logger, catastrophic error, and random seed stuff.
Charlie Lenahan
Andy Polyakov
Sep 20, 2012, 6:59:11 AM9/20/12
to
>>> 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
>> 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
>> 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
>> 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.
>> is
>> *not* independent framework running on top of NT Kernel Services.
>
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?
>
> 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].
>
> 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...
Andy Polyakov
Sep 20, 2012, 7:06:19 AM9/20/12
to
> You can build and link using banned API's , but when you run the app
> certification kit , it will give you a fail, and list of all the
> function calls you making that you can't make. If you use the .dll's ,
> its even worse because it fail you for functions that your not using
> but because that dll is included it checks all functions.
Is criteria for .dll being "green" known? Presence of accompanying
> certification kit , it will give you a fail, and list of all the
> function calls you making that you can't make. If you use the .dll's ,
> its even worse because it fail you for functions that your not using
> but because that dll is included it checks all functions.
.winmd? Installed in system32? Microsoft signature? Explicitly listed in
certification kit? Once again, this is not about saying no, it's about
understanding it better.
0 new messages