Subject: Windows NT/W2K, Borland compilation

From: Frans Meijer <[email-masked]>
Date: Sat, 25 Sep 2004 16:18:24 +0200 (W. Europe Daylight Time)

Questions about compiling the toolkit with Borland pop up once in a
while, frequently enough to warrant a postion on the FAQ, so here is a
report of an attempt to do so.

It is not a difficult task, some changes to the makefiles and a few
changes to some os dependant files, yunchan.h, env_nt.h, yunchan.c and
env_nt.c.

The biggest change is with the NT compatability functions,
create_tempfile and close_file.

Borland's compiler fell over the reference to _tmpfname. The functions
create_tempfile and close_file apparently assume these to be a member of
the FILE structure. Not in Borlands C-lib, but this one has a simple
flag (istemp) which tells fclose() to unlink the file, after closing.
This one does appear to remove the temporary file.

It is still neccesary to keep the creat_tempfile workaround though, BC's
tmpfile() will also create a file in the current working directory. If
fiddling with the internals of the FILE structure is a bit awkward, a
list with streams opened by create_tempfile could be maintained. Upon
closing a stream, those listed could be removed (after closing).

Compilation also failed on a define relating to the sleep function,
removing the #define for sleep removed the problem, Borland has a
sleep(seconds) function.

getpid() is available, removed the define in env_nt.h.

imap4r1.c has 'unreachable code at lines 3013-3039. Has nothing to do
with the compiler, I think.

random() is random(num) in BC-lib: #define random rand

A number of standard C-lib symbols were referenced by their underscored
name, such as _stricmp. I edited these to their regular names. Was there
a specific reason to use these versions? Or was it just a name-mangling
thing for the linker?

Well, that is it, or most of it. Lots of warnings about 'suspicious
pointer conversions', prototypes, that sort of stuff. But the library,
mtest and mailutil compiled and seem to work as expected. I haven't
touched the imapd and popd servers yet. Is there a more thorough
'testbed' for the c-client lib, the tools and the pop and imap daemons?

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Vadim Zeitlin <[email-masked]>
Date: Sat, 25 Sep 2004 16:48:09 +0200 (Romance Daylight Time)

On Sat, 25 Sep 2004 16:18:24 +0200 (W. Europe Daylight Time) Frans Meijer <[email-masked]> wrote:

FM> A number of standard C-lib symbols were referenced by their underscored
FM> name, such as _stricmp. I edited these to their regular names. Was there
FM> a specific reason to use these versions?

 These are not standard C library functions, they're standard Unix ones
(for this one) or POSIX ones (for _open(), _read(), ...). For this reason,
i.e. to avoid confusion with ANSI C functions, Microsoft compiler headers
define them with underscore prefix. The underscore-less versions are only
defined ("for compatibliity", according to a comment in the headers) if
__STDC__ is not set but it would be a bad idea to unset it.

 The standard solution is to have something like

	#ifdef _MSC_VER
		#define open _open
		...
		#define stricmp _stricmp
	#endif

in some header when one still wants to use these functions.

 Regards,
VZ

---

From: Shawn Walker <[email-masked]>
Date: Sat, 25 Sep 2004 12:52:48 -0500

So heres the situation, i call mail_fetch_flags() on "1:*" to have 
c-client fetch flags on all messages in a folder, I then loop over each 
message number and call mail_elt() on it, and use the returned info for 
getting my information about a messages flags.  This works great the 
first time through.  However, if I do this again after modifying the 
flags on the server (for instance, \Seen), the return from mail_elt() 
still has the old flag info (despite having called mail_fetch_flags() 
again).  Am I approaching this incorrectly? not telling c-client to 
refresh its cache correctly? or have I stumbled on a bug? (I am guessing 
one of the former, not the later). Thanks in advance for any 
thoughts/suggestions/advice, subject was "Stale message flags" feel free 
to edit/change as necessary
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Sun, 26 Sep 2004 11:58:05 -0700 (PDT)

On Sat, 25 Sep 2004, Shawn Walker wrote:
> So heres the situation, i call mail_fetch_flags() on "1:*" to have c-client 
> fetch flags on all messages in a folder, I then loop over each message number 
> and call mail_elt() on it, and use the returned info for getting my 
> information about a messages flags.  This works great the first time through. 
> However, if I do this again after modifying the flags on the server (for 
> instance, \Seen), the return from mail_elt() still has the old flag info

Either you have not modified the flags on the server, or the server is 
broken.

> (despite having called mail_fetch_flags() again).

Calling mail_fetch_flags() again is a waste of network bandwidth.  All it 
does is slow down your client.  The IMAP protocol automatically updates 
flags on the client.

Once the cache is loaded, it stays loaded and current.

The *only*, and I do mean *only*, reason *ever* to call mail_fetch_flags() 
is if you intend to reference flags in your client without otherwise 
touching at the message.  In that case, and that case *only*, the cache 
may not have been loaded.

Calling mail_fetch_flags() on "1:*" is generally a very bad idea.  There 
is almost always a better way to do what you intend.

-- Mark --

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