> Has anyone tried the beta version of the Windows CE
> addon for Visual C++ 6.0 yet?  We use 6.0 for our code
> development and it would be nice to have it available
> for CE ports.

Scott,

I would recommend against this for these reasons:

1.  Microsoft has not included any support for Windows CE
     development in Visual C++ 6.0.

2.  Performing an MS knowledge base search on Visual C++ 6.0
     and Windows CE doesn't bring up any hits.

3.  A number of people have tried to use 6.0 and CE.  To my
     knowledge nobody has yet reported success.

4.  The Visual Studio Service Pack 1 doesn't list any fixes
     that would lead you to believe that this issue is resolved.
     In typical Microsoft fashion, they refuse to acknowledge
     6.0's current lack of support for CE.

5.  The primary CE developer (Brian) is using Visual C++ 5.0.

Caveat programmadora,

Jeff Bauer
Rubicon, Inc.

P.S.  I'm preparing a how-to page for potential PythonCE
code contributors, so please document any mishaps you
encounter in getting the code to compile.  In the meantime,
here's some worthwhile reading:

     http://www.vcce.com/settingupce/settingup.htm

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Has anyone tried the beta version of the Windows CE
addon for Visual C++ 6.0 yet?  We use 6.0 for our code development and
it would be nice to have it available for CE ports.

I think I'll spend the $10 and order
a trial copy if no one has tried it yet.

Scott C.

PS. Finally! got the PyCE base source to compile and load/work
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Hi all.

I've been missing select() on Python CE, and I think
that I may have it working.  As a quick test, I copied
Aaron Watter's Gadfly gfclient.py & gfsocket.py to
the device.  After a brief interlude to add the MD5
module (very straightforward) I was able to run
gfclient and connect to a test database server
running on a Solaris box.

This is about all I have time for, but anybody
considering running a Gadfly client on CE now
knows that it stands a reasonable chance of working.

Notes for the unwary:  I'm sending in the patches to
Brian, but if anyone decides to use select() on CE
for other purposes, please be aware that there's a
huge gaping bug.  Apparently select() stomps the fds
you pass into it, so it's necessary to first create a
copy.  Fortunately (for me) someone else tripped
over this little nasty and passed the information on.

Best regards,

Jeff Bauer
Rubicon, Inc.
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

> Agreed, it is better to have independence from the
> vagarities of vendors' compilers.  Mark, what are your
> thoughts on establishing MS_WINCE as a baseline, rather
> than MS_WINCE_20?  (Reserving MS_WINCE_20 for the day
> we need to worry about _backward_ compability.)

Sounds fine.  Although the "direction" of these defines is a problem.

eg, when CE3 comes out, presumably MS_WINCE_30 will be used to
_enable_ 3.0 extensions, mainly while we move towards CE3 as a
baseline.

However, using your suggestion above, once CE 8.0 is out (ie, after
our lifetimes, or possibly next month if the MS marketting machine has
their way :-) MS_WINCE_30 should then be used to define _backward_
compatibility.  I dont see how it can do both!

My suggestion is:
* As CE2.0 is our baseline, we stick with MS_WINCE as the base.
* When CE2.0 is a b/w compat issue, we use #else - eg,

#ifdef MS_WINCE_30 // they changed the world on us again, as usual...
blah
#else // WINCE 2.0 backwards compat mode.
our lovelly "old" code (and it hasnt even been written yet :-)
#endif

OK - assuming we agree, then I have my first "core CE" patch - add
"#define MS_WINCE" to config.h :-)

Mark.

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

> > This raises another issue.  Tradition dictates that
> > Brian Lloyd is responsible for the core.  This is not
> > a problem for anyone, I trust, but it means we have
> > some administrative issues to deal with.  If Mark
> > Hammond (or anyone else) adds/fixes something, how do
> > we get it checked in?
>
> I'm interested in getting Mark's feedback on this. How do
> you currently handle fixes/contributions to pythonwin, COM,
> etc?

Sometimes I wish they flooded in, but they don't!  I dont think this
need be a problem.  You "own" the core, and that should work fine.
People tend to respect the "owner", as no one ever wants to a)
redistribute the same thing and b) continually make patched each time
something is released.  So people will tend to send their
contributions to the person to currently releases the stuff.

As I said, I wouldnt expect you to get inundated with this stuff.
Extension authors will still carry a fair bit of the burden.

I dont think this will be a problem.


> Yes - we're lucky that Mark's experience w/HP didn't turn him
> into a hardened palm pilot evangelist ;^)

:-) I really my little Casio much more than the Pilot.  And I just
_love_ being able to show people the familiar ">>>" of the Python
interpreter - they are usually blown away!

Re work to be done:  I hate to sound like a wet blanket, but expect to
be underwhelmed with contributions.  Wait until we actually start
treading on each others toes before we focus too much on the admin
stuff.  For example, although my intentions are good, the
abso-#ucking-lutely huge Amex bill from my recent US trip may make too
much work in the short term a problem :-)  Although Python does have a
benevolent dictator, much extension work seems to rely on a form of
anarchy, and it appears to work well.  There arent too many duplicated
works that I know of.  Presumably PythonCE will be quite a smaller
scale than Python itself, and it seems to be crunching along fine...

Mark.

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

> Once I see a couple of good examples from Mark
> H. on supporting 95/98/NT/CE in the same source
> file, I can dutifully follow along...I am more
> than willing to let someone else establish
> the precedence.

I'm a proud new owner of a Cassiopeia E-11 and do cross-platform work in C++ all
the time (the list my software runs on includes BeOS and VMS, to name a few
extremes - WinCE 32 is high up on my list: people have asked for a port).  I'd
be interested to help find ways to stay out of #ifdef hell.

-- Jean-Claude Wippler

-----
See the original message at http://www.egroups.com/list/python-ce/?start=19
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

[Jeff discusses accepting patches and posting them on the Starship.]

