Windows 8 UI Style A-- Who are we kidding? Windows 8 Metro App Thread

The Something Awful Forums > Discussion > Inspect Your Gadgets > Windows 8 UI Style A-- Who are we kidding? Windows 8 Metro App Thread

ljw1004: Jan 18, 2005; rum

Combat Pretzel posted:

And here's my next bad review about to happen, an email just gotten:

1) The certification delay forbids any quick fixes.
2) For all these crashes that are supposedly happening, I have zero crash data on the dev site.
3) There was a loving trial, 14 days to be specific. I hate people.

I wonder if it'd be worth putting in your own telemetry, e.g. writing to a log of what happened, and if failed to terminate properly the last time, then upload your own log of what happened the next time?

# ¿ Nov 12, 2012 19:24

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 08:07

ljw1004: Jan 18, 2005; rum

Combat Pretzel posted:

Tried something like that. Catching anything in the unexpected exception handler. Problem is, most IO functionality is async and that doesn't play well, once that handler has been reached.

In VB/C# you can log the exception's StackTrace property. This will be a useful (async-aware) representation of the stack at the time the exception was thrown.

In C++ you can log the exception's _M_DisassembleMe field. This is the instruction pointer at the time the async operation was started (specifically, when the task was created). Back home on your dev box with symbols, go to the Debug>Disassembly window, type in that address, and it'll show which async operation failed.

In JS you can log the exception's data.stack property in base.js::terminateAppHandler. To get lots more async-relevant information, it can additionally be useful to capture the callstack at the time the async operation was started: look at the source code of base.js for "var tagWithStack = false". You can chance it to "= true", or e.g. "= tag.exceptionPromise". Then, you can view this in terminateAppHandler through e.detail.promise._stack.

VB/C#: Another approach is to say, well, every single unhandled exception will crash your program. Therefore you won't be adding any additional harm if you put "Try ... Catch ex As Exception" around every single top-level event handler (i.e. all the async voids). I know it's considered poor practice to do this because it harms the crash-dumps. Well, that's not a reason in this case. Have it log every single unhandled exception. Another approach is to remove async voids entirely, and instead have your event-handlers kick off async work by doing "DoWorkAsync().FireAndForget()", where FireAndForget is an extension method on task that keeps track of all outstanding tasks and logs whichever one ended in a faulted state.

C++: the analog of this is that every single task chain you write out of .thens() should either be returned to the caller (if you're writing a task-returning async method), or finished by a .then() that catches and logs exceptions, i.e.

code:

    .then( [](task antecedent) { try {antecedent.get();} catch (...) {LOG} });

# ¿ Nov 13, 2012 16:54

ljw1004: Jan 18, 2005; rum

Combat Pretzel posted:

The relevant code runs on a separate thread, not on an async function. Hell, I can't even show a message box when I'm in the unhandled exception handler due to the async nature of it, to let the user know about a problem.

If it's already on a background thread, then the cleanest code pattern is just to fake it up sync as early as possible. In C++, I'd declare a task_completion_event. In the callback of the async API, do either set or set_exception on it. So your code looks like this:

code:

  task_completion_event e<void>;
  ActivateAudioInterfaceAsync(args, callback, e);
  task<int>(e).wait();

  // the sole job of "callback" is to do e.set() or e.set_exception().

This way you just have a good old fashioned code flow, with exceptions being thrown in the same place as they would if the code were synchronous. The only snag I'm aware of is that you must invoke AudioClient.Initialize from within the callback of ActivateAudioInterfaceAsync, not after it (like would happen if you used the above pattern everywhere).

# ¿ Nov 13, 2012 17:38

ljw1004: Jan 18, 2005; rum

Combat Pretzel posted:

And here's my next bad review about to happen, an email just gotten:
[snip]
2) For all these crashes that are supposedly happening, I have zero crash data on the dev site.

The latency from when the crash-dump is uploaded to when it appears on the devsite can apparently be up to 14 days, but I hear that 5 days is more common.

