Breaking news on Devil Mountain Software

Image of my system’s Task Manager, during a typical session with Outlook, several IE tabs and Windows Media Center (watching NASCAR via my Hauppauge card.)

Since my last post, the whirlpool that is Devil Mountain Software/XPSNet/Randall Kennedy has become more turbulent still.  The other shoes have dropped furiously in true Iraqi fashion;  President Bush was never so beleaguered.

Randall Kennedy has been removed from InfoWorld:

Devil Mountain Software is a business Kennedy established that specializes in the analysis of Windows performance data. There is no Craig Barth, and Kennedy has stated that this fabrication was a misguided effort to separate himself (or more accurately, his InfoWorld blogger persona) from his Devil Mountain Software business.

Integrity and honesty are core to InfoWorld’s mission of service to IT professionals, and we view Kennedy’s actions as a serious breach of trust. As a result, he will no longer be a contributor to InfoWorld, and we have removed his blog from this site.

It’s the right thing to do.  InfoWorld is polite enough to say that they appreciate his performance insights.  I don’t.  I can never trust him again.  That leaves Bob Lewis as the only guy I can trust from that site.

ZDNet just pushed up an article originally scheduled for Monday publication, “Why We Don’t Trust Devil Mountain Software (And Neither Should You)”, due to Randall’s self-revelation.  This article confirms a number of my suspicions.

On the software:

As for the software itself, the installer is not digitally signed. It installs two Windows services: Cfwtracker.exe and Cfwupload.exe. The tracker program adds information at regular intervals to a database (in Microsoft Access format) stored in the user profile of the currently logged-on user. The upload module periodically sends that data to a remote server.

I’d started analyzing the MSI downloadable, in which 7-Zip tells me there are two binaries.  I had been about to run Orca, Microsoft’s install tool on the file when this story broke.

XPNet claims to use an SSL connection to send its data from clients.  Not true:

We found this claim to be untrue. In our tests, using machines in widely separated geographic locations, the DMS software made simple (non-secure) HTTP connections on port 80, transmitting data to a server at IP address 66.115.28.220. The IP block at 66.115.28.* has DNS A records that point to devilmount.com, xpnet.com, and csaresearch.com. All of those companies are registered to Devil Mountain Software and include the name Randall C. Kennedy in the registration information.

When we attempted to use a browser to make a secure connection to https://xpnet.com, we received two certificate errors. The certificate associated with the site, originally issued by Equifax Secure Global eBusiness, had been issued to a different domain, csaresearch.com. In addition, the certificate had expired on September 7, 2009.

 

And their privacy policy?  Honored in the breach:

XPNet.com has no privacy policy on its site. Its license agreement contains no privacy information whatsoever. InfoWorld, however, made a prominent claim about privacy on its page that, until this weekend, offered the Windows Sentinel program:

Performance data is uploaded to the exo.performance.network, where your most recent one week of data is stored for viewing and analysis. Performance data will be shared in aggregate only and never identified as linked to your individual account.

 

We saw how well that was honored.

Dignan’s article goes on to talk about Randall’s claims that his software was used at several large Wall Street firms, including Morgan Stanley and Credit Suisse.  Why would they use a small third-party company to provide this service? 

I should note that the only way for a user to get performance figures with ClarityNet is through the XPNet web site.  There are no local gauges for the user to query.  Firms like Morgan Stanley have large IT operations.  They won’t rely on an outside website when Microsoft makes their performance data readily available to internal analysts.  Morgan Stanley’s IT (or as it happens, IBM Global Services) is truly responsible for their client machines and they know it.  They won’t knowingly enter into an agreement with XPNet.  (With all of IBM’s resources, they will hire a two bit operation for analysis?)

If they have, Mr. Kennedy has many more problems than just being fired from InfoWorld.  This isn’t over for him.

But hopefully, it’s over for me.  I don’t want to make another pundit post again today.

UPDATE:  It’s not over for Paul Thurrott.   No doubt more people will weigh in on Monday, like Ed Bott and others.

The amazing aspect is, on Randall’s exo.blog, he’s been backpedaling in the comments, kissing up to Mr. Bright and claiming his data didn’t really show disk thrashing and so forth.  Mr. Kennedy,