>Brian Lloyd:
> Why not put this stuff on the existing CE site?

Music to my ears. ;-)

Regards,

Jeff Bauer
Rubicon, Inc.

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

> Python CE:  Outlining a Source Strategy
>
> First, I'd like to say that the response to Python CE
> since last week's workshop has been overwhelming.  Several
> attendees have emailed me since then, to say they have
> purchased or plan to purchase a handheld CE device just
> so they can play with Python CE.

That's great to hear!

>
> Even more impressive is the fact that a few of these
> individuals intend to add more capability to Python CE.
> This is a major boon, because in it's short period of
> existence, the CE world has fragmented in ways MS
> Windows hasn't done in its 10 year lifetime.
>
> Translation:  We need all the developers we can get,
> preferably representing a wide variety of platforms.

<*sigh*>... I expect this will be a blessing and curse for Python
on CE. As you point out, there is a new flavor of CE every month
it seems. I had jokingly remarked before that all we have to do is
wait a little while longer and wait for CE to become full-blown NT
and then go back to just using Mark's code. Since MS is now rolling
out embedded NT as a separate entity from CE, it looks like this
wont happen ;) I find following MS strategy for CE difficult. I figure
that either:

a) MS will continue to push CE (and custom versions of it) into ever
    stranger and vertical areas such as Dreamcast, WebTV, MSMicrowave,
    MSCoffeePot, etc.

or

b) MS really dont know what the heck they plan to do with CE and are
    basically just trying to push it and sell it to whoever will buy it.

My personal perspective is that the left arm doesnt necessarily really
know what the right arm is doing at MS and it'll be interesting to see
if CE and embedded NT start cannibalizing one another before too long.

No matter what happens, our task is made harder ;)


>
> As we begin to talk about what to add, fix, enhance,
> and maintain, I'd like to back up just a moment to throw
> out some ideas about a strategy to work on the source.
>
> The first requirement is to make the source available
> to everyone who's interested in it.  I'd like to suggest
> that it is placed onto the Starship, preferably in a
> CVS tree.  I'm willing to investigate that option.
>
> This raises another issue.  Tradition dictates that
> Brian Lloyd is responsible for the core.  This is not
> a problem for anyone, I trust, but it means we have
> some administrative issues to deal with.  If Mark
> Hammond (or anyone else) adds/fixes something, how do
> we get it checked in?

I'm interested in getting Mark's feedback on this. How do
you currently handle fixes/contributions to pythonwin, COM,
etc?



> I would like to get some feedback before proceeding
> much further, but here are some models we can pick
> from:
>
> 1. Python - Benevolent dictator
>
> 2. Apache - Core group, somewhat parlimentary
>
> 3. Guile - One individual who invites specific
>            contributors to have access to check-in
>
> 4. Emacs - Cathedral approach
>
> There are many other possibilities, but the number
> of people who have the interest and resources to
> work on the Python CE sources is probably limited.
>
> Related to the check-in question is how to get
> decisions made.  One of the great things about Python
> is that after some discussion, when Guido makes a
> decision, we are all clear on where we stand.

Well, as far the PythonCE core is concerned, the answer is
#1 ;) I think that everyone generally agrees on direction,
getting in sync with desktop win32 as much as possible,
moving toward common code where possible, etc.


> Mark's earlier question about using #define MS_WINCE_20
> or factoring the .DLL's is a good example.  The problem
> now is even if no one objects, how do we know that it's
> safe to start writing code based on the consensus?
> There are also further issues about folding portions
> of the Win32 CE changes api back into Mark's original
> code.
>
>   By the way, I want to say that we've fortunate that
>   Mark is turned on about the CE platform -- I'd hate
>   it if he were disinterested.  Somebody call up Santa
>   Claus and have him put a Casio E-11 in Guido's stocking
>   this Christmas.

Yes - we're lucky that Mark's experience w/HP didn't turn him
into a hardened palm pilot evangelist ;^)


>
> For the purposes of agreement, can we declare the initial
> check-in to be the current Python CE source?
>
> http://www.digicool.com/~brian/PythonCE/dist/PythonCE-1.0beta_src.zip

Sounds good to me.


> I'm in the process of writing a Python CE section on the
> Starship.  As a purely short-term administrative task, I'd
> be willing to accept and post contributed context diffs against
> this source.  The patches would have no official status, but
> could act as a central exchange location until we put in place
> a designated procedure.

Why not put this stuff on the existing CE site?


> Finally, I'd like to post some breakdown of interests, to
> help us coordinate tasks and prevent duplication of effort.
>
> Mark Hammond has indicated that he is interested in working
> on thread support and refactoring the Win32 API.  Scott
> Cothrell has indicated that he has some contributions to
> make in this area, too.
>
> I have interests in the following areas:
>
>     IrDA interface
>     SSL interface
>     zlib module
>     making a limited Bobo server run on Python CE
>
> Brian could possibly present a shopping list of what
> he intends to work on next, and what he'd prefer to
> delegate to others.  If anyone else has a particular
> section they want to pursue, please let the list members
> know sooner than later.

This is a good idea -- I already have a "todo" list of sorts.
I'll post it on the site as a starting point.




