Session 12b1 Component-Level Programming: A ... - CiteSeerX

Session 12b1 Component-Level Programming: A Revolution in Software Technology Peter M. Maurer, Murali Varanasi, Srinivas Katkoori, Wai-Kai Mak Department of Computer Science & Engineering, University of South Florida, Tampa, FL 33620 Abstract - A profound change is taking place in the world of applications programming. Precompiled components, originally developed for visual languages, like Visual Basic and its cousins have become indispensable tools for software development. Component-level programming has raised programming “far above the statement level,” and has encouraged code reuse to a degree that was never before possible. This has all happened so quickly, that it is hard for academic curricula to keep up. Even as this is being written, profound changes are taking place in the design and scope of component-level programming. New reusable components are being invented, and different uses are being found for them. New cross-platform standards are being developed and implemented. Some of the most profound new developments are web-based hosting of components and distributed components that run interactively on several different machines. Students can be exposed to component-level program through a visual language such as Visual Basic, but this will not expose the student to the full scope of the most recent developments. This paper describes the most recent advances in component-level programming, and gives suggestions for integrating component-level development into existing curricula. The paper first describes custom controls, the precursor to component-level programming, and shows how the concepts of custom controls have evolved into more comprehensive standards. The use of existing components in several different contexts is discussed. The most important contexts are standard application development, web-based design, and distributed application development. We show how a single component could be used in each of these contexts. We illustrate these uses with examples from our own recent work in VLSI Design Automation. In addition we discuss the development of new components, and how best to integrate component development into the undergraduate curriculum. Component development is discussed in the context of the emerging COM standard which is available on a wide variety of platforms and a wide variety of programming languages.

Introduction During the late 80’s and early 90’s the world witnessed a revolution in user interfaces. The character-based terminals of the past gave way to more powerful graphical user interfaces known as GUIs[1,2,3]. Despite the inherent advantages of GUIs, they were surprisingly slow to catch on. The Apple MacIntosh managed to take over only a small segment of the personal computer marketplace, despite the superiority of both its hardware and software. It was not just

a matter of IBM PC versus MacIntosh. The Windows operating system introduced the GUI to the PC platform, but it was also slow to catch on. The main problem was software availability. Although there was some software available, the preferred operating system was still DOS, especially for custom software and shareware. Although GUIs are easy for users, they are an absolute nightmare for software developers. For example, characters typed on a keyboard are passed to a program as individual “Key-Press” messages. It is up to the program to determine where on the screen the character will appear. The program must then explicitly draw the character at that location. This is made even more complicated by the fact that locations are given in terms of pixels rather than lines and characters. It is the responsibility of the program to handle non-printable characters properly. If the user presses the backspace key, the program must locate the last character typed, and explicitly erase it from the screen. The program must handle text-scrolling by performing low-level drawing commands. Programming at this level is so tedious, that even a simple program can take months to complete. Many efforts were made to simplify GUI programming, particularly for the IBM PC, but most of them were somewhat less than successful. Both Borland, and Microsoft introduced Object Oriented packages to simplify Windows programming. Unfortunately, these packages tended to simplify the easy tasks while leaving the more difficult tasks to the programmer. To use the previous example, both Borland’s OWL package and Microsoft’s MFC package, permitted the programmer to provide a message handler for “Key-Press” messages without the need to explicitly intercept and interpret the message. No assistance is given for creating the message handler. Explicit low-level operations must still be used to draw text, handle control characters, and do scrolling. GUIs were clearly a computing revolution, but from the programmer’s point of view it was a revolution of the worst kind. Programs that do simple things should be simple to write, but they weren’t. What’s worse, there was no apparent way to solve the problem. The solution came from a unexpected source: the BASIC programming language, specifically the version of BASIC known as Visual Basic.[4]

The Visual Basic Programming Language Visual Basic is a language that is used to create dialog boxes. In a GUI, a dialog box is used to transfer small amounts of information between the user and the program. The information can be as simple as “Click OK to continue” or as complicated as a printer-setup dialog. However, they were designed to display small amounts of information for

0-7803-5643-8/99/$10.00 © 1999 IEEE November 10 - 13, 1999 San Juan, Puerto Rico 29th ASEE/IEEE Frontiers in Education Conference 12b1-11

Session 12b1 short periods of time. They were designed as an add-on to a larger program. Visual Basic takes the peculiar approach of elevating the dialog box to the status of a complete program. A Visual Basic program begins its life as a blank dialog box known as a form. The programmer draws various objects on the form. Most of these are active objects called controls. Short segments of Basic code are added to controls to implement the functionality of the program. The details of the GUI, such as intercepting keyboard messages, and displaying text on the screen, are handled automatically. Visual Basic is distributed with a number of pre-defined controls, some of which are illustrated in Figure 1. An interface is also provided that allows the user to create custom controls. (Most other GUIs provide a similar interface.)

