AccessMyLibrary provides FREE access to over 30 million articles from top publications available through your library.
Create a link to this page
Copy and paste this link tag into your Web page or blog:
If You have users who want Windows ends, take a look at tooks that DYnamic Link Libraries (DLLs). DLLs are the PC developers, equivalent of "open systems," and can extend the functionality of any package's base function call library. We'll use Gupta's SQLWindows as an example.
SQLWindows, an object-based application development environment for developers, can be used to generate applications for a variety of "back-end" database servers. One of SQLWindows' most compelling features is its ability to take advantage of Windows Dynamic Link Libraries (DLLs). This lets developers add custom functionality without having to do all the work themselves. DLLs
For example, SQLWindows doesn't support a function call to dynamically move a Form Window to a new location. However, a developer who knows C can add this functionality by using the Windows Software Development Toolkit (SDK) to create a DLL that contains the new function call. Granted, many developers use SQLWindows, or products like it, to avoid low-level programming in C, and probably aren't interested in taking on that sort of task. In this article, I'll show You an alternative that allows you to "expand" SQLWindows' functionality without coding in C.
Windows consists of three DLLs-GDI.EXE, USER.EXE, and KERNEL.EXE-each consisting of function calls that make up the entire Windows function call library. Before you can take advantage of these DLLS, you need to know where they are. Windows' default installation puts them in the System subdirectory of the Windows subdirectory.
The filename extension DLL has become the standard way of representing Windows or OS/2 DLLS. (The three Microsoft-provided DLLs mentioned above are exceptions.) One way to take advantage of the Windows DLLs is to buy the Windows SDK. The SDK gives you more than just full descriptions of its 450-plus function calls; you also get useful utilities like the Windows ICON Editor. All about particular function calls
Let's assume that as a result of browsing through the SDK function call reference manual, you discover the "FlashWindow" function call, and you want to use it in SQLWindows. Since SQLWindows doesn't support it, you need to look to the Windows DLLS. Step One is to determine which DLL contains FlashWindow. One approach would be to run either the SDK's EXEHDR.EXE or SQLWindows' MAPDLL.EXE. These programs will look at the header portion of any Windows DLL and view their function calls. Thus, the sample output from the EXEHDR for the USER.EXE DLL from Windows should look like this:
This tells us that FlashWindow is in the USER.EXE DLL. I use EXEHDR on all three DLLs and pipe the results to DOS text files. Subsequently, I can use a word processor to search for references to function calls.