Brian Lloyd        brian@...
Software Engineer  540.371.6909
Digital Creations  http://www.digicool.com
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Mark Hammond: [discussion about Windows CE #defines]
> In the Python core, we specifically chose to create our
> own #defines, to try and remain semi-independant of the
> MS compilers.  Thus, we use MS_WINDOWS (all versions of
> windows) MS_WIN32, MS_WIN16 etc.  These are in config.h,
> and give us more control than using the compilers
> built-in.  I was suggesting we use this prior art.

Agreed, it is better to have independence from the
vagarities of vendors' compilers.  Mark, what are your
thoughts on establishing MS_WINCE as a baseline, rather
than MS_WINCE_20?  (Reserving MS_WINCE_20 for the day
we need to worry about _backward_ compability.)

[Unicode: suggestion to wait until it's implemented in Python]

> So I disagree here.  We need to blaze the trail.

I agree with Mark on this point.  If we keep the String
SIG informed about our plans, then we may actually
become a valuable test case for Python's conversion to
Unicode.  This represents a good opportunity for everyone,
because there are no established applications (yet) that
will break on the CE platform.

Regards,

Jeff Bauer
Rubicon, Inc.

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

[Scott writes]
> > Mark's earlier question about using #define MS_WINCE_20
> > or factoring the .DLL's is a good example.  The problem
> > now is even if no one objects, how do we know that it's
> > safe to start writing code based on the consensus?
> Don't forget, the CE addon for VC defines several variables
> based on what you're compiling for.
> I'd suggest we standardize on one of them.

In the Python core, we specifically chose to create our own #defines,
to try and remain semi-independant of the MS compilers.  Thus, we use
MS_WINDOWS (all versions of windows) MS_WIN32, MS_WIN16 etc.  These
are in config.h, and give us more control than using the compilers
built-in.  I was suggesting we use this prior art.

>
> > There are also further issues about folding portions
> > of the Win32 CE changes api back into Mark's original
> > code.
> >
> Oh God, this is going to get messy.
> I'd like to make a suggestion (and its only my opinion) that
> we defer the rolling back into
> Mark's code base until Guido gets the Python Core converted
> to UNICODE.  I believe UNICODE coming from the Python Core is
> going to break
> extensions not specifically coded to handle it..see my
> whining in the other message posted today (I know it will break
mine).
> Suggestion is that for now, we start a new Win32CE code base
> and defer the merge
> 'til Mark's code hits major revision time.

I dont think this need be a problem.  There where some experimental
Unicode patches for 1.5.0 some time ago.  By simply #defineing my
Unicode helpers to Python's API, I was able to get all my extensions
working.  No source changes except for these macros.

However, even more pressing is the chicken and egg problem.  I dont
want to wait for Python's Unicode to port my extensions.  Without some
more extensions, PythonCE will remain interesting, but not very
usefull for doing anything serious.  And until people actually start
_using_ it seriously, Guido wont take it seriously either (it took
quite some time for Guido to take Windows itself seriously!!)

So I disagree here.  We need to blaze the trail.

> My management at Cisco Systems has agreed to let me post the
> extensions I've been working on.
> I'd put them in the "Real Soon Now" stage, but I
> have a working rewrite of
> Win32net (the enumeration and all works correctly now)
> I'm working on a rewrite of Win32service with added
> functionality for some internal customers.
> (personally, I dislike SWIG code, I dont think its very
maintainable)
> I am also working on an extension with the WNet functions. I
> call it win32wnet (such imagination)

Excellent - cant wait to see it!

Mark.

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

[Scott writes]
> A few concerns and a question or two... Does the PyCE core
> use UNICODE strings internally?
> how about passing strings to extensions?  I'm interested
> because some of my extensions are compiled with UNICODE and
> _UNICODE def'd.
> I could cut down a lot of Macro/TCHAR hell if I knew the
> strings were UNICODE to start with.
> I also think we should try to get a read on where/what
> UNICODE will be for Python Core.
> UNICODE was listed as Guido's #1 priority for 1.6 and I'd
> rather not reinvent the wheel...

Here is my take on the issues:

CE has "char *"s available, but just not accepted by any API
functions!  The ANSI versions of the API's simply do not exist.
Functions like "wsprintf", for example, want the first argument to be
Unicode, and no ansi version exists (Im still unclear if the "S"
format spec actually supports char *s.)

Regardless of Python and Unicode, there appear to be areas that will
_always_ require PyString.  The most basic example is the __str__
methods for types (and where some pain was with pywintypes).
Thus I see a few helpers we can use (which are very close to the
existing helpers pywintypes has):

PyString_FromTCHAR - simply a macro similar to:
#ifdef _UNICODE
# define PyString_FromTCHAR PyString_FromWCHAR
#else
# define PyString_FromTCHAR PyString_FromString
#endif
// Thus, _always_ returning a PyString.

PyUnicode_FromTCHAR // Similar to the above, but _always_ returns a
PyUnicode

// This next one has a bad name, but bear with me:
PyWinObject_FromTCHAR // If UNICODE, returns a Unicode, else a
string - ie, the "native" string

PyWinObject_AsTCHAR // Always return the "native" string - widening or
collapsing as necessary.

This can largely shield us from the eventual Python Unicode API - as
it evolves, we can simply #define our API to be Pythons.  Most
extensions I have written over the last 18 months support Unicode in
this way.

Re Python and unicode itself:
I urge everyone who cares to join the string SIG, which has been
discussing this on and off over the last year.  Recent archives will
give you the latest position.  My understanding is that we start with
the 1.5.2 sources, and implement a Unicode "type".  This will not be
hidden from the string type, but rather a new, discrete type.
1.5.2 has string.py methods setup to handle this.  In 1.5.2, strings
will finally have methods - this it will be possible to say: "foo
bar".split()

This will allow us to write code that works independent of the
underlying type - eg:
stringObject.split() will work for _both_ strings and Unicodes.

There are obviously other details, many of which have been discussed.
PLEASE join the string SIG, and help make this happen...

Mark.

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Python CE:  Outlining a Source Strategy

> Translation:  We need all the developers we can get,
> preferably representing a wide variety of platforms.

For the record, I'm using a Compaq PC Companion (relabled Casio). Its an SH-3
processor.


> 1. Python - Benevolent dictator
>
My pick, if Brian is interested in taking up the challenge.


> Mark's earlier question about using #define MS_WINCE_20
> or factoring the .DLL's is a good example.  The problem
> now is even if no one objects, how do we know that it's
> safe to start writing code based on the consensus?

Don't forget, the CE addon for VC defines several variables based on what you're
compiling for.
I'd suggest we standardize on one of them.

> There are also further issues about folding portions
> of the Win32 CE changes api back into Mark's original
> code.
>
Oh God, this is going to get messy.
I'd like to make a suggestion (and its only my opinion) that we defer the
rolling back into
Mark's code base until Guido gets the Python Core converted to UNICODE.  I
believe UNICODE coming from the Python Core is going to break
extensions not specifically coded to handle it..see my whining in the other
message posted today (I know it will break mine).
Suggestion is that for now, we start a new Win32CE code base and defer the merge
'til Mark's code hits major revision time.


> For the purposes of agreement, can we declare the initial
> check-in to be the current Python CE source?
yep
Can you also write up a "how-to" for generating diff's/patches? Frankly, I've
never done it other than by sending email with some cut-n-paste.

> Finally, I'd like to post some breakdown of interests, to
> help us coordinate tasks and prevent duplication of effort.
>
My management at Cisco Systems has agreed to let me post the extensions I've
been working on.
I'd put them in the "Real Soon Now" stage, but I
have a working rewrite of
Win32net (the enumeration and all works correctly now)
I'm working on a rewrite of Win32service with added functionality for some
internal customers.
(personally, I dislike SWIG code, I dont think its very maintainable)
I am also working on an extension with the WNet functions. I call it win32wnet
(such imagination)

All of them are a real hit or miss nightmare when it comes to cross platform
support.  I have to support Windows NT, so thats what they are written for.
Once I see a couple of good examples from Mark H. on supporting 95/98/NT/CE in
the same source
file, I can dutifully follow along...I am more than willing to let someone else
establish
the precedence.

Scott C

-----
See the original message at http://www.egroups.com/list/python-ce/?start=17
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

A few concerns and a question or two... Does the PyCE core use UNICODE strings
internally?
how about passing strings to extensions?  I'm interested because some of my
extensions are compiled with UNICODE and _UNICODE def'd.
I could cut down a lot of Macro/TCHAR hell if I knew the strings were UNICODE to
start with.
I also think we should try to get a read on where/what UNICODE will be for
Python Core.
UNICODE was listed as Guido's #1 priority for 1.6 and I'd rather not reinvent
the wheel...

Scott C
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Python CE:  Outlining a Source Strategy

First, I'd like to say that the response to Python CE
since last week's workshop has been overwhelming.  Several
attendees have emailed me since then, to say they have
purchased or plan to purchase a handheld CE device just
so they can play with Python CE.

Even more impressive is the fact that a few of these
individuals intend to add more capability to Python CE.
This is a major boon, because in it's short period of
existence, the CE world has fragmented in ways MS
Windows hasn't done in its 10 year lifetime.

Translation:  We need all the developers we can get,
preferably representing a wide variety of platforms.

As we begin to talk about what to add, fix, enhance,
and maintain, I'd like to back up just a moment to throw
out some ideas about a strategy to work on the source.

The first requirement is to make the source available
to everyone who's interested in it.  I'd like to suggest
that it is placed onto the Starship, preferably in a
CVS tree.  I'm willing to investigate that option.

This raises another issue.  Tradition dictates that
Brian Lloyd is responsible for the core.  This is not
a problem for anyone, I trust, but it means we have
some administrative issues to deal with.  If Mark
Hammond (or anyone else) adds/fixes something, how do
we get it checked in?

I would like to get some feedback before proceeding
much further, but here are some models we can pick
from:

1. Python - Benevolent dictator

2. Apache - Core group, somewhat parlimentary

3. Guile - One individual who invites specific
            contributors to have access to check-in

4. Emacs - Cathedral approach

There are many other possibilities, but the number
of people who have the interest and resources to
work on the Python CE sources is probably limited.

Related to the check-in question is how to get
decisions made.  One of the great things about Python
is that after some discussion, when Guido makes a
decision, we are all clear on where we stand.

Mark's earlier question about using #define MS_WINCE_20
or factoring the .DLL's is a good example.  The problem
now is even if no one objects, how do we know that it's
safe to start writing code based on the consensus?
There are also further issues about folding portions
of the Win32 CE changes api back into Mark's original
code.

   By the way, I want to say that we've fortunate that
   Mark is turned on about the CE platform -- I'd hate
   it if he were disinterested.  Somebody call up Santa
   Claus and have him put a Casio E-11 in Guido's stocking
   this Christmas.

For the purposes of agreement, can we declare the initial
check-in to be the current Python CE source?

http://www.digicool.com/~brian/PythonCE/dist/PythonCE-1.0beta_src.zip

I'm in the process of writing a Python CE section on the
Starship.  As a purely short-term administrative task, I'd
be willing to accept and post contributed context diffs against
this source.  The patches would have no official status, but
could act as a central exchange location until we put in place
a designated procedure.

Finally, I'd like to post some breakdown of interests, to
help us coordinate tasks and prevent duplication of effort.

Mark Hammond has indicated that he is interested in working
on thread support and refactoring the Win32 API.  Scott
Cothrell has indicated that he has some contributions to
make in this area, too.

I have interests in the following areas:

     IrDA interface
     SSL interface
     zlib module
     making a limited Bobo server run on Python CE

Brian could possibly present a shopping list of what
he intends to work on next, and what he'd prefer to
delegate to others.  If anyone else has a particular
section they want to pursue, please let the list members
know sooner than later.

Hint:  COM/ActiveX is wide open.

Regards,

Jeff Bauer
Rubicon, Inc.
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Scott C:
>> granularity.  Another issue, do we attempt to fully
>> support CE 1.0?  the extensions I'm working on are
>> networking related and CE versions are only available
>> in 2.0...and I think we

Mark H:
> Id say "no" for now.  Certainly it doesnt worry me :-)

I would second the notion that we consider CE 2.0 to be
the minimal platform.  It is the minimum version that
anybody buying a CE device today will purchase.  For the
people who are running CE 1.0, there is already a Python CE
available for their platform.

> OK - here are some questions:
> What #define should we use to determine if building for
> CE support?  We have existing Python #defines "MS_WIN32",
> "MS_WIN16" etc.  I propose we add "MS_WINCE_20",
> "MS_WINCE_21" etc defines.  Ugly, but it will get
> us going.

What about a generic MS_WINCE, which would imply CE 2.0
or higher?  Then version-specific CE 2.1, CE 3.0 defines
could be added later.  They would designate requirements
beyond the minimum CE 2.0.  The CE platform is far enough
along now that I think most of what will be used from
Win32 will fit in that category.

I'd also like to reserve MS_WINCE_20 for a future time
when we might move a default minimum _beyond_ CE 2.0.  The
MS_WINCE_20 would then indicate backwards compatibility.

> Some of the helpers Brian has defined has potentially made
> this easier - especially if we take them a step further - eg,
> define a "PyString_FromTCHAR" macro.  Then it (theoretically)
> should be a matter of #defineing UNICODE or not.
>
> [Eg, I have pywintypes module almost compiling using this strategy]

This seems reasonable.

> However, I may tackle getting thread's running (just so I
> can get Jeff's very cool "remote" functionality working coded
> in "100% Pure Python" (tm) :-)