(If you believe you've had a crash more than 14 days ago, but still no crashes up there, send me a personal email at lwischik at microsoft.com with details and I'll see if I can prod the team in charge of it, but no promises, since they're in a completely separate division from me.)

# ¿ Nov 15, 2012 07:21

ljw1004: Jan 18, 2005; rum

Jerk McJerkface posted:

So I have a Surface on the way. I'm mainly interested in using it for technical PDFs and reading epubs. What are some recommended epub reader apps? I have a Windows 8 laptop for work, and I tried a few readers, but it doesn't have touch, so I'm not sure how they work on a tablet.

I got my Surface on Monday. Installed "Freda" on it straight away for reading epubs. I love Freda from using it on Windows Phone. First impressions are that I like it on Surface too.

# ¿ Dec 20, 2012 03:13

ljw1004: Jan 18, 2005; rum

How are people using Facebook?

Does anyone find that the "People" app fails to show status-updates from a bunch of their facebook friends? (friends whose updates are visible from Windows Phone 8, and also from the facebook web-page?)

How are people uploading photos to facebook? I tried this app
http://apps.microsoft.com/windows/en-GB/app/share-photo-to-facebook/ae3b5341-a854-4d9b-87d0-5fb0cc852694
but it felt sleazy - it asked for more facebook permissions than seemed justified, and the photo I uploaded with it still hadn't appeared on my facebook timeline after 24 hours.

There's another app in the store
http://apps.microsoft.com/windows/en-us/app/photo-uploader/c0a4cfdf-7d36-40c8-b415-c57a41690cf3
that I haven't tried yet.

This article
http://blog.laptopmag.com/how-to-share-to-facebook-from-any-windows-8-app
claims you can just "share to facebook" from any photo, but it's not true. (One of the commentors said you can also "share to people app", but that's not true either as far as I can tell.)

# ¿ Dec 31, 2012 02:38

ljw1004: Jan 18, 2005; rum

Combat Pretzel posted:

How does that work for C++/CX code? My audio backend is in C++ because of necessity, because Microsoft refuses to bring managed APIs for audio (beyond simple playback of soundfiles).

Is that necessity your use of WASAPI? I did that from VB.Net for WinRT using pinvoke...
http://www.codeproject.com/Articles/460145/Recording-and-playing-PCM-audio-on-Windows-8-VB

# ¿ Jan 8, 2014 22:26

ljw1004: Jan 18, 2005; rum

Combat Pretzel posted:

The catch about C++ would probably be the unavailability of any native APIs that aren't part of WinRT. You can access quite some native Windows APIs in WinRT apps, whose presence on Android I rather doubt. The lower level audio stuff probably one of these. As said, if Microsoft would supply a proper WinRT API for this, Xamarin had something to clone.

I thought the point of Xamarin was NOT to provide uniform abstraction layers? So if you're writing an iOS+WP8 app, then you'll use iOS UI APIs for one version and WP8/Silverlight APIs for the other version. I believe that devs typically do MVVM where the VM goes in partial classes, e.g. "wp8-vm.cs" and "ios-vm.cs". I don't think Xamarin's cloning stuff outside the core parts of .NET, and even that becomes less important as .NET moves into NuGet.

(caveat: this is all my impression from reading articles about modern xamarin, but I haven't actually used xamarin since 2007 when I wrote console apps in it and it was called something else...)

# ¿ Jan 9, 2014 20:11

ljw1004: Jan 18, 2005; rum

Combat Pretzel posted:

Ugh, that bug of mine is rearing itself even worse on ARM. I don't even see how I'm going to reproduce it in a separate project. I just hope that VS2013 SP1 goes final pretty soon. Seems more a compiler issue that may go away with SP1. I had to hack up the worst offender in three parts for x86 to remove the MethodImpl, and it isn't that big of a function.

--edit: I must have hit the jackpot with compiler breakage, considering I have two identical functions. One breaks, one doesn't. The difference between them is one does a single additional single integer division.

(I'm on the VB/C# compiler team) This doesn't sound like a compiler bug to me, and I don't think we have any fixes in the pipeline for SP1 that are anywhere related to this. What you've said (especially ARM being worse) makes it seem like a JIT bug.

If you can't make a small repro, but are willing to give MS a copy of your entire project, we can work on it that way. Best way is to file a Connect bug and attach the source code there - you can mark the bug as Private so that other people can't see your source code. Or you could email the code to me directly, email domain "microsoft.com", email alias "lwischik", and I'll make sure it gets to the right people.

# ¿ Jan 9, 2014 23:10

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 08:07

ljw1004: Jan 18, 2005; rum

Combat Pretzel posted:

On top of that, the ability to distribute windowed WinRT apps with no API restrictions outside the store, that'd be awesome if possible.

What kind of "distribution outside the store" are you thinking of? You're already able to give someone an appx on a USB stick or whatever, and have them install it (so long as their machine is unlocked). No store restrictions.

The thing is, if there are no API restrictions, then the app can screw up your machine. And that defeats the biggest end-customer value of "apps".

You can also write a desktop WPF app which calls into WinRT APIs.

# ¿ Sep 30, 2014 16:53

The Something Awful Forums > Discussion > Inspect Your Gadgets > Windows 8 UI Style A-- Who are we kidding? Windows 8 Metro App Thread