On Wed, 22 Oct 2003, Eduardo Chappa wrote: > There is no > way I can predict what a user will do when using Pine, and you must know > very well that ignoring a possible case is one of the main reasons why > users report bugs, so I would like to offer a full featured (or as much > complete as possible) software for people in Cygwin. This means that if > they want simultaneous access to a mailbox, they'll need to get it if the > format of the mailbox allows it.
Once again... Simultaneous access in the mbx format requires meaningful file locking. There is no such thing as meaningful file locking in Windows 98. Windows 98 is not a real operating system. Nor are Windows 95, Windows Me, Windows 3.1, MS-DOS, Mac OS 9 (and earlier), etc. If you wish to have real operating system services, then you must run a real operating system. Windows NT, 2000, and XP are real operating systems. UNIX and its variants are real operating systems. Mac OS X is a real operating system. Cygwin is not a real operating system either. It is one of long series of similar products (e.g. Yale Tools, Mint, MachTen, MKS Toolkit) which provide UNIX-like library calls and compiler semantics on a different operating system (in this case, Windows). However, like all these other products, it is (and always will be) an incomplete compromise. In some cases, it will provide the service by translating the call to a similar call on the host operating system. In other cases, it must implement that service as best it can within its own environment. And in still other cases, it has to punt and provide methods into the host environment (such as the interface into the Windows concepts of logon and impersonate). Cygwin apparently implements fcntl() locking via the Windows LockFileEx() call. This implementation is *NOT* correct for UNIX, but it is close. One of these implementation bugs is a good thing, the other is not; hence the special handling required for Cygwin. LockFileEx() does not exist on the MS-DOS based versions of Windows (3.1, 95, 98, Me). If you use one of those systems, you have to live with the fact that you don't have meaningful locking. Life is tough. > I see no reason why PC-Pine and Cygwin > Pine could not be exchanged one for the other. Any favorable interaction between PC Pine and a UNIX Pine built under Cygwin is completely coincidental and is not (nor ever will be) guaranteed. This is the price that you pay for using a kludge that hacks one operating system's semantics on top of another. They may be extremely useful kludges, but they are (and always will be) limited. Most people who use such things understand these limitations. On top of that, you are expecting services out of the MS-DOS versions of Windows that do not exist. > I believe it's a priority to offer access to mbx folders to any user of > Pine/imapd/popXd, for any version of Windows, and that's the trick that > must be done. It may be a priority for you. It is not for me; and quite frankly it is a pipe-dream. The MS-DOS versions of Windows do not have the capabilities necessary to performs mbx-style shared access. The MS-DOS versions of Windows are dead products, and never will have those capabilities. Nor do I want to waste much more of my time having to explain this to you. > So my question still stands, does this patch work for Windowx 9X?, can > anyone confirm or deny this? The question is meaningless. There is no "works for Windows 9x" in the sense of "operates with the full functionality of modern systems." -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
