Modular Software for Use in ApplicationsI maintain a library of general purpose software modules for use in my projects. There are literally hundreds of thousands of lines of original code that I have developed over the years. It can reduce development times for complex projects literally by years.The following list gives an overview of some of the modules available.
Geometry LibraryA general purpose geometric library, covering:
Language: C++.
Media ChannelsSupports the display and sequencing of images, audio, and video on PCs.
Language: C++
Color Conversion LibraryConversion between different color spaces such as RGB and CYMK.Color to gray scale. Gray scale to bilevel (thresholding). Negative color images, negative gray scale, negative bilevel. Language: C.
TGSThe Tiered Graphical Subsystem is a modular graphics subsystem, designed to dramatically reduce the work involved in developing high level graphics applications. It is the flagship of my development efforts.Overview of TGSTGS, the Tiered Graphical Subsystem is a modular, tiered or layered subsystem, designed to dramatically reduce the development work involved in high level graphics applications.It effectively provides the 'missing link' between software processing data structures representing real world data and the graphical output system, generally some form of Graphical Device Interface (GDI) such as Microsoft Windows. Most conventional GDIs concentrate on providing the graphical support required. However they generally give insufficient support when it comes to handling data structures that are capable of representing real world data. For example the coastline on a map should be able to be stored and processed as map grid coordinates at a scale of 1:1. The process of converting that data to pixels on the screen or to produce a printed page should not be the responsibility of the application program. Many commercial CAD packages exist which allow this type of real world data representation and its conversion to displayed or printed output. Some have user programming facilities, and most support some form of file exchange. However the following reasons constitute the requirement for the creation of TGS:
TGS is defined as an eight layer model. The application layer describes the application program itself, as well as the TGS API and TGS API translation modules. The organization and control layer describes organization and control operations within the TGS core, as well as application specific TGS modules and symbol libraries. The 3D graphics layer describes the storage of 3D graphic primitives, and 3D editing facilities. The 2D graphics layer describes the storage of 2D graphic primitives, and 2D editing facilities. The resource layer describes the resources or drawing tools used by 2D primitives to produce graphic output - pens, brushes, fonts etc. The GDI layer describes the TGS interface to GDIs such as Windows, and import and export modules for special device and file format interfacing. This layer also describes the GDI itself. Generally the GDI layer, device driver layer, and hardware layer are external to TGS. This would be the case for example if Windows is being used for graphical output. However in some embedded applications all layers may need to be within the scope of TGS. The power of TGS lies in its modularity. It has been designed to cover all conceivable combinations of environments - different GDIs, different operating systems, static or dynamic linking, embedded applications in special equipment, multitasking/multiprocessor architectures etc. TGS is composed of a library of modules. Only those modules needed to provide the required functionality need be linked into the required application. This keeps the code size to a minimum.
Software Modules within TGSThe following modules are currently available:
2D APITGS provides a standard Application Program Interface (API). This is a collection of functions providing:
The TGS API is universal. It allows application programs to be written in device independent manner. TGS internally manages the interface to the GDI in use and the required import and export files and devices. Language: C++, but has a C compatible function call interface.
2D CoreThe 2D Core module provides all the functional elements central to TGS, and therefore must be present in all TGS configurations:
Language: C++.
TGS Master DLLsProvides Dynamic Link Library support for TGS under Windows.Language: C++.
2D Windows GDI InterfaceThis module provides the interface between TGS and the Windows Graphical Device Interface (GDI).It supports all versions of Windows. Selection between the different versions is accomplished by conditional compilation, controlled by the SYSDEF header. This module is responsible for providing all Windows functionality associated with the scope of the 'limited editing' implementation of TGS. Specifically it provides:
Language: C++.
TGS Windows Application TemplateA generic template developed as a starting point for all TGS single document applications under Windows.Language: C.
TGS Windows MDI TemplateA generic template developed as a starting point for all TGS multiple document applications under Windows.Language: C++.
The Object Oriented Architecture of TGSTGS is built up of a collection of objects, with appropriate linkages and control structures between the different objects.Although TGS is written using C++ and uses an object oriented architecture, it is not necessary for the application program to be written in C++. All API functions are duplicated using standard function calls compatible with languages such as C, Pascal, and Fortran.
TGS Session and System Objects: TGCL_Session - the session object. This stores all the operational parameters for the current session. Generally one session object is used per application. TGCL_System - the complete TGS system object. Multiple objects allow multiple windows within an application. The session and system objects provide the overall organization and control of TGS. The session object has the job of managing a complete operating environment. Generally there is one session object per TGS application running on the system. This approach allows dynamic link libraries to handle each separate application program individually. In addition it allows complex TGS environments to exist with multiple configurations running simultaneously, even in embedded equipment. The system object has the job of managing a single drawing or display window.
Resources: TGCL_Resource - generic TGS resource (drawing tool). (abstract class)
The resources used in a drawing are owned and managed by an individual system object. A resource table within the system object stores pointers to the resource objects.
2D Primitives: TGCL_Primitive - Generic TGS primitive. (abstract class)
A primitive table within the system object stores pointers to the primitive objects. Each time the drawing or display image is processed, the table is scanned from start to finish. Hence primitives later in the table can overdraw those earlier in the table. Control primitives are not displayed, but pass commands to the system object. These are generally used for changes to the scaling system. Complex drawings can have multiple groups of control primitives and graphic primitives. This allows different parts of a drawing to be scaled and positioned separately. Graphic primitives are used to produce the images. All standard geometric elements are provided as well as paths and bitmaps. A path is a compound curve, generated from series of line segments, arcs, and bezier curves. Paths may be closed, and filled with a brush as required. Multiple sub-paths can exist per path. A bitmap is a scanned image containing pixel data. The bitmap primitive stores the pixel data, a color lookup table for 1, 2, 4, and 8 bit per pixel formats (not required for the 32 bit full color format), and floating point coordinates storing the corners of the bitmap for scaling and positioning.
Groups and Symbols: TGCL_Group (concrete class)
A group is a collection of primitives that can be operated on collectively for editing purposes. Symbols are a special class of group. They are individually written objects that control the operation of one or more primitives, generally for animation purposes. One example of a symbol is a special form of text that remains upright, regardless of display rotation. When the display is updated this symbol reads the rotation angle of the display and sends a command to the text primitive it owns to rotate it in the opposite direction.
Data Storage and the Scaling System used within TGSAll primitives store their coordinates at two levels:
This approach provides the highest level of flexibility for scaling, coupled with the highest possible display update speed for repaints, panning, and animation. A regeneration operation is performed as required to calculate the device unit coordinates from the real coordinates. For very complex drawings this can take a few seconds, so special techniques are employed to regenerate what will actually be within the display window first, followed by what will be outside the window. TGS uses a comprehensive 4 tiered coordinate scaling system, and uses 3x3 matrices to perform the conversions between the different coordinate systems. This scaling system allows the application program to use one or more real coordinate systems which are in context with the graphics being processed. eg. mapping info can be defined in terms of the map grid in use. The scaling system then allows for page placement, special print operations such as multipage printing, and translation to the coordinate system required by the output device. Control primitives may be placed throughout the primitive table to dynamically change the scaling and placement of graphics throughout a drawing.
Platform Independent Binary FormatThe Platform Independent Binary Format is a universal byte-oriented data storage and transfer format.It was originated by Digital Design Ltd. in February 1994 to provide a 'future-proof' means of storing and exchanging data between different software applications and equipment. PIB is essentially a standardized wrapping around a family of data formats, which allows the data to be stored or transmitted over any carrier and restored to a known format at the receiving end. It has been specifically designed for:
Use of the PIB format inherently causes the software reading or writing the data to be separated from the transmission or storage method used. The transmission or storage software is likewise separated from the application software as it need have no knowledge of the internal data formats used. This is a valuable aid to software development as libraries supporting different transmission methods can be developed and used for all applications using the PIB format. PIB is compatible with all known carriers and storage methods, including asynchronous serial, synchronous serial, networks conforming to the OSI, TCP/IP or ATM standards, and storage as a file format or in memory. Its use can also be easily adapted to currently unknown carriers. Language: C++, but has a C compatible function call interface.
Server Abuse ControlThis is a program which runs on web, ftp, and mail servers, and detects abuse such as denial of service (DoS) attacks. All sources of abuse are automatically firewalled without any intervention from a system administrator.Language: C++
System Status MonitoringAutomatically monitors the health of individual machines and subnets, for viruses, connectivity problems etc., or unusual network activity. It alerts the system administrator when a problem is detected.Language: C++
MailroomThis is a utility program which runs on mail servers to provide SPAM filtering and a challenge/response mechanism to identify genuine senders.Language: C++
Network LibraryProvides a range of networking support features for both Linux and Windows machines.Language: C++
CGI LibraryProvides support for CGI software on web servers.Language: C++
DDL InstallerThis is a set of client-side and server-side modules which provides the ability to download, update, and repair installations of consumer software products on client PCs.Language: C++
Commercial Application Licensing (CAL)This is a set of client-side and server-side modules which provides the copy protection, licensing, and payment mechanisms for consumer software products.Language: C++
Time Zone LibraryProvides time zone and location information and conversion functions for software such as Time Zones for PCs®.Language: C++
Compression LibrariesA range of interchangeable libraries providing data compression and expansion routines for many of the popular formats.Language: C.
Input/Output Communications ModuleInterrupt driven, software buffered, serial and parallel communications. Includes LED drivers to indicate data transfer status. Languages: 80X86 ASM and Z80 ASM.
Assembler Macro and Subroutine LibrariesThese are general libraries of assembler routines used for embedded control applications.Specific areas include:
Languages: 80X86 ASM and Z80 ASM.
DDL General C LibraryThis is a general library of C routines used in all Digital Design Ltd. application software.Specific areas include:
Language: C.
DDL General C++ LibraryThis module provides C++ extensions to the general C library.Specific areas include:
Language: C++, but has a C compatible function call interface.
DDL General Windows LibraryFunctions common to all Windows programs.Language: C++.
Windows Application TemplateA generic template developed as a starting point for all single document applications under Windows.Language: C.
Windows MDI TemplateA generic template developed as a starting point for all multiple document applications under Windows.Language: C.
|
||||||||||||||||
|