diff options
Diffstat (limited to 'pthreads/WinCE-PORT')
| -rw-r--r-- | pthreads/WinCE-PORT | 439 |
1 files changed, 222 insertions, 217 deletions
diff --git a/pthreads/WinCE-PORT b/pthreads/WinCE-PORT index f5981a9db..16daa8d34 100644 --- a/pthreads/WinCE-PORT +++ b/pthreads/WinCE-PORT @@ -1,217 +1,222 @@ -NOTE: The comments in this file relate to the original WinCE port -done by Tristan Savatier. The semaphore routines have been -completely rewritten since (2005-04-25), having been progressively -broken more and more by changes to the library. All of the semaphore -routines implemented for W9x/WNT/2000 and up should now also work for -WinCE. 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 our -Commercial WinCE developments, I would be very interested -if WinCE support could be added to the main source tree -of pthread-win32. Also, I would like to be credited -for 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 the -Casio is WinCE version 2.11, but I used VC++ 6.0 with -the WinCE SDK for version 2.01. - -I used pthread-win32 to port a heavily multithreaded -commercial application (real-time MPEG video player) -from Linux to WinCE. I consider the changes that -I 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 easiely -to 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-WinCE -environment, provided that the macros used for WinCE compilation -are not used, of course! - -Overall description of the WinCE port: -------------------------------------- - -Most of the changes had to be made in areas where -pthread-win32 was relying on some standard-C librairies -(e.g. _ftime, calloc, errno), which are not available -on WinCE. We have changed the code to use native Win32 -API instead (or in some cases we made wrappers). - -The Win32 Semaphores are not available, -so we had to re-implement Semaphores using mutexes -and events. - -Limitations / known problems of the WinCE port: ----------------------------------------------- - -Not all the semaphore routines have been ported -(semaphores are defined by Posix but are not part -pf pthread). I have just done enough to make -pthread routines (that rely internally on semaphores) -work, like signal conditions. - -I noticed that the Win32 threads work slightly -differently on WinCE. This may have some impact -on some tricky parts of pthread-win32, but I have -not really investigated. For example, on WinCE, -the process is killed if the main thread falls off -the bottom (or calls pthread_exit), regardless -of the existence of any other detached thread. -Microsoft manual indicates that this behavior is -deffirent from that of Windows Threads for other -Win32 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 errno -is compiled, regardless of _MT and _REENTRANT. - -Rational: On WinCE, there is no support for <stdio.h>, <errno.h> or -any other standard C library, i.e. even if _MT or _REENTRANT -is defined, errno is not provided by any library. NEED_ERRNO -must 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 not -be 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 replacement -for calloc, which is not available on Win32. - - ------------------------------------- -- use a new macro NEED_CREATETHREAD. - -If defined, implement.h defines the macro _beginthreadex -and _endthreadex. - -Rational: On WinCE, the wrappers _beginthreadex and _endthreadex -do 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); - } -#endif - -Rational: On WinCE, DuplicateHandle does not exist. I could not understand -why DuplicateHandle must be used. It seems to me that getting the current -thread handle with GetCurrentThread() is sufficient, and it seems to work -perfectly fine, so maybe DuplicateHandle was just plain useless to begin with ? - ------------------------------------- -- In private.c, added some code at the beginning of ptw32_processInitialize -to detect the case of multiple calls to ptw32_processInitialize. - -Rational: In order to debug pthread-win32, it is easier to compile -it 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 circumstance -to handle the case where ptw32_processInitialize() is called on -an already initialized library: - -int -ptw32_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 to -convert timespec_to_filetime and filetime_to_timespec, and modified -code that was using _ftime() to use Win32 API instead. - -Rational: _ftime is not available on WinCE. It is necessary to use -the native Win32 time API instead. - -Note: the routine timespec_to_filetime is provided as a convenience and a mean -to 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 significantly -the implementation of the semaphores so that it does not use CreateSemaphore. - -Rational: CreateSemaphore is not available on WinCE. I had to re-implement -semaphores 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, and -this subset works). Some other semaphore routines (e.g. sem_trywait) are -not yet supported on my WinCE port (and since I don't need them, I am not -planning 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 -#endif - -Rational: TLS_OUT_OF_INDEXES is not defined in any standard include file -on WinCE. - ------------------------------------- -- added file need_errno.h - -Rational: On WinCE, there is no errno.h file. need_errno.h is just a -copy of windows version of errno.h, with minor modifications due to the fact -that 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 is -included (instead of <errno.h>). - - --- eof +NOTE: The comments in this file relate to the original WinCE port
+done by Tristan Savatier. The semaphore routines have been
+completely rewritten since (2005-04-25), having been progressively
+broken more and more by changes to the library. All of the semaphore
+routines implemented for W9x/WNT/2000 and up should now also work for
+WinCE. Also, pthread_mutex_timedlock should now work.
+
+Additional WinCE updates have been applied since this as well. Check the
+ChangeLog file and search for WINCE for example. (2007-01-07)
+
+[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 our
+Commercial WinCE developments, I would be very interested
+if WinCE support could be added to the main source tree
+of pthread-win32. Also, I would like to be credited
+for 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 the
+Casio is WinCE version 2.11, but I used VC++ 6.0 with
+the WinCE SDK for version 2.01.
+
+I used pthread-win32 to port a heavily multithreaded
+commercial application (real-time MPEG video player)
+from Linux to WinCE. I consider the changes that
+I 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 easiely
+to 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-WinCE
+environment, provided that the macros used for WinCE compilation
+are not used, of course!
+
+Overall description of the WinCE port:
+-------------------------------------
+
+Most of the changes had to be made in areas where
+pthread-win32 was relying on some standard-C librairies
+(e.g. _ftime, calloc, errno), which are not available
+on WinCE. We have changed the code to use native Win32
+API instead (or in some cases we made wrappers).
+
+The Win32 Semaphores are not available,
+so we had to re-implement Semaphores using mutexes
+and events.
+
+Limitations / known problems of the WinCE port:
+----------------------------------------------
+
+Not all the semaphore routines have been ported
+(semaphores are defined by Posix but are not part
+pf pthread). I have just done enough to make
+pthread routines (that rely internally on semaphores)
+work, like signal conditions.
+
+I noticed that the Win32 threads work slightly
+differently on WinCE. This may have some impact
+on some tricky parts of pthread-win32, but I have
+not really investigated. For example, on WinCE,
+the process is killed if the main thread falls off
+the bottom (or calls pthread_exit), regardless
+of the existence of any other detached thread.
+Microsoft manual indicates that this behavior is
+deffirent from that of Windows Threads for other
+Win32 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 errno
+is compiled, regardless of _MT and _REENTRANT.
+
+Rational: On WinCE, there is no support for <stdio.h>, <errno.h> or
+any other standard C library, i.e. even if _MT or _REENTRANT
+is defined, errno is not provided by any library. NEED_ERRNO
+must 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 not
+be 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 replacement
+for calloc, which is not available on Win32.
+
+
+------------------------------------
+- use a new macro NEED_CREATETHREAD.
+
+If defined, implement.h defines the macro _beginthreadex
+and _endthreadex.
+
+Rational: On WinCE, the wrappers _beginthreadex and _endthreadex
+do 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);
+ }
+#endif
+
+Rational: On WinCE, DuplicateHandle does not exist. I could not understand
+why DuplicateHandle must be used. It seems to me that getting the current
+thread handle with GetCurrentThread() is sufficient, and it seems to work
+perfectly fine, so maybe DuplicateHandle was just plain useless to begin with ?
+
+------------------------------------
+- In private.c, added some code at the beginning of ptw32_processInitialize
+to detect the case of multiple calls to ptw32_processInitialize.
+
+Rational: In order to debug pthread-win32, it is easier to compile
+it 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 circumstance
+to handle the case where ptw32_processInitialize() is called on
+an already initialized library:
+
+int
+ptw32_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 to
+convert timespec_to_filetime and filetime_to_timespec, and modified
+code that was using _ftime() to use Win32 API instead.
+
+Rational: _ftime is not available on WinCE. It is necessary to use
+the native Win32 time API instead.
+
+Note: the routine timespec_to_filetime is provided as a convenience and a mean
+to 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 significantly
+the implementation of the semaphores so that it does not use CreateSemaphore.
+
+Rational: CreateSemaphore is not available on WinCE. I had to re-implement
+semaphores 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, and
+this subset works). Some other semaphore routines (e.g. sem_trywait) are
+not yet supported on my WinCE port (and since I don't need them, I am not
+planning 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
+#endif
+
+Rational: TLS_OUT_OF_INDEXES is not defined in any standard include file
+on WinCE.
+
+------------------------------------
+- added file need_errno.h
+
+Rational: On WinCE, there is no errno.h file. need_errno.h is just a
+copy of windows version of errno.h, with minor modifications due to the fact
+that 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 is
+included (instead of <errno.h>).
+
+
+-- eof
|