I have WM6.1 and I am not affected by this bug myself. But some users of my
app reported that using UPX
http://upx.sourceforge.net/
for DLL and EXE files is a solution.
Of course it is a workaround, but a doubly useful one (you fix
incompatibility with a compressed package).
Pascal Georges
2009/
Hello,
I recently started using cegcc and encountered problems getting
anything to run under WM6.1. After searching for a while I found
this thread and followed it back to its beginnings.
I am very confused -- could someone please summarize the status of
this problem? It seems to me that a pro
Hi,
Actually it won't bring us too much information, all you will see if the
fact UPX transforms
the DLL by creating 3 PE sections :
UPX0
UPX1
UPX2 : Export Table; Import Tanle; Relocation Table
and with the original table you will have something like :
.text
.data
.idata
.edata
.bss
.reloc
s
The only difference between the two DLLs is that one is compressed with UPX.
I can send both to anybody wanting to look at them, but personally I am
unable to help much because I never encountered such problem.
Pascal
2009/1/14 Danny Backx
> Do you have two versions of that DLL to play with the
Do you have two versions of that DLL to play with then ? Or are they too
different to use for comparisons ?
Danny
On Sun, 2009-01-11 at 19:05 +0100, Pascal Georges wrote:
>
>
> 2008/12/18 Danny Backx
> What's an o32_ptr ?
>
> Does all this mean that we're not f
2008/12/18 Danny Backx
> What's an o32_ptr ?
>
> Does all this mean that we're not filling up a structure in the DLL, and
> that UPX is doing the right thing but we're not ?
Hi,
I managed to get an user test my application (http://scid.sf.net) under
WM6.1 and I confirm that the DLL cannot be l
Hum actually it seems normal tha IAT is null ...
On Sun, 21 Dec 2008 14:33:05 +0100, mosfet wrote:
> While checking differences between cegcc and visual I have also noticed
> that :
>
> 1) Visual doesn't put a checksum in PE header but I don't think it's
> important
> 2) IAT is NULL
>
> cegc
While checking differences between cegcc and visual I have also noticed
that :
1) Visual doesn't put a checksum in PE header but I don't think it's
important
2) IAT is NULL
cegcc:
--
Dump of file TESTDLL.DLL
Data Directory
EXPORT rva: 00014000 size: 004A
IMPORT rva: 00
On Fri, 19 Dec 2008 10:55:54 +0100, Danny Backx
wrote:
> This doesn't look like a structure that's included in one of our tools,
> it looks like something that might get filled up when our DLL gets
> loaded.
>
> Then we would need to figure out which entry in the structures created
> by binutils
This doesn't look like a structure that's included in one of our tools,
it looks like something that might get filled up when our DLL gets
loaded.
Then we would need to figure out which entry in the structures created
by binutils and/or gcc is responsible for filling up this field.
Or am I comple
On Thu, 18 Dec 2008 20:26:05 +0100, Danny Backx
wrote:
> What's an o32_ptr ?
>
> Does all this mean that we're not filling up a structure in the DLL, and
> that UPX is doing the right thing but we're not ?
>
> Danny
>
Yes o32_ptr is part of the PE format :
//
// MODULE structure, one for
What's an o32_ptr ?
Does all this mean that we're not filling up a structure in the DLL, and
that UPX is doing the right thing but we're not ?
Danny
On Thu, 2008-12-18 at 10:38 +0100, mosfet wrote:
> Hi,
>
> Thanks to a great Windows Mobile Hacker/tweaker mamaich, he has found why
> ceg
Hi,
Thanks to a great Windows Mobile Hacker/tweaker mamaich, he has found why
cegcc binaries are not loaded on WM6.1 platforms.
Please find below his analysis :
KITL output:
167564 PID:97eeb752 TID:b5980c3a CertVerify: \testDllexe.exe trust = 2
167635 PID:97eeb752 TID:b5980c3a CertVerify: test
On Sat, 06 Dec 2008 14:08:29 +0100, mosfet <[EMAIL PROTECTED]> wrote:
> About the WM6.1 issue, in the case newer gcc\binutils doesn't solve the
> issue I am following another
> track.
> Actually the problem with WM6.1 comes from a modification done in the
> kernel(nk.exe) and especially
> in the lo
About the WM6.1 issue, in the case newer gcc\binutils doesn't solve the
issue I am following another
track.
Actually the problem with WM6.1 comes from a modification done in the
kernel(nk.exe) and especially
in the loader. What you need to know is the fact Microsoft give access to
Windows CE source
On Sat, 06 Dec 2008 07:55:25 +0100, Danny Backx <[EMAIL PROTECTED]>
wrote:
> Actually I think it's time to move to new versions of the tools. That
> includes gcc itself. Vincent has done excellent work on getting a cegcc
> to work based on gcc-4.3.2, we should pick that up.
>
> Opinions ?
>
>
I don't see a problem with having a private version of libtool for a
while. After all, we do this with several tools.
Danny
On Sat, 2008-12-06 at 08:54 +0100, Vincent Torri wrote:
>
> On Sat, 6 Dec 2008, Danny Backx wrote:
>
> > Actually I think it's time to move to new versions of the
On Sat, 6 Dec 2008, Danny Backx wrote:
> Actually I think it's time to move to new versions of the tools. That
> includes gcc itself. Vincent has done excellent work on getting a cegcc
> to work based on gcc-4.3.2, we should pick that up.
>
> Opinions ?
A remark, actually: I have reported some
Actually I think it's time to move to new versions of the tools. That
includes gcc itself. Vincent has done excellent work on getting a cegcc
to work based on gcc-4.3.2, we should pick that up.
Opinions ?
Danny
On Fri, 2008-12-05 at 17:56 +0100, mosfet wrote:
> Pedro,
>
> I forgot to a
Pedro,
I forgot to ask you if you have time, would it be possible to incorporate
into cegcc a recent version
of binutils >= 2.18.50.
I was looking into mingw mailing list and I found this :
-
"FWIW recent 2.18.50 snapsho
20 matches
Mail list logo
