Re^5: Nobody Expects the Agile Imposition (Part VI): Architecture

[BrowserUk]

one quote I remember was that Win32 will never have Unix-like signals because Dave shouted "signals are a crock".

I've also heard that one. And from memory, it was related to me by someone (who claimed to be) in the meeting at the time. Which is about as good a defintion of hearsay as I can think of, but it did reinforce my long term impression that if anything, NT went out of its way to trying to avoid borrowing anything at all from unix.

There are obviously many things that every OS has to have in common. And many more that are so obvious that when independent teams set out to solve the same problem, similar solutions are bound to arise.

Hence, virtual memory, developed by IBM (as Virtual Storage) for OS/VS and MVS is an integeral part of any modern OS, including *nix and NT, but it would be churlish to say that they borrowed (often written as "stole") the concept from IBM.

BTW, I'm not a fan of signals either and they certainly don't mix very well with threads.

One analogy I read about signals was imagine what would happen if your car just instantly stopped, frozen in place--mid-corner or wherever--when your mobile phone rang. Cos that's what signals do to your code. And that kind of speaks to the fundamental difference between *nix and NT.

for example, compare and contrast the many complex parameters and sub parameters of the Win32 CreateProcess call with Unix fork and exec.

The NT kernel was written from the ground up to me multitasking. The entire kernel was written to be reentrant. That is, all the of the state associated with a given process (actually, thread) is maintained within the auspices of that entity, or keyed by a handle specific to that entity. It is effectively object oriented, albeit it that the restrictions of C mean that it doesn't use object syntax at the API level so you have to manually pass the object reference (handle) to the relevant APIs manually.

This shows up (at the kernal API level) in such things as the pids, tids and fids; which are available but are mostly not used at the API level, where opaque handles are used instead.

Another example is memory buffers. In *nix, these are routinely allocated by the kernel and passed back to the application program. The Win32 API forces the application program to allocate the memory for the buffer and pass it's address into the kernel.

The advantages of this approach really show up when writing code that will live in a dynamically linked library, where the same code may be executing concurrently in the auspices of many threads and many processes.

[ELISHEVA]

Your reply above was why I had belated moved my comment about NT/Unix to a separate reply from my IBM history reply (I hadn't realized you were already composing a response - sorry about that). I wanted to see a fuller discussion from you.

I've been doing some more browsing because that memory of some ribbing in the press for "unix borrowings" (whatever that means) is fairly firm. Based on your comments above and also a book review I found covering a book on the development of NT, I suspect the ribbing quality came from some rather public anomisity towards Unix by the NT team, but I only suspect. I have no memory of that either way and haven't read the book - just the "so there" quality in the press.

The comment about claiming A is like B because of superficial similarities rings a bell. While browsing around the web looking for where and what was behind whatever it was I remember being reported, I came across an article in InfoWorld way back when in 1987 arguing that *DOS* "borrowed" from Unix because it had pipes. InfoWorld, Aug 3, 1987:

from the start, DOS has been influenced by Unix. DOS 2.0 explicitly incorporated directory structures, pipes, redirection and other features that had long been hallmarks of other systems.

It may also be that those reporting on NT and OS/2 development falsely understood the built-in POSIX support as "Unix borrowings". According to Wikipedia,

Windows NT-based operating systems up to Windows 2000 had a POSIX layer built into the operating system, and UNIX Services for Windows provided a UNIX-like operating environment.

My only quibble with your post is this line: "There are obviously many things that every OS has to have in common."

They may have to, but by what definition? There are many things we now assume as must haves in OS's that were not part of some early operating systems - including multi-tasking. I agree that superficial borrowings of features are not the same as borrowing core internal architecture. On the other hand, the features that eventually became attractive enough to be "must-have" s in other systems, were built-in right from the start in *nix.

I do think we have to be careful about assuming that what now seems to us a no-brainer was always commonly accepted as so. The best innovations are tricky that way: once they are stated they seem so obvious we wonder why they are even innovative.

[BrowserUk]

the features that eventually became attractive enough to be "must-have" s in other systems, were built-in right from the start in *nix.

Hm. I've been trying to avoid getting into a full chronological review of OS development as it is all pretty well documented on-line, but the reality is that if modern users of (say) Linux sat down at the console of a machine running the early version of unix, they would find very little that they recognised.

And if they attempted to program those early versions, they'd feel that same way that modern kids would if you made them swap their iPhones for CB radios. Very little of what constitutes a modern *nix, even by the original POSIX-1 definition, was a part of unix "from the very start".

Even such stalwarts of what is now seen as fundamental *nix--tcp/ip, sockets, locking and much more--simply didn't exist until many years later after the unix-wars, when the IEEE POSIX initiative pulled them back together from System V, BSD, Xenix/SCO etc.

And a whole bunch more of what went into the original unix came from different pre-existing systems. Multics: hierarchal filesystem, swap space. RSX/VMS:the User/Group/Other file permissions mechanism. (Actually, this mechanism appeared almost unchanged in much earlier DEC OSs.)

Even the much quoted unix pipes mechanism closely resembles the 'communications files' mechanism from DTSS.

Almost nothing that made up the original unix was either completely original, or revolutionary. Indeed, the historical success and usability of *nix comes more from what they left out from Multics and the other contemporary OSs, as from what they put in. Much like Perl, their great achievement was in cherry-picking the very best ideas from many systems and putting them together as a coherent single entity that worked for programmers.

Perhaps the single biggest innovation that can be attributed to *nix, is the "everything is a file" architecture. That is what makes the unix shells work, but even that is a double-edged sword.

[Anonymous Monk]

That is what makes the unix shells work, but even that is a double-edged sword.

Twice as awesome :)

[eyepopslikeamosquito]

It may also be that those reporting on NT and OS/2 development falsely understood the built-in POSIX support as "Unix borrowings". According to Wikipedia, Windows NT-based operating systems up to Windows 2000 had a POSIX layer built into the operating system, and UNIX Services for Windows provided a UNIX-like operating environment.

The media may have been taken in by the Windows NT "POSIX subsystem" but most developers saw through it as a cynical ploy to allow Microsoft to tick the "POSIX compliant" box required by some government contracts, without actually being usable. The POSIX subsystem was (deliberately?) crippled by being unable (by design) to properly interoperate with the Win32 subsystem and most developers accordingly avoided it like the plague (again writing this from memory of 10+ years ago when we briefly considered using it but opted instead for Win32 subsystem Unix emulation layers). To paraphrase Dave Cutler, "Microsoft Windows Unix products are a crock". :) Generally, 3rd party Unix toolkits (eg. Cygwin) are preferred.