by Michael S. Kaplan, published on 2012/05/18 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/05/18/10305223.aspx
Previous blogs in this series:
I might have been the only software developer in the world who is confused about the world of "Desktop" versus "Metro".
Though I'm inclined to doubt it. :-)
Like when I was asked just the other day:
I am looking for an API that converts Unicode to Punycode. I can see that there’s already a .NET API just for this, but it’s not in Metro. What would it take to make it Metro?
My first thought was to point to IdnToAscii.
A function that claims to be available to both Desktop and Metro apps.
But someone was concerned about this answer:
As far as I know, IdnToAscii is only for C++.
The question is for C#/VB.
Okay, here is where things get complicated.
I think I have it straight now, though.
Here are the travails to get there -- imagine each one required several emails to clarify (since each one did!):
So really, the fact that you cannot get all of this from a glance at the docs is that the docs are a work in progress.
But I can live with that -- as long as people can get to functionality, they are not blocked.
We can get stuff done!
Whether Desktop or Metro.
Whether Native or Managed.
Whether x86 or x64 or WoA (ARM).
I think I know what my first Modern app will be!
Joshua on 18 May 2012 11:05 AM:
If you are using C# or VB, p/invoke cannot be used to run arbitrary code (OH NO!)
We will not be releasing an ARM build of our product then (need our own native DLL for a few key tasks).
Michael S. Kaplan on 18 May 2012 2:45 PM:
Well, you may want to dig in to get the right answer for your code -- my case kind of proves that the answer can be complicated!
Simon Buchan on 18 May 2012 8:48 PM:
My understanding of the entire point of WinRT was that APIs are WinRT apis (applies to "Metro style" applications in the docs), not "C++" or ".NET" apis: basically it's supposed to extend the language independence of .NET metadata to native code and scripting languages. So any "Metro" API should be accessible from any WinRT supporting language, so I'm more surprised that there's no .NET binding to it through some static class somewhere. I guess P/Invoke isn't so horrible, but it could be far better.
Simon Buchan on 18 May 2012 9:01 PM:
@Joshua: Cross-language/runtime interop is what WinRT is *for*. Recommendation for portal code is for you to, in your Metro builds, compile your native dll with your exports wrapped with C++/CX definitions:
int foo_bar(const char* str);
public ref class Foo sealed
static int Bar(Platform::String^ str)
// Platform::String^ is pretty close to System.String in .NET.
// Convert UTF-16 to UTF-8 here...
Then you get a WinRT .dll that's indistinguishable from any other, including builtins.
cheong00 on 20 May 2012 11:02 PM:
He can just enable the setting "configuration"->"uri"->"idn" in app.config or web.config and let Uri.DnsSafeHost class handle it. It's available on PCL too.
Alan McF on 23 May 2012 12:56 PM:
@joshua It works for me in a Metro C# app too. When I add various Win32 API P/Invoke calls they work in *most* cases, but running WACK (Windows App Cert Kit) highlights that of the one I used "socket" and etc are forbidden but has no complaints about IdnToAscii.
Pavel Minaev [MSFT] on 13 Jun 2012 1:24 PM:
>> If you are using C# or VB, p/invoke cannot be used to run arbitrary code
It cannot be used to run arbitrary code in a sense that you can't P/Invoke, say, a desktop-only API. But from everything I've seen, it can absolutely be used to P/Invoke into the Metro subset of Win32, or your own DLLs. Or did that change in RP?
go to newer or older post, or back to index or month or day