I was wondering if anyone with some insight on the NT kernel design
process could shed some light on why Microsoft decided to make such
large system calls. For example, NtCreateFile() takes 11 parameters and
requires 2 structures at minimum to be prepared. On UNIX, it’s a matter
of 3 parameters and no structures. I’m not saying this is wrong, I’m
just curious as to why it’s so ‘feature-rich’.
-Brandon
Having worked in many operating systems over the years, Unix is an
aberration in its simplicity. While it is superficially simple, what it
means is that there are no good ways to specify specific actions, such as
file sharing, etc. Most systems I’ve worked on take many more parameters
to create a file, including things like the desired file protection. Some
did these using a structure and one parameter (the pointer to the
structure). Some did it with no structures and six or ten parameters. So
I do not find the number of parameters out of line, or even unusually
large. What I’m surprised by is the oversimplicity of tbe Unix interface,
which is very limited (for example, most non-Unix people don’t know that a
“file lock” on a section of a file can be ignored by any program, which
leads to some wonderful problems. The nature of the question gives away
the answer: “feature-rich”. This interface had to support Win16, Win32,
and POSIX interfaces when it was created, and potentially many more
options in the future. So there’s lots of flexibility.
Since NtCreateFile was never intended for “consumer use”, there was no
particular reason to make it user-simple. POSIX programmers would see the
Unix _creat interface, (or fopen, which uses _creat); Windows programmers
would see CreateFile. VB programmers would see whatever opens files in
VB.
So wondering why the NtCreateFile interfaces is complex is like wondering
why low-level assembly language is so complex.
joe
I was wondering if anyone with some insight on the NT kernel design
process could shed some light on why Microsoft decided to make such
large system calls. For example, NtCreateFile() takes 11 parameters and
requires 2 structures at minimum to be prepared. On UNIX, it’s a matter
of 3 parameters and no structures. I’m not saying this is wrong, I’m
just curious as to why it’s so ‘feature-rich’.-Brandon
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> I’m just curious as to why it’s so ‘feature-rich’.
Two cornerstones of UNIX philosophy are simplicity and extensibility - as they say, “By programmers, for programmers”. The main problem with NT kernel is that it had been designed by someone who have always thought of UNIX as of a personal foe, and, apparently, refused to “borrow” quite a few concepts from the UNIX world simply as a matter of principle.
As a result, NT kernel lacks VFS, which happens to be an essential part of all modern UNIX kernels; has a peculiar component called “Cache Manager” that works on per-file basis, instead of relying upon disk cache the way all “traditional” systems do; supports paging in the kernel; the concept of IRQL; a “strange” component called 'IO Manager" with complex rules of request handing and cumbersome device stacks, etc,etc,etc. From the programmer’s perspective, this means that doing a thing that is pretty straight-forward under UNIX-like system (like, for example, writing a new file system or network protocol) is a major undertaking under Windows.
In any case, this discussion seems to belong more on NTTALK, rather than NTDEV…
Anton Bassov
> What I’m surprised by is the oversimplicity of tbe Unix interface, which is very limited (for example,
most non-Unix people don’t know that a “file lock” on a section of a file can be ignored by any program,
which leads to some wonderful problems.
Ha-ha-ha…
OK, respect for a file lock is , indeed, obligatory under Windows …but only to those who access it via WriteFile(). It does not apply to those who rely upon file mapping, which means that writes to a file that is accessed via these two interfaces simultaneously by different processes are still not synchronized by the kernel. UNIX people just have realized that it just does not make sense to offer a superficial (and no-workable) “solution” to a problem that just cannot have a reliable solution at the kernel level by its very definition, and made all file locks advisory only…
Anton Bassov
This.
Plus, note that Windows has a single, integrated, comprehensive, security subsystem. This contributes to the parameter count and complexity.
Peter
OSR
>It does not apply to those who rely
upon file mapping, which means that writes to a file that is accessed via these
two interfaces simultaneously by different processes are still not synchronized
by the kernel.
I think you’re mistaken on the concept of LockFile usage model. It implies cooperation between contenders. If you need lock for file-mapping clients, you need to use whole file locking by opening it with the specified flags.
“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:
>
> Two cornerstones of UNIX philosophy are simplicity and extensibility - as they say, “By programmers, for programmers”. The main problem with NT kernel is that it had been designed by someone who have always thought of UNIX as of a personal foe, and, apparently, refused to “borrow” quite a few concepts from the UNIX world simply as a matter of principle.
>
> As a result, NT kernel lacks VFS, which happens to be an essential part of all modern UNIX kernels; has a peculiar component called “Cache Manager” that works on per-file basis, instead of relying upon disk cache the way all “traditional” systems do; supports paging in the kernel; the concept of IRQL; a “strange” component called 'IO Manager" with complex rules of request handing and cumbersome device stacks, etc,etc,etc. From the programmer’s perspective, this means that doing a thing that is pretty straight-forward under UNIX-like system (like, for example, writing a new file system or network protocol) is a major undertaking under Windows.
>
Anton,
It is amazing what you do to history. First Cutler borrowed a lot
of concepts from Multic’s both in VMS and in Windows the same way that
all of us who worked on OS’es in the 1970’s did. Having heard Ritchie
and others speak about Unix shortly after it became available, much of
what they chose to do was a compromise based on the limited size of the
system they had (i.e. a 64KB PDP-11).
Second, VFS was released after Windows NT was released (sort of
hard to copy something that comes out after you). A lot of the network
protocol support also came about after Windows NT (or at least once it
was well along in development). The things you claim are the core of
Unix were addons. Unix was a bitch to use in the mid-1970’s and was
still a pain in the ass in the early 1980’s.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Brandon Falk wrote:
I was wondering if anyone with some insight on the NT kernel design
process could shed some light on why Microsoft decided to make such
large system calls. For example, NtCreateFile() takes 11 parameters and
requires 2 structures at minimum to be prepared. On UNIX, it’s a matter
of 3 parameters and no structures. I’m not saying this is wrong, I’m
just curious as to why it’s so ‘feature-rich’.
I hope people don’t argue to cut this thread, because I think it’s
instructive to consider the etymology of the two systems.
Multics had the more complicated kernel model. The interfaces were
feature-rich and all-inclusive. At the time, this resulted in
development delays and perceived performance issues. It was in that
environment that Unix was born. When Thompson and Ritchie designed
Unix, the complexity that they didn’t like in Multics was foremost in
their mind. That led to a minimalist design. They wanted to get things
done, quickly and simply.
Unix was not originally designed to be a commercial operating system.
The Unix philosophy was academically based, with an assumption that the
user-mode code and the kernel code were cooperative partners. NT, on
the other hand, was built from the start as a large-scale commercial
system, and that includes an assumption that user mode code is
inherently subversive. That results in complexity.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Don,
First Cutler borrowed a lot of concepts from Multic’s both in VMS and in Windows the same way that
all of us who worked on OS’es in…
Could you name a few, apart from the ones of the virtual memory, dynamic linking and accessing devices as files. Furthermore, AFAIK, the form these concepts took under MULTICS are quite different from the one of the modern mainstream OSes. For example, MULTICS concept of a virtual memory is closely related to that of a single-level store (which, btw, MULTICS itself “borrowed” from Atlas system that introduced it back in 1962)
and which does not exist under modern major OSes (although some interest in it among the researchers is still there - KeyKos and its successors come to my mind straight away). AFAIK, although you had to map a file to a process memory, MULTICS did not really have the concept of process address spaces the way we understand it nowadays…
Second, VFS was released after Windows NT was released (sort of hard to copy something that
comes out after you).
AFAIK, Solaris introduced VFS back in 1986, while NT turned up only in 1993…
A lot of the network protocol support also came about after Windows NT (or at least once it
was well along in development).
Oh, I see - according to you, TCP/IP protocol suite (i.e. IP, ICMP, IGMP, UDP, TCP) turned up only after 1993…
The things you claim are the core of Unix were addons.
So you say extensibility and simplicty are addons, right…
Anton Bassov
>I hope people don’t argue to cut this thread, because I think it’s instructive to consider the etymology
of the two systems.
In fact, I think it would be not a bad idea to continue it on NTTALK - this thread seems to be a bit of OT-issue for NTDEV since the very original post. If we keep on comparing Windows and UNIX, I guess this thread may go completely astray so that list slaves will simply lock it…
Anton Bassov
I see this topic is flourishing over in NTTALK, so I’ll lock the thread here.
See you over at NTTALK… And, actually, I think this IS a very interesting topic worthy of discussion.
Peter
OSR
Just to note, not many of the stats Anton produced are out of line :).
Philosophy, I don’t know. But it was not much later when I started my
Unix hacking ( early 80s). By '84 I knew there were lot of TCP/IP
effort going on. My brother was in another lab, where he was actively
involved, and I had to debug his code, over 2400 modem, in exchange I
get to hack / use his IBM PC ( 1st version ).
Comparing to IBM/JCL/PROC/VTAM/TCAM etc., it was a marked departure.
By '83 versions of unix were ported to x86 ( I worked on one) 3B20 was
another one but a mini. By 89, IBM main frame had TCP/IP running.
At any rate, lot of computer science were born ( specially in the
system area) due to Unix being freely distributed to the universities.
But NT was the first true preemptive multi-task OS with integrated
GUI, with such low resource consumption(s).
mmap() was from Unix, but NT had the integration with cache Manager,
which IMO vastly powerful ( and complex). IIRC solaris did the same
thing later… Until recently, Mac was co-operative multi-tasking
OS…
-pro
Peter Viscarola wrote:
I see this topic is flourishing over in NTTALK, so I’ll lock
the thread here.
I don’t see it, am I obtuse?
I only see “Coding style (continued from NTDEV)” and “Finding driver developers”.
No! You are blessed with true insight.
You probably also noticed that the thread here was not locked, as evidenced by your reply not being rejected.
Peter
OSR
Peter,
No! You are blessed with true insight. You probably also noticed that the thread here was not locked,
as evidenced by your reply not being rejected.
I have already started a new fork on NTTALK. Therefore, apparently, at this point you can already lock this discussion here - after all, all of this thread’s participants, apart from Joe, happen to be NTTALK subscribers, so that we can continue it there…
Anton Bassov