NOTE: The comments in this file relate to the original WinCE portdone by Tristan Savatier. The semaphore routines have been completely rewritten since (2005-04-25), having been progressivelybroken more and more by changes to the library. All of the semaphoreroutines implemented for W9x/WNT/2000 and up should now also work forWinCE. Also, pthread_mutex_timedlock should now work. [RPJ]----Some interesting news:I have been able to port pthread-win32 to Windows-CE,which uses a subset of the WIN32 API.Since we intend to keep using pthread-win32 for ourCommercial WinCE developments, I would be very interestedif WinCE support could be added to the main source treeof pthread-win32.  Also, I would like to be creditedfor this port :-)Now, here is the story...The port was performed and tested on a Casio "Cassiopeia"PalmSize PC, which runs a MIP processor.  The OS in theCasio is WinCE version 2.11, but I used VC++ 6.0 withthe WinCE SDK for version 2.01.I used pthread-win32 to port a heavily multithreadedcommercial application (real-time MPEG video player)from Linux to WinCE.  I consider the changes thatI have done to be quite well tested.Overall the modifications that we had to do are minor.The WinCE port were based on pthread-win32-snap-1999-05-30,but I am certain that they can be integrated very easielyto more recent versions of the source.I have attached the modified source code:pthread-win32-snap-1999-05-30-WinCE.All the changes do not affect the code compiled on non-WinCEenvironment, provided that the macros used for WinCE compilationare not used, of course!Overall description of the WinCE port:-------------------------------------Most of the changes had to be made in areas wherepthread-win32 was relying on some standard-C librairies(e.g. _ftime, calloc, errno), which are not availableon WinCE. We have changed the code to use native Win32API instead (or in some cases we made wrappers).The Win32 Semaphores are not available,so we had to re-implement Semaphores using mutexesand events.Limitations / known problems of the WinCE port:----------------------------------------------Not all the semaphore routines have been ported(semaphores are defined by Posix but are not partpf pthread).  I have just done enough to makepthread routines (that rely internally on semaphores)work, like signal conditions.I noticed that the Win32 threads work slightlydifferently on WinCE.  This may have some impacton some tricky parts of pthread-win32, but I havenot really investigated.  For example, on WinCE,the process is killed if the main thread falls offthe bottom (or calls pthread_exit), regardlessof the existence of any other detached thread.Microsoft manual indicates that this behavior isdeffirent from that of Windows Threads for otherWin32 platforms.Detailed descriptions of the changes and rationals:------------------------------------- use a new macro NEED_ERRNO.If defined, the code in errno.c that defines a reentrant errnois compiled, regardless of _MT and _REENTRANT.Rational: On WinCE, there is no support for <stdio.h>, <errno.h> orany other standard C library, i.e. even if _MT or _REENTRANTis defined, errno is not provided by any library.  NEED_ERRNOmust be set to compile for WinCE.------------------------------------- In implement.h, change #include <semaphore.h> to #include "semaphore.h".Rational: semaphore.h is provided in pthread-win32 and should notbe searched in the systems standard include.  would not compile.This change does not seem to create problems on "classic" win32(e.g. win95).------------------------------------- use a new macro NEED_CALLOC.If defined, some code in misc.c will provide a replacementfor calloc, which is not available on Win32.------------------------------------- use a new macro NEED_CREATETHREAD.If defined, implement.h defines the macro _beginthreadexand _endthreadex.Rational: On WinCE, the wrappers _beginthreadex and _endthreadexdo not exist. The native Win32 routines must be used.------------------------------------- in misc.c:#ifdef NEED_DUPLICATEHANDLE	  /* DuplicateHandle does not exist on WinCE */	  self->threadH = GetCurrentThread();#else	  if( !DuplicateHandle(			       GetCurrentProcess(),			       GetCurrentThread(),			       GetCurrentProcess(),			       &self->threadH,			       0,			       FALSE,			       DUPLICATE_SAME_ACCESS ) )	    {	      free( self );	      return (NULL);	    }#endifRational: On WinCE, DuplicateHandle does not exist.  I could not understandwhy DuplicateHandle must be used.  It seems to me that getting the currentthread handle with GetCurrentThread() is sufficient, and it seems to workperfectly fine, so maybe DuplicateHandle was just plain useless to begin with ?------------------------------------- In private.c, added some code at the beginning of ptw32_processInitializeto detect the case of multiple calls to ptw32_processInitialize.Rational: In order to debug pthread-win32, it is easier to compileit as a regular library (it is not possible to debug DLL's on winCE).In that case, the application must call ptw32_rocessInitialize()explicitely, to initialize pthread-win32.  It is safer in this circumstanceto handle the case where ptw32_processInitialize() is called onan already initialized library:intptw32_processInitialize (void){	if (ptw32_processInitialized) {		/* 		 * ignore if already initialized. this is useful for 		 * programs that uses a non-dll pthread		 * library. such programs must call ptw32_processInitialize() explicitely,		 * since this initialization routine is automatically called only when		 * the dll is loaded.		 */		return TRUE;	}    ptw32_processInitialized = TRUE;  	[...]}------------------------------------- in private.c, if macro NEED_FTIME is defined, add routines toconvert timespec_to_filetime and filetime_to_timespec, and modifiedcode that was using _ftime() to use Win32 API instead.Rational: _ftime is not available on WinCE.  It is necessary to usethe native Win32 time API instead.Note: the routine timespec_to_filetime is provided as a convenience and a meanto test that filetime_to_timespec works, but it is not used by the library.------------------------------------- in semaphore.c, if macro NEED_SEM is defined, add code for the routines_increase_semaphore and _decrease_semaphore, and modify significantlythe implementation of the semaphores so that it does not use CreateSemaphore.Rational: CreateSemaphore is not available on WinCE.  I had to re-implementsemaphores using mutexes and Events.Note: Only the semaphore routines that are used by pthread are implemented(i.e. signal conditions rely on a subset of the semaphores routines, andthis subset works). Some other semaphore routines (e.g. sem_trywait) arenot yet supported on my WinCE port (and since I don't need them, I am notplanning to do anything about them).------------------------------------- in tsd.c, changed the code that defines TLS_OUT_OF_INDEXES/* TLS_OUT_OF_INDEXES not defined on WinCE */#ifndef TLS_OUT_OF_INDEXES#define TLS_OUT_OF_INDEXES 0xffffffff#endifRational: TLS_OUT_OF_INDEXES is not defined in any standard include fileon WinCE.------------------------------------- added file need_errno.hRational: On WinCE, there is no errno.h file. need_errno.h is just acopy of windows version of errno.h, with minor modifications due to the factthat some of the error codes are defined by the WinCE socket library.In pthread.h, if NEED_ERRNO is defined, the file need_errno.h isincluded (instead of <errno.h>).-- eof