Date: Fri, 2 Feb 2001 19:57:52 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jcm@FreeBSD-uk.eu.org (j mckitrick) Cc: tlambert@primenet.com (Terry Lambert), freebsd-chat@FreeBSD.ORG Subject: Re: software development tools - microsoft and unix Message-ID: <200102021957.MAA12520@usr08.primenet.com> In-Reply-To: <20010202134033.A91283@dogma.freebsd-uk.eu.org> from "j mckitrick" at Feb 02, 2001 01:40:33 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> | A secondary problem with Windows, which is _not_ common to all
> | versions (which is why many shops choose to develope on NT), is
> | that it is really not a true protected mode OS. Because of this,
>
> Now that win2k is becoming established, and appears to be quite robust, what
> does this mean for the future of professional programming? It certainly
> makes the environment much more attractive to programmers who need that kind
> of stability. I've heard the TCP/IP performance is vastly improved as well.
This is a misconception. The value of a protected mode OS for
a user is, in fact, stability.
The value of a protected mode OS for a developer, who will only
be running a limited set of known tools, is more in how rigidly
the OS enforces _all_ boundaries.
For example, it is not particularly useful to trap a NULL pointer
dereference in a production user's environment. Sure, you crash
only the offending program, but the user loses work, or at best,
fails to accomplish work.
In a developement environment, the only option on a failed NULL
pointer dereference is to correct the failure. The result is
code which will not fail when moved to a production setting.
A secondary issue for the production environment is resource
tracking. The common FIN-WAIT-2 problem, caused by bad Windows
clients, is a resource tracking problem, having to do with
WINSOCK being implemented in user space, so that resources can
not be tracked by the OS (specifically: socket descriptors).
It's actually possible, in a resource tracking OS, to have a
mode where the close call on a socket causes console messages,
and complains if "shutdown" was not called. If this is done,
when the code is then recompiled for the non-protected mode OS,
then you can know that it won't have this failure mode. Again,
the result is better code.
Right now, neither NT nor FreeBSD support this level of interface
enforcement, though they are protected mode OSs (I personally
would implement them as a "SIGBUG", which was by default
ignored, so that a debugger/audit program could trap the code
problems and report them to the programmer, et least as a UNIX
implementation). The point is rather that this level of
enforcement is completely impossible in a non-protected mode
OS.
For the same reasons, "purify" can't run without OS assistance,
so on OSs where the assistance is unavailable, it either has a
reduced functionality, or it simply is not available. For
example, it's a kernel tuning variable on SVR4 whether or not,
when a NULL pointer dereference occurs, a zeroed page is mapped
into page zero, or a fault is generated; by default, a new
page is mapped. A program like "purify", looking for NULL
pointer dereferences, will either require that this be tuned and
recompiled (but there are many important system programs that
stupidly dereference NULL pointers), or have to step through the
program, and notice the automatic handling of the fault by
watching the page map (something that is available through procfs
on SVR4, and should be available on BSD).
Ideally, your OS would inherently have "purify" features that
don't require preprocessing (e.g. array bounds checking), to
the extent that it could.
Really, you want your OS to be as rigid as possible when it is
enforcing things; then when you go to production (perhaps on a
different OS), you can be assured that your program will work.
I remember the controversy when we started unmapping page zero,
but I also know that we got better code as a result of having
done that.
It would be really nice, for example, if FreeBSD could turn off
all interfaces which were not common between it and other UNIX
OSs. That would mean that you could immediately switch all
your UNIX developement to FreeBSD, and be certain that the
resulting program would compile and run on all other UNIX
platforms.
PS: This is largely a rehash of a source-level equivalent to my
argument for a FABIO developement environment.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102021957.MAA12520>