Apps should automatically adjust to a variety of window sizes as well as screen sizes. You shouldn’t assume that users will always want to run your app at full screen size. Even if all your users have humungous screens, they may want to show multiple windows side by side in some cases.
Designing (if not developing) for multiple window sizes is pretty easy when the data are laid out in a list/tabular or graphic format (the latter including maps, diagrams, and most WYSIWYG apps). The pane that shows the table or graphic should resize as the window resizes. Generally, you include horizontal and vertical scrollbars as necessary to allow the user to pan around the data within whatever pane size there is at the moment. Resizing the pane with window resizes generally implies all data is accessible by scrollbars. It doesn’t work well to break up the data into pages (e.g., like the way Google search results are split up).
It’s perfectly acceptable to have horizontal scrolling for a table (unlike for a web page dominated by prose) as long as the first column(s) that identifies the rows remains in view when the user scrolls horizontally. Likewise the column headers should remain in view when the user scrolls vertically. For graphics, changing window size generally should not change the level of zoom. Instead, show more data when zooming out and less when zooming in, while providing a separate zoom feature.
For data laid out as a form, with fields and labels for a single record running down the pane, there really isn’t a good way of handling multiple window sizes, and you have to choose a window size to design for. For usability, you should design so that at standard text size all fields are visible without scrolling when the window is sized to the lowest screen resolution you’re likely to come across. Use tabs or other similar controls to fit all the required fields in that space. Generally, this implies a designed-for size of 1024x768, assuming your users may use your app on a laptop. It may be acceptable to have a form layout that requires some vertical scrolling at smaller resolutions (as is common on web apps), but users should never have to scroll horizontally for typical cases. Thus, in your case you may want to design for 1024x1050 if most of your users use desktops and only occasionally use laptops. Test that users realize they have to scroll when using a low resolution before proceeding with this. If you expect users to use the window regularly while viewing other windows (e.g., it’s more like a properties dialog), that may set additional limits on the window size.
With a form layout, the size of the text or the spaces between the fields should not change when the window is resized (although allowing the user to explicitly increase text size is a good idea). Resizing larger than the designed-for size should simply add blank margins to the right and bottom. In other words, there really isn’t much point in resizing larger for form layout. That’s okay. At least some of your users will make good use of unused screen space for something else (e.g., another window or app). Real power users with big screens may open two instances of the same window side by side and have each instance show a different tab so they can monitor as much as possible at once.
Resizing smaller than the designed-for size for a form layout should cause scrollbars to appear and provide access to fields that are no longer in view. The latter situation should be an edge case if you’ve chosen the lowest screen resolution you’re likely to come across.