Figure 1. Examples of Controls. The true success of Visual Basic began with version 3.0, which included support for database access. This interface was expanded to handle virtually any existing PC database system. The Visual Basic interface was already similar to the interfaces provided by these systems and it was much cheaper than any one of them. What’s more, the programs were freely redistributable. It was now possible develop a database interface and distribute it throughout a company without installing the database system on each computer. To some users, it seemed like getting many database systems for much less than the price of one. The only real problem was that the set of controls that came with Visual Basic was so inadequate that it was almost impossible to do anything very complicated. Because of the primitive nature of the BASIC language, it was impossible to fill the gap with BASIC programming. These conditions led to one of the most amazing developments in programming history, namely the explosive growth of the third-party custom control industry.

Custom Controls Visual Basic 3.0 introduced the idea of bound controls. These controls can be associated with a field in a database, so that any changes the user makes to the field are automatically copied into the database. In some database applications it is necessary to display several records in spreadsheet form, and allow users to make modifications. This was difficult to do with Visual Basic as it was distributed. A grid control was provided to permit data to be displayed in spreadsheet form, but the control could not be

bound to a table in a database. This meant that changes to the grid were not automatically copied into the database. To fill the gap, several third-party companies developed grid controls that could be bound to database fields. Many other companies provided controls to provide other useful functions that were missing from the Visual Basic package. The third-party custom control industry has become a multibillion dollar a year industry. The original custom control interface, also known as the VBX interface, provided a set of properties and a set of events, all of which were associated with an instance of a control. Newer versions of the interface also permit the definition of functions. Properties are internal variables that can be assigned default values at compile time, and can be read or written at run time. Only simple data types or arrays of simple data types could be used for properties. Structures and pointers were not allowed. An Event is an opportunity to do something any time a particular activity occurs. One takes advantage of this opportunity by writing a Visual Basic subroutine to handle the event. Typical events mouse clicks and keystrokes, but there are many other types of events. It is not necessary to associate a subroutine with each available event. The functionality of a Visual Basic program is contained in its event handling routines. Event handlers can be associated with forms to initialize or terminate a program. As mentioned above the ability to define new functions was missing from the VBX interface. This omission has since been corrected, but it persisted for long enough that it had a permanent effect on the way custom controls are designed. The restriction to simple data types and a functionless interface meant that the procedures for using a custom control had to be simple. This imposed a severe discipline on the custom control designer, and forced the development of interface procedures that probably wouldn’t have existed otherwise. For example, many third-party programming packages require the programmer to declare a collection of data structures, and initialize them with specific function calls. In the VBX interface, there was no way to do this, so the control designer was forced to declare data structures and initialize them automatically. The inability to define new functions turned out to be a minor problem, because the control had the ability to monitor the usage of its properties. Complex actions could be performed when a new value was assigned to a property, or when the value of a property was accessed. In VBX controls, it became a common practice to provide an “action” property, which was to perform operations that could not be associated with any other property. Over the last few years, there have been several changes in the custom control interface. OLE controls (also known as OCX controls) provided the ability to define functions, and were capable of being used with several different environments, not just Visual Basic programs. ActiveX controls, based on the COM[5] standard, are capable of

0-7803-5643-8/99/$10.00 © 1999 IEEE November 10 - 13, 1999 San Juan, Puerto Rico 29th ASEE/IEEE Frontiers in Education Conference 12b1-12

Session 12b1 being hosted in a web page and downloaded automatically. The COM standard provides mechanisms for creating platform-independent controls that can be used in a distributed environment. Third party custom controls have advanced to the point that practically any application that exists as a separate program also exists as a custom control. To give a few examples, there are full-featured word processors, personal information managers, graphical editors, web browsers, communication managers, voice mail systems, as well as a vast array of interface elements like tool-bars and tabbed dialogs. There are hundreds, perhaps thousands of different products available[6].

COM and Distributed Components Although there are several emerging standards for platform independent custom controls, one of the most interesting is the COM standard. The COM standard has been implemented on a wide variety of platforms, including the IBM PC, the MacIntosh, most varieties of UNIX, VMS, and the IBM Mainframe OS. COM supports programming which is far more advanced than the simple custom control interfaces of the past. COM objects are more correctly referred to as custom components rather than custom controls. COM components are self-identifying. They are required to implement certain function standard calls that provide information about the interfaces they support. Once designed (and distributed), interfaces are frozen. New expanded interfaces can be defined, but existing interfaces can never be modified. Components can be distributed. Certain function calls can be designated as remote calls. Such calls will appear to be normal function calls, but the COM software will replace these calls with a call to an object on a remote system. As an example of how such a system might be used, consider the WinFHDL[7] system designed here at USF. This system consists of a number of custom controls combined within a Visual Basic framework. The set of custom controls includes a schematic editor, a text editor, a compiler, and a simulator. (Four custom controls.) These controls are designed to operate in the Windows 3.1/Windows 95 environment. It is relatively easy to adapt these controls to a new environment. The schematic editor could be embedded in a web page, essentially without change, to permit web-based editing of schematic diagrams. Users could edit and save schematics on their home systems by using this web page. The code for the schematic editor would be downloaded and installed on the user’s system the first time the web page was accessed. Although the current editor supports only the Windows environment, the code could be recompiled for other platforms, using the COM environment. A different control would be required for each environment. Because of the distributed nature of the COM environment, this duplication of effort is not required for each of the controls. The editors