Stop digging that hole.

I hope those financial customers of his can afford counsel and seek it out.  I would be delighted to see Randall get those cease-and-desist letters for once.


Conflict of interest in royal catfight over Windows 7 memory performance?

I haven’t made an IT Punditry post in a long time.  I haven’t missed doing that;    I am too cynical of the IT press to enjoy punditry;  most of the reporters want to be Morley Safer or Bob Woodward, but aren’t and won’t be.  Others just cynically latch on to the latest factoid that can be spun to get page views. 

The latest tempest in the IT press involves a researcher who claims Windows 7 uses more memory than previous versions, “alarmingly low memory”Ars Technica’s Peter Bright, and Computerworld have reported on this and the comments have been furious.

The claims and counterclaims center around a feature of Windows 7 called Superfetch.  With this feature, Windows extends the prefetch feature in XP so that it aggressively caches programs in memory that are most commonly called up by the user, based on his or her usage patterns.

The question has been whether XPNet’s performance metrics have taken this into account. 

The performance tool, DMS ClarityNet, works, as far as I know, by taking certain memory-related Windows performance counters, sending them to their server, combining them into a proprietary performance figure that is calculated and displayed on a web-site widget.

I say, “as far as I know”, for good reason.  Though I do remember trying out the program a few months before this controversy—I’m still listed as a customer on their website, I don’t recall if I kept it on my machine.  I’m always trying out various admin and performance software to evaluate for myself and SATV.  I seem to recall I didn’t like the tool and uninstalled it, for specific reasons I can’t remember.  I try and discard many programs if they don’t work or they don’t do what I thought they’d do or they’re unsuitable in some other way.

Unfortunately for XPNet, I’ve found a good reason never to try the program again:  Mr. Bright’s personal machine’s performance data was divulged!

But Mr. Bright didn’t stop at simply attacking our intelligence. He took the additional step of actually contributing data from his own test PC, the one he claims shows the lie in our data. And it was at this point that the story got interesting.

You see, by connecting his PC to our network, he made his raw system metrics data available to us. And after reviewing this data, it became clear why our System Monitor widget flagged his system as being low on memory.

It’s because it’s true.

A look at the Committed Bytes counter values collected from his PC…

What XPNet just did here is a Game Over by anyone’s standard of ethics.

Whatever reason I have had to try their client has totally evaporated.

There are real companies like Pingdom that monitor connectivity, uptime and availability for their customers.  Could one imagine what would happen if they made a blog post saying, “Oh, we think IIS sucks.  Here’s a stupid customer of ours who uses it.  See how bad their availability is?!”—and they named the customer!

It would be devastating, not least to Pingdom.  They would be out of business.

Devil Mountain Software, according to their business model, analyzes performance for financial-based clients. 

They have no reason to break out their data by the individual machines involved.

None at all.

If I were a client of theirs I would be an ex-client.  It shouldn’t even be possible for that exo.net blogger to even have non-aggregated individual data!

And they have financial customers?!?

In my first draft of this blog post, I was going to explain how I thought the metrics were flawed and how I have not seen the performance problems that DMS claims either on my personal network or SATV’s.

But with this development, it is beyond technical.  Any technical points I could make are now irrelevant.  I have to consider the DMS ClarityNet client as malware, on the same level as those fake antivirus programs that cause so much grief.  Or the Sony CD rootkit.

I have no compunctions about reverse-engineering this client to find out what exactly it sends.  I’m sure someone will if I don’t.

More astonishing, and what finally made me post this, is this morning’s post from Exo.Net, calling out the comment of one person who agreed with them and seeking to end the discussion on that note.

Past posts were signed “Performance Team”.  This one:  “Randall C. Kennedy”.

The same Randall Kennedy who writes for InfoWorld?  The person behind Save XP?

Houston, we have a problem…


16-Bit Installer Support in Windows 64

Followup to my TIE Fighter post.  I was not wrong about 16-bit installer support.  From MSDN: 

…For older applications that use a 16-bit stub to launch a 32-bit installation engine, 64-bit Windows recognizes specific 16-bit installer programs and substitutes a ported 32-bit version.

