Mailing List Archive

On Tue, 15 Mar 2005, [gb2312] Ìï±ó wrote:

> MBX LOCKING
>
> If use_mbx_lock is set (this is supported only if SUPPORT_MBX is defined)
> then the rules used for locking in c-client are used. Exim takes out a shared
> lock on the mailbox file, and an exclusive lock on the file whose name is
> /tmp/.<device-number>.<inode-number>. The shared lock on the mailbox stops
> any other MBX client from getting an exclusive lock on it and expunging it.
> It also stops any other MBX client from unlinking the /tmp lock when it has
> finished with it.
>
> the problem is that the shared lock on the mailbox file deny the
> next writing op to the mailbox in CYGWIN. A permission denied error
> will occur during copy_mbx_message call becuase of the shared lock.
>
> and i think the shared lock doen't make sense, it should be a
> exclusive lock. maybe the shared lock behave well in linux or other
> OS, but how about if the filesystem is mounted with mandatory
> locking? i'm not familar with linux, and i'm just wondering.

The MBX locking rules are specifically defined by the folks who invented
the MBX mailbox format. The whole idea is to enable the use of shared
mailboxes. I have a document entitled

UNIX Advisory File Locking Implications on c-client
Mark Crispin, 28 November 1995

which describes the method, and also has a lot of detail about problems
with locking in different flavours of Unix. It is all a horrible mess
(the locking, I mean, not the document).

I am not surprised that problems arise with CYGWIN, but there is no way
that the MBX locking rules will be changed in Exim.

Why do you want to use MBX mailboxes, anyway? Is there some problem
with the default Berkeley mailbox format?

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

On Tue, 15 Mar 2005, Philip Hazel wrote:

> On Tue, 15 Mar 2005, [gb2312] Ìï±ó wrote:
>
> The MBX locking rules are specifically defined by the folks who invented
is there a well documented specification?
> the MBX mailbox format. The whole idea is to enable the use of shared
> mailboxes. I have a document entitled
>
> UNIX Advisory File Locking Implications on c-client
> Mark Crispin, 28 November 1995
>
> which describes the method, and also has a lot of detail about problems
> with locking in different flavours of Unix. It is all a horrible mess
> (the locking, I mean, not the document).
>
> I am not surprised that problems arise with CYGWIN, but there is no way
> that the MBX locking rules will be changed in Exim.
I downloaded a copy of uw-imap source code and read through the section of
mbx.
I found that mbx_open (open a mailbox)and mbx_append (append message to a
mailbox) are implemented differently in locking the mailbox.
mbx_open get a exclusive lock on the temp file and a shared lock on the
mailbox, then release the exclusive lock on the temp file.
But mbx_append only acquire a exclusive lock on the temp file after
opengin the mailbox file. There is no code acquiring a shared lock on the
mailbox.
I'm wondering if the exim implements mbx open according to mbx_open of
uw-imap, or some documented specification says it must be implemented this
way. If a specification exists, I really wish to have a read. If no, I
think exim sould do as mbx_append when delivery mail using mbx format.
>
> Why do you want to use MBX mailboxes, anyway? Is there some problem
> with the default Berkeley mailbox format?
The default mailbox format works well. I'm building a mail server under
CYGWIN recently. I use exim as the MTA (exim is really an excellent work).
A imap server is also needed. But I found only uw-imap in CYGWIN setup.
The document of uw-imap says mbx format is preferred, so i got a try and
found the problem.
>
> --
> Philip Hazel University of Cambridge Computing Service,
> ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
> Get the Exim 4 book: http://www.uit.co.uk/exim-book

On Wed, 16 Mar 2005, sparrow wrote:

> I downloaded a copy of uw-imap source code and read through the section of
> mbx.

It was a long time ago, but the comments in the Exim code claim that it
uses the same rules as the c-client library. These are documented in a
long comment in the src/transports/appendfile.c module. Well, it's not
that long, so I'll include it here:

MBX LOCKING