Support for threads on CE would be high on my priority
list, right up there with a decent CE GUI :-)

Regards,

Jeff Bauer
Rubicon, Inc.

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

> I've been working on some Win32 extensions that I'd love to
> see on CE.  I have the full development system for VC++ 5.  I
> read up on the newsgroup, but I don't think I ever saw a
> conclusion to the consolidation issue nor any suggestions for
> avoiding the descent into "#ifdef hell".  As for the issue of

Im not sure there is a decent solution to this.  IMO, the most
important objective is that it be possible to write portable Win32
programs that run in NT/95/98/CE.

So to my mind, the #ifdef hell can't easily be avoided.  The only
other solution is to move to Sam's "dynwin", but the biggest problem
here is that new processor types require new assembly coding, and this
wont be pretty.

So Im afraid #ifdef hell may be the best solution.  It _appears_ to me
that if we actually code all modules as _potentially_ Unicode (eg, use
the TCHAR, _T etc macros) then this is not too painful, and the
#ifdef's will be used almost exclusively to remove whole chunks of
functionality, rather than sprinkeld throughout the code.

Some of the helpers Brian has defined has potentially made this
easier - especially if we take them a step further - eg, define a
"PyString_FromTCHAR" macro.  Then it (theoretically) should be a
matter of #defineing UNICODE or not.

