Antonio Linares: Thom, Windows.UI.Xaml-coretypes.h is no longer there and now there is a windows.ui.xaml.h. Here you can review it: http://min.us/mBk81kdVr I also thought that Start has to be used instead of Run, but it is not in IApplication. Thanks,

Antonio Linares: Thom, I use these small C++ native tests to check very simple code. This one works except the Run (obvious as it is no longer there). Getting this to run we can use it in our respective language "projections":

Earlier I posted on here about WinRT and Delphi. I'd like to expand on that a bit and share some of my experiences with Win8 and creating a Delphi language projection for WinRT. I'll start by expanding on the code that was required for that Hello World app.

The Windows 8 beta was released a few weeks ago, and I've been investigating Microsofts new WinRT library. WinRT is a whole new set of APIs that wrap existing Win32, COM, and .NET Framework APIs for creating applications for Windows' new Metro style. Due to the fact that the API is backed by a native interface based on COM, Microsoft touts the ability to create your in a wide variety of languages HTML5+CSS, JavaScript, C#, Visual Basic, and C++. But what about other languages, such as Delphi? Well, it comes with somewhat relative ease that bindings can be made for any language using the provided API metadata files (.winmd files). I say relative ease, because the bredth of the APIs is fairly wide, but because the .winmd files are Ecma-355 metadata, the Windows APIs provided in Winapi.Cor (cor.h) can be used to create a tool to read this metadata and turn it into useable interfaces. (As an aside, The easiest way to view the contents of these files from the developer preview is to open them with ildasm, the .NET Framework IL Disassembler.)Once I created flat interfaces into the runtime classes, +Allen Bauer pointed me at a few articles by Ian Griffiths on Native WinRT development in C++ (http://www.interact-sw.co.uk/iangblog/2011/09/16/real-native-winrt). Following his example, it was relatively straightforward to get a Delphi application up and running that initializes WinRT, creates an Windows.UI.Xaml.Application, Attaches it's OnLaunched event, and populated the screen with a simple bit of Hello world Xaml, and that's what you can see in the attached screenshot. You'll notice it is running in a window and not fullscreen like a typical Metro style app. That's mainly because I haven't packaged it as an Application package and deployed it, a process which ran into further snags I may go into at a further time. Anyway, the point of this post is: It's possible to create Metro style apps using Delphi, and it will be possible to create an object oriented framework that hides all the glue code required to use the raw COM interfaces that will make it as easy, if not easier, to program than C++, C#, Visual Basic, or JavaScript.

Show all 12 comments

Thom Gerdes: +Markus Müller: I'm not sure that's the case. See Karn VedBrat's talk, Introduction to DirectX for Metro style apps (http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-766T), two thing specifically: He demo's an app completely using DirectX that isn't purely a game, and he also states all of the Windows Live Essentials Applications (while not yet implemented as Metro Apps) are currently are rendered in pure DirectX. +Lars Fosdal: Karn also answers that question in the same talk: Yes, the Xaml, and even pure HTML/CSS interfaces are all accelerated using DirectX.

Yogi Yang: I agree with Markus. It would be better to adopt XAML controls as provided in Windows 8 instead of emulating them! Why reinvent the wheel?!?!?!

Daniel Rail: Although I agree that maybe the Metro Style apps can be created using FireMonkey. It would be nice to have support for XAML to create the live tile for the Metro Style apps. Also, having some templates to get started with the Metro Style apps. Also, what about the app bars(bottom and top) and the charms(on the right side)? But anyway, I'm glad to see someone at Embarcadero investigating Win8/RT support. Keep up the good work.

Why is it that installing a fresh install of MS Win7 Ultimate with SP 1 (released about two months ago) requires you to run Windows update 5 times (including 3 restarts) before it actually gets all updates? What user is going to get a new machine and not be frustrated by that?

Show all 4 comments

Larry Tetone: ^^the jaded user.

Thorsten Engler: Well, most users will do nothing explicitly, and the updates will happen automatically on consecutive days.

Przemysław Dmochowski: I would like someone to stop this almost crime proceder.

I know I have strong opinions on this subject, so I'll try (but probably fail) to keep this relatively brief. I promise to go back to frog photos after this.

Google+ forces you to have a public gender in your profile (although it can be 'Other'). I know they have reasons for this, but I don't think they're good enough.

Many women grow up with a sense of physical vulnerability that's hard for men to appreciate. Our culture's relentless treatment of women as objects teaches them that they are defined by the one thing that men around them want from them—men who are usually bigger, stronger, and (like any human) occasionally crazy. This feeling—often confirmed by actual experiences of harassment and assault—can lead, understandably, to a lifetime of low-level wariness and sense of vulnerability that men have trouble appreciating. A male designer building an interface should try to keep in mind that there are reasons a female user might feel uncomfortable being told she has to broadcast her gender. Sure, someone's gender is usually obvious from their name, but there's no need to force people to draw extra attention to it—introducing myself with "Hi, I'm Randall." sends a different message from "Hi, I'm Randall, and I'm a MAN."

I don't think making this option mandatory is a significant cause of the major Google+ early-adopter gender split, but if you're worried about how few female users your project has, marginalizing their potential worries on your introductory screen doesn't seem very bright.

There are reasons Google+ might want your gender. For one thing, the interface may need to use pronouns, and in some languages there's no way to avoid this. We have a chat-bot in the #xkcd IRC channel which serves as a repository of user nonsense. At some point, we decided to program in the ability to use pronouns, and it was surprisingly complicated:

Now, I went out of my way to support the various options for referral that users asked for (although I drew the line at recently-invented pronouns like "xir"). But even covering the basics in English is tricky, and the situation gets more so in languages like Hebrew. (It looks like Google+ punts on that issue by making all "other" users male in all languages, which is a can of worms in itself.) Yet none of the linguistic issues mean you have to make gender a broadcasted part of the user's profile.

They also (obviously) want to know more about you so they can serve ads; advertisers care about gender. But again, that's no reason to make gender public.

The "other" option is nice, but I don't really feel comfortable setting my gender as "other". There are a huge number of people whose gender is actually best-described as "other", and they come in astonishing variety, even if you set aside the issue of social gender and just ask about biology. This article has a fascinating list of eleven particularly tricky situations that lead to someone having no easy-to-agree-on biological sex:

There are quite a few people who are accurately described by an "other" option, and when they're sometimes struggling for recognition, co-opting their label for anyone who doesn't want to broadcast their gender seems a little off-putting.

The bottom line is that there are a lot of reasons Google+ would want to ask about your gender. But there's no good reason to pointedly make it the only thing in your profile that can't be private—and many reasons not to, starting with basic courtesy. It may be a small issue in the grand scheme of things, but I think it's worth getting right.

(P.S. I know I post a lot about interface quibbles and feature suggestions—and I do use the feedback button heavily—but I don't want to give the impression I'm generally unhappy with Google+. Fundamentally, I really like this system, which makes me want to tweak things in this early-adopter period so it will be as well-designed as possible, so it will survive and be around for me to use for a long time.)