If use_mbx_lock is set (this is supported only if SUPPORT_MBX is defined)
then the rules used for locking in c-client are used. Exim takes out a shared
lock on the mailbox file, and an exclusive lock on the file whose name is
/tmp/.<device-number>.<inode-number>. The shared lock on the mailbox stops
any other MBX client from getting an exclusive lock on it and expunging it.
It also stops any other MBX client from unlinking the /tmp lock when it has
finished with it.

The exclusive lock on the /tmp file prevents any other MBX client from
updating the mailbox in any way. When writing is finished, if an exclusive
lock on the mailbox can be obtained, indicating there are no current sharers,
the /tmp file is unlinked.

MBX locking can use either fcntl() or flock() locking. If neither
use_fcntl_lock or use_flock_lock is set, it defaults to using fcntl() only.
The calls for getting these locks are by default non-blocking, as for non-mbx
locking, but can be made blocking by setting lock_fcntl_timeout and/or
lock_flock_timeout as appropriate. As MBX delivery doesn't work over NFS, it
probably makes sense to set timeouts for any MBX deliveries.

> I'm wondering if the exim implements mbx open according to mbx_open of
> uw-imap, or some documented specification says it must be implemented this
> way. If a specification exists, I really wish to have a read. If no, I
> think exim sould do as mbx_append when delivery mail using mbx format.

I suspect there is no document, sadly, but it is some years since I
looked at this.

I am very, very, very, hesitant to make any change to this code at this
stage. It has been this way for a long time, and locking problems are
notoriously easy to create and difficult to solve.


--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

> On Tue, 15 Mar 2005, Philip Hazel wrote:
>
> > On Tue, 15 Mar 2005, [gb2312] ���� wrote:
> >
> > The MBX locking rules are specifically defined by the folks who invented
> > the MBX mailbox format. The whole idea is to enable the use of shared
> > mailboxes.

Indeed... but what does that mean, exactly? Let's have a look.

> > I have a document entitled
> >
> > UNIX Advisory File Locking Implications on c-client
> > Mark Crispin, 28 November 1995

The following is from that document:

This form of locking makes fewer presumptions, but it still is
guilty of presumptions (2) and (4) above. Presumption (2)
limits the ability to have processes sharing a resource in a
non-conflicting fashion (e.g. reading from a file). Presumption
(4) leads to deadlocks should the process crash while it has a
resource locked.

We seem to be talking about sharing mailbox files in RO mode.

On Wed, Mar 16, 2005 at 10:15:31AM +0800, sparrow wrote:
> I downloaded a copy of uw-imap source code and read through the section of
> mbx.
> I found that mbx_open (open a mailbox)and mbx_append (append message to a
> mailbox) are implemented differently in locking the mailbox.
> mbx_open get a exclusive lock on the temp file and a shared lock on the
> mailbox, then release the exclusive lock on the temp file.
> But mbx_append only acquire a exclusive lock on the temp file after
> opengin the mailbox file. There is no code acquiring a shared lock on the
> mailbox.

I think a careful reading of the cited document supports this reading
of the code. The point of the mbx format, IIRC, is to allow multiple
clients to concurrently READ the same file. However, when write
access is required (i.e. to append a message to a file), which I'm
making a baseless assumption that is the only mode in which exim will
operate on the file, only the exclusive lock is needed. Exim has no
need of a shared lock, because it (AFAIK) has no need to hold the file
open for reading... Isn't that the case?

> I'm wondering if the exim implements mbx open according to mbx_open of
> uw-imap, or some documented specification says it must be implemented this
> way. If a specification exists, I really wish to have a read. If no, I
> think exim sould do as mbx_append when delivery mail using mbx format.

Based only on my understanding of what Exim is doing (that being
delivering mail), the reading of the cited document, and discussion
here, without reviewing the code for either program, it seems to me
that Exim does not implement locking consistently with c-client.
There seems to be no point whatever to the shared lock...

I've reviewed this document before in regard to another program, and I
think a number of things are worth pointing out:

1. It was written 10 years ago. Much has changed in the Unix world by
now. For example:

- the bugs in most statd's and lockd's have long since been worked
out.
- fcntl() locking is part of the POSIX standard, and is now
available on almost any reasonably modern Unix variant. It's true
that legacy systems still won't have it, but IMNSHO sites which
refuse to migrate from guaranteed broken, positively unfixable
systems deserve whatever they get...
- It's reasonable to think that the several other bugs Crispin
mentions are either fixed by now or caused by site-specific
misconfigurations, and in either case not the purview of the
application developer.

2. All that said, my understanding is that it is STILL the case that,
in a heterogenious environment, NO LOCKING METHOD WORKS RELIABLY
OVER NFS. If all of your systems are homogenous and have known
working statd and lockd implementations, locking on NFS is OK, but
ONLY IF THE RIGHT METHOD IS USED ON THAT PLATFORM. The normal way
to do this is to use the link(2) system call (see the Linux open(2)
man page, in the explanation of O_EXCL, or see W. Richard Stevens,
_Advanced Programming in the Unix Environment_, for the details).

A friend of mine who is a kernel developer, and former maintainer
of Linux NFS utils, told me that the method mentioned in that man
page also suffers from a race condition on NFS, and is not
reliable. After nfs-utils was fixed in version 0.3.5 or some such,
the only reliable method of locking over NFS on Linux has been
fcntl() locking, so I am told. However, this information is itself
3 years old, and may or may not still be accurate.

The upshot of all that, I think, is that developers should stick to
fcntl() locking from heretofor (and abandon platforms that still don't
have it, if there are any), and assume that locking simply will not
work over NFS, and warn users away from putting contentious files on
NFS-mounted filesystems. To be specific, NFS-mounted mail spools are
dangerous, especially in heterogenious environments.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

On Wed, 16 Mar 2005, Derek Martin wrote:

> We seem to be talking about sharing mailbox files in RO mode.

Yes, that's how I understand it.

> Exim has no need of a shared lock, because it (AFAIK) has no need to
> hold the file open for reading... Isn't that the case?

Yes, but it has to interwork with other clients who may be opening the
file for reading. When I implemented this, I thought I understood it
(this was quite a few years ago now). It was one of those things that
needed really careful analysis and clear thought. I have not retained
the detailed understanding, and would have to think it all through again
to be sure of what goes on. Since I implemented it, there have been no
reports of problems - but then, how many people use MBX mailboxes?

> Based only on my understanding of what Exim is doing (that being
> delivering mail), the reading of the cited document, and discussion
> here, without reviewing the code for either program, it seems to me
> that Exim does not implement locking consistently with c-client.
> There seems to be no point whatever to the shared lock...

Things may have changed in c-client. Exim's code hasn't changed in this
area for a very long time. ("If it ain't broke" - or perhaps "if it
ain't been reported as broke" :-)

> 1. It was written 10 years ago. Much has changed in the Unix world by
> now.

Absolutely true. However, this thread originated as a CYGWIN thing, and
(nice though it is to know that Exim works in that environment) my main
concern is that Exim works in the "real" Unix world.

> 2. All that said, my understanding is that it is STILL the case that,
> in a heterogenious environment, NO LOCKING METHOD WORKS RELIABLY
> OVER NFS.

I wonder why we have had no problems with user mailboxes on NFS (for a
system with three separate hosts) over the last 8 or so years, then?
The last problem caused a "final" fix to the locking code in Exim. Of
course, it uses lock files and link(), not plain fcntl() or flock().

[.Note also that when I wrote Exim, I used only fcntl(). The ability to
use flock() was added later, after user pressure.]


--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

On Thu, Mar 17, 2005 at 08:46:45AM +0000, Philip Hazel wrote:
> to be sure of what goes on. Since I implemented it, there have been no
> reports of problems - but then, how many people use MBX mailboxes?

That's a valid point... When I was working on an IMAP implementation,
I never even considered support of MBX, mainly because in all my years
as a sysadmin, and in dealing with various forms of e-mail software,
I've never once encountered anyone who used it (other than perhaps
experimentally).

