Strange jump executing get_accName. (but it works fine in MS VC++ and MinGW/Upp and mingw win32 app)

[alex100]

Now there is problems on resource file... How sad...

I restored to the original windres.exe (from 64 bit download)

-------------- Build: Debug in MYYYYYYYYYYYYYYYYYYYY (compiler: GNU GCC Compiler)---------------

x86_64-w64-mingw32-g++.exe -LC:\wxWidgets-3.0.0\lib\gcc_dll -o bin\Debug\MYYYYYYYYYYYYYYYYYYYY.exe obj\Debug\MYYYYYYYYYYYYYYYYYYYYApp.o obj\Debug\MYYYYYYYYYYYYYYYYYYYYMain.o obj\Debug\resource.res -m32 -mthreads -lwxmsw30ud -mwindows
c:/tdm-gcc-64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: i386:x86-64 architecture of input file `obj\Debug\resource.res' is incompatible with i386 output
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 0 second(s))
0 error(s), 0 warning(s) (0 minute(s), 0 second(s))



I replaced the windres.exe by the 32 bit version, the application is compiled but when running it I see a windows application error (so not started correctly (0x000007b))




I also restored windres to the 64 bit version and put :

windres.exe -F pe-i386

in the resource compiller.
The appli compiles wll but 0x000007b error takes place.



Can I use the 32 bit version of TDM-GCC-32 to run get_accName?
No! I gave a try and get_accName returns to the jump initial problem

[modoran]

wxmsw30u_gcc_custom.dll MUST be placed in the same folder as your application, a wrong version could be loaded. Did you put old DLL in system32 by any chance ?

Start your program from windows explorer.



It appears you are loading a 64-bit DLL into a 32-bit process or vice versa. That error means STATUS_INVALID_IMAGE_FORMAT.


Download Depedency Walker to see EXACTLY what DLL is loaded.
http://www.dependencywalker.com/

[alex100]

No I did not put

I started it using WE and it says that it can not load _wxmsw30ud_gcc_custom.dll
I put this dll in the same folder and it then says

error c000007b

The dependency wlaker says that wxmsw30ud_gcc_custom.dll and IESHIMS.dll is also missing

if I put that dll (which is at ) in the same folder c000007b continues to happen

May be with all these transformations and compilations etc, the system got dirty...

[modoran]

So what's with wxmsw30ud_gcc_custom.dll ? It is X86 or X64 ? Dependency Walker will told you.

[alex100]

Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.



IEHIMS.DLL
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

[modoran]

Error: Modules with different CPU types were found.

Exactly as I suspected.

Select wxmsw30ud_gcc_custom.dll with your EXE loaded in Depedency Walker and read "CPU" info about it, it is X86 or X64 ?

[alex100]

Here is the last 3 lines of the bottom area:

Module column CPU column

...
wtsapi.dll x64
XMLLITE:DLL x64
IEHIMS.DLL x86
wxmsw30ud_gcc_custom.dll x86

Thre rest of the modules dll are all x64 (suppressed with ... )




May be the solution is to roolback everything to the mingw 32 bit version and implement, as a lib, the get_accName using the mingw and ultimate++. Then I link that lib with the wxwidget application. what do you think?

[modoran]

I see you are running a 64 bit operating system.

Wxwidgets DLL is fine, but your EXE ?
Presence of x64 windows system DLLs there suggests that your EXE is x64. Please check it.

[alex100]

How sad... I never thought that i could had windows 64 bit installed in my box.

For the built application and using the InspectExe free tool, I can see that:


"This is a program for Intel 386 (32 bit) computers designed for O.S. version 4"

So the exe is for 32 bit.

My aim is to be able to use my box to create application also for win 32 boxes

Thanks a lot

[modoran]

Upload the binaries yyyyyyyyyyy.exe or whatever and wxmsw30ud_gcc_custom.dll somewhere to take a look myself.

[alex100]

I uploaded project bundle to: http://www.filedropper.com/swswsw
REM: that project was created just for testing (do not ‘look’ for indentation and code structure either :-) . Just for testing! )

[modoran]

Yes, I've found the problem. I uploaded the fixed EXE here:
http://sharemobile.ro/file/754816

The problem is with the application manifest, wxwidgets is picking the one for amd64 wrongly. possible fix, add __i386__ to prepocessor definitions and REBUILD.

If that does NOT work edit the file C:\wxWidgets-3.0.0\lib\gcc_dll\mswud\wx\msw\rcdefs.h, for some reason #define WX_CPU_AMD64 is wrongly there, it should be WX_CPU_X86.


After you succeed that, we can talk about errors I've found in your code, like improper use of BSTR, char and LPCWSTR (casting between them is VERY bad !!!).

[alex100]

Well, If i replace .exe by yours (with wxmsw30ud_gcc_custom.dll near by) it runs ok!

As far as project is concerned:

firstly I added __i386__ to the #define tab of debug and release build options

Then I cleaned, and rebuild all and 0xc000007b error appears when running exe

Then I removed __i386__ flags from #define tab and replaced:

#define WX_CPU_AMD64
# 46 "..\\..\\include\\wx\\msw\\genrcdefs.h"
#endif

by


#define WX_CPU_X86
# 46 "..\\..\\include\\wx\\msw\\genrcdefs.h"
#endif

Clean, rebuild all and got 0xc000007b error



Then, keeping #define WX_CPU_X86 in the rcdefs.h I added __i386__ to the #define tab of debug and release build options. Cleaned and rebuild and got 0xc000007b error.

(may be it is time to install and compile everything from ground up...)
No way...



As far as "talk about errors I've found in your code" is concerned, I will appreciate it very much, but remember, due to the need to use get_accName it is my first time dealing with Win32 nacked API ;-) which is very confused, lots of string types and etc.

[modoran]

OK. The final fix (and this will work 100 %) is to edit C:\wxWidgets-3.0.0\include\wx\msw\amd64.manifest and C:\wxWidgets-3.0.0\include\wx\msw\wx.manifest to read this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    version="0.64.1.0"
    processorArchitecture="*"
    name="Controls"
    type="win32"
/>
<description>wxWindows application</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

(only "processorArchitecture" needs to be changed).

The changes affect ALL builds of wxwidgets and is safe (the program will work correctly for both x86 and x64).

I think this should be reported to wxwidgets developers too, it sounds like a bug in the library itself, not enough tested so far.


Recompiling of wxwidgets itself is NOT required.

This is Microsoft documentation:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb773175%28v=vs.85%29.aspx#no_extensions

[alex100]

I kept last modifications and changed amd64.manifest and wx.manifest for

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    version="0.64.1.0"
    processorArchitecture="__i386__"
    name="Controls"
    type="win32"
/>
<description>wxWindows application</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="__i386__"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

Clean rebuild => ||Execution of C:\swswsw\bin\Release\swswsw.exe" ' in 'C:\swswsw' failed.|



I roolbaked previous changes (__i386__) and kept changes in amd64.manifest and wx.manifest and Clean, rebuild => ||Execution of C:\swswsw\bin\Release\swswsw.exe" ' in 'C:\swswsw' failed.|


when executing exe in explorer I see:

It wos not possible to statrt application because of incorrect side.by-side configuration

[modoran]

I told you to put "*" there and linked to Microsoft documentation, what part of that did you did not understand ?

Valid values there are "x86" (valid for 32 bit), "amd64" (valid for 64 bit) or "*" (for both targets) ONLY.

[alex100]

Sorry, English language...

Ok, now it works in debug and release due to your continued help. :-)

( debug step by step does not works now, but no problem)

Thanks a lot!!

By the way, BSTR and related stuff? :-)

[modoran]

OK. This is the correct code for converting BSTR to wchar_t (not to char, but you don't need it anyway):

 UINT length = SysStringLen(str_name);        // Ask COM for the size of the BSTR
    wchar_t *buf = new wchar_t [length + 1]; // Note: SysStringLen doesn't
    // include the space needed for the NULL

    wcscpy(buf, str_name);                  // Or your favorite safer string function

// ...
    MessageBox(NULL, buf, buf, MB_OK);
    delete buf; // Done 

[alex100]

Great!

Thank you Modoran for your patience with me