[win][gcc] problem with compiling 64 bit dll on 32 bit windows (via tdm-gcc)

[fir]

i was never doin that and i dont now
the thing, maybe someone here will know
(googling dont gives stright answer)

i use old win32 (xp) for convenience, hovever i would need to produce dll for win64 (7 or 10) via some gcc on windows (i use tdm-gcc)

i found some hint i could use -m64 option
but the created dll dont work when linked to that 64 bit application (it like silently crashes from what i heard, i do not link it only send that dll to someone)

is there an option to make it work? does maybe someone know why it crashes?

[sependency walker seem to shows something:
dependency of my dll on msvcrt.dll and kernel32.dll (eben though i dont use none explicitely in that dll) .. if this -m64 option targets the output on 64bit windows shouldnt it to be dependant on some 64 bit verions of it (i dont know if it poinnts 32 bit or 64 bit ones, are there same named 64 bit versions of that think on 64 bit windows?)

how to repair this problem?
tnx

[Paavo Helde]

On 9.03.2019 3:30, fir wrote:
> i was never doin that and i dont now
> the thing, maybe someone here will know
> (googling dont gives stright answer)
>
> i use old win32 (xp) for convenience, hovever i would need to produce dll for win64 (7 or 10) via some gcc on windows (i use tdm-gcc)
>
> i found some hint i could use -m64 option
> but the created dll dont work when linked to that 64 bit application (it like silently crashes from what i heard, i do not link it only send that dll to someone)
>
> is there an option to make it work? does maybe someone know why it crashes?

C++ does not have standardized ABI (binary interface), so for a C++ DLL
to work in another C++ program the both have to be compiled with the
same compiler and with the same relevant compiler options and macro
definitions.

Another common reason for the crashes are 64-bit specific bugs in the
code. I can well imagine your code is littered with unsafe casts from
void* pointers to int and back. Also other dormant bugs may get exposed.

>
> [sependency walker seem to shows something:
> dependency of my dll on msvcrt.dll and kernel32.dll (eben though i dont use none explicitely in that dll) .. if this -m64 option targets the output on 64bit windows shouldnt it to be dependant on some 64 bit verions of it (i dont know if it poinnts 32 bit or 64 bit ones, are there same named 64 bit versions of that think on 64 bit windows?)

The Windows dll-s have the same names in 64-bit than in 32 and reside in
the same folders. Hence, there is a new 64-bit DLL called kernel32.dll
which resides in a folder having 32 in its name, C:\Windows\System32.
For balance, the old 32-bit kernel32.dll resides in a folder having 64
in its name (C:\Windows\SysWOW64). However, this is not something which
you should worry about, normally this is all resolved automatically.

>
> how to repair this problem?

No way. You cannot port a DLL to 64-bit and deliver it without testing
and debugging it in 64-bit environment.

[fir]

tnx for answer, maybe you could yet me some more

this is simple plugin for c++ app, (as i just try to make it work it may be extremally simple like one simple function exported, i may also write it in c (and in fact wrote it in c when tested as i knewed on this mangling and problems)

it still dont work - like silently crashes (i dont test it i sand it to someone and she testes it, as for she says it silently crashes... she test it in console among couts and when adding plugin nothing is printed just "press enter to close this window" console text appears

so if you generally say it should work why it not works?

as for those dependencies thing is unclear, as i watch on those dependencies they are listed witch pathes and are two

C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\msvcrt.dll

though this dll is for sure 64 bit and at this kernel32 dependency there is yellow "!" shwed when in 32 bit its the same but this yellow "!" is not present

is it possible that those dependencies are proper fo 64 bit dll?

got damn no idea why it not work, not being even shure if it is said it eally should?

[Alf P. Steinbach]

Use COM.

[snip]


Cheers!,

- Alf

[Paavo Helde]

On 9.03.2019 11:40, fir wrote:

> this is simple plugin for c++ app, (as i just try to make it work
it may be extremally simple like one simple function exported, i may
also write it in c (and in fact wrote it in c when tested as i knewed on
this mangling and problems)

If the exported function is defined as extern "C", then binary
compatibility problems should not arise indeed.

>
> so if you generally say it should work why it not works?

I did not say it should work. I said it most probably will NOT work,
without debugging it in 64-bit and fixing the problems.

There are countless programs ported from 32-bit to 64-bit and working,
so obviously it's possible to make this happen.

However, in most cases (especially on Windows) this porting involves
also fixing the bugs and portability issues in the code, it's not just
recompiling. There are many potential portability issues, without seeing
your code it is impossible to tell what might be the culprits.

See e.g. https://www.viva64.com/en/a/0004/

[Christian Gollwitzer]

Am 09.03.19 um 10:40 schrieb fir:

> W dniu sobota, 9 marca 2019 07:58:42 UTC+1 użytkownik Paavo Helde napisał:
>> On 9.03.2019 3:30, fir wrote:
>>>
>>> how to repair this problem?
>>
>> No way. You cannot port a DLL to 64-bit and deliver it without testing
>> and debugging it in 64-bit environment.
>
> tnx for answer, maybe you could yet me some more

As Paavo said, you'll need to get hold of a 64-bit system and test for
yourself, catch the crashes in a debugger and find out what is wrong.

If it helps, MS provides a number of VM images for testing purposes. The
development VMs contain Windows and the most recent compiler, but they
are currently unavailable (until the next update for Win10):
https://developer.microsoft.com/en-us/windows/downloads/virtual-machines

You could also use the testing VMs for internet browsers:
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

Not sure, if your use case falls under the license, you'll have to check
izt for yourself. Technically, you can debug your program there.

A classic 64bit issue is that on Windows 64 bit, both int and long are
32 bit only, so offsets into memory do not find into either of them -
for that you'll replace them by ptrdiff_t, which has the correct size
for both platforms. These problems can hardly be found unless you debug
it in 64 bit.

Christian

[Mr Flibble]

Yeah use COM if you want to be Microsoft's bitch. Alternatively design
your own cross-platform plugin system (like I have done) which is similar
to COM but is not so Microsofty.

/Flibble

--
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[fir]

allright it gett to work

it seemed to be some linking arffairs, and as i cant debug it myself i dont even know what it was - she resolved it by blind hit

as i sasd its not quite about porting.. i just want to write some simple plugins for her for fun (im experienced c coder and not make much 'crash type' mistakes
when coding..i really know c well

but as i said its unconvinient to me to turn on my win10 machine which is covered by large coat of dust and can only compile it in 32 version when writing recompile it with -m64 before sending that plugin for her, but as i guess it
should work

[fir]

if no that is the another story, i will see

[Kenny McCormack]

In article <q60d11$dtq$1...@dont-email.me>,

Christian Gollwitzer <auri...@gmx.de> wrote:
>Am 09.03.19 um 10:40 schrieb fir:
>> W dniu sobota, 9 marca 2019 07:58:42 UTC+1 użytkownik Paavo Helde napisał:
>>> On 9.03.2019 3:30, fir wrote:
>>>>
>>>> how to repair this problem?
>>>
>>> No way. You cannot port a DLL to 64-bit and deliver it without testing
>>> and debugging it in 64-bit environment.
>>
>> tnx for answer, maybe you could yet me some more
>
>As Paavo said, you'll need to get hold of a 64-bit system and test for
>yourself, catch the crashes in a debugger and find out what is wrong.

I think (but am not at all certain, and have no reason to research or test
or verify or anything else) that you can actually emulate a 64 bit CPU on a
32 bit machine using Virtual Box.

So, if you only have a 32 bit machine available, you can still run and test
a 64 bit OS.

I think...

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/RepInsults

[fir]

W dniu sobota, 9 marca 2019 16:34:43 UTC+1 użytkownik Kenny McCormack napisał:
> In article <q60d11$dtq$1...@dont-email.me>,
> Christian Gollwitzer <auri...@gmx.de> wrote:
> >Am 09.03.19 um 10:40 schrieb fir:
> >> W dniu sobota, 9 marca 2019 07:58:42 UTC+1 użytkownik Paavo Helde napisał:
> >>> On 9.03.2019 3:30, fir wrote:
> >>>>
> >>>> how to repair this problem?
> >>>
> >>> No way. You cannot port a DLL to 64-bit and deliver it without testing
> >>> and debugging it in 64-bit environment.
> >>
> >> tnx for answer, maybe you could yet me some more
> >
> >As Paavo said, you'll need to get hold of a 64-bit system and test for
> >yourself, catch the crashes in a debugger and find out what is wrong.
>
> I think (but am not at all certain, and have no reason to research or test
> or verify or anything else) that you can actually emulate a 64 bit CPU on a
> 32 bit machine using Virtual Box.
>
> So, if you only have a 32 bit machine available, you can still run and test
> a 64 bit OS.
>
> I think...
>

no, i got 2 machunes on my table, one is 32 bit windows 5 that i love (and code on it) and othet is win10 which i probably like also but extremaly rarely turn it on

its not i dont like win10 but i much profer win5 so i want to code that plugin for convenience here

besides she got another problem:
she linked that dll in her gcc form commandline but she cant link it in qt
- same as before she got like 'quiet crashing, couts do not print on console, just "press enter to close this window" in console.. i cannot debug it remotely

does someone maybe know how to link that dll in qt?

she uses something like

LIBS+= -L$$PWD/./ -ltest

in qt project file
where test.dll is that plugin

but it gives this result i told

(it seem to me that before she get same error when she linked in commandline like

g++ her.cpp -l test.dll

(showed that gcc needs .sll extension skipped

g++ her.cpp -l test

then it worked (she says if i correctly understood that when this .dll was added she got such error as she gets now in QT (this what i call silent crash, when she triec to call function form test)

but qt still dont work, some hints maybe
(its very confusing to debug it remotely, but thats my present option)

[Manfred]

On 3/9/19 1:58 AM, Paavo Helde wrote:
> On 9.03.2019 3:30, fir wrote:
>> i was never doin that and i dont now
>> the thing, maybe someone here will know
>> (googling dont gives stright answer)
>>
>> i use old win32 (xp) for convenience,  hovever i would need to produce
>> dll for win64 (7 or 10) via some gcc on windows (i use tdm-gcc)
>>

<snip>

>>
>> how to repair this problem?
>
> No way. You cannot port a DLL to 64-bit and deliver it without testing
> and debugging it in 64-bit environment.
>

If possible in this case, wouldn't it be simpler to deliver a 32-bit dll
and let Windows "thunk" it to the 64 bit executable?
Obviously this would only take care of the ABI, not of anything inside
the code that is 64 or 32-bit specific.
Depending on the case, the performance hit could be acceptable, compared
to the hassle of cross-compiling without the ability of native testing.

[fir]

this project is for fun, so i dont care... miss emo writes somewhat elaborate bot (or bot system) for an irc (in c++ in windows, she connects via sockets) i only want to have some option to write some plugins myself and not bother to move to another machine(like one for example for learning french and spanish, and so on)

[Richard Damon]

I didn't think windows handled 64-to-32 bit thunking, at least not in
general. The big issue in trying to do this is that pointers in any
structure will not be compatible, being different sizes, and most
objects in the 64 bit memory space will be non-accessible to the 32 bit
code.

A 64 bit program might be able to take special steps to be able to call
a 32 bit library (doing some special system calls to get buffers in the
32 bir space, and special types/headers that make things the right
size), but is it not going to be transparent.

[fir]

if cpu would 'handle' various pointer sizes (like 16, 32, 48 , 64 bits, along as various 'word' sizes liek 8 bit 16, 32, 48, 64) then the 'division' on 16, 32, 48, 64 bits systems could wanish - and that would be probably quite good

in that kind of system you could use 32 bit codes apart of 16 bit ones or 48 bit ones or 64 bit ones or ones that mix all together

unfortuanatelly todays assembler /cpu architecture is sh*t

[fir]

there is obviously side question if it is worth to suport 8 or 16 bit operations (in some way it seem that it would be good to have byte that is 32 bit and forgot all the less) but thats side story