Windows doesn't need a bookshelf full with around 15 OReilly books for GUI programming.
Since we are counting arguments:
Window XCreateWindow(
Display *display,
Window parent,
int x,
int y,
unsigned int width,
unsigned int height,
unsigned int border_width,
int depth,
unsigned int class,
Visual *visual,
unsigned long valuemask,
XSetWindowAttributes *attributes
);
Yeah, I don't understand the grandparent on that. The Xt API (and the Athena widget set) were hardly a great work of computer science. But they were relatively clean and easy to understand, and basically invented the "widget" (rectangle on the screen that can draw itself and respond to input in an encapsulated way) component model that we're all still thinking in today.
I wouldn't say Xt invented the "widget", and I would never pass up the opportunity to state most emphatically that Xt widgets are neither clean nor easy to understand.
Here's a video tape by Brad Myers called "All the Widgets" [1] that shows demos of widgets from way back, many of them long before Xt. (Over 175 segments, from 30 systems, from 15 companies!)
All the Widgets, by Brad Myers. This was made in 1990, sponsored by the ACM CHI 1990 conference, to tell the history of widgets up until then. Previously published as: Brad A. Myers. All the Widgets. 2 hour, 15 min videotape. Technical Video Program of the SIGCHI'90 conference, Seattle, WA. April 1-4, 1990. SIGGRAPH Video Review, Issue 57. ISBN 0-89791-930-0.
What kicked Xt's and Motif's ass, especially in terms of power and flexibility, as well as being clean and easy to understand, was TCL/Tk.
The reason TCL/Tk was so successful in spite of how lame TCL was as an scripting language, is that TCL was there from day one of Tk's design, not an afterthought.
As a result, there was no need for Tk to invent a bunch of half-assed kludges, and require applications to build complex Rube Goldberg devices on top of those, when Tk could simply call into TCL to do anything the scripting language interpreter could handle, including calling into the application's C code from TCL.
So there was zero overlap between what the scripting language could do, and what the toolkit needed to do. And that made the toolkit vastly simpler and more consistent, and much easier to flexibly program and modify.
Xt based toolkits like Motif [2] had to built on top of all that half assed pseudo-object-oriented crap trying to reimplement programming language level concepts like objects, components, properties, defaults, inheritance, events, handlers, delegation, layout, etc, in brittle C and macros.
Motif was yet another proof of Greenspun's tenth rule of programming [3]: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
"The only redeeming feature is the documentation."
Lmao. That's close to what I said when I first learned it. I was griping about how complicated window creation was vs some tools I had. "The MSDN docs are awesome, though!"
I never get why some people think the Win32 MSDN doc are appropriate. They are typically several order of magnitude less precise than man-pages on function about a similar topic -- if not just containing a few errors!
I don't think that at the raw level there is that much of a difference. XCreateWindow() has mostly the same arguments as CreateWindowEx() except that the X11 API only handles creating window and does not mash it together with upper layer concepts like event handling (lpClassName) and widget sets (hMenu).
The X11 model is also easier to reason about because it is clear where the layer boundaries are and what is implemented in your process as opposed in the kernel/display server and what causes some kind of IPC (eg. what happens to lParam when you send message to window with WndProc implemented in different process?).
I do UI coding since Amiga 500 days and never found so borked API, with more parameters and configuration structures than Xlib, without any support for printing or proper use of fonts.
The amount of wasted hours of my life using xlsfonts....
And those bare bones widgets, yet another headache.
And yet Xlib ran happily on machines with 4MB of RAM and would only use 512K of that; mind you that was X11R3. I used to run this very config on Apollo Domain/OS machines in 1990.
The Amiga had 512KB for the whole OS, including a GUI stack way better than X.
For us targeting desktop computing, the network features of X were never relevant, what mattered was GUI toolkits for workstation usage, running on the same computer.