As before, avoiding UPX compression on the module is a magic fix. It’s particularly frustrating because the compression isn’t hiding anything, since the original module can be extracted using freely available code that they’re already using! Why should using a reversible executable packer be an instant black mark? Shouldn’t they be more worried about unknown or non-reversible packers? Grrr.

I’ve updated the driver installer with a UPX-less version. Hopefully the complete removal will mean an end to these virus scanner hassles.

Avira have since confirmed the issue as a false-positive, and will be fixing it in a future virus definition update. Thanks to zogzog for taking the time to report the original problem.

It’s also a stepping stone to possibly releasing the driver as open source in the future, which is something I’ve been asked to consider. Though at least one of the requests was just so the driver could be used by GNU GPL programs, which I didn’t think was a problem anyway. I’m unclear on whether the driver is seen as a library dependency or part of the OS, and whether it’s only a problem if the calling program is useless without the driver.

Another reason for postponing an open source release is the confusion about Vista x64 driver signing. A binary release for would need to be signed, effectively making the digital certificate another project dependency. Nobody would be willing to distribute their own certificate to allow an equivalent binary to be built, which seems to violate the GNU GPL. Or am I missing something?

Unfortunately, it’s not a simple matter of upgrading the project files and building new versions. The old C run-time DLL (MSVCRT.DLL) is available on Win95 (with IE4 installed) and later, but the new version (MSVCR80.DLL) is shipped only with Vista. It can be installed on older Win32 platforms, but only by using official vcredist_*.exe installers, which total almost 6MB for both x86 and x64 version. Ouch.

Fortunately, the run-time library can still be linked statically to remove the DLL requirement. Though that becomes less practical when done for many different modules in the same project. Another option is to leave out the run-time library altogether, though that’s really only suitable for small programs, or those specifically written to avoid it. Most of the missing functionality is available through compiler intrinsics and directly through the Win32 API (including string functions such as lstrlen, lstrcpy, etc.).

Unless we completely omit the CRT there’s yet another problem. VS2005 compiled binaries don’t work on Win95 or NT4, as the CRT startup code uses API functions (including IsDebuggerPresent) that don’t exist on those older versions of Windows. Attempting to launch the program gives a Windows loader error about the missing export, and the process is terminated.

There is a work-around for this, but it’s not particularly nice. It involves including two CRT source modules in the project, and using an alternative implementation of the missing function. The linker will then use these versions instead of the ones found in the static CRT library, so our module is 95/NT4 compatible once more.

I do now plan to use VS2005 where possible, with the approach depending on the size of project. SimCoupe has no option but to use the CRT, so I’ll link in the static version and use the Win95/NT4 work-around for backwards compatibility. SamDisk targets only Windows 2000 and later, but is designed to report a helpful message if run on older Windows versions. It doesn’t (currently) use the CRT at all, so using the new compiler is not an issue.

Googling for other online scanners I came across a handy site to check it more thoroughly. Simply upload your file and have it checked by around 30 commercial scanning engines, with near-live results (if there aren’t too many queued jobs).

I submitted the latest FdInstall.exe, and as expected AntiVir was the only engine to consider it infected, so I fired off an e-mail to report the false-positive. However… eSafe, Fortinet and Panda considered the file to be ‘suspicious’. The Additional Information section at the bottom reported the UPX packer, and that the file had a binary resource.

Just to compare, I submitted the old FdInstall.exe for scanning. No virus detected, but both eSafe and Fortinet still considered it suspicious due to the use of UPX.

I rebuilt FdInstall.exe without compressing the header, and resubmitted it for scanning. Result: completely clean! One of the scanners still reported the presence of UPX and binary resources, but it wasn’t enough to show as suspicious.

It seems that many scanning engines consider compressed executables to be a worry, as though they’re trying to hide something. I’m surprised this is still the case when using well-known packers like UPX, which can be unpacked using freely available programs and code.

I’ve now updated the FdInstall.exe on my site with an uncompressed version. It adds a whopping 11% (11K) to the installer size, but it’s well worth it to avoids further false-positives.

Hats off to Fortinet for their comprehensive response to my query in less than an hour. The file is white-listed in their latest definitions. Avira have also confirmed the file is clean, and plan to fix the issue in a future definition update.

1. Avoiding touching the primary display surface

   SimCoupe uses a video overlay surface for the SAM display by default, which gives the best performance on old video cards. For this I must determine a colour-key value where overlay pixels should show through to the display, like green-screen special effects used on TV. This meant locking the primary surface to peek a pixel value, and that’s something Vista wasn’t happy with me doing.

   In previous versions of Windows the primary display surface was what you saw on your screen, and where most objects were drawn directly. Vista’s Aero interface uses off-screen compositing for its fancy scaling and transparency effects. The visible display is managed by the compositing engine and is off-limits to direct manipulation. Any attempts to do so disables the Desktop Window Manager (DWM), returning the display to a compatibility mode. As part of this it also rather unhelpfully reports: “This program is not compatible with Windows“!

   Video card overlays don’t really fit into the new composite world anyway. They can be scaled, but they can’t be rotated or skewed, and don’t support transparency. The DWM can’t make any use of them, so there’s little point in us trying to use them – problem solved!

   SimCoupe no longer attempts to create a video overlay on Vista, and to avoid any confusion I also grey the setting in the options used to toggle it on and off.

2. Avoid querying the capabilities of the primary display surface

   This is related to the first issue, but shouldn’t have been a problem at all. I found that simply querying the capabilities of the primary surface (using GetSurfaceDesc()) was enough to disable the DWM.

   This was confirmed to be a Windows bug in beta 1, scheduled to be fixed in beta 2. In the meantime I changed my code to work around it, using the required capabilities from the back surface instead.

3. Double-checking the main window is the correct size

   The partial scanlines on the boot screen were showing a banding effect, which happens if the main window is resized to non-multiple of the natural display size. Further investigation showed the main window size (as set using AdjustWindowRect()) was slightly too small.

   This was yet another Windows bug, and not one I found documented anywhere! The size calculations didn’t seem to be including all the extra window decoration and the larger Vista borders were throwing it out. This just required a second size adjustment in SimCoupe if the first one was found to be wrong. This problem affected other programs that required an exact display size, which was mainly other emulators.

These changes were the bare minimum needed to run the program correctly under Vista. True Vista support will require additional changes, almost all related to the tightened security model. More about those in a future update.