September 1995 How-To Columns
NT Gets the Look But Not the Logo
by: John D. Ruley
to see a
49KB bitmap image of artwork
which goes with this article, entitled:
Witness the unveiling of the new NT
I just got an early copy of Microsoft's Shell Technology Preview, and it finally gives NT a Windows 95 look and feel.
All the details on the preview should be on CompuServe's MSDR forum and ftp.microsoft.com by the time you read this. But I can tell you a few things now.
For starters, Microsoft is calling this a "preview" release. That means two things: You won't get technical support and you use the shell at your own risk. The README.WRI file Microsoft ships with the Preview is quite specific on that. It states: "The Shell Technology Preview has
not been fully tested and should not be deployed in production environments."
The good news is I've been using it for about a week now and it's been perfectly stable. Of course, that may mean I just haven't run into the bugs yet.
The next thing to know about the preview is that in some significant ways, it's not finished. One of Windows 95's nicest features is that it treats everything as a graphical object. You can click the right mouse button on any object to bring up associated properties. For the desktop, this includes the color scheme, screen saver and so on.
When you click the right mouse button on the NT Preview desktop and select Properties from the menu, you get the Color Schemes Control Panel applet. That's not nearly as useful as the associated properties in Windows 95. Similarly, if you select Properties from the My Computer icon you'll get the System Control Panel item.
Even though the preview gives NT a Windows 95 look, it doesn't give it all of Windows 95
's features. In particular, it doesn't support Plug and Play, it doesn't provide the telephony API or the universal modem (unimodem) driver, and it doesn't support Windows 95-style private device drivers (VxDs). Which brings me to ...
Microsoft says there's just one 32-bit Windows Application Programming Interface--the Win32 API. It has several implementations, but aside from specialized areas like security, everything's compatible, and applications written for one platform "just work" on the other. Vendors writing programs for Windows 95 must provide an NT version to get the Windows 95 logo. So, as Windows 95 applications ship, they'll all work on NT, right? If you believe that, I have shares in the Brooklyn Bridge available at a very reasonable price.
The situation's not a total disaster. The 32-bit (Intel) NT versions of MS Word 6.0 and Excel 5.0 run perfectly on Windows 95. Indeed, I'm writing this using a beta version of Word for Wind
ows 95. A major reason Microsoft deployed NT 3.51 so quickly after NT 3.5 is that it adds features needed to support the Office-95 suite. And the shell update I'm previewing resolves any compatibility issues resulting from NT's and Windows 95's different looks. So what's the problem?
When you step beyond the minimal features needed to support a word processor or spreadsheet, the fundamental differences between Windows 95 and NT become blindingly obvious. Any Windows 95 application that depends on a VxD--or Windows 95's low-level I/O architecture (
see my June column
), Plug and Play or the unimodem driver--won't run in NT.
What does this mean in practice? I've tried running applets from Windows 95 on NT 3.51. Only the Windows 95 calculator runs on NT. Every other application from the Windows 95 CD-ROM failed. Error messages referred to missing entry points in DLLs, missing VxDs and so on. Not only the shell itself, but applications as generic
as Windows 95's WordPad text editor and HyperTerminal communications app, won't run on NT. Neither will Norton's Navigator and File Manager--even with the Shell Update installed.
But according to Microsoft, the Windows 95 logo program takes care of all this. Vendors that want the logo--and they all want the logo--must support Windows NT. So these problems disappear as the new Windows 95 applications appear, right? In a word, no.
My colleague, Dave Methvin, attended an eye-opening briefing on the logo program at Microsoft's Tech*Ed conference this spring. The presenter went through chapter and verse on how Microsoft required NT support for the logo. He then provided the assembled vendors with an escape hatch: "If an application depends on a feature specific to Windows 95, it's excused from the requirement to support NT."
In practice, that means any vendor that doesn't want to support NT doesn't have to. All a vendor has to do to sidestep the requirement is to make a Windows 95 fea
ture central to an application. Write one custom VxD, and you're off the hook.
Several pioneering NT vendors see Windows 95 as a major opportunity and will show the industry how to achieve compatibility. Micrografx has been doing this for more than a year. Its NT version of Picture Publisher runs on everything from Windows 3.1 with Win32s to Windows 95 and NT (I haven't tried it on Warp yet). Doug Hamilton plans to release a Windows 95 version of his C-Shell. And his major competitor, Mortice Kern Systems, is doing likewise with the MKS Toolkit 4.4. Cheyenne Software, which just got an NT-based version of its ARCserve backup software running, will add a Windows 95 client later this year. MKS and Cheyenne have overcome serious compatibility issues. For instance, Windows 95 doesn't support the same tape device API and drivers as NT. Each has had to provide its own drivers.
Even Intergraph Corp. has gotten into the act. Its MicroStation line of workstation-grade CAD software is based on OpenG
L, and you wouldn't expect it to run on Windows 95. But it will, using a set of compatibility libraries that will retrofit OpenGL on top of Windows 95. The result probably won't match the performance under NT, where OpenGL is part of the operating system, but it will work.
Notice a trend here? These companies are established NT vendors, and they're making their software Windows 95-compatible, rather than Win95 vendors making their products NT compatible. That may be key to getting through the next few months with a minimum of frustration. Look for NT applications that also support Windows 95. The Windows 95 logo is no guarantee of NT compatibility. So if you want to run a Windows 95 app on NT, call the vendor to be sure it supports NT as a platform.
I'm confident this situation will improve--it can't get much worse. As Windows 95 and NT 3.51 go to release, this problem will become apparent. And as vendors that try to cheap-out on NT support wa
tch their competitors sell product, you can bet they'll change their tune. Microsoft is also working on the problem, even though the company barely acknowledges it in public. I've spoken with senior people from both the Personal Systems (Windows 95) and Business Systems (NT) divisions. Both say they're trying to improve the situation in future versions. In the meantime, let the buyer beware.
If you're thinking the compatibility issues between Windows 95 and NT might create an opportunity for another operating system--like OS/2 Warp--think again. Recently, I spotted an online comment about IBM expanding Win32 support in OS/2 Warp. These types of rumors are common, but this time two things caught my attention: "more than 700 APIs" and "WLO-like." The second bit gave me a strange feeling of deja vu.
You may want to refer to my article "Windows in OS/2," which ran in the May 1991 issue of "Windows and OS/2 Magazine." The article described a set of Windows L
ibraries for OS/2 (WLO). Microsoft provided these libraries so Windows programmers could port their applications to run under then state-of-the-art OS/2 version 1.21. The trouble was, applications written for Windows--using Microsoft's Windows API--had to be recompiled and relinked (something only a programmer can do) to become OS/2 applications. IBM thought so little of the idea that it refused to use it. Instead, the company built 16-bit Windows support directly into OS/2 2.0 and Win32s support into Warp.
Although IBM didn't buy the idea, it never completely died. Micrografx and other vendors used a variation on the concept called "Mirrors" to port applications to OS/2. Nobody much liked the approach, and to the best of my knowledge, it hasn't been used for some time.
IBM is resurrecting the WLO concept, according to the May 29 issue of InfoWorld. A new set of libraries called the Developer API Extensions (DAX) will let Windows programmers recompile their software to run under OS/2. Unfo
rtunately, it doesn't work any better this time. The InfoWorld piece states programmers using DAX will end up with code that's 80 percent common to both Windows and OS/2. That leaves 20 percent of the code to be customized.
Whether you call it DAX, Mirrors or WLO, this approach results in separate Windows and OS/2 programs. That means either two separate boxes on the shelf--along with separate manuals, installation programs and so on--or one big box and a horribly complicated setup program. Either way, it's a bad deal for the vendor, which does twice the work (20 percent more code, plus a second setup program, manual, help system and so on) to sell, at most, 10 percent more product. That's a losing proposition unless someone else foots the bill.
Does IBM have a slush fund to finance DAX ports? Maybe it's paid for by the consumer-friendly new price ($299) for OS/2 Warp Connect, the network-connected version.
to see a
20KB bitmap image of artwork
which goes with this article, entitled:
Microsoft's concurrent connection licencing in NT SERVER 3.51 is brilliant
Microsoft takes the prize for the most brilliant and the most bogus--even more bogus than DAX--ideas. Oddly enough, both ideas involve software licensing.
The brilliant one is Microsoft's support for concurrent connection licensing in NT Server 3.51. Beginning with NT Server 3.5, Microsoft went from an unlimited license to a per-seat "information access" license that's--to put it mildly--complicated. You buy two licenses: one for the server and another for each connected client. If your users need access to many servers, it's a good idea. But if you need just one server, it's not.
The concurrent connection license option handles this nicely. Just tell NT Server you're licensed for 20 users, and when the 21st user tries to log in, an error message will appear. It's perfect for folks who are used to that
kind of license (dare I say, NetWare customers?). It's also perfect for systems used as Internet servers, where it's not practical to buy a license for each user. I applaud Microsoft for giving us this extra flexibility.
License Manager, on the other hand, takes this month's prize for bogus software. This program claims to make life easy for network administrators by automating license compliance. All it does, though, is keep track of license numbers once you type them in. That's right--it's nothing more than a spiffy electronic worksheet.
C'mon, Microsoft, you can do better than that. How about taking a little of Hermes' systems management technology and using it to update license information automatically? From what I hear, Hermes isn't selling anyway, so the technology ought to be put to some use.
This month's tip is a warning: If you're upgrading from an NT 3.51 beta to a later version, be sure the root directory on your boot disk isn
't marked as compressed.
You can do this using File Manager. Select the root directory, then File/Uncompress. You'll see a dialog asking if you want to uncompress all files and directories. Just say no. (You just want to make sure new files copied to the root aren't compressed.) If you don't do this, you may have trouble with the upgrade. When I installed an NT 3.51 release candidate it did a very neat job of copying all the system files, but it compressed them. When I rebooted the system, I got a cute little "NTLDR is compressed--insert a setup floppy" message. That would have been okay, but the floppy drive was dead on the system I was using (it's now on its way back to the vendor). Microsoft tells me the compression problem was fixed post-RC2. But to be safe, I recommend you make sure that root directory is uncompressed before you upgrade.
The book of the month this time around is--mine (well, mine, Dave Methvin's, Martin Heller's, Arthur Germa
in's and Eric Hall's). It's Networking Windows NT 3.51 (John Wiley & Sons, 1995, $32.95), a complete update of our earlier book. It covers everything NT network-related: protocols, scripts, network operation, maintenance, planning, support, internetworking and lots more.
John D. Ruley is WINDOWS Magazine's editor-at-large and resident Windows NT expert. To find his E-Mail ID
Chocolates Are Nice, But Good Code Is Sweeter
by: Martin Heller
Life is like ... well, life is like nothing else. Life is.
I was tempted to quote Forrest Gump on life, but reason got the better of me as it sometimes does--like when WINDOWS Magazine asked me to add OpenGL benchmarks to the new version of NTHELL, my 32-bit low-level benchmark utility fo
r Windows NT and Windows 95. The problem is that OpenGL (which I covered exactly a year ago in this column) is currently supported only in Windows NT 3.5 and above. There's talk of having OpenGL support in Win95 in the future, but we can't count on it now.
Reason made it clear that I couldn't blithely link my benchmark application with the OpenGL libraries and expect it to run in the absence of the OpenGL .DLLs. That left me two options: I could either dynamically link to a .DLL holding the OpenGL test or run the OpenGL test in a separate process. I chose to run the OpenGL test in a separate process because it seemed simpler, and I've never delved into the mysteries of synchronizing two Win32 processes. Besides, I've already written about dynamically linking to DLLs in my books and several articles.
My original cut at an OpenGL benchmark involved starting with the standard Stonehenge simulation found in the samples\opengl\demos\ stonehng subdirectory under the main Win32 SDK or C compiler
directory, turning on all the options I could find so it would really exercise the hardware and adding some calls to clock. That seemed to work fine when I tested it on an Intergraph TD-4, which has a graphics accelerator designed for OpenGL. But on just about any other hardware I tried, the wait was deadly.
I finally went along with John Ruley's suggestion to use the Olympic Rings program found in samples\opengl\ samples\tolympic.c, which simulates five rings spinning into the Olympic Ring formation. The only problem I had with the program was that it's designed for interactive use and relies on the GLAUX package to handle its user input. I realized fairly quickly that the auxMainLoop function handles all the keystroke input. After a little too much trial and error, I discovered I could simply call the program's "idle" function, DrawScene, from a for loop to get the deterministic effect I wanted. That done, I had to figure out how to start a process and wait for it to complete. In 16-bit Windows, I
'd start the process with WinExec, then go through all sorts of gyrations to figure out when the process was complete. Although WinExec is still supported in 32-bit Windows, it's much better for our purposes to use the new Win32 function CreateProcess. This returns handles to the created process and to the thread in a PROCESS_INFORMATION structure. If the CreateProcess call is successful, you can simply wait for the process handle to signal to know when the created process has completed, as shown in
How Long Must We Wait?
By the way, you'll often want to start an interactive process and then synchronize with it or control it while it runs. This would work well if you were creating a tutorial, for instance. CreateProcess returns without waiting for the new process to initialize. You can use WaitForInputIdle to wait until the process has completed its initialization and is waiting for user input.
This sidebar also demonstrates the use of GetProcessTimes to determin
e the time the process started and finished and how much USER and KERNEL mode CPU time it used. You'll notice GetProcessTimes takes a process handle, and you call it after you know the process has already exited. Indeed, the process handle remains valid until it's closed, as does the thread handle. Although such handles are automatically released when the calling process exits, it's good hygiene to explicitly close the handles once you no longer need them. There are two reasons for this: Kernel handles are limited system resources, and the process remains in the system until all handles to it are closed.
The four times returned by Get ProcessTimes are placed in FILE TIME structures, each of which is a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601. With a little work we can turn a FILETIME structure into a more tractable number, such as the number of milliseconds since midnight.
The four values returned by Get ProcessTimes are enough to tell you how
much clock time and CPU time the process took from the time it loaded until the time it exited. But they don't measure the time from when you asked to create the process until it actually started running. You can get that additional information by timing the function that starts and waits for the process. You use the timing routine DoBench shown at the top of
Timing Is Everything
, and provide the external interface with the function TimeAProcess shown at the bottom.
To keep from unnecessarily displaying error messages--which would happen if creating the TOLYMPIC process failed for lack of OpenGL support--test for the presence of OpenGL before running the test. To do this, call LoadLibrary ("opengl32.dll"). It's theoretically possible that OPENGL32.DLL will be present while one of the other OpenGL .DLLs is absent, but that's the sort of pathological situation that should generate an error message.
On the home frontI recently moved my office. It wasn't pleasant.
One good thing that came out of moving my office was I found a lot of stuff vendors had sent me--some of which is quite interesting. My old office became overburdened to the point where I threw stuff into piles, often unopened, after a brief triage. When the piles got too big, I started new piles in front of the old ones. I know it sounds horrible, but every time I tried to go through the stacks to find something, I'd have a project or article facing a deadline and I'd have to submerge until it was done. It got to the point where I really had no idea what was in there.
I'm told that being overwhelmed by incoming material is normal for magazines and columnists, but it's a fairly new and somewhat unsettling experience for me--right up there with having complete strangers come up to me at trade shows and talk to me as if they've known me for years. I guess from their viewpoint they have.
A number of good products turned up after the move, some of which fit in with my interests. For the langua
ge junkie in me, there was Allegro CL for Windows 2.0, a Common Lisp Object System development environment and compiler (Franz, 510-548-3600) and Symantec C++ 7.0 (503-334-6054). The latter supports both 16- and 32-bit Windows programming, features object-oriented browsing tools and sports a distributed network build utility.
The debugging fiend in me fancied HeapAgent, a memory error detection and diagnostics tool (MicroQuill, 206-525-8218), along with new and improved versions of Bounds Checker--for Windows, Win32s, Windows NT and Windows 95--and Soft-ICE (Nu-Mega, 603-889-2386). WinHelp Office, a suite of help file development tools (Blue Sky, 619-459-6365) satisfied the user-interface designer in me.
For the documentation stickler in me there was C-DOC Professional (Software Blacksmiths, 905-858-4466), a collection of C and C++ documentation aids, including a call tree generator, a commenting aid, a cross-referencer, an action-diagrammer and code reformatter, and a metric generator. Th
e device driver writer in me uncovered VtoolsD (Vireo, 508-779-8352), a set of tools and libraries to help you write VxDs in C or C++.
The last one gave me pause. VxDs, and device drivers in general, have always been the domain of a small priesthood--gonzo assembly language programmers who've been through the initiation rites of plowing through the DDK. They've suffered with the lousy or nonexistent documentation, read the poorly structured sources and traced through ring transition after ring transition to try to make sense of PIC masks and virtualized IRQs. What do they want to do, make it easy?
And then reason prevailed.
consults on, writes about, teaches and practices 16- and 32-bit Windows programming. To find his E-Mail ID
Here's a way to know exactly when a created process is completed.
by: Martin Heller
extern "C" void SpawnTheProcessAndWait(void)
BOOL fOK = CreateProcess(ImageName, CommandLine.NULL, NULL,
FALSE, 0, NULL, NULL, &sui, &ProcInfo);
&ftExit, &ftKernel, &ftUser);
TRACE("CreateProcess error %d\n",error);
OkMsgBox("Time Process","CreateProcess error %d\n",
These two examples show how to measure the time it takes for a function to
execute and how to time a process.
by: Martin Heller
Timing a function call:
double DoBench(char *bname,char *strp,void(*funcp)())
long stime; /* Start time */
long etime; /* End time */
double time; /* Elapsed time */
int secs; /* Seconds */
int ms; /* milliseconds */
sprintf(temp1,"%4s %-22s", bname, strp);
stime = clock();
etime = clock();
ltime = etime - stime;
time = ltime / ((double)CLOCKS_PER_SEC/1000.0);
ltime = (long)time;
secs = int(ltime / 1000);
ms = int(ltime % 1000);
sprintf(temp2,"%4d.%03d secs\n", secs, ms);
extern "C" __declspec( dllexport )
float WINAPI TimeAProcess(char *sz
ImageName, char *szCommandLine)
//accumulate time in seconds
Wtime = DoBench("P0","Time Process",