Untitled Document
View RSS Feed

The ShipRush Product Management Blog

Backwards Compatibility Religion, Microsoft, Printing, and You

Rating: 4 votes, 4.25 average.
Name:  Microsoft_logo.png
Views: 2838
Size:  3.6 KB

Techie alert: This article is %100 technical plumbing talk. If you are just interested in ShipRush, skip this one.

A fun part of tech is discovery. Every day brings new technologies, approaches, algorithms, and ways to mesh technology with our human needs. Most days, I learn several new things. (Yet! After working with computers since childhood in the 70’s).

Discoveries put a smile on my face. At the end of the day, the sense of progress is refreshing.

It is rare, thankfully, that darkness is found. Only once or twice a year do we discover something that makes us cringe. When we find something that is both bad and has user impact, we often say “Are we the only ones with this problem?”

Here is one that has small impact today. It is growing. Tomorrow the impact will be larger.

The essence of the problem is that Microsoft “Lost the Backwards Compatibility Religion” (see Joel Spolsky, June 2004 http://www.joelonsoftware.com/articles/APIWar.html).

Every app has its primary mission. Amazon's mission is to let you buy stuff. PayPal's mission is to let you send or receive money. Facebook's mission is to keep you out of the sun. ShipRush has a primary mission of printing. Labels, packing lists, customs forms. Folks use ShipRush for one reason: To print. To do this, we work a lot with Win32 printing API’s. We are, shall we say, rather intimate with the Win32 printing system. No, printing is not glorious. Yes, it may have negative impact in terms of the environment. But printing is why people need ShipRush. And ShipRush feeds our children.

And our pets.

So we care.

Name:  fedex_thermal-2_small.jpg
Views: 873
Size:  4.3 KB

Better (worse?), we use parts of the printing API’s that many folks avoid. For example, we know how to “speak the printer’s language” and send commands directly to certain printers (Zebra GK420 anyone?). In the warehouse and parcel shipping segment, it is very normal to do this. Doing normal Win32 hDC drawing is not appropriate when using these printers.

And the sun did shine. In its season, the rain did fall. The kingdom prospered.

Until Windows 2008 Server arrived.

Actually, everything continued to prosper, even with Windows 2008. But a few users noticed a chink in the castle wall. Where Win32 printing had been stable and reliable for years, suddenly a certain special combination spelled doom.

< /EndOfFigurativeLanguage >

Here is the story:

When Remote Desktop (aka rdesktop aka rdp) is used, and the host system is either Windows 2008 Server or Windows v7, a new Microsoft technology is used for printing. This technology is called “QuickPrint” and generally, it rocks.

Unless you do something called RAW printing.

Then QuickPrint fails to rock. In fact, it fails to do anything. Nothing prints.

Zilch. Zippo. Nada.

But (conveniently!) the API calls return “success.” (In other words: Unless you are paying attention, and actually expect something to come out of a physical printer, you will never know anything is wrong. Joy!)

There are only a handful of developers who need to do RAW printing. A lot of them (er, us) are working with printers from Zebra (and Eltron before it). We speak to the printers using a stream of raw printer commands in the EPL and ZPL printer languages. We work at companies like FedEx (makers of FedEx Ship Manager software), UPS (makers of WorldShip software), Intuit (who have built-in UPS and FedEx shipping technology in QuickBooks), Kewill (high end multi-carrier shipping software), Pitney Bowes (ditto), Z-Firm (maker of ShipRush), and others.

We aren’t the only ones. Certain forms-processing application (think mortgage documents) often function by sending a form to the printer, and then merging in data on the printer itself. (This is usually done with the PCL printer language.)

These developers (and I am sure others I haven’t thought of), depend on a specific sequence of Win32 api calls. To summarize in pseudo-code, these calls are:

-  OutputFile = nil;
-  DataType = 'RAW';
(If you want to see a full implementation of how to do RAW printing, please see http://support.microsoft.com/kb/138594/EN-US/ )

These calls work perfectly, unless QuickPrint is in use. Then the calls themselves succeed (as seen from the API caller's perspective), but no data is sent to the printer if the setup is as follows:

  1. The user is using rdesktop/rdp to access a Win7/Win2008 host
  2. The printing software is running on the host
  3. The printer is attached to the local PC
  4. The rdesktop connection uses the "local resource" redirection to allow the host session to access the local printer

(This configuration is, in fact, THE normal way to use Terminal Server to print when using a Zebra printer.)

Note that if the host system is a Windows 2003 server, there is no problem and everything works fine.

So what should you do?

  1. You could avoid Windows 2008 server
  2. You can change the Group Policy to disable Easyprint
  3. You can put your Zebra printer on the network, and do a ton of policy and VPN setup to make it visible to the Terminal Server host
  4. You can ask Microsoft to please fully enable RAW printing in EasyPrint (the Microsoft support incident we submitted is [REG:110050457489818])
  5. Vote for this entry on Slashdot (press the little "+" symbol and/or post a response): http://slashdot.org/submission/14309...-Compatibility
  6. You can tell us some new information (that we can add to our ZF Case 22818)
  7. Pray that Microsoft rejoin the Backwards Compatibility Religion

I don't like #1.

Sysadmins don't like #2.

Network admins (and users) don't like #3.

I tried #4. Microsoft acknowledges the issue, but the support team said they couldn't escalate it unless we have a Premier Support account with Microsoft (cost: $50,000 per year).

#5 is in your hands.

We are always open for #6. Talk to us on the forums.

#7 is not how I normally work. But for now, it is all I have.

I would put this recording here... but it does not seem to be publicly available. Here are the lyrics. Hum it in your head...


Updated 12-31-2010 at 01:14 PM by Rafael Zimberoff

Software Development & Technology