This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Q: should it work?


> Eric House is also using the pocketpc-gcc toolchain to build Win32 API
> code. On this topic, he would be the person with whom to speak.

Happy to help if I can.

As Shaun says, I've been focussed on moving an app that was originally
developed with "Embedded Visual Studio" to the Debian pocketpc tools
that Shaun maintains.  I'm working with an app that's written using the
standard win32 APIs, rather than porting posix code to Wince, say.

> > - To do that, I've implemented some workarounds that I'd like to get rid
> >   of. Also maybe some of the limitations can be lifted by further work.
> 
> To use the GUI API, you've probably attacked the same problems as
> Eric. Get in touch with him.

There have been two classes of problems, IIRC.

First, the pocketpc tools rely on headers supplied by the MinGW
project which is entirely focussed on desktop win32 systems.
Microsoft supplies different headers for the two platforms for good
reason: sometimes the APIs and structures are subtly different.  For
example, some functions that are exported by .dlls on the desktop are
inline macros on pocketpc.  And some structs, though they have the
same name, are defined differently, perhaps with fields removed that
don't make sense on a handheld.

The second class of problem is that the official tools cooperate with
the OS in undocumented or unexpected ways.  For example, an app built
with evc 3 will always be run in "emulated" mode on a PPC 2003 device.
That's generally not what you want (if you're using menus, anyway), so
you want to appear to have been built with more recent tools.  The way
the OS determines what toolset built the app is by the major and minor
version flags in the .pe file header (in the .exe).  The only way to
figure out what the flags should be is to examine an app or .dll that
works and set yours the same.

> >   I was thinking about doing that, but am inclined to start off with a
> >   more up to date source distribution, to at least have a chance on the
> >   GCC/binutils folks pick up the patches.
> 
> I absolutely agree with moving to a newer toolchain. The toolchain
> only stopped because it was the last version with which *I* developed.

I'd also like to see us move to the most recent stable toolchain.
Emphasis on "stable", though.  I'm trying to ship a PPC app, not ask
my users to help find gcc bugs.  The current toolchain seems to work
as far as I've pushed it, but the project benefits by appealing to as
many potential developers as possible.

> > By the way I have a standard PocketPC (a Mio 168) and a PC with
> > Mandriva, and I'd like to develop GUI apps for the PocketPC. As an
> > experiment I'm porting Xinvest (http://xinvest.sunsite.dk).
> 
> An X11 app! Very ambitious. Which X server will you use? I'd think a
> GTK+DirectFB application would be easier.
> 
> > What I am missing :
> > - Documentation so I know what I'm doing (to be honest, I've been doing
> >   some trial and error, there has to be a better way).
> 
> There's no documentation. Reading the source is the only way to reach
> enlightenment. newlib/libc/sys/wince and pocketpc-sdk will be good
> reading.

I'm not sure if you're trying to do the same things, but you're
welcome to take a look at the Makefile for my app.  (Ignore the
comments at the top.  They're stale.  I'd fix 'em, but CVS is down on
sourceforge.  And I think I'm switching to subversion anyway....)

http://cvs.sourceforge.net/viewcvs.py/xwords/xwords4/wince/Makefile?rev=1.12&view=markup

At the moment, it builds perfectly (it's even a bit smaller than when
built with eVC), but only on my machine.  I've submitted patches to
the MinGW project to modify the headers for PPC but the patches have
not yet been accepted.

> >   I'd like to find out more about the processor (how do you program
> >   it in assembler, what's the ABI, ..). Also I don't have much info
> >   on how WinCE really works on this hardware.
> 
> The processor is an ARM sumpin sumpin (Intel StrongARM mebbe).
> 
> The ABI may be the standard ARM ABI:
> 
> 	http://www.arm.com/products/DevTools/ABI.html
> 
> I have no idea what syscall ABI the Pocket PC uses. In my discussion
> with Eric on this topic, we concluded that the machine syscall
> interface (SWI probably) may or may not be a rather fast moving and
> unpredictable target, which is usually wrapped by coredll.dll to such
> a degree that you should consider calling the coredll.dll API the
> syscall interface.

I have not attempted to program below the Win32 API level.  At some
point I'd like to try compiling THUMB code, but that's as low as I'll
go.  Actually, that's not quite true.  I also ship on Palm, and
compile for ARM there too.  It'd be great if some part of the app
could be identical for both, but there's too little gained to justify
any work in that direction.  Palm *as an ARM platform* is an even
faster moving target than PPC.

--Eric
-- 
******************************************************************************
* From the desktop of: Eric House, xwords@eehouse.org                        *
*        Crosswords 4.1.4 for PalmOS now ARM-native: xwords.sourceforge.net  *
******************************************************************************


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]