> Things may have changed in c-client. Exim's code hasn't changed in this
> area for a very long time. ("If it ain't broke" - or perhaps "if it
> ain't been reported as broke" :-)

Indeed...

> > 1. It was written 10 years ago. Much has changed in the Unix world by
> > now.
>
> Absolutely true. However, this thread originated as a CYGWIN thing, and
> (nice though it is to know that Exim works in that environment) my main
> concern is that Exim works in the "real" Unix world.

Understood. OTOH, if it is a legitimate bug, knowing about it,
wouldn't you want to fix it?

> > 2. All that said, my understanding is that it is STILL the case that,
> > in a heterogenious environment, NO LOCKING METHOD WORKS RELIABLY
> > OVER NFS.
>
> I wonder why we have had no problems with user mailboxes on NFS (for a
> system with three separate hosts) over the last 8 or so years, then?

It could just be that you've been lucky...

In all honesty, the race conditions involved are (as I understand it)
such that should be exceedingly rare to encounter a problem. It would
mean that the MDA and the MUA would have to, at the exact same time,
both request an exclusive lock on the same file, and the request which
came over NFS came first but was interrupted before it completed.
Even on busy mail spool files, how likely is that to happen? You'd
probably only ever see a problem on really busy mail servers, with
unusually high loads. Otherwise, since both the MUA and MDA spend
most of their time waiting around for stuff to happen, I imagine once
they are woken up to do some file I/O, it's really unlkely that a
context switch would occur in the middle of a request to obtain a
lock...

But, that doesn't mean it will never happen... If it did happen, it
might be with such infrequency that noone would think to attribute it
to a locking problem. It may even have happened at a site under your
contol, and you never heard about it, because the user didn't report
it, or something of the sort.

Even with the old, broken nfs-utils on Linux, the occurence of data
corruption/loss under these circumstances was largely unheard of. But
that doesn't mean it never happened... More likely it did, but with
sufficient infrequency that no cause was ever attributed, and the data
loss was written off as "just one of those things..." Obviously I'm
theorizing.

And, again, with the OS vendors constantly doing development to fix
these kinds of problems, it may be that there really isn't a problem
anymore. Perhaps the probability of a loss occuring is
satisfactorally low that it's worth the risk in the name of
convenience.

Personally, given that there are other potential (security) problems
with NFS spools, in addition to potential locking issues, I would
never consider allowing it in my environment. But environments vary,
and there may be very little risk of either kind of problem in
yours... I still think it's worth a strong caution against doing it.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

On Thu, 17 Mar 2005, Derek Martin wrote:

> Understood. OTOH, if it is a legitimate bug, knowing about it,
> wouldn't you want to fix it?

Yes, I would. The problem here is in the knowing... :-)

> > I wonder why we have had no problems with user mailboxes on NFS (for a
> > system with three separate hosts) over the last 8 or so years, then?
>
> It could just be that you've been lucky...
>
> In all honesty, the race conditions involved are (as I understand it)
> such that should be exceedingly rare to encounter a problem.

Did I mention that we do you the lock files + link() trick? As well as
fcntl() locks. Looks like I forgot.

> It would mean that the MDA and the MUA would have to, at the exact
> same time, both request an exclusive lock on the same file, and the
> request which came over NFS came first but was interrupted before it
> completed. Even on busy mail spool files, how likely is that to
> happen?

I did say "mailboxes", not spool files. (Assuming the Exim usage of
the word "spool".) I wouldn't put a mail spool (in the Exim sense) on
NFS. But from your mention of MUAs, I guess you were meaning mailboxes.

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

On Fri, 18 Mar 2005, I wrote:

> Did I mention that we do you the lock files + link() trick?
^^^

I meant "use" of course. Sheesh. The connection between brain and
fingers is getting lossy...

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

On Fri, Mar 18, 2005 at 09:12:15AM +0000, Philip Hazel wrote:
> On Thu, 17 Mar 2005, Derek Martin wrote:
>
> > Understood. OTOH, if it is a legitimate bug, knowing about it,
> > wouldn't you want to fix it?
>
> Yes, I would. The problem here is in the knowing... :-)

