Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Donate
Contact info
Forum
 
Other projects
   Altirra

Search

Calendar

« December 2012 »
S M T W T F S
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

Archives

01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ File extension madness, Windows Vista / 7 style

Last time I wrote about the old way of associating file types and file extensions with a program. I've since tried Default Programs, the new way of handling file associations starting with Windows Vista. You still have to register the file types in HKEY_CLASSES_ROOT in order to set the defaults (or more specifically HKLM\Software\Classes or HKCU\Software\Classes as required), but afterward you use the Default Programs mechanism to select the user mapping. This has the following advantages:

And... that's about it. Now for the bad parts:

As such, I'd say the new Default Programs system is not an improvement over the old way of doing file type associations. Sadly, the way things are, there isn't much choice unless you're willing to start hacking the Explorer registry keys, which I couldn't recommend as a good choice.

(Read more....)

§ File extension madness

Ever hit the problem in Windows where you tell a program you want it to handle some file types, and only some of them "take"?

I've got a pretty good idea now why this happens, and it's a mess.

The MSDN Library has a section on how to associate file types in code. There are some omissions -- I knew what the positive and negative numbers meant on icon references, although that doesn't actually seem to be documented -- but in all it's actually not bad. If you follow the documentation you can indeed add a UI to your program to associate file types, and if you spend another hour in the Vista UAC section you can even get your program to properly relaunch itself as elevated as needed. Then you send it out to your users, and you find out it inexplicably doesn't work on some users' systems.

Well, long story short, the culprit turns out to be yet another overlay on the file type mechanism located at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts. This is a bit odd, because there is already a user-local overlay over the main class database at HKCU\Software\Classes. Within the key for each extension here there can be a subkey called UserChoice, which is created when the user specifically overrides the current association with the Open With... option and has the "always use this type" checked. This then overrides the ProgID selected through in HKCR. Frustratingly, I wasn't able to find any documentation on this in MSDN, but it wasn't until I tried to delete the subkey for testing in Registry Editor and got an Access Denied error that I had a clue why it wasn't documented. Let's take a look at the security settings:

[Security settings]

A Deny entry for the current user, for only Special permissions? That's strange. What exactly are they?

[Deny Set Value entry]

Mmmhmm, the shell explicitly set a Deny entry for the Set Value permission on the key. That makes this Microsoft's latest salvo in the War Against the Coolest Most Amazing Program Ever Written, especially since bypassing this requires mucking around in security APIs that are mazes of SIDs and ACEs. While I appreciate the intent -- having had to manually clean up the mess from programs that thought it funny to claim .ZIP and .PDB as media types -- I'm not sure that the resultant game of Open With whack-a-mole that results is any better, where first I have to manually switch AVI, then MPG, then MP4, and every other extension still bound to the ugly-as-sin Windows Media Player. It would be nice if the file type documentation actually mentioned this user override too, even if it didn't include storage details, because this appears to make the documented HKCR method useless for any sort of custom association UI.

Digging around the MSDN links a bit reveals an IApplicationAssociationRegistration interface added with Vista which might work, but I haven't tried that yet. Annoyingly, it requires you to register your application in HKLM, which seems backward given the moves toward storing file associations per-user. That it offers a programmatic interface to override associations also doesn't make me hopeful since that also goes against the bunker Microsoft's been trying to build around the file type settings.

(Read more....)

§ Screen recording with WDDM 1.2

While browsing through some of the changes to the Windows 8 Developer Preview, I happened upon the list of improvements in DXGI 1.2. I have to say, the list looks pretty good. After fixing the most glaring problems with the transition to WDDM and DWM -- memory usage and unaccelerated GDI rendering -- Microsoft has started evolving DXGI further, and there's some good stuff here.

Especially desktop duplication.

Formerly, the options for doing screen recording in Windows weren't that great. These were the options I knew of:

To sum it up, there were no good global solutions on Windows XP, and only one decent one on Windows Vista and up. Well, desktop duplication in WDDM 1.2 finally has a good option. The process for capturing the desktop with the new APIs is surprisingly simple:

(Read more....)

§ Recompiling code for Windows 8 ARM

I've been a bit busy on non-coding stuff as of late, but I did manage to get some time to install the Windows 8 Developer Preview natively. Previously I had been running it on a VirtualBox VM, which worked but only supported non-accelerated video and was prone to heavy freezing for minutes at a time. After a few tries at installing before I figured out that the BIOS had to be forced to boot the DVD in UEFI mode to install on a GPT-formatted disk -- strangely, a problem I didn't have with Windows 7 x64 -- I got it installed and happily it runs much more smoothly on real hardware.

The last time I tried the Developer Preview, I compiled some small snippets with the Visual Studio 11 Express preview that was included. Loading a full Win32 project revealed a big problem: the VS11 Express preview doesn't have support for loading non-Metro C++ projects. I ended up installing the full Visual Studio 11 Developer Preview to fix that. After a few hours of download and installation -- and a bit of Disgaea 4 levelling in the meantime -- I loaded the solution I had previously converted to VS2010, upgraded it to the v110 toolset, and started an ARM build.

ARM build?

Truth be told, I don't know if I'll bother actually compiling anything for Windows 8 ARM. Between the current signed-only requirement for Metro apps, the uncertainly around whether Windows ARM will support desktop apps and whether WinRT can be used from desktop apps, what APIs will be able for ARM, and simply whether any of the Windows ARM devices will be worth buying it's not clear whether it'll be a hospitable environment for what I do. There's also the issue of actually having a device to test on, since code you can't run is virtually guaranteed broken. However, building for ARM has another beneficial side effect, which is to flush out unguarded x86-isms in a code base, and being able to do so with Visual C++ is much easier than doing so with another compiler or on another platform. I've done a decent amount of x64 and also some PPC, so I did have a good idea of what to expect going in. For the most part it went smoothly, but some problems I ran into:

The showstopper was when I got link errors on comctl32.lib, and then after fixing that shlwapi.lib. Game over, missing essential libs for a desktop app. Oh well. At least it only took a few minutes to get the main codebase building, since I had already done a lot of the gruntwork for AMD64/x64. What this tells me is that if you've done reasonable diligence to keep x86/x64isms low in your code, that rebuilding it for ARM with VC11 is going to be pretty painless. Availablility of APIs could potentially be a lot more painful but we won't know how much for sure until the official API list for Windows 8 ARM is released.

(Read more....)