[Eg, I have pywintypes module almost compiling using this strategy]

> win32api vice win32reg and naming conventions.  Personally!,
> I'd prefer to break things out a lot more than win32api.  To
> put a point on it, win32reg makes it clear where to find the
> registry functions, and the smaller packages make it easier

I would be happy with that - except for the fact that we then end up
with even _more_ win32*.pyd modules.  However, I do agree the registry
etc should be split.

A solution here may be to remove them from win32api, but add some
hackery to win32api to make them _look_ like they exist.  Eg, win32api
could internally do a "from win32reg import *" when not running on CE.
We can start documenting them as in win32reg, but keep them in
win32api on NT/95 just for b/w compat.

But this doesnt really scale.  eg, I notice that win32sys has
functions such as "MessageBeep" etc - to my mind, they dont really fit
in win32sys any better than win32api.  IMO, win32api can become a
reasonable subset of functionality (ie, is "win32sys" a more logical
place for MessageBeep/Box than win32api??)

I have grappled with this myself for the "normal" stuff - I have
around 8 win32* .pyd's as it is, and some feedback I have had is "too
many".  My reaction is "too hard" :-)

> granularity.  Another issue, do we attempt to fully support
> CE 1.0?  the extensions I'm working on are networking related
> and CE versions are only available in 2.0...and I think we

Id say "no" for now.  Certainly it doesnt worry me :-)

The good news is that I have the dev environment setup, and CE
building.  Ive also made steps towards pywintypes building on CE, and
it doesnt seem too messy or hard.

OK - here are some questions:
What #define should we use to determine if building for CE support?
We have existing Python #defines "MS_WIN32", "MS_WIN16" etc.  I
propose we add "MS_WINCE_20", "MS_WINCE_21" etc defines.  Ugly, but it
will get us going.

Also, does anyone know where I find the CE 2.1 SDK etc?  I seem to
only have the CE 2.0, which is missing some COM functionality?

Im quite stoked on this, and Brian has done an excellent job.  FWIW,
my focus will be less on the core, and more on the extensions.  This
way I hope to avoid treading on anyone's toes.  However, I may tackle
getting thread's running (just so I can get Jeff's very cool "remote"
functionality working coded in "100% Pure Python" (tm) :-)

Thanks,

Mark.

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

I've been working on some Win32 extensions that I'd love to see on CE.  I have
the full development system for VC++ 5.  I read up on the newsgroup, but I don't
think I ever saw a conclusion to the consolidation issue nor any suggestions for
avoiding the descent into "#ifdef hell".  As for the issue of win32api vice
win32reg and naming conventions.  Personally!, I'd prefer to break things out a
lot more than win32api.  To put a point on it, win32reg makes it clear where to
find the registry functions, and the smaller packages make it easier to
customize your CE load.  I use a 1st generation Compaq PC Companion w/6MB and
CE2.0...I really, really like the finer granularity.  Another issue, do we
attempt to fully support CE 1.0?  the extensions I'm working on are networking
related and CE versions are only available in 2.0...and I think we need a way to
indicate to the user what the prereqs are if we do 1.0 & 2.0

My $.02 worth.
Looking forward to it!
Scott C.
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

I've been using Eiichiroh Itoh's CEShell for CE devices,
and asked him about distributing it with PythonCE, in case
we should ever decide to add this interface.  Despite
the language barrier, his response appears below.  For
more info, check out the site at: http://www.oohito.com/

