High DPI - it's an everyone thing.
As larger displays are becoming more popular, they're increasingly being used in places like the livingroom. And if you've ever tried to read text across the room with the default DPI setting, you'll find you may need a pair of opera glasses.
In Windows 7, if you're using a larger display, the OS will automatically adjust for you, in the hopes that you will be more likely to be able to read text.
From this we see that there is a real end user benefit to tap into here. It turns out that there is existing infrastructure in Windows called “High DPI” which can be used to address this. High DPI is not a new feature for Windows 7, but it was not until Vista that the OS user-interface made significant investments in support for high DPI (beyond the infrastructure present earlier). To try this out in Vista, rt. Click desktop -> personalize and select “Adjust Font Size (DPI)” from the left hand column. Our thinking for Windows 7 was that if we enable high DPI out of the box on capable displays, we will enable users to have a full-fidelity experience and also significantly reduce eye strain for on-screen reading. There is even infrastructure available to us to detect a display’s native DPI so we can do a better job of configuring default settings out of the box. However, doing this will also open up the door to expose some issues with applications which may not be fully compatible with high DPI configurations. - Engineering Windows 7
It may be worth a look to see what your app looks like in 120 DPI. In both windows forms and WPF, good use of the AutoSize features usually accomodates most scaling issues. It can be tricky to set up, but once it works, it usually works well.
Windows Forms lets you set everything in pixels, and then during the loading process, it uses the AutoScale feature to magically multiply whatever you said by however bigger and/or smaller things are supposed to get. How much bigger/smaller things get is best calculated by taking the font size of the Form when you designed it (which is what AutoScaleBaseSize, AutoScaleDimensions are), then taking the new font size as currently run on the system. The percent difference in size is used to adjust the size/location of controls.
For windows forms, check out the "AutoScale" section of this layout FAQ for tips as to how to use AutoScaleDimensions.
WPF uses Device Independent Units, which is a fake unit that makes you always think you're drawing in 96DPI. When it goes to render to the screen, it translates the DIU to DPI doing the math under the hood for you. Charles Petzold does a good job explaining how the math works. For the most part this system works well, though you need to know the tricks for image rendering and getting lines to draw crisply.
Note this also means when doing WPF->Win32 interop, you need to translate back to the device coordinate system. E.g. a WPF button that's set to Width=75, Height=23 is set to 75x23 DIU, not 75x23 pixels. To translate back you can use Visual.PointToScreen or PresentationSource.FromDependencyObject(dobj).CompositionTarget.TransformToDevice .
In either system, if you have bitmap artwork in your application, you may want to consider whether or not you want to use a separate larger image for this mode - as in high DPI, the image will be stretched larger.
If I have any more specific tips, I will be sure to post them!