With each passing year, we see new products and services delivered through the Internet. Insurance quotes have been online since 1995 but some insurance carriers are still reluctant to get onboard. This insurance carrier wanted us to use their PC quote engine to automatically display quotes online.
Knowing that this would not be the last time this task was requested, we realized that trying to get the data from the PC by screen-scrubbing was out of he questions. It seemed that each month when carriers delivered their PC quoters, something in the screen layout had changed. This would make extracting the data from the PC screen, unreliable.
We opted for interfacing with the insurance carriers’ PC product through DLL interfaces. This required writing C/C++ and Visual Basic code to talk to the carriers’ executables.
Once a request was received from the website, the PC would query the carrier’s PC quoter for the correct quotes. Then the data was transferred back to the client’s web server and displayed using Perl.
In the long run, the client was very happy with this decision. This approach still requires some frequent changes due to interface changes from the carriers, but the amount of change is minuscule compared to the GUI changes.
Languages: C/C++, Visual Basic (VB), Perl, COM
Platforms: Windows, SunOS, Web
Many Fortran programmers need to access the Windows API without being stuck with a MS compiler. This client needed just such access and found that many others shared that need.
To make this work right, we needed to add a Windows-like control loop as well as many wrappers to the usual MS API functions.
Our goal during this project was to use as much Fortran as possible and only rely on C/C++ or Assembly Language wrappers when absolutely necessary.
Of course, this project also required close work with numerous Fortran compiler vendors as we were exercising parts of the language than hadn’t been tested thoroughly.
Languages: Fortran, C/C++, Assembly Language
Our client had a website with many hundreds of pages of HTML and dynamic content. Many of the pages had similar format but there were always enough differences to make the site look irregular. Furthermore, data entry personnel were responsible for much of the dynamic content which changed at a rate of around 200 page changes per month.
The website was hosted on a SunOS machine and managed remotely using SSH and FTP using Windows machines
Since the page irregularities were the paramount issue to the client, we tackled them first. The solution was to work with a graphic artist and come up with a standard page layout, complete with images, buttons, bullets, and navigation gifs. Then we produced a suite of tools to merge the content with the templates.
This merging process allowed us to completely separate the content from the page layout. This separation allowed us to produce a concept of page “skins” that we could change at will with minimal work from the regular HTML programmers.
Most of the dynamic pages were produced with Perl CGI programs so they were converted to use the templates as well.
The next step was to deal with the content produced and maintained by the data entry personnel. This was a bit trickier since these employees didn’t know much about HTML and had even less interest in learning. The solution here was to produce a few more tools for the suite that formatted new HTML pages whenever the data entry personnel updated the content in the database. This required having select fields for the data entry personnel, such as “header”, “subject”, “date”…
Obviously, this new data-driven layout greatly enhanced the usability of the client’s data and allowed them to leverage their data entry employees better by producing more content with easier data maintenance.
Platforms: Windows, SunOS, SSH, FTP
This project involved substantial modifications to an existing Fortran compiler, bringing it up from F77 standards to F90 standards. Since the ANSI Standards parsing requirements were so radically different, the entire parsing mechanism was rebuilt.
The core of this system relied on an intermediate language (IL) designed specifically for writing compilers. The IL was written in Assembly Language as were many of the Runtime Library routines
Since the client was located on the east coast, most of the works was dome remotely using TCP/IP file transfer tools as well as diff and merge tools.
This project also involved creating and maintaining a set of version control project files.
Languages: Fortran, Assembly Language, Intermediate Language
Platforms: GCOS, Honeywell
This project encompassed numerous facets of design and development of a Fortran compiler and language system. This compiler ran on the Windows platforms and produced executables for Intel platforms.
Numerous tools for the project were written in Fortran. We also developed a validation suite that contained many hundreds of Fortran test programs.
The core of the language system was written in C/C++ and Assembly Language, relying on support from a bottom-up design. The parser was based on a finite automata design.
Code produced by this language system could run on both DOS and Windows systems.
This language system interfaced with numerous languages through our mixed language interface. Users were able to interface with our Fortran using Visual Basic (VB), Pascal/Delphi, C/C++, and more.
This project completed successfully with just over a year duration.
Languages: Visual Basic (VB), Fortran, C/C++, Pascal, and Delphi
Platforms: Windows, Intel
Our client was seeking a TripWire alternative. When it comes to security projects, “Security by Obscurity” is the wrong approach. However, there’s always some benefit found in stacking the deck in your favor.
The client wanted to avoid a well known security tool where everyone knew how it worked, where it saved the data dictionary, and what it weaknesses were.
Since the platform was a Sun box, the solution was to write a tool using Perl5 which traversed the directory tree and created hashes of each file. The system needed a way to exclude files or entire directory branches — something the user could configure. For simplicity’s sake, we agreed to put the list of exclusions in a human editable text file that the IDS read at startup.
The target machine served as the company’s web presence as well as the e-mail server.
To protect the data dictionary, we wrote the md5 hashes to a CD-R. disk. This has meant that the tool has had to be run with the “write” option whenever system files have changed.
The system used e-mail, syslog, and dedicated port alert mechanisms. The last one required a listening PC server, written in Visual Basic (VB) on the local network.
This system tested well and the client was very happy with the added security.
Languages: Visual Basic (VB), Perl using dedicated ports
Platforms: Windows, SunOS
As many of you have noticed, we are in the process of updating the Access Technologies website. Please bear with us during the migration process and be sure to come back often to see what’s new.
With the new design, you’ll be able to access the same information and many of the same pages as the pieces come together.