This client has numerous supervisors who work in the field and score and review the work. Using clipboards and then entering the clipboard data into a PC was troublesome and error prone, not to mention oh so “last century”.
After investigating numerous handheld computers, we decided on the HP pocket PC running Windows CE and Windows Mobile.
This project started in the early days of Windows CE and we worked through and worked around many many MS bugs. Before the project was even finished, HP and MS quit supporting the original platform so we migrated to the latest products.
The first release of ADOCE was of typical MS quality and next to useless so we built all the data management through file support. Once the new release of the CE operating system was released and the ADOCE was fixed, things went more smoothly
The initial release of the product was ready for testing within 5 months.
Since multiple pocket PCs where being used by many supervisors, and many different copies of the PC based data management software could be running simultaneously, we needed systems for managing concurrent connections and keeping tack of which supervisors used which pocket PCs.
The client wanted the pocket PC product written in VB/CE since there are many VB programmers available for future maintenance and enhancements. The one drawback to using VB was the lack of icon support. In order to support corporate icons, the client is considering using a C/C++ wrapper.
Languages: Visual Basic (VB, VBCE), ADO, ADOCE
Platforms: Windows CE (WINCE), Pocket PC (PPC)
This Financial Services client had special requirements for office software. Much of the existing data was being maintained in spreadsheets and it was time consuming and error prone to change data entry personnel.
This particular client had used Quickbooks in the past and hated being “nickel and dimed to death” so he opposed the suggestion of going with a packaged product. It’s probably just as well, since his office personnel required considerable training.
We produced custom software for this client using VBA under MS Access.
The software was completed with two weeks, but documentation and training took two more weeks.
The benefits to the client’s decision to go with custom software included cost and reliability. Modifications were always fast and inexpensive and he wasn’t always having to pay for upgrades and add-on services.
Languages: Visual Basic Applications (VBA), Access
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.