From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.os.ms-windows.advocacy,comp.os.os2.advocacy
Subject: Re: Some more misconceptions regarding OS/2 and NT
Date: 26 Jul 92 23:39:27 GMT
Followup-To: comp.os.ms-windows.advocacy
Organization: Auspex Systems, Santa Clara

(Another silly Distribution: line - and especially amusing, as the
German Federal Republic was, when last I checked, not part of North
America, so either Mr. Rommel isn't reading it from a machine in
Germany, or the Distribution: line doesn't restrict distribution of
articles in the fashion that some people probably think it does.  I'll
bet on the latter being true, but I'll get rid of the stupid "na"
distribution in any case.  It was probably stuck in by some site running
news software that was trying to be "helpful" by giving a default
distribution other than "world"; I wish they'd stop being so "helpful".

For the benefit of those non-North American readers who *didn't* see the
previous articles, the topic under discussion is the POSIX "fork()"
operation, and its implementation in the Windows NT and in a possible
OS/2 POSIX-compatibility environment.)

>OS/2 (and I think NT too) provide DLL's. Of course, many Unixes have
>shared libraries too, but I don't know if they provide all the features
>of DLL's. For example, DLL's under OS/2 may have shared data between
>all instances. This allows to put some kind of "server" for a ressource
>into a DLL with shared data and have several clients connect to it.

No, none of the UNIX shared library mechanisms I know of provide such a
mechanism, although many of them do provide shared-memory mechanisms
that would allow the library code to be written in such a way as to
build such per-library data.  (For example, a dynamically-linked SunOS
4.x or System V Release 4 or OSF/1 shared library could "mmap()" a file
MAP_SHARED.)

>Now, what should happen if such a client forks? Should it be
>disconnected from the DLL?

Well, the equivalent UNIX mechanism would *not* result in such a
disconnection; "fork()" does not delete any mappings into the process's
address space.

>Difficult. Otherwise, how could the DLL be
>told that there is now an additional client? This at least is
>impossible.

Well, that depends on whether the dynamically-linked library (which, it
appears, is inequivalent to "DLL", as "DLL" appears to refer
specifically to the OS/2 and, presumably, Windows mechanism; I use
"dynamically-linked library", as the issues aren't restricted to systems
whose dynamically-linked libraries are also "DLL"s) cares whether
there's an additional client or not.

If there are some that do, then either:

	1) there would have to be some way for a dynamically-linked
	   library to request that it be notified on a "fork()"; this is
	   probably doable under the UNIX systems described above
	   (remember, "fork()" is, in most UNIX systems, a user-mode
	   library routine; it generally executes a trap into the
	   kernel, but it's not forbidden from doing anything else, as
	   long as it doesn't cause compatibility problems), and might
	   be doable under Windows or OS/2;

or

	2) the application would have to know that the
	   dynamically-linked library requires such notification, and
	   would have to notify the library itself.

The latter could be a problem, given that in SunOS 4.x and SVR4,
possibly in OSF/1, and possibly in Windows and OS/2, most of the
official binary application-program interface to the system is defined
in terms of procedure calls to routines in dynamically-linked libraries.

This means that any binary interface of that sort would have to be
defined, from the start, as requiring such notification; you couldn't
plug a new version of a dynamically-linked library into the system that
required such explicit notification, if previous versions didn't require
that notification.

>Now, if NT provides a POSIX layer next to to Windows (and perhaps OS/2)
>layer, this POSIX layer may provide fork

If it's a POSIX 1003.1 layer, it *WILL* provide "fork()", by definition
(if it doesn't provide "fork()", it's not 1003.1-compliant). 

>- but without DLL's, I guess.
>DLL's would probably only be in the Windows and OS/2 API's in NT.

Not necessarily - those DLL's that don't require the aforementioned
notification shouldn't have problems, and if it's possible for those
that do to request notification from "fork()", or if it's possible for
them to request explicit notification from their users, even those that
do shouldn't have problems.
Newsgroups: comp.os.ms-windows.advocacy