From: "Robert Drzyzgula" Subject: Are Windows NT and WIndows 95 Unsupportable? Date: 27 Jan 1998 00:00:00 GMT Message-ID: <#eMK9w5K9GA.295@uppssnewspub04.moswest.msn.net> Followup-To: microsoft.public.windowsnt.misc Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Newsgroups: microsoft.public.inetexplorer.ie4,microsoft.public.win95.general.discussion,microsoft.public.windowsnt.misc All, Over the past several weeks, I've been running up against problems within Windows NT and Windows 95 that appear to have no direct resolution. This "re-install the operating system" business has me frustrated, angry and concerned. I have been supporting Unix (mostly Solaris) machines for fifteen years, and I have never seen the likes of this outside of the Windows environment. For example: a.. On one of my systems, I have lost the "New" submenu both on the Explorer right-pane pop-up menu and the File pull-down menu. I am running WinNT Workstation 4.0 SP3/128, with IE 4.01. I have found nothing on this problem in any Microsoft knowledge base article (perhaps my search technique is lacking, but then I kind of needed to look for keywords like file, new, menu, lost, folder and explorer, which don't exactly give the search engine much to go on), and, despite many people posting descriptions of exactly my problem over the past couple of weeks, there have been no solutions posted other than "re-install the operating system" or "reinstall IE 4.01". A few days ago, in Microsoft.public.win95.filediskmanage, MVP tess@feist.com points out that "new Folder" is hard-coded into shell32.dll, and that replacing this executable might resolve the problem. Since I'm running Windows NT, I didn't pursue this, but how can hard code inside a dll get corrupted so that only a single function like this is lost and yet have the machine otherwise remain relatively stable? And how can so many people have the dll damaged in precisely the same non-fatal way? b.. At my office, we run SMS. We installed SMS 1.1 under Windows NT 3.51 on a Dell P90 two years ago during a pilot phase of our NT deployment. As we settled on a production environment, we wanted to upgrade the SMS server to a dual-processor Pentium server running SMS 1.2 under Windows NT 4.0. After much head-banging and screaming at Microsoft, we finally obtained the answer: This is not directly possible. The only way to do this is to rip all vestiges of SMS out of our production network, shut down the existing SMS server, and then build a new SMS server from scratch, creating a new site in the process; the old site database must be made gone gone gone. While the software is upgradable (SMS 1.1 can be upgraded-in-place to SMS 1.2 and NT 3.51 can be upgraded to 4.0), the hardware is not. Even if the we could dump and reload NT to the new machine (MS of course does not officially allow this), the second processor could not be used because the SMP machine requires a different HAL And the SMS database may not be reloaded to a machine other than the one it was created on; there is something deep in the bowels of the product that will blow a gasket if you try. I now have a good half-dozen spare motherboards for this system locked away; they are Intel 82430HX dual-processor Pentium motherboards which are now unobtainable except for random appearances at computer shows. When we get to the point that we have several hundred production users, I can't imagine what I would do if we had to go through such an "upgrade" on short notice. c.. In several instances recently, we have had problems with machines for which the resolution lies in editing the registry. However, the knowledge base problem resolution notes invariably contain that vile disclaimer: "Use Registry Editor at your own risk." Calls to Microsoft about registry-related issues are usually not fruitful -- their support technicians typically will only respond that they don't provide support for registry issues (we have a Priority Comprehensive support contract). If the only way (other than a complete re-install) to fix a problem is to edit the registry, and Microsoft advises us that we edit the registry at the risk of losing continued support, then how could one conclude that the operating system was "supportable"? What does it mean when a vendor scolds you for asking hard questions? d.. One of our security staff asked me a few days ago if I had documentation for the actual on-the-wire protocol used to support NT's domain trust functionality. I spent a while digging rather than simply laughing at him, but in the end my fears were sadly confirmed: Any documentation that may be available is deeply buried. e.. I recently rebuilt my home PC; there was far too much cruft on the hard disk, so I started over again. I installed NT 4.0 from the CD, and I wanted to bring it up to SP3/128 and IE 4.01, neither of which I had on CD or on my hard disk. I figured that SP3/128 would be the first thing to install, but IE 2.0 was far too broken to navigate the MS support pages to get the download. So I installed IE 4.0 from CD, downloaded the service pack, installed that, and then attempted to upgrade my IE 4.0 install to IE 4.01. This was a disaster. If you read the notes for SP3, it says to re-apply the service pack if any parts are added to the OS, while the notes for IE 4.01 say to never install SP3 over IE 4.01. After much wrangling and many foul incantations, I finally had a copy of 4.01 that would do 128-bit SSL, but the whole process took close to a day. I suppose that in retrospect IE 3.0 would have been a better intermediate step. But if now I, say, add a new network protocol to my machine, am I supposed to re-apply SP3 or not? Do I need to de-install IE 4.01 first? How many more things would then be broken? f.. What MS-sanctioned "training" we have gone through on NT systems administration and the like has been decidedly unsatisfying; generally it seems more like indoctrination, not training. Far too much time seems spent on telling you what things not to do so that you may avoid the difficult, irresolvable problems; understanding, comprehension and creativity are not encouraged. Rules such as "don't use hardware not listed on the HCL" are drummed into such classes, rather than empowering them to know what kinds of hardware designs are more prone to problems and how to test for compatibility. What is one supposed to do when one's boss says "install a 7GB drive" and there are no 7GB drives listed on the HCL? Microsoft, as hard as it tries, simply can't control real life to that extent. It is apparent that there are many critical portions of the windows operating systems that are simply not documented. I'm not that naive; this much I expected; Solaris, for example, has more than its fair share of undocumented interfaces. But what seems apart from my previous experience with computer operating systems is how much essential stuff seems *deliberately* obscure. We're not talking undocumented interfaces here, we're talking hand-waving, misdirection and obfuscation. How many times are we told to simply reinstall the OS or the software product? Why is this? Is it because Microsoft doesn't know why the thing breaks? Is it because the truth would be too embarrassing or dangerous in the wrong hands? Is it because documenting the actual required fixes for all those problems would take about double the tech-writer bandwidth as they currently possess? Honestly, I'd like to know: Why does Windows develop so many problems that are "fixable" only by starting all over again? At my office, we steadfastly avoided Windows for many years; three years ago we had two dozen PCs for nearly 400 users; secretaries and managers used X Terminals just like all the technical staff. We happily did our Unix rdists and machine cloning while watching PC support staff in other divisions scurry about with piles of floppies, desperately trying to keep their whole systems from collapse. But finally we were worn down by the steady decline in the availability of OA software for Unix, and the corresponding fertility of the Windows software market. NT seemed the first supportable version of windows, what with the server-based profiles, access-controlled file system and RPC-based management. So we went for it. Now I feel like it was a mistake; it seems like we've been tricked. NT is not supportable after all, I'm beginning to conclude. NT only provides, it seems, the superficial appearance of being supportable. Dissenting views are encouraged (I really wish I was wrong about this), but please hold the flames. Bob Drzyzgula bob@mostly.com