Q: should it work?

[eehouse]

> I've cut out some of the pieces, and answered/followed up on others.

Good idea.  I'll just keep what I can answer.

> > I suppose this depends on what limitations you have encountered.
> 
> I'll try to summarize here :
> - Recompiled Shaun's stuff (Mandriva is RPM based, not DEB)
> - I've been able to create and run GUI apps, but I had to work around
>   having WinMain() and no main() by still having an empty main()
>   function but telling the compiler to use _WinMain as the entry point
>   of the executable (gcc -e_WinMain)

That may be better than what I had to do:

#ifdef __GNUC__
int
main()
{
    return WinMain( GetModuleHandle(NULL), 0, 
#if defined TARGET_OS_WINCE
                    GetCommandLineW(), 
#elif defined TARGET_OS_WIN32
                    GetCommandLineA(), 
#endif
                    SW_SHOWDEFAULT );
}
#endif

>   I'd like to replace this by something more sensible.

WinMain should be an acceptable entrypoint out-of-the box, without
any special flags to gcc.  MinGW already allows this.

> - Had to remove the rename.o from the newlib libc.a because it clashed
>   with unistd.o, the both define the _rename symbol.

There's currently a whole set of function names that get munged to
avoid a conflict.  The windows side gets renamed, e.g. M$_select() for
select().  I've accomodated this with macros on the PPC side, but
since the same code compiles for win32 (mingw again) without the
munging there's clearly a better way.

> - I built include files based on the ones I found on my system from
>   wine. I've really taken over most of the wine files except where I
>   got in trouble using them, and edited them somewhat.
>   An example is that the TabCtrl_XX() macros all map to SendMessageA()
>   which is wrong for CE, it should use SendMessageW().

Yep.  I posted to the mingw list back in January explaining that
pocketpc dev tools were using their headers and needed some changes
and asking if they'd prefer that we submit patches or fork.  They were
enthusiastic in prefering the first.  I then submitted a patch
following their directions and nobody was even assigned to it for a
month.  It's not a priority for them because there are so few PPC
developers using their stuff.  Maybe if more of us complain... :-)

The patch is here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1426209&group_id=2435&atid=302435

I just did a cvs-update on the mingw include sources I've modified,
and there are no conflicts.  I think this means the patch will still 
apply cleanly.

> - I used Shauns SDK and extended it to generate libaygshell.a,
>   libcomctrl.a and libfileopen.a on a 'need to have' basis.
>   I'm not sure what I'm doing here but some things appear to work.

I've already done this for the most recent version of the pocketpc-sdk
.deb.  And my mingw patch adds the necessary headers.

> Limitations I see :
> - I don't have a solution for icons/images in the build process yet.

Crosswords (my app) uses lots of icons.  See the source.

> - A simplistic drawing example compiled with eVC4 creates a 5K exe
>   file, my toolchain creates an exe of about 186K.

My app's a tiny bit smaller than the last version I built with evc4,
but two caveats.  First, when I moved from evc3 to evc4 it jumped from
about 100K to the current ~170K.  I believed the change was due to
different compiler flags being default, but every time I tweaked them
I got a crashing binary.  Still, it's clearly possible for the binary
to be much smaller.  

Second, there is a lot of cruft in the .a files that could be
eliminated.  Run 'strings' on a stripped .exe to see all the debugging
code, for example.

> - Can't get dialog creation functions to work.

Works for me with the mingw patches.

>   Erics mail makes me wonder whether this is another include file
>   issue.

The only struct that's flat-out wrong for PPC (that I've encountered,
that is; I haven't done an audit) is WIN32_FIND_DATA.  But
DialogBoxParam is one of the functions that's not in the .dll and must
be implemented (via an inline, typically) locally.  My impl is in the
sources, but should eventually be moved into a library that's part of
the sdk.  Or incorporated in another patch to the mingw headers.

But that's not your problem: if you were trying to call the function
in the .dll your app wouldn't load at all.

> - I don't have a debugger

That sucks most of all!  It's pretty easy to keep code working on both
win32 and ppc to use whatever debugging Wine provides, but I do wonder
if I could have developed this app from scratch without eVC.  Most of
my code is cross-platform, so I can debug it on Linux or Palm where I
have gdb, but for some issues logfile-based debugging is a very slow
process.  Oh, and an emulator would be nice too. :-)

> - The apps I create do run, but they appear to create a non-standard
>   toolbar. Not sure what's causing this.

That's because by default the linker flags them as Wince apps rather
than PocketPC 2003, which was the first to put the menubar at the
bottom.  From my Makefile:

LFLAGS += -Wl,--major-subsystem-version,4,--minor-subsystem-version,20

> > Eat more rice pudding. It's tasty.
> 
> Hmm, I baked an almond cake a couple of days ago, there's still some :-)

'Round here we settle for pumpkin pie and ice cream. 

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