Regards,

Jeff Bauer
Rubicon, Inc.

---
> I was wondering if it would be possible to distribute
> your Console library along with Python CE, a programming
> language freely available for Windows CE devices.

It's very nice. Wonderful!!

Of course, you can feel free to distribute console library
along with Python CE.

Thank you.
(Eiichiroh Itoh)
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

There may be some short-term relief towards a CE
user interface, if python users don't mind the following
limitations:

- commercial product (but the runtimes are royalty-free)
- forms builder (ergo, the apps must be fairly simple)

I've been talking to SyWare, the makers of Visual CE,
a forms builder application.  Their product works with
both H/PC's and P/PC's.  It is capable of importing
and exporting ASCII files (I know -- they're really
Unicode) so it would be pretty easy to leverage off
of PythonCE's current strengths.

The main thing that Visual CE lacked (lacks) was
a way to tell the engine to import/export in batch,
non-interactive mode. (i.e. via lpCmdLine)  We
have offered to contract SyWare to add this capability
to Visual CE (heck, I offered to write the code) and
it looks like we will soon come to some agreement.

I mention this now, because a lot of people will
soon be complaining about the lack of GUI-ness
in Python CE.  And if history is any indication,
a user interface will not be built overnight.

From our (Rubicon's) point of view, we think we
can build working prototypes of applications
using Visual CE for the interface and Python CE
as the glue to sync/format with the main repository.
It's worth a try, at least.  SyWare can be reached
at:  http://www.syware.com/  An email to them
explaining the usefulness of this feature probably
won't hurt.

Comments?

Jeff Bauer
Rubicon, Inc.
______________________________________________________________________
No tricks, no gimmicks - just a great intro rate for Internet users!
NextCard Internet VISA -- Apply online now!
http://ads.egroups.com/click/61/1/nextcard

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

>Obviously with 16 meg of memory and a color
>screen a port of pythonwin to python-ce must
>become a priority - yes?

Yes, but it would be an even higher priority if one of these vendors would
donate some hardware to the developers doing the work :-)

Mark.


------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

>I think we just misunderstood each other - I didn't choose not to
>answer, rather the right answer seemed to be a future decision
>given the CE landscape at the time ;^)

Excellent - Im pleased to hear that!  I hope I didnt sound too annoyed - I
do know that I didnt express properly how impressed I was to see it work at
all, and what a great job Brian has done.  Im walking around with my device
showing anyone who cares (and lots of people who dont :) Python on this
device.  Writing Python programs with a stylus presents a whole new set of
challenges, tho :-)

>Some issues/thoughts in no particular order:
>
>o CE is Unicode-only
>
>o #1 is actually a lie, because it's really only _mostly_
>  unicode-only, and the exceptions make it difficult to
>  solve the problem in a mechanical fashion (TCHARs, etc).

Yes.  This is one reason why "pywintypes" would be a good starting point -
it has basic support for Unicode.  Also, the string-sig is looking at
Unicode native to Python, and some progress appears to have been made.
Hopefully this will sort itself out sooner rather than later...  It is worth
noting that we have been dealing with Unicode and COM for quite a while.

>o CE versions of APIs differ in sometimes strange ways from
>  their desktop counterparts, often requiring different arg
>  validation logic in C extensions.

Damn.  IMO, we should not try and hide these differences (but we obviously
need to work!).  We should stay a thin wrapper over the win32 api - warts
and all!

>o CE is still missing some big chunks of C runtime that will
>  have to be added to the existing crt emulation to support
>  existing code.

What areas in particular?  Im happy to have chunks left out if they dont
appear on the device.  Im less happy with common functionality being
accessed differently, depending on the device.

>o We would like to leverage common code
>
>o We also dont want to descend into an #ifdef hell ;^)

Yes and yes, but how do we do both?  Even where there are differences, it
makes sense to me that single sources can be used.  At time rolls on, I
expect to see fewer differences between CE and win32 itself, so some hackery
we need to do now may be able to be removed later.

>o Some of these issues affect the actual Python sources. I didn't
>  want to propose any patches until they were fairly well thought
>  out (and until I was sure MS wouldnt suddenly cancel CE and make
>  the point moot ;)

Do you have a vague description of the changes?  We are probably too late
for 1.5.2, but it would be good to get these into the core - if for no other
reason than to make Guido and others aware of the port, and of the
differences.

>It seems to me that we should take a very design-oriented approach
>to this since getting to a portable port seems likely to have a
>rather non-trivial impact on the existing win32 port.
>
>Thoughts, comments?

Im still obviously clueless with lots of this stuff, so I cant quite picture
the problem.  I have never seen the sources to your port, so Im completely
in the dark.

But I like "non trivial impacts" - keeps life interesting :-)

I think Jeff's idea of a "ce-hackers" group has merit - although Im inclined
to suggest it should be "ms-windows-hackers", and could be charged with
maintaining all the Microsoft Windows extensions - Im thinking CE and 64 bit
Windows here.  Would be good to have a focal point for some of the more
obscure topics (that normally end up in my mailbox, or discussed privately
between Greg Stein and myself!).  FWIW, Greg has started a "com hackers"
type mailman list, but hasnt published its existance yet - it is probably
where COM related CE stuff will end up (we need to ensure Greg gets a CE
device, just so we can rope him in :-)

One obvious thing we can think of is whether we should be moving to Sam's
"calldll" stuff for all the windows stuff.  Im really in 2 minds about this,
but I am aware many people think "yes".  It has obvious appeal.  Greg is
looking at doing some exciting new COM stuff with it.  The obvious problem
for CE is porting to those new processor architectures.  Greg indicated once
he didnt see it as a big problem (but also didnt indicate he would do it :-)
OTOH, the way I use SWIG these days makes it easy, and the C compiler
worries about the platform differences.  (The SWIG code is very fat, tho,
but that could/must change!)