I've written e-mail to Mark Crispin asking about the impolementation.
If/when I receive an answer, I'll forward the results.

> > > I wonder why we have had no problems with user mailboxes on NFS (for a
> > > system with three separate hosts) over the last 8 or so years, then?
> >
> > It could just be that you've been lucky...
> >
> > In all honesty, the race conditions involved are (as I understand it)
> > such that should be exceedingly rare to encounter a problem.
>
> Did I mention that we do you the lock files + link() trick? As well as
> fcntl() locks. Looks like I forgot.

You hadn't mentioned it. I will point out that, in cases where two
different operating systems are communicating over NFS, each of which
has a different working method of locking over NFS, this MAY still not
be sufficient to solve the problem (though it goes a long way in the
majority of cases)... It depends on the precise manifestation of the
locking poblem. If one method doesn't work for the client OS, and the
other doesn't work for the server OS, you still don't have a reliable
lock...

However, I think in the majority of cases, the lock would fail due to
race conditions on the server side. If so, this should be enough to
solve the problem. It would be nice to have a current and accurate
survey of what locking methods work where, and why they fail... =8^)

On Fri, Mar 18, 2005 at 10:12:54AM +0000, Philip Hazel wrote:
> > Did I mention that we do you the lock files + link() trick?
> ^^^
>
> I meant "use" of course. Sheesh. The connection between brain and
> fingers is getting lossy...

<grin>


--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

On Fri, Mar 18, 2005 at 10:58:32AM -0500, Derek Martin wrote:
> I've written e-mail to Mark Crispin asking about the impolementation.
> If/when I receive an answer, I'll forward the results.

Here's Mark's response (with a couple of short comments of mine).
Mark, thanks for your quick response.

On Fri, Mar 18, 2005 at 11:22:41AM -0800, Mark Crispin wrote:
> As it is, I agree and disagree with both sides. Please don't quote me
> unless you quote this response in its entirety.
>
> That old locking paper that I wrote does not specifically deal with mbx
> format, which has a number of semantics that are unique to it. However,
> on the crudest level, the text about tenex and mtx applies.
>
> It is correct that, for appending, the current c-client code only acquires
> the exclusive parse/append lock (on the /tmp file) and does not acquire a
> shared lock on the actual mbx mailbox file. However, this may change in
> the future when the delete/rename code gets restructured.
>
> The bottom line is that there is no harm on UNIX in acquiring a shared
> lock on the mailbox file prior to initiating an append; and in the future
> it may become mandatory.

[Here seems to be the crux of the matter:]
> The problem in mail delivery on Cygwin is due to a bug in Cygwin; it does
> not emulate flock() correctly. Cygwin uses the Windows LockFileEx() to
> implement flock(), even though Windows LockFileEx() is mandatory and UNIX
> flock() is advisory. The UNIX mbx driver *requires* that flock() be
> advisory.
>
> As a workaround, instead of using Cygwin's broken flock(), Exim can use
> the Cygwin version of the flocksim() code in c-client. This code only
> applies the lock on the first byte of the file and goes through the
> fcntl() interface. Make sure that it uses the flockcyg.c version and not
> other versions which are also in c-client.
>
> I recommend this as a far superior path for Exim to take than to remove
> the shared lock.
>
> Now, onto the necessary "cover my posterior"...:
>
> I do NOT support Cygwin in c-client. Cygwin does not implement true UNIX
> semantics; it implements an unpredictable mix of UNIX and Windows
> semantics.
>
> Although a modest amount of effort has been made to get some aspects of
> UNIX c-client to work under Cygwin, there are several known problems that
> will never be fixed. The answer to these problems is: "there's a native
> Windows port of c-client."
>
> Furthermore, c-client under Cygwin does *not* interoperate with native
> Windows c-client. This is a recipe for disaster.
>
> I can't speak for Philip Hazel, but I guess that he may have similar
> sentiments about Exim under Cygwin.