16-bit DOS, Windows, or OS/2 applications often use a 16-bit stub to check the machine type, then launch a 32-bit installation engine to actually perform the installation. To enable installation of applications that use this technique, 64-bit Windows substitutes 32-bit versions for the following 16-bit installer programs:

Microsoft Setup for Windows 1.2

Microsoft Setup for Windows 2.6

Microsoft Setup for Windows 3.0

Microsoft Setup for Windows 3.01

InstallShield 5.x

The registry key that defines these installer shims is at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NTVdm64.  The list, according to Microsoft, cannot be extended.

I was certain that TIE Fighter used InstallShield (as did the majority of apps in the era) but what version?

I used Sysinternals’ Strings utility on the setup file (on the install CD, \INSTALL\SETUP.EXE).  And got this (redacted a bit):

CompanyName
InstallShield Corporation, Inc.
FileDescription
Setup Launcher ( SETUP.EXE) 
FileVersion
3.00.111.0
LegalCopyright
Copyright InstallShield Corporation, Inc. 1990-1996 Phone : (847) 240-9111 
ProductName
InstallShield
ProductVersion
3.00.111.0

That is it.  The installer is version 3.0 and the shim only works with 5.x.   I noted elsewhere in the Strings output, clues as to the real age of the installer at the time—there are references to MIPS and Alpha architectures, which have not been in Windows for a very long time (MIPS was discontinued around the time of NT4 and Alpha never made it past Windows 2000 before being assimilated by Compaq.)

So much for that.


The Force is With Me! TIE Fighter 95 on Windows 7 x64

I’ve mentioned before how I was looking forward to trying many of my old games on Windows 7.  I was delighted to learn I could get my most favorite game working, Star Wars: TIE Fighter.  This game was released for DOS, when I first played it, and then on a CD collection for Windows 95, when I played it some more.

TIE Fighter wouldn’t work on Windows XP for anything I tried.   When Lucasarts said that the game would never work on XP and would never be fixed, I figured that was it.   I was crushed.  I couldn’t bring myself to get rid of the install CD.  As with Duke Nukem, I had hoped someday I’d get it going on a leftover copy of Windows 98.

I knew, over the years, Microsoft was releasing new application shims for XP, and I had intended to try the Application Compatibility Toolkit (ACT).  I never got to it.

In 2004, someone did!   Craig Perry created a compatibility shim for both TIE Fighter and X-WingIt’s on the Lucasfiles web site.  (UPDATE:  Use my shim instead:  xwtie95v2.zip)   It doesn’t feel right for me to use it unless I can understand how it works—I should have figured this out in the first place!  I’m stupid!

Quoting Microsoft, the application compatibility infrastructure works like this:

You can circumvent the compatibility problem by using the Compatibility Fix infrastructure to target a specific application fix, for a particular application (and typically for particular versions of that application). The Compatibility Fix infrastructure implements a form of application programming interface (API) hooking, which uses the inherent linking ability of the APIs to redirect from Windows code directly to alternative code that constitutes the compatibility fix. The Windows Portable Executable File Format includes a number of headers that contain the data directories that are used to provide a layer of indirection between the application and the linked file.

There are many compatibility fixes, or shims, exposed in the ACT, most of which are not in the standard compatibility mode UI that you see in the properties tab of a shortcut or an EXE file.   The shims for an application (which may cover more than one executable) are bundled into a .SDB file and placed in the Windows directory \Windows\AppCompat.  Here is the SDB file for TIE Fighter, XWTIE95.SDB:

After installing the ACT, and running Compatibility Administrator on this SDB, we can see this fix applies to two applications, Star Wars TIE Fighter 95, and X-Wing 95.  The right pane displays specific settings for TIE Fighter.   There are shims for two programs, TIE95.EXE and TIESTART.EXE.  (X-Wing 95 is similar, so I won’t describe that application.)

TIESTART, the game launcher, has two fixes applied, CorrectFilePaths, and SingleProcAffinity.  The latter is a common fix—it tells Windows to keep the application on one processor.  Until very recently, there were almost no home PC’s with multiple processors;  XP Home, the host for most modern PC games was only licensed for one processor and in any event you could not buy, let alone afford, a multi-processor board that supported a 3D video card, sound or even game controllers (analog, in those days.)   Almost all PC games are single-processor;  there may be some newer games that now take advantage of multicore CPU’s, but since I seldom run contemporary (read: expensive) games, I wouldn’t know.

