home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / mswindo / programm / misc / 5327 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  6.8 KB
  1. Path: sparky!uunet!gatech!concert!ais.com!bruce
  2. From: bruce@ais.com (Bruce C. Wright)
  3. Newsgroups: comp.windows.ms.programmer,comp.os.ms-windows.programmer.misc
  4. Subject: Re: Comparison between MS-Windows and X-Windows
  5. Message-ID: <1993Jan24.233048.5960@ais.com>
  6. Date: 24 Jan 93 23:30:48 GMT
  7. Organization: Applied Information Systems, Chapel Hill, NC
  8. Lines: 119
  9.  
  10. >If anyone has worked in both MS Windows and X windows environment, I
  11. >would like to know about your experience about these two with respect to
  12. >:-
  13. >1. ease of learning.
  14. >2. flexibility in design and implementation
  15. >3. ease in implementing a given application (probably 2 should cover
  16. >this)
  17. >4. portability.
  18. >
  19. >I would appreciate any comments on these issues. Please send your
  20. >responses to dhan@cs.arizona.edu
  21.  
  22.     1)    Ease of learning for the end-user or for the programmer?  For the
  23.     end-user there isn't much difference, at least to get to a point
  24.     that you're reasonably productive.  X is much more customizable
  25.     than MS-Windows, but often in obscure ways;  there isn't a
  26.     generally-applicable way to have certain apps always start up
  27.     iconified, for example, but most apps support it in some way
  28.     in their resource file.  Applications on MS-Windows tend to be
  29.     more integrated with each other and with MS-Windows, which can be
  30.     a plus;  but there are numerous problems with the applets in
  31.     MS-Windows (the Terminal program still doesn't do an ANSI terminal
  32.     properly, and the Notepad is a toy that can't examine even modest-
  33.     sized files).  Many implementations of X tend to look very
  34.     utilitarian compared to MS-Windows, which is a drawback for many
  35.     people.  But there are exceptions on X as well;  SCO and HP
  36.     both have versions of X that are very nicely packaged for the
  37.     typical non-technical end-users, as nice as anything that's come
  38.     out of Redmond.  
  39.  
  40.     For the programmer the biggest problems with Xwindows are that it
  41.     doesn't support printing very well (generally programs can produce
  42.     Postscript and text file output, for example, but the Xwindows API
  43.     does not have any hooks to make this easier like the MS-Windows
  44.     API), and that since it runs on multiple OS's (Unix, VMS, OS/2,
  45.     maybe Windows NT when it comes out ...), writing programs that
  46.     will run on all of the X platforms is not straightforward.  (Of
  47.     course that means you have the additional services of the OS
  48.     available, many of which are not available under MS-Windows).
  49.     The fact that X is usually implemented on top of fairly complex
  50.     operating systems means that it requires considerably more resources
  51.     than MS-Windows (disk space and memory, mostly;  CPU cycles roughly
  52.     balance out between the two:  X directly consumes somewhat more CPU
  53.     because of all its layers, but MS-Windows fritters it away with its
  54.     primitive messaging and tasking models).
  55.  
  56.     2)    Flexibility in design and implementation -- MS-Windows is far
  57.     less flexible than X;  it really only supports a single `look
  58.     and feel', while X allows different window managers to impose
  59.     different `look and feel' policies, and even allows users to
  60.     install their own window managers.  But this also means that
  61.     there is not as much standardization in the X world -- every
  62.     vendor's implementation has different `enhancements' and
  63.     features (and bugs).
  64.  
  65.     3)    Ease of implementing a given application -- Depends on what the
  66.     application is.  In general X is nicer because it is harder to
  67.     crash the whole system than it is with MS-windows (X is usually
  68.     implemented on a true protected-mode OS, while MS-Windows is
  69.     only a sort of pretend protected-mode system; it's very easy to
  70.     crash it during development).  But there are drawbacks -- X has
  71.     fewer neat tools like Visual Basic, and if you're doing simple
  72.     printing then X is a pain because if you want more than just a
  73.     simple text file, you have to go to the trouble of writing Post-
  74.     script or something similar (if the printer installed doesn't
  75.     support Postscript, there are typically Postscript interpreters
  76.     used on the output print queue so the effect from the end-user's
  77.     point of view is much the same).  If you're doing really fancy
  78.     printing then the difference is less important because at that
  79.     level various problems arise in the MS-Windows printer model
  80.     (things are not always quite as `portable' between different
  81.     printers as the SDK might lead you to believe).
  82.  
  83.     4)    Portability -- If this is important then there's really no
  84.     choice;  MS-Windows apps are the epitome of non-portable code:
  85.     X is your only alternative.  X will run on a variety of machine
  86.     architectures and OS's;  MS-Windows apps are limited to running
  87.     on Intel architectures under MS-Windows, OS/2 or NT (when it
  88.     comes out, unless you want to run the beta version), or possibly
  89.     a PC Unix with a DOS box (there are a couple that support this);
  90.     or an MS-Windows app can be run on a RISC workstation in a DOS
  91.     emulator, with horrible performance that more than makes up for
  92.     the speed of the RISC chip.  This latter approach is only useful
  93.     if you have a non-compute-bound MS-Windows app that you really
  94.     like and want to run on your workstation;  if its performance
  95.     matters then you either need to run it on an 80x86-compatible
  96.     CPU or find something equivalent that runs in native mode on
  97.     the workstation.  With X, if an app runs on one workstation,
  98.     the vendor is likely to port it to other types of workstation,
  99.     or the source code is likely to be possible to adapt to run on
  100.     another workstation without enormous effort (modulo the problems
  101.     mentioned above that you might encounter with different operating
  102.     systems if you do anything operating-system-specific in the
  103.     program).
  104.  
  105.     The only possibility for MS-Windows portability will be Windows
  106.     NT;  an NT program should be fairly easily portable between
  107.     different CPU architectures, but running it under standard
  108.     MS-Windows may not be possible (it would require Win32S, which
  109.     won't run on anything less than a 386, and which does not support
  110.     many of the more advanced features of NT.  Basically what it gets
  111.     you is a 32-bit memory model and some additional graphics calls).
  112.     The main problem at this point is that right now NT seems to be
  113.     thought of as mostly an Intel-based operating system, even though
  114.     there will be versions for various RISC machines.  Therefore the
  115.     availability of code for other architectures (and possibly even
  116.     the availability of the OS for some RISC architectures) may be
  117.     problematic until and unless it becomes popular on RISC machines.
  118.     I prefer to think of these as NT apps rather than as MS-Windows
  119.     apps, but the original question was sufficiently vague that I
  120.     suppose that an NT app could be considered an MS-Windows app for
  121.     this purpose.  In any event, if there's any interest in running
  122.     the app on other operating systems or CPU's, NT still won't get
  123.     you much portability in that respect unless you write X code on NT.
  124.  
  125. This is nothing more then a rough thumbnail sketch;  I may be (and probably
  126. am) leaving out important items.
  127.  
  128. Bruce C. Wright
  129.