Peer to Peer

November 11, 1996

Daring Microsoft to lead the industry out of confusion

By Clark Brady

I've been working up my nerve for the past few months to dare Microsoft to make some strategic improvements to its technology. If Microsoft wants to lead, then it should overwhelm the computer industry with fundamental practices that can be emulated by other companies.

So, Microsoft, I dare you to meet the following challenges:

Reorganize the Windows "Dead Sea." Why does everything eventually ends up in the Windows "Dead Sea" (er, I mean directory). You know, the lowest place in the OS where everything flows in but nothing flows out. Don't make the Windows directory a dumping ground for all miscellaneous files from every different application. It takes any well-organized group of related materials and purposely piles them together with no way of knowing the relationship later, and no convenient way of selectively removing one. This can be seen when a software vendor wants to deploy its software. It creates a pretty installer package of everything under the sun required to make the application work. But the installer takes a well organized group of files and throws it into the pile. Now, you are lucky if you can find the application that was just installed.

Instead, Microsoft needs to make a new directory structure that only contains OS files. Encourage developers to structure their own directories so that applications can be moved and removed easily even by a novice. Add tracks to keep records of all the activities within components that might absolutely require sharing such elements as fonts, filters, and drivers. Lose the file extension significance and go to a file structure that takes into consideration the true purpose of the file regardless of the file name. And, keep track of other properties for files such as versions. Don't make the file have to store its own data.

Eliminate DLLs and other antiquated technologies. I have to ask myself, what's the purpose of a DLL anyway? The answer is to share memory and disk space. These days, both of these commodities are available at such reasonable prices that it is no longer cost effective to support all the issues and complexities associated with DLLs. Instead of deploying DLLs, most code could be directly linked into the application. This would eliminate many of the version problems now experienced.

Rework printing devices. In my mind, printing has got to be one of the weakest afterthoughts of Windows (a close second is device management, but we'll get to that later). Precise representation of information on screen and on paper is a must. For many applications, even small variation between the two is unacceptable. The lack of consideration for paper can be seen throughout available development tools. These extend from missing print containers and previews to poor print coordination of controls such as the Rich Text Box that assumes that it is the only thing on a printed page. (Forget trying to make it work in conjunction with other components.)

Lose the drive letters. Device management has been very weak in Windows. It still irks me to have to mount a network drive to a drive letter. Yeah, you can get to networks without drive letters, but it still isn't presented very well to the user. I've been thinking that one approach could be to have the underlying OS handle more. For instance, even links under Windows 95 haven't been addressed in the OS. Instead it's addressed in the API.

Let's talk about the API. If you don't call the new API function (such as use an old program), you don't get access to the links. What's that? How about removing drive letters by putting a mapping function into the OS that knows how to translate old letters to new locations? Or for backward compatibility, what about mapping the desktop to a drive letter so that the complete desktop (my computer) drive is available directly through a pseudo path that consists of one little letter and a colon?

Facilitate Reuse. I dare you, Microsoft, to lead the industry by packaging all the components that you can.

For instance, whenever a new visual control is built for a commercial application, it should be documented and packaged for external use and made available at a reasonable cost. This practice would instill a true sense of component reuse within the industry. Examples include the outline control found in Project or the common spell-checker part of MS Word that handles spelling dictionaries, personal dictionaries, and a thesaurus that does the suggest, replace, and ignore thing. Perhaps another control would include the ability to convert graphics and files as easily as MS Office.

The main problem with reuse is that it doesn't happen for free, and most organizations don't (or can't) devote the resources for planning for reuse. If the promise of reuse ever became a reality, then we would be far ahead of where we are now. Instead, the delivery of systems is behind the evolution of the solutions. New solutions are being created faster than they can be applied.

Make partnerships, don't dominate. We're all tired of seeing decent products and efforts being trashed by Microsoft just because they have the financial position. Instead of focusing on the same technology as other companies, how about spending time in new research.

I cannot figure out why free research is being rejected. That's what it seems Microsoft is doing when it tries to make everything snap into its kludged API set instead of working with other groups that are creating new models for computing. Can you imagine how fast some of the object standards (OpenDoc, CORBA) could take off if desktop support were available directly from Microsoft? The whole tool box approach for applications is yet to explode. This approach has the same potential as the Web, where critical mass is obtained in the industry to create unheard of opportunity and to shake many companies right down to their foundations.

The gauntlet is now down. Any takers?

Clark Brady is a senior scientific systems analyst at Eli Lilly & Company and a member of EmTAG, the Emerging Technology Advisory Group, of AIIM , Association for Information and Image Management. Feedback can be sent to Clark at cbrady@iquest.net. Thanks to Grant Lindman and Barry Crist for their assistance.

Copyright © 1996 by InfoWorld Publishing Company