zeus@stratix.UUCP (Mark Mullin) (11/05/87)
After receiving mail concerning my attack on MS-Windows, I am following up my original posting with some specifics. 1: The departure from the standard C environment MS has tightly coupled the graphics display functions of windows to a non-preemptive multitasking service library. You cannot ignore it or leave it out of the system and it's presence requires that the compiler write specialized preludes to all of the compiled routines. This makes it tough to use certain libraries and preprocessing systems with Windows (eg: Objective C). The reason that Windows applications are taking so long to appear is that complete new toolsets are still being ported to the Windows environment. Many existing Windows applications are based on previously existing code ported to the windows environment, often with great pain. 2: Any piece of windows means you take the WHOLE thing While many programs benefit from multitasking a la Windows, some could give a hoot. You are forced to accept the entire Windows control environment when you develop any application. Windows is far more than a graphics display flib, regardless of the pgmrs desires. This introduces a lot of system overhead. So, while Windows is nice for making little tools, it's pretty poor when dealing with larger projects, unless of course you wish to hard code the entire system design for the MS environment, which doesn't produce the worlds most portable code. We have Smalltalk and LISP packages we are moving to the PC from UNIX, and we would like to PORT them, not completely re-engineer them. 3: MS isn't playing nice When we aquired windows, we subscribed to MS Dial, an expense of about $450 bucks, + Telenet. You have to do this, since phone service keeps telling you that they can't answer questions but Dial can. Dial is a nice trick. MS provides the computer, users post problems and then solve them themselves. MS doesn't even say thanks. We also have an account on CSERVE, where MS has a company sponsored SIG including Windows. Funny, but MS doesn't even bother to ensure that knowledge is equally represented on both Dial and CSERVE. You get bits and pieces on each. MS has made many promises about the upward compatibility of Windows, and the development schedule. Well, Windows 386 is out, and they said otherwise. The presentation manager calls on the PS-2 are different than Windows, and they said otherwise. 4: Similarity between Windows & Mac environment Some commented on the similarity between the Windows system and the Mac. This is true. The MAC is built using Object Oriented (OO) programming as a basis. Windows does exhibit an OO oriented architecture. However, MS denies that they have ever heard of Objects, Smalltalk, etc. Hmmm. 5: Stupid Things A: WINDOWS.H The include file that must be read in to every windows program is quite large and significantly increases compile time. When you take a 50+ module system this grows to an insane amount of time. B: Pascal Calling Conventions All of the functions in your program that windows will call, and all of the windows control functions are defined using PASCAL calling conventions. For a package apparently designed for the C environment, this is a strange action. C: Debugging While I commend Microsoft for realizing that debugging would best be done on a secondary display, they provide symdeb as the development package. Why can't they adapt CodeView for a dumb terminal. I don't care about the graphic display, its the symbolic referance capabilities I want. If desired, I will beat any one or more of these issues to death. Mark Mullin @ Stratix Inc uunet!stratix!mark DISCLAIMER: Microsoft(MS) is a trademarked name (i believe) and Windows refers to a proprietary product of theirs. Scientis who dislike the restraints of highly organized research like to remark that a truly great research worker needs only three pieces of equipment; a pencil, a piece of paper, and a brain ... But they quote this maxim more at academic banquets than at budget hearings. Don Price