CorrectFilePaths fixes the Windows path for the executable so that it sees Windows 95 file paths.

TIE95, the main executable, has the most important fixes as far as the game is concerned.  In addition to SingleProcAffinity, it has EmulateCDFS;  this allows Windows 95 apps to see  the CD (now DVD) drive in the way they expect;  there were many changes to the CD filesystem drivers between 9x and XP.  But two more fixes really make this game work.

IgnoreException instructs Windows to ignore specific runtime exceptions.  In TIE Fighter’s case it is set to READ_ACCESS_VIOLATION.  The game would often crash when launched, and this fixes that without affecting the rest of the executable too much.

MapMemoryB0000 is the most important fix for the game.  Microsoft:

Some applications require that a block of memory be mapped at B0000 as it is on Windows 9x. This compatibility fix will map a block of memory at the B0000 address for the application. Applies to: Windows 95, Windows 98.

Without this fix, it was impossible to run TIE Fighter with 3D hardware.  Fix this and the game runs.

Am I all set?  Not quite.  I run 64-bit Windows (7 Ultimate).  TIE Fighter and many other Windows games use a 16-bit installer which won’t work in 64.  Windows has code for some 16-bit installers but not this one.

Fortunately, many games, unlike most applications, don’t have complicated installations:  Just a directory copied off the install CD or uncompressed from packages into \Program Files, a Start Menu shortcut, and installation of redistributables like DirectX and other common libraries.  Many games never use the Windows registry and store their configuration data separately from Windows.

Easier still, a guy in Austria has made MSI packagers for the Star Wars series;  all you need to do is get game patches and the Microsoft Visual C++ 2008 redistributables, plus the original CD, and copy all the files to a directory to slipstream a new install CD.   Markus Egger’s site has install patches for TIE Fighter, and all of the Laurence Holland games (X-Wing, TIE Fighter, X-Wing Vs. TIE Fighter and X-Wing Alliance.  Did I mention I own all of these?!)

The Totally Games forum has tips on getting this series of games to work on modern Windows.

I’ve successfully run TIE Fighter and the other games, though all of them have their individual compatibility quirks, some of which are fixable, others not.  Many newer video cards don’t support older video modes (320×200) correctly, which is a problem for a good number of old games.  X-Wing Alliance is notorious for distorted fonts (there is a replacement fonts package available.)

Amazingly, TIE Fighter and the other Star Wars games work and play great with the XBox controller—the games even default to useable control bindings even though gamepads were not originally made for the PC, let alone with analog controls like modern pads.  (I have not bought or used a traditional joystick in years.)

This is already a long post, so I’ll just close with one last screenshot:

In this training mission,  my commanding officer is about to have a really bad day.  It’s actually one of the mission goals that you take over for your flight leader if he’s taken out of the action.  The game doesn’t say exactly how that’s supposed to happen…then again, it’s just a regular day in the Imperial Navy.

Happy Star Wars gaming!

(UPDATE:  Once again, I’ve revised the SDB file.  Get it here.  And read my updated post.)


Making system backup images in Vista Business

After nearly eight months using Windows 7 I am beginning to forget how to do things in Vista.  At SATV, we are upgrading our new Dell workstations to Win7.  As is good practice I need to make an image backup of each workstation before the update. 

I’ve chosen to update rather than clean install since the machines are relatively new and in good health so far as Windows is concerned.  But I still need to make that image backup in case it blows up.

If you go by the Backup and Restore UI in Vista it isn’t obvious how to make a image, and it may seem that it isn’t possible.  But I live on the command line and it is possible.

WBADMIN is what you want:

wbadmin start backup –allCritical –vssFull –backuptarget: <location>

On our network, it took six hours to backup one workstation to a network share.  A caveat I have to keep in mind is that the Windows recovery process will not take an image from a share so if it does blow up, I will need to copy that image to an external hard disk and take the HD to the affected computer.

One computer is running Seven without incident;  five more to go.