must be recompiled for each environment, because they must interact directly with the user. However the compiler and simulator could be designed to run remotely. When a simulation is requested on a Windows system, the simulator and compiler will be downloaded and run on the user’s system. When a simulation is requested on a UNIX system, remote procedure calls will be made to components running on a Windows system. Because COM interfaces are frozen, the user will not be able to tell the difference between the systems. (Even a programmer would have difficulty telling the difference.) The only thing that would be affected is performance. What is even more interesting is that once a component is downloaded and installed on a user’s system, the component can be used locally to develop new programs. Suppose, for example, that we provided a full-featured text editor in one of our web pages. The first time the user accesses this page, the text editor will be installed on the user’s system. It would then be possible for the user to write a program that included the full-featured text editor as a component. (Commercial tools have built-in mechanisms to prevent unauthorized use by developers.) Because the interface is frozen, it is possible to upgrade tools without disturbing the user. Suppose that someone has made extensive use of our web page containing a text editor. Then suppose that we create an entirely new version of the text editor, and install it on our server. The next time the user accesses our web page, the web browser will check for an updated component. When the presence of the new component is detected, it will be downloaded and installed on the user’s system, replacing the old component. The user may not even notice this has happened, even if the component has been used to develop programs locally.

Inserting Controls into the Curriculum The development of visual programming and custom controls has been sudden and surprising, so much so that Visual Basic has become one of the most important tools for application development. We in the academic community must to respond to this, but it is necessary to proceed slowly. Visual programming with custom controls is still undergoing profound changes. It’s hard to keep up with the latest developments, and it’s even harder to identify any unifying principles that could be used as the basis for a “Visual Languages” course. Nevertheless, there is a strong industry demand for visual programming, and we should at least introduce our students to the fundamentals, as they exist today. While it would be useful to provide a course in visual programming, this material is easy to learn, can be offered as an add-on to an existing course. For example, Visual Basic could be introduced during the last week of a C programming course. Our approach was to add several Visual Basic exercises to a highly recommended elective course, which also had the effect of increasing the

0-7803-5643-8/99/$10.00 © 1999 IEEE November 10 - 13, 1999 San Juan, Puerto Rico 29th ASEE/IEEE Frontiers in Education Conference 12b1-13

Session 12b1 enrollment of that course. Regardless of how the material is offered, we believe that students should complete the following exercises. • Read a list of items from a text file, and display the list in a grid, list-box, or combination-box control. • Perform different manipulations of data in response to clicking on different buttons. • Accept text from a text-box, process it in some way, and display the result in another text-box. It is possible to combine these three things into one or two exercises, depending on taste. A week or two should be enough time to complete these exercises. Once the basic concepts of visual programming have been introduced, we recommend a short exercise in combined C/Visual Basic programming. In this exercise, the students implement several small functions in C, and compile them into a Windows DLL file. DLL programming is important, because custom controls reside in specially named DLL files, so it is important that students familiarize themselves with the basic principles of DLL programming. A DLL file is a library of functions that can be loaded at run time. Once the DLL is created, it can be tested using an instructor-supplied interface program or with a program created by the student. The following is an example of such an exercise from a recent course offering[8]. A Dynamic Link Library is a collection of independently compiled functions that can be called by other programs. A DLL can contain two types of functions, Exported Functions, and Internal Functions. Exported Functions must be the target of a FAR call, and must use PASCAL calling conventions. Exported functions must also have the _export keyword. Small DLLs, such as that created in this experiment, usually are coded in a single .c file. This .c file should begin with the following code.

/* the following statement is used only with Borland C */ #pragma argsused int FAR PASCAL LibMain (HANDLE hInstance, WORD wDataSeg, WORD wHeapSize, LPSTR lpszCmdLine) { return 1 ; }

Instructions: Create an MS Windows dynamic link library that will perform the following functions. 1. Convert a string of hexadecimal digits into a long integer. 2. Convert a long integer into a string of eight hexadecimal digits. 3. Given an integer n, compute the sum of integers from 1 to n. Return an integer. 4. Compute the square of an integer, and return an integer. The first function must be named HexToLong, the second must be named LongToHex, the third must be named SumToN, and the fourth must be named ISquare. The name of your library must be firstone.dll. The function declarations must look as follows. long FAR PASCAL _export HexToLong(char *Hex) void FAR PASCAL _export LongToHex(long Value, char *Hex) int FAR PASCAL _export SumToN(int N) int FAR PASCAL _export ISquare(int N)

