This article is more than 1 year old
Why burning CDs on Windows really, really sucks
Roxio destined for the rocks
Your correspondent suggests that the Windows XP driver model has changed in some way from Windows 2000 which has caused EasyCD 4.x to break. I really don't think this is true.
Because device drivers all run in kernel mode, it's perfectly possible for them to call into known-but-undocumented entry points, or to simply
call the code at a particular address. The problem with calling into a function when you don't know the proper semantics of the call is that your idea of what the call is supposed to do may differ from Microsoft's
own idea of the call's purpose.
The user-mode application writer can't easily do this - most Windows NT/2000/XP API services are implemented either in kernel mode or in separate server processes. It's very difficult to get the kernel or the
server process to do something other than that advertised (if the function is actually implemented in the library-interface DLLs, such as Kernel32.dll or User32.dll, it's possible to call into a non-advertised
entry point and get some additional behaviour).
Between operating system revisions (and, yes, between service packs) the implementation of certain documented functions is changed (to correct bugs or to improve performance, or to add new features used by other
functions). This often leads to modifications being made to the undocumented functions used in the implementation of the documented functions. The undocumented functions may be renamed, moved in the image, or removed altogether. When this happens, an application or
driver calling into an undocumented function will stop working.
The reason this kind of thing occurs is because some developers don't seem to care about keeping their code working across different platforms, and are somewhat lazy or in search of too much space efficiency. The usual situation is that a documented function does
nearly-but-not-quite what is wanted, and instead of working out the algorithm and writing the whole routine again, and any undocumented routines it calls, but modifying them slightly, the developer calls into
the undocumented functions or calls into the documented function, but not at its proper entry point. When the undocumented function changes, or the implementation of the documented function changes, this technique
breaks. And when it breaks, people blame Microsoft.
Sometimes the undocumented functions actually appear in the export tables of a DLL, or in the header files supplied with the SDK or DDK. Just because you know
the name, doesn't necessarily mean you know what it does.
This kind of thing happened fairly recently with some Personal Firewall software - BlackICE broke when Microsoft released Windows 2000 Service Pack 1, because they were hooking pieces of the TCP/IP stack, which
hadn't been designed to accommodate calls into that stack at that point.
Microsoft's own application programmers have themselves been known to do this on many occasions - see for example the number of different versions of Word that appear in the Application Compatibility information. The irony is that when Microsoft applications call
undocumented functions in Windows, the Windows team still move or change these functions.
So I suspect that what's happened is that Roxio's drivers try to hook into the CD device drivers in a way that the CD drivers weren't intended to be used. Microsoft have changed something in the implementation, and it's caused the Roxio drivers to break.
The reason Microsoft can fix things like this with the Application Compatibility tools is that they've added some flags to the operating system which can be looked up in the registry when a driver or application is loaded. This then causes the faulty calls to be
redirected to a function which performs the operation that the program expects to be performed. I believe it can also patch the application code in cases of jumping to the wrong location. This kind of thing shouldn't be necessary, and isn't - so long as the applications are
written correctly to the SDK, and the drivers are written to the correct DDK. I'm distinctly grateful that I don't have to recompile or reobtain
all my drivers when the operating system revision changes - c.f. Linux.
I note that most of the antivirus programs, which have to hook into the file system drivers and storage device drivers, work flawlessly across Windows NT, Windows 2000 and Windows XP.
This is incidentally why I'm against open source - if the source is open, it causes developers to go hunting for implementation they can borrow, rather than calling into the published APIs. It's also why I'm against the 'Rogue States' wanting to open-source Internet Explorer - it will produce less compatible applications, not more compatible ones.
And Microsoft will have a headache three or four times larger in needing to keep track of what applications call into which functions, which will probably mean that nootherwise unneeded functions will be removed
from the codebase, or modified for new functionality, meaning that IE will bloat up in size as well (yes, all right - even more than it already is...)
Your article correctly describes the chicken and the egg confusion of bundling Roxio software with hardware. It's cheaper for Plextor, TDK, etc., to continue to bundle older versions of EZ(Crap)CD Creator than to
bundle the newest version for which Roxio charges a higher bundling fee.
In this day of sub $100 24x burners, the manufacturers need to shave every penny of extra expense to remain alive in the market place.
Of greater concern is the extremely poor quality of the install and uninstall routines in the Roxio products. On a clean machine, no matter what flavor of Windows, install EZ(Crap)CD Creator - either standard or
Deluxe. Then do an uninstall. That uninstall should return you to a clean machine. Yet a quick search through the registry will always show numerous references to the product left behind.
Getting the current version up to the state needed for the current OS has always been an exercise in futility too. With XP, you start with the version 5.0 you buy at your favorite retailer. Then you have to patch it to get it up to 5.02c, and then ignoring what the screen tells you about having to reboot for the changes to take effect, you must also install the winxp_up_up.exe patch. If you apply the myriad of patches in the wrong order, the program will not work. If you apply the patches
in the correct order, but follow the instructions on the screen telling you to reboot, the program will not work.
That, my friend, is simply poor programming. And, let's not even get into the special upgrade pricing organically offered to 4.0 Deluxe owners that was higher than the off the shelf pricing for a completely
new retail box on the shelves of both Best Buy and CompUSA the day 5.0 was released. Nor should we discuss why Go Back, bundled with the Deluxe version, does not function in XP.
Roxio is headed to the same destination that Central Point, WordPerfect Corp, Lotus Corp and several other software vendors have already gone to. Roxio just don't know it yet, but they are dead!