Re: [Cegcc-devel] Some cegcc issues, was: Re: Producing a cegcc binutils/gcc patchset, after all

[Paul S. <pm...@gm...>]

Hello,

On Sat, 18 Dec 2010 14:29:25 +0100
Danny Backx <dan...@sc...> wrote:

> On Thu, 2010-12-16 at 23:48 +0200, Paul Sokolovsky wrote:
> > And back to the issue at that link, I worked it around with the
> > following patch:
> > 
> > -BOOL WINAPI Shell_NotifyIconW(DWORD,PNOTIFYICONDATAW); 
> > +BOOL WINAPI Shell_NotifyIcon(DWORD,PNOTIFYICONDATAW); 
> > -#define Shell_NotifyIcon Shell_NotifyIconW 
> > +//#define Shell_NotifyIcon Shell_NotifyIconW 
> > 
> > But where's correct place to resolve this issue? AFAIK, headers come
> > from w32api/mingw32, so extra-patching them makes little sense,
> > besises they seem to be correct per MS docs, which say that wince
> > has only "W" functions. I understand that coredll is dllinked by
> > oridinals, so names are secondary, but maybe libcoredll.a is what
> > actually should provide "W" symbols?
> 
> I'm not going to get involved again, but take this advice from me :
> - you'll find that the MS docs are not always correct
> - you'll find every version of Windows to be subtly different

I bet ;-I

> 
> Merging with some other development (e.g. w32api) involves
> introducing a set of #ifdefs for CE into their sources.

Well, #ifdef is 2 lines => bigger patches, harder to eye-ball, higher
chance of conflict on upstream merge. Would you have comments regarding
_WNAME() macro I proposed in the other mail? (I undertstand it's only
part of the story, there're also CE-only funcs, funcs introduced in
newer CE versions, where #ifdefs are unavoidable).

> 
> 	Danny
> -- 
> Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
> 



-- 
Best regards,
 Paul                          mailto:pm...@gm...