Menu
▾
▴
cegcc-devel — Discussion about CeGCC development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(63) |
Sep
(78) |
Oct
(111) |
Nov
(104) |
Dec
(39) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(69) |
Feb
(68) |
Mar
(23) |
Apr
(61) |
May
(56) |
Jun
(122) |
Jul
(82) |
Aug
(44) |
Sep
(63) |
Oct
(73) |
Nov
(77) |
Dec
(102) |
| 2008 |
Jan
(34) |
Feb
(51) |
Mar
(39) |
Apr
(43) |
May
(8) |
Jun
(59) |
Jul
(69) |
Aug
(97) |
Sep
(140) |
Oct
(72) |
Nov
(37) |
Dec
(35) |
| 2009 |
Jan
(70) |
Feb
(104) |
Mar
(42) |
Apr
(121) |
May
(161) |
Jun
(109) |
Jul
(90) |
Aug
(85) |
Sep
(104) |
Oct
(59) |
Nov
(76) |
Dec
(145) |
| 2010 |
Jan
(123) |
Feb
(45) |
Mar
(37) |
Apr
(9) |
May
|
Jun
(5) |
Jul
(22) |
Aug
|
Sep
(4) |
Oct
(5) |
Nov
(2) |
Dec
(83) |
| 2011 |
Jan
(19) |
Feb
(33) |
Mar
(14) |
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(8) |
Dec
(8) |
| 2012 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
|
May
(5) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: SourceForge.net <no...@so...> - 2011-02-05 14:32:35
|
Bugs (deprecated, use Trac) item #2954077, was opened at 2010-02-18 01:05 Message generated for change (Settings changed) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2954077&group_id=173455 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Radics Peter (mitch0) Assigned to: Danny Backx (dannybackx) Summary: configure fix for building on freebsd Initial Comment: The configure scripts under src/gcc and src/gcc-4.4.0 incorrectly use ${target} when trying to locate libgmp and libmpfr on freebsd hosts. I moved the check to a different case which checks ${host} instead. Patch attached, it was made against r1444. cheers, mitch ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2010-02-20 01:43 Message: Two remarks : - the real fix is not to configure but to configure.ac - this should be reported to the gcc bugzilla, it's not cegcc specific. I'll make the change to cegcc too if you get approval from the gcc folks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2954077&group_id=173455 |
|
From: Paul S. <pm...@gm...> - 2011-02-05 14:27:22
|
Hello, Per previous RFC, I'm proceeding with bugtracking migration to Trac: 1. Trac's tracker configured for usage, first bug posted. 2. SF.net native bug tracker was augmented with visible notices that Trac should be used, but tracker renamed to "Bugs (depracated, use Trac)" 3. Unused Support Request tracker was disabled. 4. All tickets from Feature Requests and Patches are being move are Bugs, corresponding trackers to be disabled afterwards. 5. Notice are to be added to each open ticket, asking submitter to repost the ticket to Trac. 6. Depending on user response, I'll try to migrate important tickets myself as time permits. -- Best regards, Paul mailto:pm...@gm... |
|
From: SourceForge.net <no...@so...> - 2011-02-05 14:21:47
|
Bugs item #2721601, was opened at 2009-03-29 18:26 Message generated for change (Settings changed) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2721601&group_id=173455 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: Death Knight® (erdem_ua) Assigned to: Danny Backx (dannybackx) Summary: x86_64 Build Initial Comment: Hi, First of all thank you for this great project. I am 64bit linux user. And I have some problems with your release. Is it possible to release x86_64 bit for linux? Thank you. ---------------------------------------------------------------------- Comment By: Death Knight® (erdem_ua) Date: 2009-04-28 15:30 Message: Like librapi dependency. I also tried install librapi2 i586 rpm for opensuse but it doesn't work. I don't know if it possible to compile cegcc in 64 bit mode, but if you release x64 bit one, I prefer x64 bit one. Thank you. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-04-28 06:49 Message: Which problems exactly ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2721601&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 14:21:36
|
Bugs item #1889860, was opened at 2008-02-08 13:52 Message generated for change (Settings changed) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=1889860&group_id=173455 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Boris Brodski (boris_brodski) Assigned to: Nobody/Anonymous (nobody) Summary: DirectShow include files problem Initial Comment: If you try to include following h-files #include <windows.h> #include <dshow.h> you get /cygdrive/d/CeGCC/cegcc/bin/../lib/gcc/arm-wince-cegcc/4.1.0/../../../../arm-wince-cegcc/lib/../include/w32api/dshow.h:8, from ..\src\WinCETest.cpp:15: /cygdrive/d/CeGCC/cegcc/bin/../lib/gcc/arm-wince-cegcc/4.1.0/../../../../arm-wince-cegcc/lib/../include/w32api/amaudio.h:7:20: error: dsound.h: No such file or directory In file included from /cygdrive/d/CeGCC/cegcc/bin/../lib/gcc/arm-wince-cegcc/4.1.0/../../../../arm-wince-cegcc/lib/../include/w32api/dshow.h:9, from ..\src\WinCETest.cpp:15: /cygdrive/d/CeGCC/cegcc/bin/../lib/gcc/arm-wince-cegcc/4.1.0/../../../../arm-wince-cegcc/lib/../include/w32api/amvideo.h:7:19: error: ddraw.h: No such file or directory It seems, that at least ddraw.h and dsound.h files are missing. For example as a result a definition of IBaseFilter can't be found. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-28 08:17 Message: Thank you very much for reply. Unfortunately, after more that one year I can't test it any more. If #include <windows.h> #include <dshow.h> cause no compile errors you can close this feature request safely. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-04-28 07:34 Message: IBaseFilter is in w32api/include/strmif.h . Please provide complete information (preferably a patch) for the stuff you're missing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=1889860&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 14:21:27
|
Bugs item #2750052, was opened at 2009-04-10 02:02 Message generated for change (Settings changed) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2750052&group_id=173455 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Marcel Smit (marcelsmit) Assigned to: Danny Backx (dannybackx) Summary: Definitions of API functions results in compiler errors Initial Comment: In kfuncs.h some API functions are declared as follows: #define GetCurrentThread() ((HANDLE)(SH_CURTHREAD+SYS_HANDLE_BASE)) This sometimes results in compiler errors. Defining them as follows, resolves these compiler errors: inline HANDLE GetCurrentProcess() { return ((HANDLE)(SH_CURPROC+SYS_HANDLE_BASE)); } Attached a changed kfuncs.h ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-04-10 03:07 Message: Applied your fix, thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2750052&group_id=173455 |
|
From: cegcc <no...@so...> - 2011-02-05 14:00:22
|
#1: Internal compiler error taking address of dllimported symbol
----------------------+-----------------------------------------------------
Reporter: pfalcon | Owner: somebody
Type: bug | Status: new
Priority: critical | Milestone:
Component: gcc | Version: gcc-4.4.0
Keywords: |
----------------------+-----------------------------------------------------
Changes (by pfalcon):
* priority: major => critical
* version: => gcc-4.4.0
--
Ticket URL: <http://sourceforge.net/apps/trac/cegcc/ticket/1#comment:1>
cegcc <http://sourceforge.net/projects/cegcc/>
CeGCC - GCC cross-compiling toolchain for WinCE
|
|
From: cegcc <no...@so...> - 2011-02-05 13:10:28
|
#1: Internal compiler error taking address of dllimported static class member
---------------------+------------------------------------------------------
Reporter: pfalcon | Owner: somebody
Type: bug | Status: new
Priority: major | Milestone:
Component: gcc | Version:
Keywords: |
---------------------+------------------------------------------------------
Reported in mailing list. Testcase was reduced to:
{{{
class __declspec(dllimport) Test {
public:
int member;
static int smember;
};
int main() {
// This is ok
int x = Test::smember;
// This leads to internal compiler error
int *p = &Test::smember;
}
}}}
Leads to:
{{{
dllimport-class-static.cpp: In function 'int main()':
dllimport-class-static.cpp:12: error: unrecognizable insn:
(insn 10 9 11 2 dllimport-class-static.cpp:11 (set (reg/f:SI 138)
(symbol_ref:SI ("_ZN4Test7smemberE") [flags 0x440] <var_decl
0xb75cf000 smember>)) -1 (nil))
dllimport-class-static.cpp:12: internal compiler error: in extract_insn,
at recog.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://sourceforge.net/tracker/?func=add&group_id=173455&atid=865514>
for instructions.
}}}
Further reduction lead to:
{{{
__declspec(dllimport) extern int from_dll;
int main() {
int *p = &from_dll;
}
}}}
--
Ticket URL: <http://sourceforge.net/apps/trac/cegcc/ticket/1>
cegcc <http://sourceforge.net/projects/cegcc/>
CeGCC - GCC cross-compiling toolchain for WinCE
|
|
From: Paul S. <pm...@gm...> - 2011-02-05 03:15:17
|
Hello,
On Fri, 04 Feb 2011 18:42:12 +0100
Mauro Ziliani <mau...@ng...> wrote:
> Oh sorry.
> I sent the email with the attachment by the list kill it because it
> was too big.
>
> I reattach the file zipping it.
>
> It is the preprocessed output.
>
> About the testing program.
> I try a small main program but it works well.
> The problem is compiling qt.
>
>
>
> Il 04/02/2011 18.23, Paul Sokolovsky ha scritto:
> > Hello,
> >
> > On Fri, 04 Feb 2011 17:51:10 +0100
> > Mauro Ziliani<mau...@ng...> wrote:
> >
> > []
> >
> >> In function 'int (HINSTANCE__*, HINSTANCE__*, WCHAR*, int)':
> >> qtmain_win.cpp:140: error: unrecognizable insn: (insn 9 8 10 3
> >> ../../include/QtCore/../../src/corelib/tools/qbytearray.h:364 (set
> >> (reg/f:SI 214)
> >> (symbol_ref:SI ("_ZN10QByteArray11shared_nullE") [flags
> >> 0x4c0]<var_decl 0x7ff97b68 shared_null>)) -1 (nil))
> >> qtmain_win.cpp:140: internal compiler error: in extract_insn, at
> >> recog.c:2048
Ok, so the matter is not at qtmain_win.cpp:140 (end of program), but
where _ZN10QByteArray11shared_nullE is accessed.
And that's:
--------------
class __attribute__((dllimport)) QByteArray
{
inline QByteArray();
...
static Data shared_null;
...
};
inline QByteArray::QByteArray(): d(&shared_null) { d->ref.ref(); }
----------------
So, there's issue with accessing static members in dllimported class.
And static members and dllimport already a peculiar area, see for
example
http://stackoverflow.com/questions/3491990/c-definition-of-dllimport-static-data-member
Definition of shared_null doesn't happen here, but maybe GCC mixes up
something and mistreats static/dllimport combo which gives result
unexpected to itself. Or maybe it's instead the most obvious
explanation: taking an address of dllimported static field is not
implemented for arm-pe target. So the next step would be trying to
compile it with win32's mingw32, to see how x86-pe handles it, then try
to compare machine definitions for x86 and arm.
> >> Please submit a full bug report,
> >> with preprocessed source if appropriate.
> >> See<http://gcc.gnu.org/bugs.html> for instructions.
> >> mingw32-make[2]: *** [tmp/obj/release_shared/qtmain_win.o] Error 1
> >> mingw32-make[2]: Leaving directory
> >> `C:/qt/qt-embedded-wince-opensource-src-4.4.0/src/winmain'
> >> mingw32-make[1]: *** [release] Error 2
> >> mingw32-make[1]: Leaving directory
> >> `C:/qt/qt-embedded-wince-opensource-src-4.4.0/src/winmain'
> >> mingw32-make: *** [sub-winmain-make_default-ordered] Error 2
> >>
> >> I attach the qtmain_win.ii completeness
> > Attachment didn't get thru. If you actually attached it, then maybe
> > list is configured to remove them. Try pasting lines where error
> > happens directly into mail then. And to make steps towards resolving
> > it, a standalone test program would be likely needed.
> >
> >> Any idea?
> >>
> >> MZ
>
--
Best regards,
Paul mailto:pm...@gm...
|
|
From: Mauro Z. <mau...@ng...> - 2011-02-04 17:42:25
|
Oh sorry.
I sent the email with the attachment by the list kill it because it was
too big.
I reattach the file zipping it.
It is the preprocessed output.
About the testing program.
I try a small main program but it works well.
The problem is compiling qt.
Il 04/02/2011 18.23, Paul Sokolovsky ha scritto:
> Hello,
>
> On Fri, 04 Feb 2011 17:51:10 +0100
> Mauro Ziliani<mau...@ng...> wrote:
>
> []
>
>> In function 'int (HINSTANCE__*, HINSTANCE__*, WCHAR*, int)':
>> qtmain_win.cpp:140: error: unrecognizable insn: (insn 9 8 10 3
>> ../../include/QtCore/../../src/corelib/tools/qbytearray.h:364 (set
>> (reg/f:SI 214)
>> (symbol_ref:SI ("_ZN10QByteArray11shared_nullE") [flags
>> 0x4c0]<var_decl 0x7ff97b68 shared_null>)) -1 (nil))
>> qtmain_win.cpp:140: internal compiler error: in extract_insn, at
>> recog.c:2048
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See<http://gcc.gnu.org/bugs.html> for instructions.
>> mingw32-make[2]: *** [tmp/obj/release_shared/qtmain_win.o] Error 1
>> mingw32-make[2]: Leaving directory
>> `C:/qt/qt-embedded-wince-opensource-src-4.4.0/src/winmain'
>> mingw32-make[1]: *** [release] Error 2
>> mingw32-make[1]: Leaving directory
>> `C:/qt/qt-embedded-wince-opensource-src-4.4.0/src/winmain'
>> mingw32-make: *** [sub-winmain-make_default-ordered] Error 2
>>
>> I attach the qtmain_win.ii completeness
> Attachment didn't get thru. If you actually attached it, then maybe
> list is configured to remove them. Try pasting lines where error
> happens directly into mail then. And to make steps towards resolving
> it, a standalone test program would be likely needed.
>
>> Any idea?
>>
>> MZ
|
|
From: Paul S. <pm...@gm...> - 2011-02-04 17:24:07
|
Hello,
On Fri, 04 Feb 2011 17:51:10 +0100
Mauro Ziliani <mau...@ng...> wrote:
[]
> In function 'int (HINSTANCE__*, HINSTANCE__*, WCHAR*, int)':
> qtmain_win.cpp:140: error: unrecognizable insn: (insn 9 8 10 3
> ../../include/QtCore/../../src/corelib/tools/qbytearray.h:364 (set
> (reg/f:SI 214)
> (symbol_ref:SI ("_ZN10QByteArray11shared_nullE") [flags
> 0x4c0] <var_decl 0x7ff97b68 shared_null>)) -1 (nil))
> qtmain_win.cpp:140: internal compiler error: in extract_insn, at
> recog.c:2048
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> mingw32-make[2]: *** [tmp/obj/release_shared/qtmain_win.o] Error 1
> mingw32-make[2]: Leaving directory
> `C:/qt/qt-embedded-wince-opensource-src-4.4.0/src/winmain'
> mingw32-make[1]: *** [release] Error 2
> mingw32-make[1]: Leaving directory
> `C:/qt/qt-embedded-wince-opensource-src-4.4.0/src/winmain'
> mingw32-make: *** [sub-winmain-make_default-ordered] Error 2
>
> I attach the qtmain_win.ii completeness
Attachment didn't get thru. If you actually attached it, then maybe
list is configured to remove them. Try pasting lines where error
happens directly into mail then. And to make steps towards resolving
it, a standalone test program would be likely needed.
>
> Any idea?
>
> MZ
--
Best regards,
Paul mailto:pm...@gm...
|
|
From: Mauro Z. <mau...@ng...> - 2011-02-04 16:51:18
|
Hi all. My name's Mauro and I'm working on QT and arm-mingw32ce compiler. I follow this post. http://permalink.gmane.org/gmane.comp.gnu.cegcc.devel/1214 Compiling qtmain_win.cpp the compiler tell me this error. cd src/winmain/ && C:/MinGW/bin/mingw32-make -f Makefile mingw32-make[1]: Entering directory `C:/qt/qt-embedded-wince-opensource-src-4.4.0/src/winmain' C:/MinGW/bin/mingw32-make -f Makefile.Release mingw32-make[2]: Entering directory `C:/qt/qt-embedded-wince-opensource-src-4.4.0/src/winmain' arm-mingw32ce-g++ -c -O2 -Wall -fno-exceptions -fno-rtti -DQT_THREAD_SUPPORT -DUNDER_CE -DWINCE -D_WINDOWS -D_UNICODE -DUNICODE -D_WIN32_WCE=0x420 -D_WIN32_IE=0x400 -DARMV4I -D__ARMV4I_ -Darmv4i -D_ARM_ -D_WIN32 -D__arm__ -DQT_NO_PRINTER -DQT_NO_PRINTDIALOD -DGNUWINCE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -D_USE_MATH_DEFINES -DQT_NO_DEBUG -save-temps -I'../../include' -I'tmp' -I'../../include/QtCore' -I'c:/qt/qt-embedded-wince-opensource-src-4.4.0/include/qtmain' -I'tmp/rcc/release_shared' -I'tmp' -I'c:/qt/qt-embedded-wince-opensource-src-4.4.0/include/ActiveQt' -I'tmp/moc/release_shared' -I'.' -I'c:/Qt/qt-embedded-wince-opensource-src-4.4.0/mkspecs/wince-arm-g++' -o tmp/obj/release_shared/qtmain_win.o qtmain_win.cpp qtmain_win.cpp: In function 'int (HINSTANCE__*, HINSTANCE__*, WCHAR*, int)': qtmain_win.cpp:140: error: unrecognizable insn: (insn 9 8 10 3 ../../include/QtCore/../../src/corelib/tools/qbytearray.h:364 (set (reg/f:SI 214) (symbol_ref:SI ("_ZN10QByteArray11shared_nullE") [flags 0x4c0] <var_decl 0x7ff97b68 shared_null>)) -1 (nil)) qtmain_win.cpp:140: internal compiler error: in extract_insn, at recog.c:2048 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. mingw32-make[2]: *** [tmp/obj/release_shared/qtmain_win.o] Error 1 mingw32-make[2]: Leaving directory `C:/qt/qt-embedded-wince-opensource-src-4.4.0/src/winmain' mingw32-make[1]: *** [release] Error 2 mingw32-make[1]: Leaving directory `C:/qt/qt-embedded-wince-opensource-src-4.4.0/src/winmain' mingw32-make: *** [sub-winmain-make_default-ordered] Error 2 I attach the qtmain_win.ii completeness Any idea? MZ |
|
From: SourceForge.net <no...@so...> - 2011-01-26 10:19:18
|
Bugs item #3165793, was opened at 2011-01-26 11:19 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=3165793&group_id=173455 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW32CE (arm-wince-mingw32ce Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Error creating WinCE DLL Initial Comment: Hi all, i'm trying to create a WinCE DLL. I've created the original project under VS and i ported it under Eclipse+Mingw32+Mingw32CE. At the end of the compile phase I receive: **** Internal Builder is used for build **** g++ -LC:\Documents and Settings\mora\Documenti\Visual Studio 2005\Projects\VciProjects\EosTX32\VciLib\Release -LC:\Programmi\mingw32ce\arm-mingw32ce\lib\ ..\EosTX32.def --enable-stdcall-fixup -shared -oEosTX32.dll util.o stdafx.o log.o j2534fns.o Reg.o EosTX32.o -lvcilib ld: dllcrt3.o: No such file: No such file or directory Build error occurred, build is stopped Time consumed: 156 ms. but dllcrt3.o is under :\Programmi\mingw32ce\arm-mingw32ce\lib\ I inserted into the library path. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=3165793&group_id=173455 |
|
From: André H. <ne...@da...> - 2011-01-16 15:21:26
|
Am 16.01.2011 14:17, schrieb Paul Sokolovsky: > Hello, > > On Fri, 07 Jan 2011 17:24:08 +0100 > André Hentschel <ne...@da...> wrote: > >>>>> Has anybody stumbled at the implementation of aygshell functions >>>>> like SHCreateMenuBar() for pure Win32? Maybe not as a standalone >>>>> library, but as part of a project which supports both Win32 and >>>>> WinCE. I'd appreciate any hint. > [] >> >> Would love to see some OSS implementation of the CE Menu functions, >> will be usefull for winece (sry, still no repo online ...) > > Well, it actually occurred to me that I should look at Wine/ReactOS for > such stuff, and indeed I found mentioning of some initial work to > support WinCE in ReactOS, but not beyond some coredll proxying, which > even was removed from their repo since then due to lack of further > progress for years. > > I now have read your posts about wine-arm in the archive, nice work, > hope you'll break the ice on this matter ;-). > > In the meantime, I've put my stuff at > http://github.com/pfalcon/aygshell-win32 (not pledging for full or > complete impl, just purely pragmatic approach of adding stuff which > helps porting specific other stuff). > >> >> Best Regards, André Hentschel >> > > Looks good, when my repo is up i e-mail you, you maybe want to send me a patch then. That would be great! -- Best Regards, André Hentschel |
|
From: Paul S. <pm...@gm...> - 2011-01-16 13:17:16
|
Hello, On Fri, 07 Jan 2011 17:24:08 +0100 André Hentschel <ne...@da...> wrote: > >>> Has anybody stumbled at the implementation of aygshell functions > >>> like SHCreateMenuBar() for pure Win32? Maybe not as a standalone > >>> library, but as part of a project which supports both Win32 and > >>> WinCE. I'd appreciate any hint. [] > > Would love to see some OSS implementation of the CE Menu functions, > will be usefull for winece (sry, still no repo online ...) Well, it actually occurred to me that I should look at Wine/ReactOS for such stuff, and indeed I found mentioning of some initial work to support WinCE in ReactOS, but not beyond some coredll proxying, which even was removed from their repo since then due to lack of further progress for years. I now have read your posts about wine-arm in the archive, nice work, hope you'll break the ice on this matter ;-). In the meantime, I've put my stuff at http://github.com/pfalcon/aygshell-win32 (not pledging for full or complete impl, just purely pragmatic approach of adding stuff which helps porting specific other stuff). > > Best Regards, André Hentschel > -- Best regards, Paul mailto:pm...@gm... |
|
From: André H. <ne...@da...> - 2011-01-07 17:06:23
|
Am 05.01.2011 11:01, schrieb Paul Sokolovsky: > Hello, > > On Tue, 4 Jan 2011 13:42:51 +0100 (CET) > Vincent Torri <vt...@un...> wrote: > >> >> >> On Tue, 4 Jan 2011, Paul Sokolovsky wrote: >> >>> Hello, >>> >>> Has anybody stumbled at the implementation of aygshell functions >>> like SHCreateMenuBar() for pure Win32? Maybe not as a standalone >>> library, but as part of a project which supports both Win32 and >>> WinCE. I'd appreciate any hint. >> >> The code is not released. But you can try google. I found that: >> >> http://wmdevelopers.blogspot.com/2008/05/create-menu-bar-programmatically-wm5.html > > Well, this talks how init menubar programmatically (vs from resource) > on device, but I'd like to find code which creates something close on > desktop windows. I did googling, but nothing good, even found > aygshell.dll mock for HPC devices, but there it still recurses to > wince-only CommandBar. > > So, I started to look how to implement it. The simplest case, when > SHCMBF_HMENU is used with SHCreateMenuBar() easy to handle - just > setting that menu for window/dialog. But normal case is more complex. > > For reference, here's what on find while thinking how it can be > implemented: > > Toolbars don't natively support adding arbitrary controls, here's > technique how: > http://msdn.microsoft.com/en-us/library/bb760446(v=vs.85).aspx#Embedding_Non_Button_Controls_in_Toolbars > > Though it suggests using a Rebar instead. > > Here's an article on creating a menu with toolbar/rebar: > http://msdn.microsoft.com/en-us/library/bb775450(v=vs.85).aspx > > Would love to see some OSS implementation of the CE Menu functions, will be usefull for winece (sry, still no repo online ...) -- Best Regards, André Hentschel |
|
From: Vincent T. <vt...@un...> - 2011-01-06 19:49:47
|
Hey, I used to compile one of the EFL libs with cegcc, it was working nicely. Today i recompile and strangely, one of the lib complains about a missing implementation of tzset(). tzset() does not exist on Windows CE, so it's not surprising, but it seems that it was implemented (mingw32ce and not cegcc). Was it dropped ? Vincent Torri |
|
From: Vincent T. <vt...@un...> - 2011-01-05 22:02:40
|
On Wed, 5 Jan 2011, Paul Sokolovsky wrote: > Hello, > > Here's one typical pearl from Microsoft. > > 2 pages describing SHRecognizeGesture(): > > http://msdn.microsoft.com/en-us/library/aa925176.aspx > "If a context menu gesture was recognized, a WM_CONTEXTMENU message will > be sent to shrg->hwndClient and propagated up the parent chain if not > handled." > > http://msdn.microsoft.com/en-us/library/aa458077.aspx > No mentioning of WM_CONTEXTMENU > > The first page is marked as Windows Mobile 6.5. > > So, how to understand that? Have they been providing incompatible > behavior for WinCE (GN_CONTEXTMENU notification instead of > WM_CONTEXTMENU) and several years later learned what is interface > contract and that it's bad to break it, and added sending > WM_CONTEXTMENU, or did they just have been forgetting "to state the > obvious" (typical blog headline of one of Microsoft guys - > http://blogs.msdn.com/b/oldnewthing/archive/2006/03/02/542115.aspx) > for years? > > Looking at the real code: > > iDialer - explicitly calls SHRecognizeGesture(), handles WM_CONTEXTMENU > GSPlayer - doesn't call SHRecognizeGesture() (apparently relies on > by-default tap-and-hold support in common controls), handles > GN_CONTEXTMENU. > tManCfg - doesn't call SHRecognizeGesture() (but it's MFC app, MFC > should call that), handles GN_CONTEXTMENU. > > So, it's not my confusion, people for years used on WinCE something > different than on Win32. Google gives scarce results. Some people > reported WM_CONTEXTMENU not being available on eVC3, etc., but that > might be user error. > > > Does anyone have an idea about this stuff? Iirc, aygshell is hardware dependant (a friend told me that and he also gave me the advice to never use aygshell functions). So you can have different implementations of the dll with different phones Vincent Torri |
|
From: Paul S. <pm...@gm...> - 2011-01-05 12:14:16
|
Hello, Here's one typical pearl from Microsoft. 2 pages describing SHRecognizeGesture(): http://msdn.microsoft.com/en-us/library/aa925176.aspx "If a context menu gesture was recognized, a WM_CONTEXTMENU message will be sent to shrg->hwndClient and propagated up the parent chain if not handled." http://msdn.microsoft.com/en-us/library/aa458077.aspx No mentioning of WM_CONTEXTMENU The first page is marked as Windows Mobile 6.5. So, how to understand that? Have they been providing incompatible behavior for WinCE (GN_CONTEXTMENU notification instead of WM_CONTEXTMENU) and several years later learned what is interface contract and that it's bad to break it, and added sending WM_CONTEXTMENU, or did they just have been forgetting "to state the obvious" (typical blog headline of one of Microsoft guys - http://blogs.msdn.com/b/oldnewthing/archive/2006/03/02/542115.aspx) for years? Looking at the real code: iDialer - explicitly calls SHRecognizeGesture(), handles WM_CONTEXTMENU GSPlayer - doesn't call SHRecognizeGesture() (apparently relies on by-default tap-and-hold support in common controls), handles GN_CONTEXTMENU. tManCfg - doesn't call SHRecognizeGesture() (but it's MFC app, MFC should call that), handles GN_CONTEXTMENU. So, it's not my confusion, people for years used on WinCE something different than on Win32. Google gives scarce results. Some people reported WM_CONTEXTMENU not being available on eVC3, etc., but that might be user error. Does anyone have an idea about this stuff? -- Best regards, Paul mailto:pm...@gm... |
|
From: Paul S. <pm...@gm...> - 2011-01-05 10:02:06
|
Hello, On Tue, 4 Jan 2011 13:42:51 +0100 (CET) Vincent Torri <vt...@un...> wrote: > > > On Tue, 4 Jan 2011, Paul Sokolovsky wrote: > > > Hello, > > > > Has anybody stumbled at the implementation of aygshell functions > > like SHCreateMenuBar() for pure Win32? Maybe not as a standalone > > library, but as part of a project which supports both Win32 and > > WinCE. I'd appreciate any hint. > > The code is not released. But you can try google. I found that: > > http://wmdevelopers.blogspot.com/2008/05/create-menu-bar-programmatically-wm5.html Well, this talks how init menubar programmatically (vs from resource) on device, but I'd like to find code which creates something close on desktop windows. I did googling, but nothing good, even found aygshell.dll mock for HPC devices, but there it still recurses to wince-only CommandBar. So, I started to look how to implement it. The simplest case, when SHCMBF_HMENU is used with SHCreateMenuBar() easy to handle - just setting that menu for window/dialog. But normal case is more complex. For reference, here's what on find while thinking how it can be implemented: Toolbars don't natively support adding arbitrary controls, here's technique how: http://msdn.microsoft.com/en-us/library/bb760446(v=vs.85).aspx#Embedding_Non_Button_Controls_in_Toolbars Though it suggests using a Rebar instead. Here's an article on creating a menu with toolbar/rebar: http://msdn.microsoft.com/en-us/library/bb775450(v=vs.85).aspx -- Best regards, Paul mailto:pm...@gm... |
|
From: Paul S. <pm...@gm...> - 2011-01-04 17:59:12
|
Hello, On Tue, 04 Jan 2011 18:10:10 +0100 Vincent Richomme <fo...@sm...> wrote: > On Tue, 4 Jan 2011 13:42:51 +0100 (CET), Vincent Torri wrote: > > On Tue, 4 Jan 2011, Paul Sokolovsky wrote: > > > >> Hello, > >> > >> Has anybody stumbled at the implementation of aygshell functions > >> like > >> SHCreateMenuBar() for pure Win32? Maybe not as a standalone > >> library, but as part of a project which supports both Win32 and > >> WinCE. I'd appreciate any hint. > > > > The code is not released. But you can try google. I found that: > > > > > > http://wmdevelopers.blogspot.com/2008/05/create-menu-bar-programmatically-wm5.html > > > Hi, > > SHCreateMenuBar is so specific to wince that I don't think it's very > relevant to implement it under win32. > What you should do is define a common function/method to create a > menu and that would > call SHCreateMenuBar on wince. Well, it's about 3rd-party software, to let test/debug it with more comfort. Apparently, linking with a mock lib is more productive than to figure out and patch each case, especially in bulk. As for "specific to wince" - well, it's just an adhoc toolbar which tend to appear even on dialogs. I'm surprised that noone implemented it over all this time... [] -- Best regards, Paul mailto:pm...@gm... |
|
From: Vincent R. <fo...@sm...> - 2011-01-04 17:10:19
|
On Tue, 4 Jan 2011 13:42:51 +0100 (CET), Vincent Torri wrote: > On Tue, 4 Jan 2011, Paul Sokolovsky wrote: > >> Hello, >> >> Has anybody stumbled at the implementation of aygshell functions >> like >> SHCreateMenuBar() for pure Win32? Maybe not as a standalone library, >> but as part of a project which supports both Win32 and WinCE. I'd >> appreciate any hint. > > The code is not released. But you can try google. I found that: > > > http://wmdevelopers.blogspot.com/2008/05/create-menu-bar-programmatically-wm5.html Hi, SHCreateMenuBar is so specific to wince that I don't think it's very relevant to implement it under win32. What you should do is define a common function/method to create a menu and that would call SHCreateMenuBar on wince. |
|
From: Vincent T. <vt...@un...> - 2011-01-04 12:42:59
|
On Tue, 4 Jan 2011, Paul Sokolovsky wrote: > Hello, > > Has anybody stumbled at the implementation of aygshell functions like > SHCreateMenuBar() for pure Win32? Maybe not as a standalone library, > but as part of a project which supports both Win32 and WinCE. I'd > appreciate any hint. The code is not released. But you can try google. I found that: http://wmdevelopers.blogspot.com/2008/05/create-menu-bar-programmatically-wm5.html Vincent Torri |
|
From: Paul S. <pm...@gm...> - 2011-01-04 12:25:24
|
Hello, Has anybody stumbled at the implementation of aygshell functions like SHCreateMenuBar() for pure Win32? Maybe not as a standalone library, but as part of a project which supports both Win32 and WinCE. I'd appreciate any hint. -- Best regards, Paul mailto:pm...@gm... |
|
From: Paul S. <pm...@gm...> - 2011-01-01 14:08:45
|
Hello, Who knows the story about w32api and tchar.h header? The latter is includes in mingw, but lots of software expect _T() to be available with just <windows.h>. w32api doesn't even mention it there, and the only tchar include occurance, in oledlg.h, is commented. So, what is approach here? -- Best regards, Paul mailto:pm...@gm... |
|
From: Paul S. <pm...@gm...> - 2011-01-01 13:50:59
|
Hello, On Sat, 01 Jan 2011 14:29:21 +0100 Danny Backx <dan...@sc...> wrote: > On Sat, 2011-01-01 at 15:21 +0200, Paul Sokolovsky wrote: > > Ok, I see, need to run windres with -D_WIN32_WCE. > > Sometimes not just that but with a specific value. Yeah, and here comes the new question. As far as I can tell, msvc-based software has those values in decimal, not in hex, like cegcc has. As a reference, I can give http://code.google.com/p/tman/source/browse/trunk/tman/Makefile?r=28 , which is gnumake file which still uses msvc compiler. # 300 for eVC 3.0 CEVersion=420 CePlatform=WIN32_PLATFORM_PSPC=400 CPP_FLAGS=/nologo /W3 /D "ARM" /D "_ARM_" /D "ARMV4" /D UNDER_CE=$(CEVersion) /D _WIN32_WCE=$(CEVersion) /D "$(CePlatform)" Googling confirms that (even though for native msvc projects, CEVersion and friends are apparently nmake-defined vars), including this: http://msdn.microsoft.com/en-us/library/ms838200.aspx So, what should we do? > > Danny > -- > Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info > -- Best regards, Paul mailto:pm...@gm... |
15 messages has been excluded from this view by a project administrator.