FWIW, I wholeheatedly agree with this sentiment from Mark:
> Personally, I find it bewildering that anyone would want to run something
> as complex as a mailer (such as Exim) under Cygwin, rather than any of the
> following far superior solutions:
> . run a native Windows mailer
> . run true UNIX instead of UNIX
[I think he meant something like, "...instead of UNIX emulation" there]

> . do a true Windows port of Exim
> . use VMware to run true UNIX under Windows
>
> There are limits to what a system call compatibility package (which is
> what Cygwin is) can do for you. Please keep this in mind.
>
> I don't want to sound harsh, but I get very nervous when people start
> talking about software running under Cygwin in starry-eyed terms which
> imply support. Thanks for your understanding.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.


--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

On Fri, 18 Mar 2005, Derek Martin wrote:
>> . run true UNIX instead of UNIX
> [I think he meant something like, "...instead of UNIX emulation" there]

Yup. Brain fart. Thanks... ;-)

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

On Fri, 18 Mar 2005, Derek Martin wrote:

> On Fri, Mar 18, 2005 at 11:22:41AM -0800, Mark Crispin wrote:

> > The bottom line is that there is no harm on UNIX in acquiring a shared
> > lock on the mailbox file prior to initiating an append; and in the future
> > it may become mandatory.

That reinforces my view that Exim should continue to do this.

> > Although a modest amount of effort has been made to get some aspects of
> > UNIX c-client to work under Cygwin, there are several known problems that
> > will never be fixed. The answer to these problems is: "there's a native
> > Windows port of c-client."
> >
> > Furthermore, c-client under Cygwin does *not* interoperate with native
> > Windows c-client. This is a recipe for disaster.
> >
> > I can't speak for Philip Hazel, but I guess that he may have similar
> > sentiments about Exim under Cygwin.

Absolutely (though there is no native Windows port of Exim). I have done
exactly the same - put in a couple of patches that were small and had
zero effect on the Unix version, but that's as far as I'm prepared to
go. I do not offer any support.

> > Personally, I find it bewildering that anyone would want to run something
> > as complex as a mailer (such as Exim) under Cygwin, rather than any of the
> > following far superior solutions:
> > . run a native Windows mailer
> > . run true UNIX instead of UNIX
> [I think he meant something like, "...instead of UNIX emulation" there]

Me too!

> > . do a true Windows port of Exim

Twice (to my knowledge), people have gone away with the code of Exim to
try to do that; in each case, I heard nothing more. I know zilch about
Windows (never used it, let alone programmed for it), but I suspect the
mismatch of system facilities is just too great.

> > I don't want to sound harsh, but I get very nervous when people start
> > talking about software running under Cygwin in starry-eyed terms which
> > imply support. Thanks for your understanding.

You don't sound harsh. You sound completely on target. I'm right there
with you.

Philip

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book

On Mon, 21 Mar 2005, Philip Hazel wrote:
>>> . do a true Windows port of Exim
> Twice (to my knowledge), people have gone away with the code of Exim to
> try to do that; in each case, I heard nothing more. I know zilch about
> Windows (never used it, let alone programmed for it), but I suspect the
> mismatch of system facilities is just too great.

It's not as bad as all that, but it is true that, sooner or later, in
doing any Windows port of a UNIX application you come to a major fork in
the road between "the Windows way of doing things" and "thus UNIX way of
doing things." At first, the latter looks like the much easier road, but
presently you start encountering deep ruts in the road...

Windows does a good job of doing POSIX stuff; but the notion that "POSIX
is all you need" is rather quickly dashed. Cygwin does a good job of
paving the road quite a bit further, but it won't take you all the way.

My conclusion from my experience is that simple applications port pretty
well, but the more sophisticated the application, the more that you need
to consider the host operating system's native mode of operation.

If I were to undertake the task of porting a complex UNIX application,
such as Exim, to Windows, I would first strip down Exim to its "essential"
aspects (e.g., such things as its queue management) and completely replace
its interfaces. The minute you ask yourself "how do I fork or make a hard
link under Windows?", you're on the road with the ruts without 4-wheel
drive...

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.