A local community church approached us to replace an outdated and inaccessible website that presented an unattractive face to those looking for a church to attend and was no longer serving the needs of the congregation. After extensive requirements gathering with the church's board of directors, DSS quickly and efficiently implemented an attractive, full-featured and responsive new website based on an excellent content management system (the same one we used for the site you're looking at). The 'skin' of the site is a port of a popular WordPress theme that appealed to the members of the church's board of directors. Have a look!   Dingletown Community Church 

A New York-based hedge fund approached DSS about re-designing and re-implementing a large portion of their portfolio management system. They had outgrown an Excel- and Access-based application they had had written for them a number of years ago, and were beginning to have problems accurately tracking P&L, portfolio pricing, and portfolio performance over varying time frames.

After many months of requirements gathering and analysis, we ended up implementing a full-blown SQL Server data warehouse which aggregated data from both the Advisorware accounting system and the Eze Trading system.

On top of the data warehouse, we layered a set of special-purpose Excel add-in applications written in C# and integrated with Microsoft Excel using Visual Studio Tools For Office. These applications provided P&L, portfolio pricing and daily performance reports. DSS used a number of other technologies here, including the Bloomberg .NET API. Among our other accomplishments, we mentored their in- house development staff in the use of the Unified Modeling Language for system requirements gathering, analysis and design, and taught them several techniques for understanding and managing the complexities of software development in support of the software environment required to support the firm's business needs.

DSS spent 9 months designing and implementing a Peer-To-Peer Multiplayer engine based on Microsoft DirectPlay 8.x to replace the failed Sony RTime multiplayer engine used in UbiSoft's/Ultimation's two 2001 World War II simulation titles, Silent Hunter II and Destroyer Command. These two simulations were intended to be played against each other in recreations of the desperate convoy battles of the North Atlantic, in which Germany's u-boat fleet attempted to sever the Allied supply line to Europe. The sims were billed as supporting 8 players via TCP/IP, but in reality failed to support even 4 players reliably.

DSS gambled on a web community-funded project, and took on the task of replacing the failed multiplayer engine. On Christmas Day, 2002, DSS and Subsim Review released the first half of Projekt Messerwetzer, Silent Hunter II, integrated with DSS's new DirectPlay Peer-To-Peer multiplayer engine. It has been a smashing success! The Destroyer Command side of the project was completed and released on January 15, 2003.

DSS added several enhancements and fixed a number of pre-existing bugs at the behest of the members of the Wolfpack League, in addition to the replacement of the multiplayer engine in both simulations. We'd like to add that this type of project is unheard of in the PC gaming industry; for a third-party developer to step in, come up to speed on an extremely complex existing code base, and rip out and replace the heart of two simulation's multiplayer capabilities has never been done.

Needless to say, we're very, very proud of this accomplishment!

Silicon Valley Group (now ASML) Lithography Division builds a series of machines that laser-etch silicon wafers in preparation for semiconductor mass-production. The Micrascan 4/5 machines contain several computers which serve as subsystem controllers for the various functions of the machine. During operation, these subsystem controllers generate large volumes of status information which went to logfiles on the hard drives of the respective controllers, or was lost. Each of the development teams built their own logfile format and had to manage logfile proliferation and lifetime. While these logfiles worked well enough while the machines were under development, it presented a serious problem for operators and service engineers in the field. Not only did they have to know where to find the logfiles (if they still existed) in the event of a problem, but how to make sense of the logs given the different formats. DSS was called in to bring some order to this chaos.

Upon observing that the subsystem controllers are connected via a LAN, DSS conceived of, proposed, designed and built what was to become the heart of a Collaborative Diagnostics System. The solution consisted of an ASP application running under IIS 4 with a SQLServer 7 database backend and built around the advanced DHTML and databinding capabilities in Internet Explorer 5.5. The CDS website provides logging, query and report facilities for the volumes of status information formerly stored on each of the subsystem controllers.

While a small intranet project wouldn't be very noteworthy in and of itself, this one required overcoming a number of technical issues and the use of a wide array of technologies including XML, C++/COM, DHTML, Javascript, VBScript, Windows Script Components, ADO and SQLDMO (SQLServer Distributed Management Objects).

To provide a common data format and a transport mechanism from the subsystem controllers to the database, we used the Microsoft XML component in ASP on the web server and encapsulated it in a dynamic link library usable by the subsystem controller software. We built the DLL using Microsoft Visual C++ 6.0 to provide efficient and robust component lifetime management. Communication was done via the XMLHTTPRequest interface. We used Microsoft Visual Basic and ADO between the ASP and the stored procedures in the database.

