🚀 go-pugleaf

>If anyone has worked in both MS Windows and X windows environment, I
>would like to know about your experience about these two with respect to
>:-
>1. ease of learning.
>2. flexibility in design and implementation
>3. ease in implementing a given application (probably 2 should cover
>this)
>4. portability.
>
>I would appreciate any comments on these issues. Please send your
>responses to dhan@cs.arizona.edu

    1)	Ease of learning for the end-user or for the programmer?  For the
	end-user there isn't much difference, at least to get to a point
	that you're reasonably productive.  X is much more customizable
	than MS-Windows, but often in obscure ways;  there isn't a
	generally-applicable way to have certain apps always start up
	iconified, for example, but most apps support it in some way
	in their resource file.  Applications on MS-Windows tend to be
	more integrated with each other and with MS-Windows, which can be
	a plus;  but there are numerous problems with the applets in
	MS-Windows (the Terminal program still doesn't do an ANSI terminal
	properly, and the Notepad is a toy that can't examine even modest-
	sized files).  Many implementations of X tend to look very
	utilitarian compared to MS-Windows, which is a drawback for many
	people.  But there are exceptions on X as well;  SCO and HP
	both have versions of X that are very nicely packaged for the
	typical non-technical end-users, as nice as anything that's come
	out of Redmond.  

	For the programmer the biggest problems with Xwindows are that it
	doesn't support printing very well (generally programs can produce
	Postscript and text file output, for example, but the Xwindows API
	does not have any hooks to make this easier like the MS-Windows
	API), and that since it runs on multiple OS's (Unix, VMS, OS/2,
	maybe Windows NT when it comes out ...), writing programs that
	will run on all of the X platforms is not straightforward.  (Of
	course that means you have the additional services of the OS
	available, many of which are not available under MS-Windows).
	The fact that X is usually implemented on top of fairly complex
	operating systems means that it requires considerably more resources
	than MS-Windows (disk space and memory, mostly;  CPU cycles roughly
	balance out between the two:  X directly consumes somewhat more CPU
	because of all its layers, but MS-Windows fritters it away with its
	primitive messaging and tasking models).

    2)	Flexibility in design and implementation -- MS-Windows is far
	less flexible than X;  it really only supports a single `look
	and feel', while X allows different window managers to impose
	different `look and feel' policies, and even allows users to
	install their own window managers.  But this also means that
	there is not as much standardization in the X world -- every
	vendor's implementation has different `enhancements' and
	features (and bugs).

    3)	Ease of implementing a given application -- Depends on what the
	application is.  In general X is nicer because it is harder to
	crash the whole system than it is with MS-windows (X is usually
	implemented on a true protected-mode OS, while MS-Windows is
	only a sort of pretend protected-mode system; it's very easy to
	crash it during development).  But there are drawbacks -- X has
	fewer neat tools like Visual Basic, and if you're doing simple
	printing then X is a pain because if you want more than just a
	simple text file, you have to go to the trouble of writing Post-
	script or something similar (if the printer installed doesn't
	support Postscript, there are typically Postscript interpreters
	used on the output print queue so the effect from the end-user's
	point of view is much the same).  If you're doing really fancy
	printing then the difference is less important because at that
	level various problems arise in the MS-Windows printer model
	(things are not always quite as `portable' between different
	printers as the SDK might lead you to believe).

    4)	Portability -- If this is important then there's really no
	choice;  MS-Windows apps are the epitome of non-portable code:
	X is your only alternative.  X will run on a variety of machine
	architectures and OS's;  MS-Windows apps are limited to running
	on Intel architectures under MS-Windows, OS/2 or NT (when it
	comes out, unless you want to run the beta version), or possibly
	a PC Unix with a DOS box (there are a couple that support this);
	or an MS-Windows app can be run on a RISC workstation in a DOS
	emulator, with horrible performance that more than makes up for
	the speed of the RISC chip.  This latter approach is only useful
	if you have a non-compute-bound MS-Windows app that you really
	like and want to run on your workstation;  if its performance
	matters then you either need to run it on an 80x86-compatible
	CPU or find something equivalent that runs in native mode on
	the workstation.  With X, if an app runs on one workstation,
	the vendor is likely to port it to other types of workstation,
	or the source code is likely to be possible to adapt to run on
	another workstation without enormous effort (modulo the problems
	mentioned above that you might encounter with different operating
	systems if you do anything operating-system-specific in the
	program).

	The only possibility for MS-Windows portability will be Windows
	NT;  an NT program should be fairly easily portable between
	different CPU architectures, but running it under standard
	MS-Windows may not be possible (it would require Win32S, which
	won't run on anything less than a 386, and which does not support
	many of the more advanced features of NT.  Basically what it gets
	you is a 32-bit memory model and some additional graphics calls).
	The main problem at this point is that right now NT seems to be
	thought of as mostly an Intel-based operating system, even though
	there will be versions for various RISC machines.  Therefore the
	availability of code for other architectures (and possibly even
	the availability of the OS for some RISC architectures) may be
	problematic until and unless it becomes popular on RISC machines.
	I prefer to think of these as NT apps rather than as MS-Windows
	apps, but the original question was sufficiently vague that I
	suppose that an NT app could be considered an MS-Windows app for
	this purpose.  In any event, if there's any interest in running
	the app on other operating systems or CPU's, NT still won't get
	you much portability in that respect unless you write X code on NT.

This is nothing more then a rough thumbnail sketch;  I may be (and probably
am) leaving out important items.

Bruce C. Wright