Every Windows DLL must have a .def file which is used during the link phase of the compilation. The .def file for this project should look as follows. LIBRARY FIRSTONE

#include

DESCRIPTION 'My First DLL'

/* The following two functions are required, but do nothing */

EXETYPE WINDOWS

/* the following statement is used only with Borland C */ #pragma argsused int FAR PASCAL _export WEP(int exittype) { return 1; }

CODE PRELOAD MOVEABLE DISCARDABLE DATA PRELOAD MOVEABLE SINGLE HEAPSIZE 4096 …

0-7803-5643-8/99/$10.00 © 1999 IEEE November 10 - 13, 1999 San Juan, Puerto Rico 29th ASEE/IEEE Frontiers in Education Conference 12b1-14

Session 12b1 As a final step, students should be required to create a custom control. Although it is possible to create custom controls for virtually any environment, it is far simpler to use the Windows 95/98 environment. Development tools are cheaper than for the UNIX environment, and are far more thoroughly tested. The latest C/C++ development tools provide “Wizards” that will assist students in creating the control, and will permit projects to be completed in a reasonable amount of time. Students will have the opportunity to choose between an OLE control or an ActiveX control based on the COM standard. The following is an example of a student exercise. Using the control wizard, create a custom control that has two custom properties InString and OutString, and one custom event, BadString. InString and OutString must be of type String and will normally contain multiple lines of text. When a new value is assigned to InString, the control will process the string one line at a time. Any line that contains parentheses must have balanced parentheses. If a line has unbalanced parentheses, fire the BadString event. This event must have two parameters, the line number (starting with zero) where the error occurred, and the text of the offending line. Eliminate all bad lines from the output. For a line where the parentheses are OK, change the parentheses to square brackets. In other words., ( ) goes to [ ]. Accumulate the output for all OK lines into the OutString property. Test the control using input and output from multi-line text boxes. Although a substantial amount of “framework” code is necessary to create the custom control, the wizard will supply virtually all of it. The student can then concentrate on writing the algorithms to handle the properties and fire events. This last task should take two weeks to complete. The more adventurous students may wish to create their own custom controls. There are two ways that this can go, depending on whether the control creates visible output on the screen. The controls that we have created so far are invisible at run time, and do nothing more than provide a programming interface to algorithms written in C. Most students will want to stay with invisible controls, but some may wish to try their hand at screen output. Any control that interacts with the screen must provide message handlers for mouse and keyboard events. Students should start with simple graphical exercises and work up to more complex screen/mouse/keyboard interactions.

Conclusion In short, we believe that visual programming and the use of custom controls should be an essential part of all Computer Science and Computer Engineering curricula. It is not yet clear how this will affect the curricula, but we believe that it is necessary to begin taking steps to integrate these topics into existing courses. In the future, we would expect to see curriculum changes that include both courses in visual programming, and courses in the design of custom controls. One of the more interesting trends is the development of COM controls that can be used in many different environments and on many different platforms. It is too soon to see where this trend is leading, but it appears that we are entering an era of simple-to-use distributed components. In the near future, that programs of any complexity will be distributed. Those programs that are designed to run on a single site may become the exception rather than the rule. There is much development being done and there are many new things becoming available. It is impossible to predict where future development will lead. Although the future is uncertain, it is certain to be exciting.

References 1.

Inside Macintosh: MacIntosh Toolbox Essentials, Addison-Wesley Publishing Company Inc., New York, 1992.

2.

Petzold, C., Programming Windows 95, Microsoft Press, Seattle 1996.

3.

Mansfield, N., The Joy of X: An Overview of the X Window System, Addison-Wesley Publishing Company Inc., New York, 1992.

4.

Microsoft Corporation, Visual Basic 5.0 Professional Edition, web site, http://www.microsoft.com/products/prodref/730_ov.htm .

5.

Eddon, Guy, Eddon, Henry, Inside Distributed COM, Microsoft Press, Seattle, 1998.

6.

VBXtras Website for ordering custom controls, http://www.vbxtras.com.

7.

Maurer, P. The FHDL Home Page, http://www.csee.usf.edu/~maurer/fhdl.html.

8.

Maurer, P. Dr. Maurer’s Course Materials, http://www.csee.usf.edu/~maurer/courses.html#UGDA.

0-7803-5643-8/99/$10.00 © 1999 IEEE November 10 - 13, 1999 San Juan, Puerto Rico 29th ASEE/IEEE Frontiers in Education Conference 12b1-15