All just food for thought.  Im just regretting that I didnt bring my CE
developers CD with me, so I cant play with it much, nor see any decent
sample code until I return home - and this wont be until after the SpamFest.

Mark.

------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Folks,

I'm very new to python but deeply in love
with it and much interested in using it to
develop native on a CE device. One in particular
has sparked my interest - the new Clio as
described at http://www.vadem.com/home.html .
Obviously with 16 meg of memory and a color
screen a port of pythonwin to python-ce must
become a priority - yes?

Peter Merel.

-----
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________
No tricks, no gimmicks - just a great intro rate for Internet users!
NextCard Internet VISA -- Apply online now!
http://ads.egroups.com/click/61/1/nextcard

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

> [Mark]
>
> The good news is that I have a new CE machine (a Cassiopeia
> "palm size"
> model).
>
> Even better news - Brian's MIPS port worked first time :-)
>
> The bad news is that I have a new CE machine - so watch out :-)
>
> I have a question that I have previously asked of Brian, but
> much to my
> dissapointment he chose not to answer:  How do we consolidate
> the win32
> versions?

I think we just misunderstood each other - I didn't choose not to
answer, rather the right answer seemed to be a future decision
given the CE landscape at the time ;^)

As we've noticed that CE is slowly evolving into desktop win32
and much more capable 2nd and 3rd generation devices have come
out, I totally agree that consolidation would be a Good Thing.

Sorry if I've seemed uncommunicative on this - I've been doing
things like getting married and dealing with some big (good) changes
happening at DC, so I haven't had much time to put into CE for the
last couple months ;)


> While both CE and Python attempt to be portable, it appears
> that the current
> situation is not at all portable.  It appears there is no way
> we can write a
> win32 Python program, and have it work on both CE, and Win95/NT.
>
> At the most basic level, simple win32 wrappers are in
> differently named
> modules.  For example, the CE port has win32reg for the
> registry functions,
> but in the existing win32 ports, they exist in win32api.
> This is not to
> suggest my scheme is anywhere near ideal, but IMO a common strategy is
> needed.

I agree. The main hysterical reason for these warts was that
when I started working on that stuff, 4MB was the high-end as
far as total storage/memory on HPCs (and most folks seemed to
have 2MB) so footprint was very important back in the old days ;)

I've actually already started on this front, with the specific
goal of making those apis which are common to desktop win32
appear in the normal place. APIs that are CE specific (like the
CE database stuff) will probably stay separate for now.


>
> Longer term, I intend moving Pythonwin and COM support onto
> the CE platform.
> But I am faced with an obvious dillema.
>
> I would really like to hear ideas about how we move this
> forward, and make a
> truly portable port for all win32 variations.  I really dont
> want to start
> from scratch with the existing win32 extensions, but I fear
> there is no
> other alternative unless we can come to at least a basic
> agreement!  And two
> discrete ports are not in anyone's interests....

I think everyone would love to see Pythonwin and COM on CE, and
I'm certainly willing to do whatever I can to facilitate that.
Pywin/COM and a unified win32 port can basically be thought of as the
same effort IMHO, since the problems that will have to be solved
are entirely (or at least mostly) the same for both.

Some issues/thoughts in no particular order:

o CE is Unicode-only

o #1 is actually a lie, because it's really only _mostly_
   unicode-only, and the exceptions make it difficult to
   solve the problem in a mechanical fashion (TCHARs, etc).

o We probably dont want python users to care, if possible,
   about #1

o CE versions of APIs differ in sometimes strange ways from
   their desktop counterparts, often requiring different arg
   validation logic in C extensions.

o CE is still missing some big chunks of C runtime that will
   have to be added to the existing crt emulation to support
   existing code.

o We would like to leverage common code

o We also dont want to descend into an #ifdef hell ;^)

o Some of these issues affect the actual Python sources. I didn't
   want to propose any patches until they were fairly well thought
   out (and until I was sure MS wouldnt suddenly cancel CE and make
   the point moot ;)


It seems to me that we should take a very design-oriented approach
to this since getting to a portable port seems likely to have a
rather non-trivial impact on the existing win32 port.

Thoughts, comments?

Brian Lloyd        brian@...
Software Engineer  540.371.6909
Digital Creations  http://www.digicool.com
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Mark,

After Sam's last message most of the discussion went
offline.  Here's the current status.  My original question
had to do with the viability of getting Medusa working
on the CE environment.  At the time, the assumption was
that since CE did not support socket select(), this would
not be likely.  Since then, however, it appears that
select _is_ supported (just not the WSA equivalent) with
the following proviso, contributed by John Mills:

> I had a simple solution.  Select appears to destroy
> the array you pass it, so I copied the array before
> using select, and gave select the copy.  I created
> a new variable of type 'fd_set' called 'id'.
> Evidently I was testing for a timeout on the socket.
> Here's the function where I used it:
>
> BOOL CListenSock::GetStatus(BYTE of)
> {
>   if(m_socket)
>   {
>     // Unbelievable! Stupid select function destroys
>     // the array, so I have to copy it!!!
>     fd_set id = m_testID;
>
>     if(of==0)
>       return(select(0, &id, NULL, NULL, &m_zerotout));
>     else if(of==1)
>       return(select(0, NULL, &id, NULL, &m_zerotout));
>     else if(of==2)  //id replaces &m_testID
>       return(select(0, NULL, NULL, &id, &m_zerotout));
>   }
>   return(FALSE);
> }

Best regards,

Jeff Bauer
Rubicon, Inc.

------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Mark Hammond
> The good news is that I have a new CE machine (a
> Cassiopeia "palm size" model).
>
> Even better news - Brian's MIPS port worked first time :-)

I'm looking forward to seeing it in operation at the November
workshop.

> The bad news is that I have a new CE machine - so watch
> out :-)

You and your co-conspirators (Greg & Christian) are
getting ready to sully a perfectly good device with
COM and ActiveX.  I can see that it will all end in
tears.

