If you need Windows expertise, you've come to the right place! Our experience developing for Windows dates back to the late 1980's and Windows/286. We've been around a long time, and our breadth of Windows experience is extensive. Give your project a boost with our hard-earned skills!
We understand the internal underpinnings of Windows to a high degree and regularly read industry gurus such as Mark Russinovich, Jeffrey Richter, and Paul di Lascia. From them, we have learned to use Threading, File Mapping, Mutex, Critical Section, Event, WaitForInputIdle(), MsgWaitForMultipleObjects(), NTDLL, DDE, RAS, etc. to give your apps the edge. David's very first Windows assignment was debugging a crash in a third-party library which had accidentally unlocked a real-mode segment that Windows subsequently discarded! Early on, we learned that only by truly understanding Windows Internals can your app truly shine. Coupled with our formal education in Computer Engineering, our Windows skills are based on a firm foundation.
We are highly skilled in modifying behavior of foreign applications, for which source code is unavailable. We use SetWindowsHookEx(), SetWinEventHook(), and user mode API Hooking to inject our DLLs into foreign processes, subclass foreign windows, get notified of keystrokes and mouse buttons, and modify the behavior of standard Windows API's to enhance these applications. Of course tools like API Monitor, Wireshark, and SweetScape 010 make the reverse engineering easier.
For example, RegEditX adds a combobox to the standard RegEdit application. Other clients use Hooking extensively to implement security features or application virtualization. Hooking is a very powerful concept, and it is hard to do correctly. Hooking is also used by malware, but we use the same techniques to enhance applications in ways that benefit the end user.
We've written Tray Icons, Shell Extensions, ShellExecute hooks, WinLogon Notification Packages, and battled Fast User Switching gotchas.
We have implemented Vista Sidebar gadgets that incorporate ActiveX controls to supplement the standard Gadget API. For increased deployability, the ActiveX control doesn't require Admin privilege to be registered.
Qt has become our C++ framework of choice, now that MFC has been put out to pasture, and is a joy to use. It's API defines common sense and simplicity, in contrast to some of the dubious complexity appearing in Modern C++. David architected Ironkey Control Panel and Basis Sync using Qt Widgets, Signals and Slots, and to simulatneously ship Windows and Mac versions. Though it's open source and roots in Linux makes support for some modules spotty, and it's C++ heritage does not have quite as good tooling as .NET, Qt has a leading place in our toolbox.
In 2007, we saw .NET mature enough to become a legitimate technology to develop commercial applications. The performance and deployability had improved enough. We learned .NET with C++/CLI and still today use that and P/Invoke to interface to C/C++ code. Of course C# is the language of choice now. We have developed WinForms-based Office add-ins like ExcelFSM, WPF-based applications like Amicus Diagnostics Monitor, and ASP.NET (MVC) web applications.
Since 1995, we're deployed many, many apps written with MFC. Examples include: Logitech SetPoint, Linksys Control Utility, CDRCue. David has received his Microsoft MVP award for his contributions to the MFC newsgroup. Although not many new applications use MFC, we are kind of amazed that we still find use of it.
We use the WinInet, IPHelper, and Winsock API's to create connected apps. We've written small downloaders (100 KB) capable of downloading and installing any app or its prerequisites, as well as a WebUpdate facility that powers DCSoft applications.
We've used a variety of XML parsers. FirstObject Markup is our favorite; it's small, fast, easy to use, and embeddable.
We've written our own Public Key Encryption library using Crypto++ for DCSoft application licensing, as well as various items like a reusable hashing component with the Windows CryptoAPI.
We have successfully embedded the Lua script engine into an Internet client that interacts with popular browsers in unique ways; the actual behavior is customized with Lua scripts. The Lua engine also sees action in a custom debug logger that uses Lua scripts to filter debug messages prior to dumping them into the log. Lua makes it easy to expose 'C' functions which are callable from Lua scripts, making it very easy to move functionality from compiled, high performance 'C' code to easily modifiable Lua scripts, accessible by less skilled programmers.
It's not an overstatement to say we're fanatical about 100% clean Setup and Uninstall. Our favorite toolkit is Nullsoft. Some clients demand MSI Installs, and we have used the de-facto InstallShield for that; we hope to replace this with Advanced Installer.
We have used MFC's resource-only DLL's, Qt's great localization capabilities (we love that you can embed strings directly into the source code, and the localization tool will seemlessly replace them), and our homegrown XML and INI file driven localization (the localizations contained in these simple text files can be tested immediately, there is no intermediate compilation step required, making it much easier for remote localization teams to check their work).
For deployed applications complete with Windows Help (.chm) files, some of which include context-sensitive help.
GDI/GDI+ are old friends. We've implemented a translucent window framework supporting per-pixel translucency, used Memory DC's more times than we can count, struggled with Z-order issues (Windows does not truly support overlapping child controls), and ultimately developed two skin-based frameworks that draw all client and non-client areas with custom images. Skins should complement the user's choice of Themes, so we also know the Theme API.
As proven Windows Desktop developers, our journey to embrace the web started with baby steps in 2007. ASP.NET Classic, Visual WebGUI, and even LightSwitch offered a reassuring RAD design which sufficed for our first attempts at ERG TimeCard, an electronic timecard system. However, while these crossover technologies did let us get a website deployed, it became clear it would never be a first class web application, which more and more have the look and feel of the best desktop applications. To get to this point required giving up the familiar and embracing native web technologies.
It hasn't been easy, and we are still learning, but we have successfully created jQuery-based, interactive, data-driven web applications, and are now onto the cutting edge of Angular SPA apps.
Not yet. We are into Productivity and System Utilities. While the situation is rapidly improving, people do not regularly turn to tiny phones and touch-only tablets for these things. We are sure they will get there, just like Web apps have gotten there (as opposed to their early days of filling out CGI forms). When they do, we will offer solutions for them.
BTW, we have studied Xamarin and made a few trials apps, but this is not our priority today.