Reusable parts of the code

(In progress)

Libwdi implements reusable solutions to the following problems:

Creating a Windows application that uses the exact same codebase for MSVC, WDK/DDK, MinGW and cygwin

3 sets of files are being used for that:

• For MinGW/cygwin, autotools scripts, that automatically generate the config.h and Makefiles used during compilation
• For MSVC/Visual Studio, a regular set of project files, depending on the manually edited /msvc/config.h
• For DDK/WDK, a batch script, depending on the manually edited /msvc/config.h

File(s): (MinGW/cygwin)	​/autogen.sh, ​/configure.ac, ​/Makefile.am, ​/libwdi/Makefile.am, ​/examples/Makefile.am
File(s): (MSVC)	*.sln, *.vcproj
File(s): (DDK)	​/ddk_build.cmd, *_sources

Creating a Windows application that is compatible with all versions of Windows from 2000

The trick is to use MinGW as the compiler along with the "-DWINVER=0x500" flag.

File(s):	​/configure.ac

Creating a Windows GUI application that use the latest Windows visual enhancements (Aero Glass look on Vista/Windows? 7 for instance), even if compiled from MinGW/cygwin

The default from all compilers, including Microsoft ones, is NOT to use the default look and feel from each platform, but to force the XP/2k one.
To enable a more up to date look and feel in standard GUI applications, you need to manually embed the ​common-controls manifest, as well as include <commctrl.h> in your source.

• For MSVC projects, just adding the manifest to your resources files in the project will do.
  
• For DDK/WDK, as documented ​here, you need to add an SXS_APPLICATION_MANIFEST line with the name of your manifest
• For MinGW/cywgin, it's a bit more tricky. What you want to do is link to the manifest in your .rc file, with something like CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "common_controls.manifest". The problem is that, this needs to appear at the end, else MinGW will ignore it, and you want to be able to edit your .rc in Visual Studio, without destroying the additional data you add to the .rc. The solution is to have the following at the beginning of your .rc

  3 TEXTINCLUDE 
  BEGIN
      "
  "
      "// Must reference a manifest for visual styles
  "
      "// Oh, and it must happen at the end, or MinGW will ignore it!
  "
      "#if defined(__GNUC__)
  "
      "CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST ""common_controls.manifest""
  "
      "#endif
  "
      ""
  END
  

  And of course, you need a matching section at the end.

File(s):	​common-controls manifest, ​example DDK sources (Zadig), ​example MinGW manifest from .rc (Zadig)

Creating Windows application from MSVC, WDK/DDK, MinGW and cygwin that require UAC elevation, even if compiled from MinGW/cygwin

Running a 32 or 64 bit version of an embedded application depending on the platform

Compiling an project for both 32 and 64 bit

Folder selection / File open/save Windows dialogs that uses to new enhanced Vista/Windows? 7 controls when available (and default to the regular version on older platforms)

USB hotplug detection

USB device listing, including driverless devices

USB driver installation

Compiling libconfig for all of MSVC/DDK/MinGW/cygwin and for both 32 and 64 bit

Bumping the executable/DLL version number automatically using git tags

If you are using versioning in .rc files, it would obviously be nice to bump the version minor according to major commits that you push into your git repository.
In libwdi's case, we use incremental git tags to identify minor versions ("w123", "w124", ...) and we use the numeric part of that tag as the minor for the exe/DLL (eg. "1, 0, 0, 123"). The shell script linked below will:

1. retrieve and increment the current git tag
2. update the version in the .rc files using sed
3. commit the changes in git Additionally, the script also updates the USB VID -> Vendor ID string source (see below).

File(s):	​/bump.sh

Windows GUI MouseOver/Hover Tooltip

A simple call that creates and displays a tooltip when hovering over a dialog item (eg. text field)

File(s):	​/examples/zadig_stdlg.c -> create_tooltip()

Sed script to convert the USB VIDs into a C source that will resolve then to Vendor ID strings

In our applications, this is used to display the Vendor name of a specific USB device when hovering over the VID hex string.
​http://www.linux-usb.org/usb.ids does a great job at maintaining known Vendor IDs, but the list still needs to be converted into something ​a bit more C-friendly. For that purpose we built a shell script that, when executed:

1. uses wget to retrieve the latest version of the list
2. uses sed to convert t to a C source with a function call that will take a VID and return the matching string.

File(s):	​/libwdi/vid_data.sh

UTF-8 wrappers to Wide Char (UTF-16) MS API

This is what Microsoft should have done a long time ago. Along with the A (Ansi) and W (WideChar/Unicode) versions of an API call, it should have implemented U (UTF-8) as well, as it usually makes more sense to use UTF-8 than UTF-16 in an application, especially one that is not localized but still wants to support localized user input. For instance, wouldn't it be nice if there existed a ​CreateFile version that accepted an UTF-8 char * for the file name?
Our UTF-8 wrapper API provides just that, for a selected subset of the Windows API calls, with:

• FormatMessage (FormatMessageU)
• SendMessage (SendMessageLU: lParam as UTF-8)
• SHGetPathFromIDList (SHGetPathFromIDListU)
• GetWindowText/SetWindowText (GetWindowTextU/SetWindowTextU)
• GetWindowTextLength (GetWindowTextLengthU)
• GetDlgItemText/SetDlgItemText (GetDlgItemTextU/SetDlgItemTextU)
• GetTextExtentPoint (GetTextExtentPointU)
• CreateFile (CreateFileU)
• GetCurrentDirectory/GetFullPathName/GetFileAttributes (GetCurrentDirectoryU/GetFullPathNameU/GetFileAttributesU)
• SHCreateDirectoryEx (SHCreateDirectoryExU)
• ShellExecuteEx/CreateProcess (ShellExecuteExU/CreateProcessU)
• GetOpenFileName/GetSaveFileName (GetOpenSaveFileNameU)
• UpdateDriverForPlugAndPlayDevices/SetupCopyOEMInf (UpdateDriverForPlugAndPlayDevicesU/SetupCopyOEMInfU)

File(s):	​/libwdi/msapi_utf8.h

etc.