LETTERS

I hope that you find these issues useful in the development of an article addressing the critical issues. As for me, I wonder why a nation with an increasingly permissive society supports the Gestapo-like tactics of the SPA. Because of my lack of understanding regarding the full implementation of the new and or existing laws and SPA's use of fear to motivate software users, I must request that you not print my name in your magazine.

OS Resource Management: Another Country Heard From

Dear DDJ,

I take issue with Andrew D. Todd's assertion that it is the role of the operating-system developer (OSD) to manage computer resources ("Letters," DDJ, February 1993). It is the role of the OSD to provide computer resources. Managing those resources should be the role of the application-program developer (APD), which implies that the APD be given the opportunity to manage them. When an OSD provides resources that it uses routinely in its own software products, but refuses to make available to the programming community at large, that is management of computer resources of a particularly invidious sort.

Furthermore, the whole point of Undocumented DOS (and, I assume, Undocumented Windows) is not that Microsoft should put more into DOS in order to reduce the workloads of APDs, but that DOS already has more in it than Microsoft is willing to divulge. The work of the authors of the Undocumented books, and the thousands of others who mine for hidden nuggets in the operating systems we've bought into, is based on the premise that everyone who owns a stake in the claim should start digging with the same-sized shovel, and have an equal chance at striking a rich vein.

Microsoft's claim that it doesn't document some features because it would then be committed to supporting them in the future rings a bit hollow. Many of the undocumented features exist in the first place because Microsoft needed to circumvent DOS's deficiencies in its own products to the same nightmare of incompatibility as everyone else's, besides making it impossible to do some of the things that users have come to expect of their software. The fait accompli with which Microsoft has been presented is entirely of its own making.

Is Microsoft, having been forced to document and maintain some of the features that developers (including myself) found indispensable, better off than it would be if it had presented those features in an orderly manner in the first place? Would Microsoft enjoy its present status among OS vendors, and would Bill Gates be one of the wealthiest men in America, if some of the first APDs hadn't found unmapped routes around the roadblocks that DOS erected and, as a consequence, made their products so useful that they sold in the hundreds of thousands? When we buy an operating system, do we buy the whole thing or just those parts of it that the OSD is sure won't allow us to create products that could conceivably compete with its own? If I don't have the right to use everything the OSD put into the product, where is my discount from the purchase price? Would you buy a car, Mr. Todd, if the manufacturer hid the fuel filter and then refused to tell you where it was?

Mr. Todd's proposal for dealing with undocumented features, if followed to its logical conclusion, presents a chilling prospect. In fact, part of it is already in place. A system of [leaks] "to the APDs of known probity" is not exactly a new idea, though it isn't always clear just how an APD's probity is assessed. The idea that "APDs may commission new features in the operating system," of which "interested parties" would then be notified, and for which they would presumably be billed, is a prescription for turning the dull headache of version incompatibilities into an epidemic of unimaginable virulence.

Finally, I would say to Mr. Todd that if he has ever written a DOS TSR that made more than trivial use of OS resources without resorting to undocumented features, he should write a book. It is sure to find a ready market among serious programmers, who aren't looking for thrills when they use undocumented features, but for ways to accomplish what would otherwise be impossible.

Richard Zigler

Marion, Michigan

Example 1

/* find_prev_wnd(): Find the main window of the previous
 * instance by searching all top-level windows
 */
HWND      prev_wnd;
FARPROC   find_prev_wndi;

BOOL CALLBACK _export  find_prev_wnd(HWND wnd, LPARAM lParam)
{
      /* Look for a top-level window having the same instance*/
      if (!GetParent(wnd)
          &&  GetWindowWord(wnd, GWW_HINSTANCE)== (HINSTANCE)lParam)
      {
          prev_wnd = wnd;
          return FALSE; /* Stop enumerating */
      }
      return TRUE; /* Continue enumerating */
}

/* Main application function */
int pascal
WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR pCmdLine, int Show)
{
      /* If there is a previous task instance, return to it */
      if  (hPrevInst)
      {
              find_prev_wndi =
                  MakeProcInstance((FARPROC)find_prev_wnd, instance);
              EnumWindows(find_prev_wndi, hPrevInst);
              FreeProcInstance(find_prev_wndi);
              /* Window not found error */
              if  (!prev_wnd)
                     return  0;  /* Fail silently */
              /* Return to the last active popup window, if any,
               * of the previous instance
               */
              prev_wnd = GetLastActivePopup(prev_wnd);
              /* if the existing window is minimized, restore it */
              ShowWindow(prev_wnd, SW_SHOWNORMAL);
              SetActiveWindow(prev_wnd);
              return 0;
        }
        . . .
} /* end WinMain() */