They didn't mention that pango should bring gtk a better text widget. Pango should supply a text widget that actually has horizontal scroll bars, and better performance.
Umm, what makes you believe that Pango has anything to do with any of the stuff that the new text widget does better, other than stuff involving, well, displaying text in various languages?
Hopefully it will make it easier to make a html widget for gtk / gnome
Wouldn't it be cool to include ALL OS's? Not just the *NIX's (getting one package manager to correctly handle both BSD and Linux is a complicated task as it is), but Mac, Windows, etc?
I don't know whether you'd ever get all the *NIXes to adopt one package format (heck, not even all of the *NIXes that use the Linux kernel use the same package format, so far; is it even possible to generate an RPM that works, for a given instruction-set architecture, on all distributions that use RPM?).
It's probably even more unlikely that you'd get Windows, or MacOS Classic (MacOS X might be considered "one of the *NIXes", although it may be different enough from other *NIX-flavored OSes that it'd be even less likely that it'd adopt some standard package format).
If they could get something that would reliably install stuff under Win2K (InstallShield really doesn't cover it),
It might be possible to have tools such as Easy Software Product's Package Manager (as mentioned in another posting; ESP are the folks who do CUPS) work with various non-*NIX packaging tools, as well as handling the various *NIX package formats it now handles (debs, RPMs, SVR4 packages, IRIX packages of some sort, HP-UX packages of some sort, source tarballs).
The must be using a better DSL than the standard ADSL the most providers use. Maybe the ISDN DSL (IDSL or what ever it's called).
IDSL may be "better" in terms of how far from the central office it can go, but it's typically not "better" in terms of how much bandwidth you can get - it's just running, as I understand it, a raw bit stream over an ISDN line, i.e., instead of splitting a basic rate 144K bits/second ISDN line into 2 64K bits/second B channels and 1 16K bits/second D channel, they just give you one 144K bits/second channel (or maybe you only get 128K bits/second). ADSL often goes up to 384K bits/second to the subscriber, or better, and 128K bits/second from the subscriber (my service is "at least" 384K/128K, but my downloads are typically around 1.1Mb/sec).
It may be VDSL (others in this thread have spoken of VDSL in this context), which is higher speed than typical ADSL.
There was a line of IBM mainframes 8360 (used to run VM/ESA stuff) that had 31 bit CPUs!
No, those were 32-bit CPUs (in the sense of having 32-bit general registers), like all IBM S/3x0's; they just happened to have 31-bit virtual addresses, unlike earlier S/3x0's, which had 24-bit virtual addresses even though they had 32-bit registers. (At least on the ones with 24-bit addressing, the uppermost 8 bits of the address were ignored - just like the original 68000; the 31-bit S/3x0's had a mode bit so they could run applications in 24-bit mode, in case somebody'd stuffed extra data into the upper 8 bits of pointers, relying on them being ignored. I think similar problems cropped up when Apple went from the 68000 to the 68020 in Macs.)
I dunno what OSes you might run on them apart from Ultrix and possibly OSF/1.
NetBSD? ("NetBSD/pmax is the port of NetBSD to Digital Equipment Corporation's MIPS based computers. NetBSD/pmax runs on wide range of DECstation and DECsystem family. NetBSD/pmax is the first port which can run on either MIPS R3000 processors or MIPS R4400 processors; single kernel can run common set of user programs.")
BBN sold an OS for the '10 called TENEX, and when TOPS-20 came out (looking quite like it in some respects)
I'd been under the impression that DEC had {bought,licensed,whatever} TENEX and turned it into TOPS-20, i.e. the reason TOPS-20 looked quite like TENEX was that it pretty much was TENEX.
The "traditional UNIX filesystem" was called something like "ss5",
Actually, originally, it wasn't called anything, as it didn't need to be called anything - it was the only UNIX file system there was (at least in UNIXes from AT&T), so it didn't need a name to distinguish it from other file systems.
I think of it as "the V7 file system", as it first showed up in the UNIX often called Version 7 (although it was really the UNIX that came with the Seventh Edition of the document "The UNIX Time-Sharing System"; it always amused me when companies referred to V7 as "Release 7.0", or something such as that implying that there was any formal Official Release Process - as far as I know, it was "what was on the main Research UNIX machine at the time they decided to make the tape").
That was the basis of the file system in System V (SV boosted the block size to 1K bytes from 512 bytes, and I think made a few other minor changes) , so some might think of it as the System V file system, e.g. "s5fs". (It was also the basis of the file system in 4BSD prior to 4.2BSD.)
Oh, and the dipstick that said "snapshots" were dangerous needs to get a clue.
I think at least one of those postings was joking about the "atomic" part, as per the "Geiger counter" comment later in the posting.
The FFS (Berkeley Fast File System) is an optimized file system based upon the earlier UFS (Unix File System).
Not exactly.
Originally, there was the 4.2BSD file system; this was 18 years ago, so memories have faded a bit, but I think that it was, indeed, called the "fast file system".
Sun dubbed the Berkeley file system "UFS" when they put vnodes into "Sun UNIX 4.2BSD Release 2.0" or whatever they called it (this was before "SunOS" was coined).
Berkeley, in, I think, 4.3BSD (or was it 4.3-tahoe, or a later version?) came out with a modified version called the "fat fast file system" ("fat" is lower-case; this helps avoid confusion with the "FAT" in the DOS file system), sometimes called FFFS. Sun picked that up when it came out, so that UFS, at that point, was the FFFS, not the FFS.
Various organizations have subsequently extended the Berkeley file system in various ways, e.g. many of them have added access control lists, implemented "fast symlinks" whose contents are stored in the inode itself (instead of storing block pointers in the inode, for short symlinks the actual target pathname is stored), the 4.4BSD per-inode flags (system immutable, user immutable, etc.).
So, unless by "UFS" you meant the file system that came with The UNIX Time-Sharing System, Seventh Edition (which was the basis of the 4.1BSD file system, as well as the System V file system), FFS is not "an optimized file system based on the earlier UFS", as "UFS" at Sun was just the FFS. (And, frankly, I wouldn't say that FFS was based on the V7 file system; the FFS was intended to implement a superset of the same semantics as the V7FS, and took some implementation ideas from it, but shared little, if any, code, and few on-disk data structures, with it.)
Re:PDP-11 != DECSYSTEM 10, but TOAD-1 does.
on
PDP-10 Revival
·
· Score: 2
They're not even really called PDP-10's: the real name is DECSYSTEM 10.
Well, they were originally called PDP-10s; I guess the DEC marketoons (or should that be "Digital marketoons"?:-)) decided to change the name, maybe because "PDP" was what they called minicomputers, but the '10's were Systems or something such as that.
Re:pdp-10 ran UNIX therefore...
on
PDP-10 Revival
·
· Score: 2
Thompson and Ritchie wrote the first version of UNIX on a PDP-11. I just read the paper last week.
You mean the paper that starts out with "There have been three versions of UNIX. The earliest version (circa 1969-70) ran on the Digital Equipment Corporation PDP-7 and PDP-9 computers."?
The first version Ritchie was involved with might've been one of the PDP-11 versions, but the very first UNIX was on the PDP-7 (the -9 was compatible with the -7; both were 18-bit machines, along with the -15).
Unless, of course, you had a KA-10 without the fast registers option, in which case the registers were in core. (Did the PDP-6 have the registers in core, or were they flip-flops?)
I wonder how long it'll take to turn samba admin into a 'control panel', and be done with Dave.
Be done with DAVE (if by that you mean, as I suspect is the case, Thursby Software's DAVE) for people using it as an SMB server, that is. For people using DAVE as a client, you'd need to have something like the smbfs for FreeBSD ported to MacOS X. (I don't know how hard it is to port a FreeBSD file system to the MacOS X kernel; I'm assuming here that it'd be easier than porting the Linux smbfs.)
It sounds as if the person who asked the question to which you responded was saying that VMS allows different threads in a process to have different privileges. The NT per-thread security described by the stuff to which you linked isn't per-thread security in the sense of "what the thread is allowed to do", it's per-thread security in the sense of "what other processes are allowed to do to the thread".
Last I checked, the BPF has to be compiled into the kernel, and is NOT there by default.
In the 2.2[.x] Linux kernel, you have to configure the socket filter code on; it's not on by default (for reasons not obvious to me).
(If you're referring to the BSD BPF code, that has to be compiled in on some BSDs, although it's there by default in recent FreeBSDs and possibly in other BSDs; however, if it's not there, you can't do packet capture at all - the in-kernel BPF engine is an integral part of the BPF packet capture mechanism, unlike Linux where you can have PF_PACKET sockets without the socket filter.)
so you don't have to cut and paste the frigging URL from the article's text.
I also seem to remember some discussion of some IDE setting perhaps being more conservative on Linux than on BSD in an earlier Slashdot article about that benchmark.
Sometimes benchmarking results get read as "release x.y of OS A did better than release z.w of OS B in this benchmark, so OS A is better than OS B" rather than as "...so release x.y of OS A may be better than release z.w of OS B for this particular type of task". The fact that release x.y of OS A did better than release z.w of OS B doesn't, in and of itself, demonstrate that OS A will always be better than OS B at that particular task (which should be borne in mind by fans of Linux, {Free,Net,Open}BSD, Windows NT (which includes W2K), Solaris, etc.). The OSes in question are "moving targets"....
Well, looking at the date on that page (01 October 1998) it seems to me that this info just might be just a tad out of date. Have you actually looked at what's in the 2.4 kernel? Maybe things haven't changed, but it sure wouldn't harm to have a look before fudding.
The item in Linux on that page says
Current releases of the supported versions of Linux (Red Hat and Slackware) do not use BPF or DLPI. Instead, libpcap sniffs packets by reading packets one by one into user space. The packets source address is compared against its interface name. This implies that all interfaces send all data to all promiscuous listening processes and that the user code is responsible for determining if a packet is interesting.
The packet sniffing mechanisms available in 2.0[.x] kernels, err, umm, suck. 2.2 introduced a better mechanism, and if you've configured in the right kernel option ("Socket Filter" or something such as that) it supports doing packet filtering at the kernel level (i.e., uninteresting packets aren't copied up to userland).
Some Linuxes come with libpcap libraries that use the new mechanism; the current CVS version of libpcap at the tcpdump.org Web site, and the beta versions of libpcap 0.6, also use the new mechanism.
2.4 has, I believe, a mechanism that shares a memory-mapped buffer between the kernel and userland; I don't know if any versions of libpcap use it yet.
So Linux may now do a better job, at least if you configure the socket filter code into your kernel. It doesn't have any buffering mechanism to "batch up" multiple packets in one recvfrom() call, the way BPF and the bufmod STREAMS module on Solaris do; the 2.4 mechanism (which will, I think, eliminate a copy) might obviate the need for that.
(People are looking at similar memory-mapped mechanisms for BSD. Had I bothered to implement the "memory-mapped stream head" stuff I was thinking about ages ago at Sun, it might've been available in Solaris as well; so it goes....)
Note that on Solaris, the same "everything is copied to userland" problem exists that exists on some versions of Linux; I'm not sure why the NFR document speaks of the Linux mechanism as being lower-performance - it may be due to the lack of a buffering mechanism to batch up packets. (They speak of HP-UX, which also lacks such a buffering mechanism, as requiring more CPU for that reason.)
Re:I waited for that a long time
on
GTK+ without X!
·
· Score: 2
But this is pretty cool for platform with no X, or for ports (say BeOS, or Mac OS X).
For ports, "this", in the sense of GTK+-fb, isn't relevant; what's relevant is that ports can be done, to a large extent, by changing the GDK layer, rather than by changing stuff all over GTK+.
I think the Win32 port, which antedates the frame buffer port, was also done largely at the GDK layer.
I'm still left wondering exactly what the actual size limit is
It's potentially dependent on what OS you're running; it's not limited on some OSes, and may be limited on others. Try a limit command in the C shell or compatible shells, or ulimit -a in the Bourne shell or compatible shells (the latter may not work on some OSes).
how to work around it
In a program, put in a setrlimit() call that sets the RLIMIT_CORE limit to RLIM_INFINITY (if the OS for which the program is being built supports setrlimit() and RLIMIT_CORE - if it doesn't support them, there's probablly either no limit or a limit that can't be changed; if it doesn't define RLIM_INFINITY, try a maximum-sized integral value).
From the command line (i.e., if the debug version of the program doesn't work around it), use the limitulimit (Bourne shell and compatibles) command. (If they don't let you get or set the limit, there's probably either no limit or a limit that can't be changed.)
Now, you may think its the worst thing in the world, but we never hear about Max Microserf and his great contributions to Win2k...
Well, err, umm, at one point, there was a "Dave Cutler's Fan Club Page" - see the reference to it in one of the comments in this Slashdot article - but it seems to have disappeared.
The silence on IA64 from the BSD crowd is deafening.
Low volume != silence. There is an IA64 FreeBSD port in progress, although it's in its very early stages; I don't know whether the NetBSD folk are doing anything with IA64, but they've probably at least considered it.
OpenVMS (no relation) and NT are two prominent operating systems that use a microkernel archetecture.
NT's kernel isn't all that micro; network-layer and transport-layer protocols, file systems, and the drivers to which they talk live in kernel-mode code. Some of the Win32 environment is provided by a privileged user-mode server process, but this isn't one of those "almost all the real work is done in servers" microkernesl.
VMS was, at least at one point, more microkernelish, as file systems were implemented in user-mode Ancillary Control Processes (or whatever ACP stood for); I have the impression that the file system code may have moved into kernel or executive mode, however.
And he is, refreshingly, fairly contemptuous of the effect of (relatively) unearned wealth on people and communities. Check out the "greed" gruntle on his site.
Slashdot Mirror
Umm, what makes you believe that Pango has anything to do with any of the stuff that the new text widget does better, other than stuff involving, well, displaying text in various languages?
You mean a widget such as GtkHTML?
Or not. I don't necessarily install only source packages, even on BSD or Linux...
...and, from what I see on the Ethereal mailing lists, I'm not the only one; there are plenty of people who install binaries of Ethereal, for example.
I don't know whether you'd ever get all the *NIXes to adopt one package format (heck, not even all of the *NIXes that use the Linux kernel use the same package format, so far; is it even possible to generate an RPM that works, for a given instruction-set architecture, on all distributions that use RPM?).
It's probably even more unlikely that you'd get Windows, or MacOS Classic (MacOS X might be considered "one of the *NIXes", although it may be different enough from other *NIX-flavored OSes that it'd be even less likely that it'd adopt some standard package format).
It might be possible to have tools such as Easy Software Product's Package Manager (as mentioned in another posting; ESP are the folks who do CUPS) work with various non-*NIX packaging tools, as well as handling the various *NIX package formats it now handles (debs, RPMs, SVR4 packages, IRIX packages of some sort, HP-UX packages of some sort, source tarballs).
Some tools for packaging on Windows include MindVision's Installer VISE (available for Windows and MacOS), for which "qualifying shareware and freeware developers" can get a free license (it's what the GTK+ and GIMP for Windows uses), and Nullsoft's "SuperPimp" Install System, which is also free. (I've not used either of them, so I can't say how good or bad they are.)
Well, there's a tool called nmake, which comes as part of a package called "Visual C++" from some company up in Redmond, Washington that has done some software for Windows; its makefiles aren't exactly like those for the various *NIXes (but those aren't all the same, either - you have System V make, Sun's make which is a superset of SV make, GNU make, Berkeley make, etc.).
It's not clear that it's a package manager's job to deal with the differences between the "make"s on various platforms.
IDSL may be "better" in terms of how far from the central office it can go, but it's typically not "better" in terms of how much bandwidth you can get - it's just running, as I understand it, a raw bit stream over an ISDN line, i.e., instead of splitting a basic rate 144K bits/second ISDN line into 2 64K bits/second B channels and 1 16K bits/second D channel, they just give you one 144K bits/second channel (or maybe you only get 128K bits/second). ADSL often goes up to 384K bits/second to the subscriber, or better, and 128K bits/second from the subscriber (my service is "at least" 384K/128K, but my downloads are typically around 1.1Mb/sec).
It may be VDSL (others in this thread have spoken of VDSL in this context), which is higher speed than typical ADSL.
No, those were 32-bit CPUs (in the sense of having 32-bit general registers), like all IBM S/3x0's; they just happened to have 31-bit virtual addresses, unlike earlier S/3x0's, which had 24-bit virtual addresses even though they had 32-bit registers. (At least on the ones with 24-bit addressing, the uppermost 8 bits of the address were ignored - just like the original 68000; the 31-bit S/3x0's had a mode bit so they could run applications in 24-bit mode, in case somebody'd stuffed extra data into the upper 8 bits of pointers, relying on them being ignored. I think similar problems cropped up when Apple went from the 68000 to the 68020 in Macs.)
I'd been under the impression that DEC had {bought,licensed,whatever} TENEX and turned it into TOPS-20, i.e. the reason TOPS-20 looked quite like TENEX was that it pretty much was TENEX.
Actually, originally, it wasn't called anything, as it didn't need to be called anything - it was the only UNIX file system there was (at least in UNIXes from AT&T), so it didn't need a name to distinguish it from other file systems.
I think of it as "the V7 file system", as it first showed up in the UNIX often called Version 7 (although it was really the UNIX that came with the Seventh Edition of the document "The UNIX Time-Sharing System"; it always amused me when companies referred to V7 as "Release 7.0", or something such as that implying that there was any formal Official Release Process - as far as I know, it was "what was on the main Research UNIX machine at the time they decided to make the tape").
That was the basis of the file system in System V (SV boosted the block size to 1K bytes from 512 bytes, and I think made a few other minor changes) , so some might think of it as the System V file system, e.g. "s5fs". (It was also the basis of the file system in 4BSD prior to 4.2BSD.)
I think at least one of those postings was joking about the "atomic" part, as per the "Geiger counter" comment later in the posting.
Not exactly.
Originally, there was the 4.2BSD file system; this was 18 years ago, so memories have faded a bit, but I think that it was, indeed, called the "fast file system".
Sun dubbed the Berkeley file system "UFS" when they put vnodes into "Sun UNIX 4.2BSD Release 2.0" or whatever they called it (this was before "SunOS" was coined).
Berkeley, in, I think, 4.3BSD (or was it 4.3-tahoe, or a later version?) came out with a modified version called the "fat fast file system" ("fat" is lower-case; this helps avoid confusion with the "FAT" in the DOS file system), sometimes called FFFS. Sun picked that up when it came out, so that UFS, at that point, was the FFFS, not the FFS.
Various organizations have subsequently extended the Berkeley file system in various ways, e.g. many of them have added access control lists, implemented "fast symlinks" whose contents are stored in the inode itself (instead of storing block pointers in the inode, for short symlinks the actual target pathname is stored), the 4.4BSD per-inode flags (system immutable, user immutable, etc.).
So, unless by "UFS" you meant the file system that came with The UNIX Time-Sharing System, Seventh Edition (which was the basis of the 4.1BSD file system, as well as the System V file system), FFS is not "an optimized file system based on the earlier UFS", as "UFS" at Sun was just the FFS. (And, frankly, I wouldn't say that FFS was based on the V7 file system; the FFS was intended to implement a superset of the same semantics as the V7FS, and took some implementation ideas from it, but shared little, if any, code, and few on-disk data structures, with it.)
Well, they were originally called PDP-10s; I guess the DEC marketoons (or should that be "Digital marketoons"? :-)) decided to change the name, maybe because "PDP" was what they called minicomputers, but the '10's were Systems or something such as that.
You mean the paper that starts out with "There have been three versions of UNIX. The earliest version (circa 1969-70) ran on the Digital Equipment Corporation PDP-7 and PDP-9 computers."?
The first version Ritchie was involved with might've been one of the PDP-11 versions, but the very first UNIX was on the PDP-7 (the -9 was compatible with the -7; both were 18-bit machines, along with the -15).
Unless, of course, you had a KA-10 without the fast registers option, in which case the registers were in core. (Did the PDP-6 have the registers in core, or were they flip-flops?)
Be done with DAVE (if by that you mean, as I suspect is the case, Thursby Software's DAVE) for people using it as an SMB server, that is. For people using DAVE as a client, you'd need to have something like the smbfs for FreeBSD ported to MacOS X. (I don't know how hard it is to port a FreeBSD file system to the MacOS X kernel; I'm assuming here that it'd be easier than porting the Linux smbfs.)
It sounds as if the person who asked the question to which you responded was saying that VMS allows different threads in a process to have different privileges. The NT per-thread security described by the stuff to which you linked isn't per-thread security in the sense of "what the thread is allowed to do", it's per-thread security in the sense of "what other processes are allowed to do to the thread".
In the 2.2[.x] Linux kernel, you have to configure the socket filter code on; it's not on by default (for reasons not obvious to me).
(If you're referring to the BSD BPF code, that has to be compiled in on some BSDs, although it's there by default in recent FreeBSDs and possibly in other BSDs; however, if it's not there, you can't do packet capture at all - the in-kernel BPF engine is an integral part of the BPF packet capture mechanism, unlike Linux where you can have PF_PACKET sockets without the socket filter.)
Actually, he meant
so you don't have to cut and paste the frigging URL from the article's text.
I also seem to remember some discussion of some IDE setting perhaps being more conservative on Linux than on BSD in an earlier Slashdot article about that benchmark.
In any case, please note that Slide 42 says:
Sometimes benchmarking results get read as "release x.y of OS A did better than release z.w of OS B in this benchmark, so OS A is better than OS B" rather than as "...so release x.y of OS A may be better than release z.w of OS B for this particular type of task". The fact that release x.y of OS A did better than release z.w of OS B doesn't, in and of itself, demonstrate that OS A will always be better than OS B at that particular task (which should be borne in mind by fans of Linux, {Free,Net,Open}BSD, Windows NT (which includes W2K), Solaris, etc.). The OSes in question are "moving targets"....
The item in Linux on that page says
The packet sniffing mechanisms available in 2.0[.x] kernels, err, umm, suck. 2.2 introduced a better mechanism, and if you've configured in the right kernel option ("Socket Filter" or something such as that) it supports doing packet filtering at the kernel level (i.e., uninteresting packets aren't copied up to userland).
Some Linuxes come with libpcap libraries that use the new mechanism; the current CVS version of libpcap at the tcpdump.org Web site, and the beta versions of libpcap 0.6, also use the new mechanism.
2.4 has, I believe, a mechanism that shares a memory-mapped buffer between the kernel and userland; I don't know if any versions of libpcap use it yet.
So Linux may now do a better job, at least if you configure the socket filter code into your kernel. It doesn't have any buffering mechanism to "batch up" multiple packets in one recvfrom() call, the way BPF and the bufmod STREAMS module on Solaris do; the 2.4 mechanism (which will, I think, eliminate a copy) might obviate the need for that.
(People are looking at similar memory-mapped mechanisms for BSD. Had I bothered to implement the "memory-mapped stream head" stuff I was thinking about ages ago at Sun, it might've been available in Solaris as well; so it goes....)
Note that on Solaris, the same "everything is copied to userland" problem exists that exists on some versions of Linux; I'm not sure why the NFR document speaks of the Linux mechanism as being lower-performance - it may be due to the lack of a buffering mechanism to batch up packets. (They speak of HP-UX, which also lacks such a buffering mechanism, as requiring more CPU for that reason.)
For ports, "this", in the sense of GTK+-fb, isn't relevant; what's relevant is that ports can be done, to a large extent, by changing the GDK layer, rather than by changing stuff all over GTK+.
I think the Win32 port, which antedates the frame buffer port, was also done largely at the GDK layer.
There are people working on a BeOS version of GTK+ - there's a GTK+ for BeOS page on the GTK+ Web site, and somebody's been sending patches to the gtk-devel mailing list.
It's potentially dependent on what OS you're running; it's not limited on some OSes, and may be limited on others. Try a limit command in the C shell or compatible shells, or ulimit -a in the Bourne shell or compatible shells (the latter may not work on some OSes).
In a program, put in a setrlimit() call that sets the RLIMIT_CORE limit to RLIM_INFINITY (if the OS for which the program is being built supports setrlimit() and RLIMIT_CORE - if it doesn't support them, there's probablly either no limit or a limit that can't be changed; if it doesn't define RLIM_INFINITY, try a maximum-sized integral value).
From the command line (i.e., if the debug version of the program doesn't work around it), use the limitulimit (Bourne shell and compatibles) command. (If they don't let you get or set the limit, there's probably either no limit or a limit that can't be changed.)
This mail message to "gtk-devel" from Owen Taylor" says
(presumably meaning in the main CVS branch; i.e., it'll eventually be in 2.0, but probably not 1.2[.x]).
Well, err, umm, at one point, there was a "Dave Cutler's Fan Club Page" - see the reference to it in one of the comments in this Slashdot article - but it seems to have disappeared.
Low volume != silence. There is an IA64 FreeBSD port in progress, although it's in its very early stages; I don't know whether the NetBSD folk are doing anything with IA64, but they've probably at least considered it.
NT's kernel isn't all that micro; network-layer and transport-layer protocols, file systems, and the drivers to which they talk live in kernel-mode code. Some of the Win32 environment is provided by a privileged user-mode server process, but this isn't one of those "almost all the real work is done in servers" microkernesl.
VMS was, at least at one point, more microkernelish, as file systems were implemented in user-mode Ancillary Control Processes (or whatever ACP stood for); I have the impression that the file system code may have moved into kernel or executive mode, however.
For more information, see the BESM-6 Nostalgia Page.
Or the "don corleone" gruntle, which is also apposite.