Data processing: software development – installation – and managem – Software upgrading or updating – Including multiple files
Reexamination Certificate
1998-09-03
2002-05-14
Chaki, Kakali (Department: 2122)
Data processing: software development, installation, and managem
Software upgrading or updating
Including multiple files
C717S175000
Reexamination Certificate
active
06389591
ABSTRACT:
FIELD OF THE INVENTION
The invention generally relates to a method for allowing an operating system to be upgraded without destroying the compatibility of applications written for the operating system. By distinguishing between applications which are going to customize the operating system controls from those applications which are not going to customize the operating system controls, the operating system can determine which applications can use upgraded operating system controls when they become available.
BACKGROUND OF THE INVENTION
Many computer systems provide a window-based user interface through which a user can interface with a computer program. A window is an area, typically rectangular, of a display device in which the computer program displays its output. A window may contain several different types of “fields” into which the computer program can display data. For example, in one field the computer program can display a label to be viewed by a user, and in another field the computer program can echo characters entered by a user with a keyboard. Each of these fields is typically implemented as a child window of the window in which they are contained.
FIG. 1
illustrates a prior art window that contains controls. Controls are graphical user interface elements which provide access by a user to any properties or events in an object-oriented programming environment. Because the window shown in
FIG. 1
contains information relating to properties of a document, it is known as a property sheet. A property specifies certain characteristics of an object, such as a document. For example, the properties of a document may include the name of the author and the date of creation, whereas the properties of a character may include font and color. The property sheet
11
contains five property pages: general
12
, summary
13
, statistics
14
, contents
15
, and custom
16
. Each property page is a child window of the property sheet and contains various controls, which are child windows of the property page. For example, in
FIG. 1
, the custom property page has been selected and contains controls in the form of combobox
17
, edit box
18
, check box
19
. Other examples of property pages are a general property page, a summary property page, a statistics property page, and a contents property page. As shown in
FIG. 1
, each of these property pages can be accessed by a user.
There are several reasons why it is difficult to innovate the user interface in an operating system. The controls (window classes, like button, edit, etc.) are used not only by the operating system itself, but also by applications that want the same “look and feel” as the operating system. The operating system exposes its controls and encourages developers of applications to make use of them. Many of the controls can be customized to fit particular application needs. This type of customization can be explicit, for example an ‘owner draw button’, or implicit by ‘subclassing’ a window.
If an application makes use of either of these customization methods, certain assumptions about the controls are made by the application developer, the predominant one being that those controls will not change behavior dramatically. Applications make use of this kind of customization to make their applications look more exciting, or to add functionality to controls that the operating system did not provide, for example, such as providing hot tracking. Hot tracking, for example, is a mechanism by which a selected button on a user interface can be made to look three dimensional when the pointer is located over the button.
If an application vendor subclasses a button control to add hot tracking, for example, it is difficult for the operating system to add hot tracking in the future. Some applications, however, do not make use of these customization options, often to improve their time-to-market or because it is not a requirement for their customers. Since the operating system can not distinguish between non-customized and customized applications, applications that are not customized suffer because they can not take advantage of upgrades to the operating system that could have been made but are not made for fear of not being compatible with applications which have customized their controls. Failure of an operating system to remain compatible with applications is also known as “breaking” applications.
Currently, there is only a limited solution to this problem. Applications are written to a specific version of the operating system, and the application is marked with this version number, e.g. 3.1 (for Windows® 3.1) and 4.0 (for Windows® 95). The operating system can read the version number and make some use of the version number to determine the “look and feel” the operating system should provide to the application, and what “common dialogs” the application can use. For example, in a single code path, for drawing the edges of a button, the operating system will determine the application version, and draw the edges ‘flat or ‘raised’ depending on the ‘look and feel’ of that version of the operating system. This is to match the user interface of the application, which may contain its own controls that are ‘flat’, as was the previous ‘look and feel’ of the operating system. Modifications such as these are tested very thoroughly, for many months, on thousands of applications to ensure that the modification does not break any of the applications. The levels of change capable are very low, so only minor changes can be made. If it is found that a particular application ‘breaks’ under the new behavior, a judgement call is made to either include the changed behavior or remove it. If it is decided to keep the new behavior, more code is added to exclude this new behavior for any particular application which will be broken by the new behavior.
Presently, when a developer wants to create a control, such as a button, in an application, the following line of code, for example, can be used:
HWND hwnd=CreateWindow(“BUTTON” . . . )
In this case, the developer is explicitly asking for a window whose classname is BUTTON. The operating system provides this window, but may also perform checks against the version number in the application to slightly modify its behavior.
As noted above, developers are free to customize this control, and can modify its behavior by using, for example, the following line of code:
SetWindowLong(hwnd, GWL_WNDPROC,(DWORD)myWndProc)
Once this line of code is used, the myWndProc fiction will override all the windows messages that are sent to the control to add or modify the behavior of the BUTTON control. As a result, it is difficult for the operating system to improve the functionality of the BUTTON control.
SUMMARY OF THE INVENTION
The above-described shortcomings, disadvantages and problems are addressed by the invention by providing a naming convention which distinguishes between controls that will be or may be customized and controls that will not be customized so as to allow the operating system to upgrade its controls without destroying the compatibility of applications which have previously customized the operating system controls.
The controls of an operating system are generally made available for use by applications running on the operating system. The application developer has the option of using the control in the same manner that the operating system uses the control or the developer can customize the control by changing a set of features that define the control. When the control is not going to be customized, the developer identifies in the code of the application that the control will not be customized. Likewise, the developer identifies in the code of the application that the control will be customized.
When the application is running on the operating system and a control is requested, the operating system first determines whether the control is identified as being customized or non-customized. If the control is not going to be customized, the operating system is free to use an upgraded set of features to creat
Banner & Witcoff , Ltd.
Chaki Kakali
Chavis John Q.
Microsoft Corporation
LandOfFree
Method and apparatus for determining preferred controls for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for determining preferred controls for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for determining preferred controls for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2915120