Hi,
About the issue with WM6.1 I am following another track to fix it.
I have installed Platform Builder 5.0(tools used to generate ROM image from
WCE sources) with the latest updates available
and Armv4i device emulator BSP available here :
http://blogs.msdn.com/mikehall/archive/2006/03/01/54163
On Wednesday 24 September 2008 17:29:51, Jérôme Decoodt wrote:
> Did you try to delete the IAT entry in PE Explorer?
No, I didn't.
--
Pedro Alves
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challe
Hello,
> > > (each points at its own section, which means there's a gap between
> > > them. Plus, .idata comes after .edata, while MSFT puts it the
> > > other way around. I don't think this is invalid according
> > > to the PE specification, but you never know what assumptions MSFT
> > > is mak
Hello,
> Indeed it's helpful. Thanks for the pointer. I've tracked this
> down to something around the export data directory or the import data
> directory. On our toolchain, we put them each on their own section
> (.edata, .idata), while MSFT puts them all merged in one
> section (.rdata).
I
On Monday 22 September 2008 08:34:20, Jérôme Decoodt wrote:
> Hello,
>
> This post seems to be related to our problem:
> http://blogs.msdn.com/hopperx/archive/2008/09/19/writeable-code-sections-go
>t-you-down-fear-no-more.aspx
>
> Hopping this can help some gurus on resolving the issue,
Indeed it'
Hello,
This post seems to be related to our problem:
http://blogs.msdn.com/hopperx/archive/2008/09/19/writeable-code-sections-got-you-down-fear-no-more.aspx
Hopping this can help some gurus on resolving the issue,
Best regards
--
Jérôme Decoodt
Hello,
> Jerome Decoodt found a workaround to get applications working on Windows
> Mobile 6.1.
> It seems that you can ask system not to load DLL in high memory :
I precise this is just a workaround/ugly hack because DLL will probably
be loaded in Slots 0&1 instead of slots > 60, so you'll not
Good news!
Jerome Decoodt found a workaround to get applications working on Windows
Mobile 6.1.
It seems that you can ask system not to load DLL in high memory :
Danny could please update FAQ and add something like :
19. I get an "Invalid Pocket PC application" when I try to run my program
on W
> Yes I know but Platform Builder 6 only provides sources for windows CE 5.2
> and the bug seems to happen only
> with Windows Mobile 6.1 ie Windows CE 5.2 + AKU.
> As a developer I don't think you have access to these AKU, only OEM or
> Microsoft partners can have this kind of updates.
I'm curre
> I wouldn't call it a BUG for now because Visual exe works fine.
> But this BUG is BLOCKER for cegcc project because more and more device
Hum my post is not very logic ;-)
I have posted on some newsgroups dedicated to platform builder but I don't
really expect answers because it'a Microsoft NG a
Yes I know but Platform Builder 6 only provides sources for windows CE 5.2
and the bug seems to happen only
with Windows Mobile 6.1 ie Windows CE 5.2 + AKU.
As a developer I don't think you have access to these AKU, only OEM or
Microsoft partners can have this kind of updates.
About the device in
Hello,
> I have tried to launch application on a device in debug mode and I have
> found this :
>
> LoadDLL(4873762a,8bc3e7e0,coredll.dll,03f5b000)
> LoadDLL(,8a4c73e0,cegcc.dll,7881)
> [...]
> So there is an access violation in kernel, unfortunately without map file
> it's going to b
I have tried to launch application on a device in debug mode and I have
found this :
CreateProcess(4873762a,testDLLexe.exe,2a00)
CertVerify: \Temp\testDLLexe.exe trust = 2
LoadDLL(4873762a,8bc3e7e0,coredll.dll,03f5b000)
[Cpu] 71 70802731 03F6CE4C 8B8FBB6C 03FE5744
08/28/2008 14:49:03 [D :: KE
Hello,
> I have attached an bz2 archive with sources you provided and two
> "makefile", one for cegcc and the other one for Visual 2005.
> Could you please check we are using same compilation flags.
Indeed, I was compiling this way :
/opt/mingw32ce/libexec/gcc/arm-wince-mingw32ce/4.1.0/cc1 -quie
On Wed, 27 Aug 2008 16:25:15 +0200, Jérôme Decoodt
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Wed, Aug 27, 2008, [EMAIL PROTECTED] wrote:
>> > BTW, does anyone have successfully loaded a .exe linked with a DLL
>> > larger than 64kB under an official WM6.1 (cooked WM6.1 seems to
> work...)?
>> >
>
On Wed, 27 Aug 2008 16:25:15 +0200, Jérôme Decoodt
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Wed, Aug 27, 2008, [EMAIL PROTECTED] wrote:
>> > BTW, does anyone have successfully loaded a .exe linked with a DLL
>> > larger than 64kB under an official WM6.1 (cooked WM6.1 seems to
> work...)?
>> >
>>
Sorry I really didn't understand your question ;-)
I was talking about standard dll (visual one).
Hope you will find the issue ...
On Wed, 27 Aug 2008 16:25:15 +0200, Jérôme Decoodt
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Wed, Aug 27, 2008, [EMAIL PROTECTED] wrote:
>> > BTW, does anyone have
Hello,
On Wed, Aug 27, 2008, [EMAIL PROTECTED] wrote:
> > BTW, does anyone have successfully loaded a .exe linked with a DLL
> > larger than 64kB under an official WM6.1 (cooked WM6.1 seems to work...)?
> >
> Hum I don't really understand your question because of course I have
> successfully loade
> BTW, does anyone have successfully loaded a .exe linked with a DLL
> larger than 64kB under an official WM6.1 (cooked WM6.1 seems to work...)?
>
Hum I don't really understand your question because of course I have
successfully loaded a DLL larger than 64kB on a WM 6.1.
What is the problem ?
--
Hello,
> Thanks for investigating that kind of low level stuff.
> Could I ask why you are playing with PE executable ? You learn viruses ;-)
Well, I'm just searching what can cause the executable to be flagged as
not valid under WM6.1 and valid on WM6...
BTW, does anyone have successfully loaded
Thanks for investigating that kind of low level stuff.
Could I ask why you are playing with PE executable ? You learn viruses ;-)
On Tue, 26 Aug 2008 18:07:25 +0200, Jérôme Decoodt
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> Some news about this bugs... It appears that compiling under gcc then
> link
Hello,
Some news about this bugs... It appears that compiling under gcc then
linking into visual can work. In details, I do :
- compile source into .o
- edit the .o to remove the write attribute of .text section (sed -e
's/\x20\x00\x30\xe0/\x20\x00\x30\x60/')
- call linker.exe from Visual Studi
Hello,
> DWORD SizeOfImage
> This appears to be the total size of the portions of the image
> that the loader has to worry about. It is the size of the region
> starting at the image base up to the end of the last section.
> The end of the last section is rounded up
You can use Microsoft dumpbin located by default in C:\Program
Files\Microsoft Visual Studio 9.0\VC\bin.
Do not forget to launch vcvars32.bat before to call it.
You can also use pedump.exe available here http://www.wheaty.net/pedump.zip
On Sat, 16 Aug 2008 11:31:37 +0200, Danny Backx <[EMAIL
In http://msdn.microsoft.com/en-us/magazine/ms809762.aspx I found this :
DWORD SizeOfImage
This appears to be the total size of the portions of the image
that the loader has to worry about. It is the size of the region
starting at the image base up to the end of the last sec
Hello,
> I don't have a clue. Have you tried looking this up on MSDN ?
I've search for this in MSDN but I didn't find anything that corresponds
to my problem.
> I'm a bit confused about what you write, though. Are you saying that
> adding one NOP changes the SizeOfImage from 1 to 11000 ?
T
Excuse the delay, I've been away from my mail.
I don't have a clue. Have you tried looking this up on MSDN ?
I'm a bit confused about what you write, though. Are you saying that
adding one NOP changes the SizeOfImage from 1 to 11000 ?
Danny
On Thu, 2008-08-07 at 11:42 +0200, Jérôme
27 matches
Mail list logo
