Menu
▾
▴
cegcc-devel
|
From: Pedro A. <alv...@gm...> - 2010-12-25 12:47:09
|
On Friday 24 December 2010 22:22:56, Paul Sokolovsky wrote: > Hello, > > Anyone can explain me meanings and differences between _WIN32_CE & > UNDER_CE ? UNDER_CE is not defined by CeGCC, while used for some > #ifdefs. I'm going to replace these with _WIN32_CE in my clean up work > so far. Would be useful to know what is it you're thinking you're cleaning up. UNDER_CE is a builtin define (defined by the compiler). You can use it to check whether you're targetting Windows CE, even if you haven't included any header in your compilation unit. There is no _WIN32_CE, you mean _WIN32_WCE (I've now fixed the $subject). _WIN32_WCE is the equivalent of _WIN32_WINNT on desktop Windows. You define it to the WinAPI version you want to target (e.g., 0x500), either on something like CFLAGS, or before including any w32api header. If you don't define it to anything, the w32api headers define it to a default conservative Windows CE version. Then, there's __COREDLL__ (for coredll.dll). This is defined by the compiler, and it selects the C runtime. On Desktop Windows, this would be either __MSVCRT__ (for msvcrt.dll), or __CRTDLL__ (legacy, for crtdll.dll). Early versions of Windows CE had some other C runtime dll (I can't remember which now). In mingw/ code, you always use __COREDLL__, _WIN32_WCE is verbotten there. -- Pedro Alves |
|
From: Paul S. <pm...@gm...> - 2010-12-25 14:14:25
|
Hello, On Sat, 25 Dec 2010 12:46:08 +0000 Pedro Alves <alv...@gm...> wrote: > On Friday 24 December 2010 22:22:56, Paul Sokolovsky wrote: > > Hello, > > > > Anyone can explain me meanings and differences between _WIN32_CE & > > UNDER_CE ? UNDER_CE is not defined by CeGCC, while used for some > > #ifdefs. I'm going to replace these with _WIN32_CE in my clean up > > work so far. > > Would be useful to know what is it you're thinking you're cleaning up. Hello Pedro, nice to have your attention ;-). I recently sent several mails to the list pondering how to make what cegcc achieved more maintainable. In short, my ideas were: extract patches from cegcc svn repo, clean them up to contain only wince-pertinent changes and optimize for size (change as little as possible), then use modern SCM which allows to track upstream close and maintained changes in flexible manner (read: git). I currently try to to this for w32api, following procedure I outlined at http://article.gmane.org/gmane.comp.gnu.cegcc.devel/3163 (even though I already see drawbacks there). > > UNDER_CE is a builtin define (defined by the compiler). You can use > it to check whether you're targetting Windows CE, even if you haven't > included any header in your compilation unit. Ok, I see, it is set up in your mingw32ce-gcc_20091228_r155193.diff patch. > > There is no _WIN32_CE, you mean _WIN32_WCE (I've now fixed the Yes, sure, that's a typo. > $subject). _WIN32_WCE is the equivalent of _WIN32_WINNT on desktop > Windows. You define it to the WinAPI version you want to target > (e.g., 0x500), either on something like CFLAGS, or before including > any w32api header. If you don't define it to anything, the w32api > headers define it to a default conservative Windows CE version. > > Then, there's __COREDLL__ (for coredll.dll). This is defined by the > compiler, and it selects the C runtime. On Desktop Windows, this > would be either __MSVCRT__ (for msvcrt.dll), or __CRTDLL__ (legacy, > for crtdll.dll). Early versions of Windows CE had some other C > runtime dll (I can't remember which now). In mingw/ code, you always > use __COREDLL__, _WIN32_WCE is verbotten there. Ok, sounds good, rules for mingw are clear. But original question popped up while looking at w32api: $ grep -r -n UNDER_CE --exclude-dir=.svn w32api/include/ w32api/include/ws2tcpip.h:44:#ifdef UNDER_CE w32api/include/winbase.h:813:#ifdef UNDER_CE w32api/include/winbase.h:1189:#ifndef UNDER_CE $ grep -r -n _WIN32_WCE --exclude-dir=.svn w32api/include/ | wc -l 174 As w32api defines _WIN32_WCE first thing and already uses it in 99% cases, maybe it should use it exclusively? > > -- > Pedro Alves -- Best regards, Paul mailto:pm...@gm... |
|
From: Pedro A. <alv...@gm...> - 2010-12-27 14:33:06
|
On Saturday 25 December 2010 14:14:10, Paul Sokolovsky wrote: > On Sat, 25 Dec 2010 12:46:08 +0000 > Pedro Alves <alv...@gm...> wrote: > > > On Friday 24 December 2010 22:22:56, Paul Sokolovsky wrote: > > > Hello, > > > > > > Anyone can explain me meanings and differences between _WIN32_CE & > > > UNDER_CE ? UNDER_CE is not defined by CeGCC, while used for some > > > #ifdefs. I'm going to replace these with _WIN32_CE in my clean up > > > work so far. > > > > Would be useful to know what is it you're thinking you're cleaning up. > > Hello Pedro, nice to have your attention ;-). I recently sent > several mails to the list pondering how to make what cegcc achieved > more maintainable. In short, my ideas were: extract patches from cegcc > svn repo, clean them up to contain only wince-pertinent changes and > optimize for size (change as little as possible), Hello! :-) IIRC, the w32api wince changes compared to upstream aren't that many or that invasive that cause trouble when merging from upstream. The scheme I was following, was that I kept the CVS (metadata) directories in our svn repository, so a merge from upstream is literally just a regular cvs update, and whole diff from upstream is just a "cvs diff". > then use modern SCM > which allows to track upstream close and maintained changes in flexible > manner (read: git). > > I currently try to to this for w32api, following procedure I outlined at > http://article.gmane.org/gmane.comp.gnu.cegcc.devel/3163 (even though I > already see drawbacks there). I haven't looked at your git tree, but I'm not sure what we'd be really buying with your suggestion. Instead of adding/removing ifdefs, we're now actually _changing_ declarations, which is troublesome in its own way at merge time. It also hides things from grep and from users when the compiler/IDEs points "wrong arguments, here's the declaration", so I'm not convinced it's a change we want. > Ok, sounds good, rules for mingw are clear. But original question > popped up while looking at w32api: > > $ grep -r -n UNDER_CE --exclude-dir=.svn w32api/include/ > w32api/include/ws2tcpip.h:44:#ifdef UNDER_CE > w32api/include/winbase.h:813:#ifdef UNDER_CE > w32api/include/winbase.h:1189:#ifndef UNDER_CE Agreed. The winbase.h:813 change (r1278) should have never gone in like that though :-( :-( > r1278 | dannybackx | 2009-05-18 11:57:49 +0100 (Seg, 18 Mai 2009) | 2 linhas > > Definition for CE for CRITICAL_SECTION taken from http://fpc.freedoors.org/fpc-2.2.0.source/rtl/win/sysosh.inc under LGPL license. Argh. LGPL code in w32api headers is not allowed. :-/ > > $ grep -r -n _WIN32_WCE --exclude-dir=.svn w32api/include/ | wc -l > 174 > > As w32api defines _WIN32_WCE first thing and already uses it in 99% > cases, maybe it should use it exclusively? Sure. -- Pedro Alves |
|
From: Paul S. <pm...@gm...> - 2010-12-27 16:30:17
|
Hello, On Mon, 27 Dec 2010 14:32:54 +0000 Pedro Alves <alv...@gm...> wrote: > On Saturday 25 December 2010 14:14:10, Paul Sokolovsky wrote: > > On Sat, 25 Dec 2010 12:46:08 +0000 > > Pedro Alves <alv...@gm...> wrote: > > > > > On Friday 24 December 2010 22:22:56, Paul Sokolovsky wrote: > > > > Hello, > > > > > > > > Anyone can explain me meanings and differences between > > > > _WIN32_CE & UNDER_CE ? UNDER_CE is not defined by CeGCC, while > > > > used for some #ifdefs. I'm going to replace these with > > > > _WIN32_CE in my clean up work so far. > > > > > > Would be useful to know what is it you're thinking you're > > > cleaning up. > > > > Hello Pedro, nice to have your attention ;-). I recently sent > > several mails to the list pondering how to make what cegcc achieved > > more maintainable. In short, my ideas were: extract patches from > > cegcc svn repo, clean them up to contain only wince-pertinent > > changes and optimize for size (change as little as possible), > > Hello! :-) > > IIRC, the w32api wince changes compared to upstream aren't that many > or that invasive that cause trouble when merging from upstream. Actually, I have to agree, using such objective criteria, as patch size, or number of actual conflicts experienced. I now finished 1st round of my cleanup, and was able to cut size only from 120K to 115K. I also had just one conflict upgrading to w32api CVS HEAD. But there's more involved criterion as maintainability, and I believe my changes improved it. That said, I'll probably will be less vigorous with in-depth cleanup with other components, instead will try to set git repos for each first. > The > scheme I was following, was that I kept the CVS (metadata) directories > in our svn repository, so a merge from upstream is literally just a > regular cvs update, and whole diff from upstream is just a "cvs diff". Yes, I got that, that's how I produced w32api-cegcc patchset: cvs -z9 diff -u -w -B >diff_w_B.diff (-w -B are part of my "cleanup" plan). Except that it involves dealing with CVS and its quirks (which I for example already forgot for good), and lacking base-level DSCM goodness, like ability to get that diff immediately, with or without network. > > > then use modern SCM > > which allows to track upstream close and maintained changes in > > flexible manner (read: git). > > > > I currently try to to this for w32api, following procedure I > > outlined at > > http://article.gmane.org/gmane.comp.gnu.cegcc.devel/3163 (even > > though I already see drawbacks there). > > I haven't looked at your git tree, Yeah, I actually didn't announce it yet, though pushed already and started to describe. It's here: https://sourceforge.net/apps/trac/cegcc/wiki/Git%20Migration (feel free to skip blurb, to "Draft w32api Repository"). > but I'm not sure what we'd be > really buying with your suggestion. Instead of adding/removing > ifdefs, we're now actually _changing_ declarations, which is > troublesome in its own way at merge time. It also hides things from > grep and from users when the compiler/IDEs points "wrong arguments, > here's the declaration", so I'm not convinced it's a change we want. I'm not sure what you exactly mean, as I meant procedure of migrating w32api-cegcc changes to git in such a way as to track upstream closely, which is at the link above. I guess, you comment on _WNAME() macro which I proposed in another mail. Well, one can utter such arguments against it (I already hear them from GNU bureaucrats ;-) ), but they are not very stable: 1. Changing existing declaration => problem of conflicts. Yes, if that declaration will be updated in upstream, there will be conflict. But there's much less chance that declaration will be added than what new will be added (w32api is still lacking) - right where one of dozen ifdefs is planted. 2. Grep unfriendly? Why, grep for "Shell_NotifyIcon" and you'll find what you want. What, you grep for "Shell_NotifyIcon("? Oops, then in the original w32api you also won't find anything, there's only Shell_NotifyIconA( and Shell_NotifyIconW(. 3. Compiler error line numbers? Oops, when programming for win32, you used "Shell_NotifyIcon" in your code and compiler pointed you at "Shell_NotifyIconA" or "Shell_NotifyIconW". Gotta learn what that means. Manageable? Then looking up what _WNAME means couple of times and remembering that should be too. 2&3 show that w32api already not that obvious. But _WNAME is at least clean change on messy base (it does one specific thing in one specific way). While #ifdef's are messy change on messy base, let me give more examples why (in addition to type example I gave before, I saw couple more already IIRC). There're different structural variants used, like: #ifdef _WIN32_WCE void foo(); #else void fooA(); void fooW(); #endif and #ifndef _WIN32_WCE void fooA(); void fooW(); #else void foo(); #endif then, if few goes in row, they are grouped together. Then there're 2 groups with thin layer, like: #ifdef _WIN32_WCE void foo1(); void foo2(); .. #endif void bar1(); #ifdef _WIN32_WCE void baz1(); void baz2(); .. #endif Then human editor tries to "optimize" that by moving upstream line at the top and merging #ifdef chunks, and that goes in rounds and rounds, without criteria to converge. On the other hand, again, _WNAME does just what it does, line-local, and there's no proverbial "there's more than one way to do that". Final argument is that it's possible to produce #ifdef's from _WNAME (when wince support will stabilize or upstream will play up), but not the other way around, per examples above. > > > Ok, sounds good, rules for mingw are clear. But original question > > popped up while looking at w32api: > > > > $ grep -r -n UNDER_CE --exclude-dir=.svn w32api/include/ > > w32api/include/ws2tcpip.h:44:#ifdef UNDER_CE > > w32api/include/winbase.h:813:#ifdef UNDER_CE > > w32api/include/winbase.h:1189:#ifndef UNDER_CE > > Agreed. The winbase.h:813 change (r1278) should have never gone > in like that though :-( :-( Yeah, caught my attention too. https://github.com/pfalcon/cegcc-w32api-try1/commit/47e68fa3391758aa4e3352a6916ac06c649278a4 > > > r1278 | dannybackx | 2009-05-18 11:57:49 +0100 (Seg, 18 Mai 2009) | > > 2 linhas > > > > Definition for CE for CRITICAL_SECTION taken from > > http://fpc.freedoors.org/fpc-2.2.0.source/rtl/win/sysosh.inc under > > LGPL license. > > Argh. LGPL code in w32api headers is not allowed. :-/ > > > > > $ grep -r -n _WIN32_WCE --exclude-dir=.svn w32api/include/ | wc -l > > 174 > > > > As w32api defines _WIN32_WCE first thing and already uses it in 99% > > cases, maybe it should use it exclusively? > > Sure. https://github.com/pfalcon/cegcc-w32api-try1/commit/be2a26d09e971f81dee8b4787e30ab06d9707eff > > -- > Pedro Alves -- Best regards, Paul mailto:pm...@gm... |
|
From: Paul S. <pm...@gm...> - 2010-12-28 10:27:08
|
Hello, On Mon, 27 Dec 2010 18:30:01 +0200 Paul Sokolovsky <pm...@gm...> wrote: [] > > > > > > $ grep -r -n _WIN32_WCE --exclude-dir=.svn w32api/include/ | wc -l > > > 174 > > > > > > As w32api defines _WIN32_WCE first thing and already uses it in > > > 99% cases, maybe it should use it exclusively? > > > > Sure. > > https://github.com/pfalcon/cegcc-w32api-try1/commit/be2a26d09e971f81dee8b4787e30ab06d9707eff Figured this issue, UNDER_CE usage comes from upstream, so will revert this patch, as rule "Don't patch upstream without real necessity" prevails "Have 100% consistency". -- Best regards, Paul mailto:pm...@gm... |
|
From: Vincent T. <vt...@un...> - 2010-12-27 17:16:58
|
Hey, On Mon, 27 Dec 2010, Paul Sokolovsky wrote: > https://github.com/pfalcon/cegcc-w32api-try1/commit/be2a26d09e971f81dee8b4787e30ab06d9707eff shouldn't the critical section be removed if (L)GPL code is not allowed instead of replacing UNDER_CE by WIN32_WCE (first change) ? Vincent Torri |
|
From: Paul S. <pm...@gm...> - 2010-12-27 18:20:16
|
Hello, On Mon, 27 Dec 2010 18:16:48 +0100 (CET) Vincent Torri <vt...@un...> wrote: > > Hey, > > On Mon, 27 Dec 2010, Paul Sokolovsky wrote: > > > https://github.com/pfalcon/cegcc-w32api-try1/commit/be2a26d09e971f81dee8b4787e30ab06d9707eff > > shouldn't the critical section be removed if (L)GPL code is not > allowed instead of replacing UNDER_CE by WIN32_WCE (first change) ? Following commit was in regard to CRITICAL_SECTION: https://github.com/pfalcon/cegcc-w32api-try1/commit/47e68fa3391758aa4e3352a6916ac06c649278a4 Internally, I removed it, then did some googling (mostly looked at the search highlight excerpts), friend phoning, few debugging sessions. In the end, it seemed that structure was laid out right, just comments were dubious. Btw, while looking at vendor source may be considered questionable practice, because vendor source access is granted by a license which itself, and its licensing process (like changes evolution), don't receive enough 3rd-party review (and thus may contain *really* funky things), I consider that (L)GPL and its motivation is sufficiently known to public, so looking at (L)GPL texts to *get knowledge* is ok. It's like, some time ago I read in some glossy magazine that wearing specific model of hat in some specific way would protect my ears from frost much better than anything else. Not common knowledge on its own. And I couldn't copy and sell their magazine on my own, in full or in part, or copy that article to other magazine. But I use that knowledge since then, including in public, and wasn't requested to stop doing that or pay royalties. That's because that magazine is like all other magazines, and they don't do things like that. And there are many projects which use (L)GPL and stopping spreading of knowledge is not known to be among their aims. And it's different from the vendor, which has its proprietary license, motives of which are less clear. > > Vincent Torri -- Best regards, Paul mailto:pm...@gm... |
|
From: Pedro A. <alv...@gm...> - 2010-12-27 18:27:30
|
On Monday 27 December 2010 18:19:59, Paul Sokolovsky wrote: > Btw, while looking at vendor source may be considered questionable > practice, because vendor source access is granted by a license which > itself, and its licensing process (like changes evolution), don't > receive enough 3rd-party review (and thus may contain really funky > things), I consider that (L)GPL and its motivation is sufficiently > known to public, so looking at (L)GPL texts to get knowledge is ok. No it's not. <http://www.mingw.org/wiki/SubmitPatches>, point 8. -- Pedro Alves |
|
From: Paul S. <pm...@gm...> - 2010-12-27 18:56:02
|
Hello, On Mon, 27 Dec 2010 18:26:53 +0000 Pedro Alves <alv...@gm...> wrote: > On Monday 27 December 2010 18:19:59, Paul Sokolovsky wrote: > > Btw, while looking at vendor source may be considered questionable > > practice, because vendor source access is granted by a license which > > itself, and its licensing process (like changes evolution), don't > > receive enough 3rd-party review (and thus may contain really funky > > things), I consider that (L)GPL and its motivation is sufficiently > > known to public, so looking at (L)GPL texts to get knowledge is ok. > > No it's not. <http://www.mingw.org/wiki/SubmitPatches>, point 8. You probably misread, Pedro, they talk about source, and I'm about knowledge. I consider it to be a different matter to do dumb cut&paste and reading an electronic book, even if it's Chinese or C++, to get understanding of some subject. For example, I could study question of process synchronization and even remember key points like object member names, though I doubt I'd remember footnotes or comments, word by word, or at all. Also, it seems that using LGPL source is allowed after all: they prohibit GPL and LPGL (sic!). Everyone's mileage will vary, though. I'm not interested in upstreaming (I know all this mumbo-jumbo oh so well), so mingw's specific mileage won't hurt me much. That said, I hereby confirm that I know of such issues and am doing reasonable effort to follow upstream's guidelines on the matter. I also know that Pedro Alves and Danny Backx are aware of these issues and did their reasonable effort to comply either, so I take their code "as is" as the basis for my work. Specific cases may be considered later. > > -- > Pedro Alves -- Best regards, Paul mailto:pm...@gm... |
|
From: Paul S. <pm...@gm...> - 2010-12-27 18:58:58
|
Hello, On Mon, 27 Dec 2010 20:55:49 +0200 Paul Sokolovsky <pm...@gm...> wrote: [] > Everyone's mileage will vary, though. I'm not interested in > upstreaming (I know all this mumbo-jumbo oh so well), so mingw's > specific mileage won't hurt me much. That said, I hereby confirm that > I know of such issues and am doing reasonable effort to follow > upstream's guidelines on the matter. I also know that Pedro Alves and > Danny Backx are aware of these issues and did their reasonable effort > to comply either, so I take their code "as is" as the basis for my "their code" == "code they maintained" > work. Specific cases may be considered later. -- Best regards, Paul mailto:pm...@gm... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X