Applications should automatically adjust to different window sizes as well as screen sizes. You should not assume that users will always want to run your application at full screen size. Even if all your users have bulky screens, they may want to show several windows side by side in some cases.
The development (if not development) for several window sizes is quite simple when the data is laid out in the form of a list / tabular or graphic format (the latter include maps, diagrams, and most WYSIWYG applications). The panel that displays the table or figure should change as the window resizes. Typically, you enable horizontal and vertical scrollbars as needed, so that the user can pan the data within any panel size that is currently available. Resizing a panel with window changes usually implies that all data is accessible by scroll bars. It does not work well to paginate data (for example, how to paginate Google search results).
It is perfectly acceptable to have horizontal scrolling for a table (as opposed to a web page with a predominance of prose) if the first column (s) that identifies the rows remains in view when the user scrolls horizontally. Similarly, column headings should remain in view when the user scrolls vertically. For graphics, resizing a window usually should not change the zoom level. Instead, when zooming in and out, while zooming in, while zooming in, increase the amount of data, providing a separate zoom function.
For data laid out as a form, with fields and labels for one record running on the panel, there really is no good way to handle multiple window sizes, and you need to choose the window size for the design. For ease of use, you should design so that with the standard text size, all fields are visible without scrolling, when the window size corresponds to the smallest screen resolution that you are likely to encounter. Use tabs or other similar controls to match all the required fields in this space. Typically, this implies a size of 1024x768, suggesting that your users can use your application on a laptop. It may be acceptable to have a form layout that requires some vertical scrolling at lower resolutions (as is common in web applications), but users do not have to scroll horizontally for typical cases. Thus, in your case, you can create a design for 1024x1050 if most of your users use desktop computers and only occasionally use laptops. Verify that users understand that they need to scroll when using low resolution before embarking on this. If you expect users to use this window regularly when viewing other windows (for example, more like a property dialog), this may set additional restrictions on the size of the window.
When composing a form, the text size or the spaces between the fields should not change when the window is resized (although it allows the user to explicitly increase the text size, this is a good idea). Resizing in excess of the specified size should simply add empty fields to the right and bottom. In other words, there really is no point in resizing for the layout of the form. This is normal. At least some of your users will use unused screen space for something else (such as another window or application). Real users with large screens can open two instances of the same window next to each other and each instance displays a different tab so that they can track as much as possible simultaneously.
Resizing smaller than the size intended for the layout of the form should cause the appearance of scroll bars and provide access to fields that are no longer displayed. The latter situation should be the edge case if you have chosen the smallest screen resolution that you are likely to encounter.