[Comments about consolidating the Win32/CE versions.]
> I would really like to hear ideas about how we move
> this forward, and make a truly portable port for all
> win32 variations.  I really dont want to start
> from scratch with the existing win32 extensions, but
> I fear there is no other alternative unless we can
> come to at least a basic agreement!  And two discrete
> ports are not in anyone's interests....
>
> Comments, thoughts or flames?
>
> Mark.

No flames from me.  I think Mark has brought up an
important issue.  If history is a guide, you and Guido
can probably provide some insight as to how the
consolidation (assuming it occurs) might proceed.

In fairness to Brian, I think he (and everyone else at
Digital Creations) is just very busy rather than being
deliberately unresponsive.  The fact that Brian got
Python to work on CE at all is a minor miracle.

I'd like to propose a couple of possibilities:

1.  Creation of a separate mailing list for those
of us who want to work on the Python CE source:

   http://www.egroups.list/python-ce-hackers

These issues are different from those (most) users
who expect to use functioning Python CE binaries.

2.  Publish the current release of Python CE source
on the Starship (perhaps in CVS read-only browsable
format).  Posting the code is probably a good first
step, before we tackle consolidation strategies, etc.
Otherwise our discussion is occuring in a vacuum.

Posting the code also permits those of us who have
specific interests or needs to start making some
contributions sooner than later.  It also forces those
of us with the biggest axes to put up or shut up :)

Possible examples of CE code that could be contributed:
     1.  IrDA interface
     2.  SSL interface
     3.  Port of Sam Rushing's calldll Intel assembly code
         to MIPS, SH, processors.
     4.  GUI widgets  (strong-arm PythonWare into porting Topaz :)
     5.  zlib
     6.  audio interface
     7.  ActiveSync/ADO/COM/ActiveX/Oreo Cookies/Limeade :)

... and much, much, more ...

Best regards,

Jeff Bauer
Rubicon, Inc.

------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Sam asks:
> Does it have [Msg]WaitForMultipleObjects() ?

ce2 appears to have the Ex versions - eg, MsgWaitForMultipleObjectsEx is
documented as CE version 2 or later...

Mark.

-----
See the original message at http://www.egroups.com/list/python-ce/?start=3
--
Free e-mail group hosting at http://www.eGroups.com/
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

The good news is that I have a new CE machine (a Cassiopeia "palm size"
model).

Even better news - Brian's MIPS port worked first time :-)

The bad news is that I have a new CE machine - so watch out :-)

I have a question that I have previously asked of Brian, but much to my
dissapointment he chose not to answer:  How do we consolidate the win32
versions?

While both CE and Python attempt to be portable, it appears that the current
situation is not at all portable.  It appears there is no way we can write a
win32 Python program, and have it work on both CE, and Win95/NT.

At the most basic level, simple win32 wrappers are in differently named
modules.  For example, the CE port has win32reg for the registry functions,
but in the existing win32 ports, they exist in win32api.  This is not to
suggest my scheme is anywhere near ideal, but IMO a common strategy is
needed.

Longer term, I intend moving Pythonwin and COM support onto the CE platform.
But I am faced with an obvious dillema.

I would really like to hear ideas about how we move this forward, and make a
truly portable port for all win32 variations.  I really dont want to start
from scratch with the existing win32 extensions, but I fear there is no
other alternative unless we can come to at least a basic agreement!  And two
discrete ports are not in anyone's interests....

Comments, thoughts or flames?

Mark.


------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

>>>>> "j" == Jeff Bauer <jeffbauer@...> writes:

     j> The CGI server will probably be Python code along the the lines
     j> of Amos' BoboHTTPServer or Sam Rushing's Medusa.  Brian has
     j> pointed out one major problem with using Medusa: Windows CE
     j> lacks select().

Does it have [Msg]WaitForMultipleObjects() ?

-Sam
______________________________________________________________________
For the absolute lowest price on Computer Hardware visit:
http://www.bottomdollar.com/egroups/


Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Paul Everitt [paul@...]
> Oh, cool!  I remember Brian's face when I said how cool
> it would be to run Bobo on CE.  Kind of, "Yeh, and slice
> a tomato with a handheld, but I wouldn't eat it."
>
> What web server are you thinking about on CE?

Well, I kind of let the cat out of the bag for the
upcoming Python Conference, but Amos' remarks about
converting regex -> re were too serendipitous to ignore.
I've got SimpleHTTPServer running on a WinCE device,
serving up static pages. I'll be demonstrating this
in November.

As far as the rationale goes of why this is being done
(besides having a spiffy web server you can carry around
in your back pocket), there are circumstances that we
want the mobile device to respond to external stimuli.
Running Bobo on Python CE isn't necessary to our goals,
but it could become a pretty slick solution.

The CGI server will probably be Python code along the
the lines of Amos' BoboHTTPServer or Sam Rushing's
Medusa.  Brian has pointed out one major problem with
using Medusa:  Windows CE lacks select().

Regards,

Jeff Bauer
Rubicon, Inc.

______________________________________________________________________
For the absolute lowest price on Computer Hardware visit:
http://www.bottomdollar.com/egroups/


Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Welcome!

My name is Jeff Bauer and I've started this mail
list as a supplement to the discussion group at
http://www.digicool.com/~brian/PythonCE/discuss/
and the regular comp.lang.python news group.

If you don't know about Python:

     http://www.python.org/

For more information and to download Python CE:

     http://www.digicool.com/~brian/PythonCE/

Brian Lloyd, the creator of Python CE, will be unable to attend the November
1998 Python
Conference (SPAM-7).  It will be the first
conference to provide resources for demonstrating
Python applications.  This seemed like too good
an opportunity waste, so I have volunteered to
demonstrate Python CE at the conference.

I'm looking forward to seeing many of you in
November.

-Jeff


-----
Free e-mail group hosting at http://www.eGroups.com/

______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.