[Python-Dev] Status of MS Windows CE port

["Martin v. Löwis"]

> 1. TCHAR is always WCHAR

Python shouldn't be using TCHAR at all; that getpathp uses it is
misguided (IMO).

> The first point is interesting to the desktop win32 variants because 
> everything since NT4 (or even 3.x) also used UCS2 or UTF-16 internally. Only 
> win9x and ME(?) use 8-bit chars, and since support for them is being dropped, 
> this would save a few conversions while allowing better Unicode support. I 
> think getting Python to compile with _UNICODE #defined will be my first step.

Please don't. Whether or not _UNICODE is defined should have no effect.

> The third means that functions like e.g. system() are simply not available in 
> the supplied C API.

In this case, not defining HAVE_SYSTEM would be already sufficient, no?

> If the functionality itself exists, it can be built on 
> top of the win32 API. There might be a few cases where the desktop variants 
> would benefit from one less adaption layer, too.

Again, in the specific case of system(), the replacement is already
there, in form of the subprocess module· There might be other places
also, but apart from stdio (which is mostly gone in 3.0) and memory
management, I can't think of any.

> The last one only affects the build system and possibly the integration of 
> unit testing. pythonce.sf.net already have one based on SCons, which is nice 
> and easily extended. Being able to build 64 bit variants on 32 bit systems 
> and vice versa might be another benefit.

Wouldn't it be easier to extend the VS projects? VS targets CE fairly
well, no?

>> It's possible.  The best way to get the ball rolling is to produce
>> some patches against the mainline.
> 
> Hmmm, which mainline? 2.5, 2.6 or 3.0?

The mainline is 2.6 (i.e. trunk). 2.5 and 3.0 are branches.

> Up to now I have only looked at 2.5, 
> because that one is stable. However, quite a few of above changes are not 
> suitable for a stable version though, so I'll either have to restrict them to 
> only CE or rather apply them to version 3. We can discuss that when I have 
> actual patches.

I guess none of your changes are suitable for 2.5 (as they probably
constitute new features). You should really target trunk (i.e. 2.7) when
you produce patches.

Regards,
Martin