The database needed to be both easy to install and self-maintaining. We used SQLDMO from ASP to automate database creation, including all necessary tables, stored procedures, triggers and SQLServer Agent database backup and pruning jobs.

We used many, many other very cool techniques in other areas of the project.

DSS was presented with an interesting problem by a rising .COM in the San Diego area: they needed a generalized form filler for Netscape 4.x, one which didn't unload when Netscape navigated. As we had not yet learned to hate Netscape, we took it on; no one was there to say 'Danger, Will Robinson!'

The first thing anyone learns who has ever tried to write a piece of code to get and stay in-process with Netscape is that the plugin API is useless; they unload when Netscape navigates. The same is true of Java applets; they're only there on a given page. Seemingly, the only other way to get in-process with Netscape was to masquerade as one of its' own dynamic link libraries and provide passthrough functions for the dll's entrypoints. This method is dangerous and version-dependent. We found a better way! Nope; won't tell you; our lips...are sealed!

Once in-process to stay, the next problems are to know when Netscape navigates, and obtain the HTML of the page it's just navigated to. Now, Internet Explorer supports an extension called a Browser Helper Object which is essentially an event sink for things that happen in the browser, and a number of interfaces to actually control IE's behavior and appearance, obtain a pointer to a tree of DOM elements, and other very useful things; Not so, Netscape! It was just not built with programmability or extensibility in mind. While snooping through code obtained from the Mozilla open source initiative (which is all Netscape really is, branded, open source code), we discovered that Netscape supports only two interfaces, an antiquated automation interface and an (queue expression of horror here...) even more antiquated Dynamic Data Exchange interface, both of which combined barely provide the necessary functionality to monitor navigations and obtain the HTML for the URL it just navigated to. Bear in mind also that the client of automation and DDE interfaces is NOT expected to be the same process as the server!

So we had the URL, and we had the HTML... Now we needed to know if there were a form or forms anywhere on the page. Anyone who's done any amount of HTML for any length of time knows that browsers are incredibly forgiving of MONUMENTAL stupidities in the markup. At this point, we had to write a lightweight HTML parser, with all the complexities inherent in dealing with framesets and frames and moronic markup. In order to keep from dragging down Netscape's main thread (very EASY to do), this process needed to be multithreaded. Once we had located a form in the markup, we had to match it up with the actual Windows controls in Netscape's client area. In other words, there is nothing in the markup to link a tag denoting a form element with its' corresponding child window. The need to support frames meant that this code was of necessity recursive in nature, decending from top-level windows, enumerating children as we went until we had a match. Top this all off with the fact that we had to be able to terminate processing of a given URL in the event the user navigated away from the page in the middle of it.

When all is said and done, we were filling forms in Netscape with 90% accuracy; not too shabby for a piece of code Netscape didn't even know was there!

In summation, since we completed this project, we have assiduously lived by the simple rule: FRIENDS DON'T LET FRIENDS USE NETSCAPE!

The same San Diego .COM that presented us with the Netscape form filler problem had a form filler for Internet Explorer, implemented as a Browser Helper Object, or BHO, which they used to determine when the user navigated and scan the new URL for a form to be filled. As the company's business goals evolved, they decided they needed a Browser Bar to pop up from the bottom of the browser client area on navigations and top-level domain changes to notify the user of the security rating of the site navigated to.

A BHO is really nothing more than a sink for Internet Explorer events, implemented as a COM object. This COM object implements a connection point interface through which it receives those events. In order to implement their Browser Bar, a number of other events were required. Add to this that the Browser Bar itself is implemented as a COM object. Now we had two applications requiring access to browser events, and the possibility of two others beyond the Browser Bar and form filler, both running in their own processes.

DSS studied the issue, and determined that the smart thing to do was to factor the browser event sink into its' own object and allow applications needing access to events to subscribe to them selectively. This we did by reimplementing the BHO as a browser event multiplexer and exposing it via the COM Category Manager so that any application could use it simply by enumerating objects in the BrowserEventSink category, and then subscribing to the desired events. This made it possible for the company to abstract the form filler, browser bar, and the two other applications which needed different types of events from Internet Explorer into their own COM objects without ever having to deal with the specifics of hooking Internet Explorer events directly again.

We implemented the BHO entirely in Visual C++ 6.0 and ATL 3.0.

• 24-bit Windows color printer drivers in support of wide-format color inkjet printer/plotters. (We wrote one of the very first!)
• PC/Windows-based satellite data acquisition.
• Mixed-mode raster/vector Windows device drivers for laser engraving machines.
• Firmware for an "intelligent pig" (oil and natural gas pipeline inspection tool).

There is a high likelihood that we can help you, too; give us a call!