| fir <profesor.fir@gmail.com>: Mar 08 05:30PM -0800 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 <myfirstname@osa.pri.ee>: Mar 09 08:58AM +0200 On 9.03.2019 3:30, fir wrote: > 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 <profesor.fir@gmail.com>: Mar 09 01:40AM -0800 W dniu sobota, 9 marca 2019 07:58:42 UTC+1 użytkownik Paavo Helde napisał: > > 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 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" <alf.p.steinbach+usenet@gmail.com>: Mar 09 11:26AM +0100 On 09.03.2019 10:40, fir wrote: >> and debugging it in 64-bit environment. > 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) Use COM. [snip] Cheers!, - Alf |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 09 01:13PM +0200 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 <auriocus@gmx.de>: Mar 09 01:53PM +0100 Am 09.03.19 um 10:40 schrieb fir: >> 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 <flibbleREMOVETHISBIT@i42.co.uk>: Mar 09 01:33PM On 09/03/2019 10:26, Alf P. Steinbach wrote: >> write it in c (and in fact wrote it in c when tested as i knewed on this >> mangling and problems) > Use COM. 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 <profesor.fir@gmail.com>: Mar 09 05:42AM -0800 W dniu sobota, 9 marca 2019 13:54:03 UTC+1 użytkownik Christian Gollwitzer napisał: > for both platforms. These problems can hardly be found unless you debug > it in 64 bit. > Christian 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 <profesor.fir@gmail.com>: Mar 09 05:50AM -0800 W dniu sobota, 9 marca 2019 14:42:39 UTC+1 użytkownik fir napisał: > 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 if no that is the another story, i will see |
| gazelle@shell.xmission.com (Kenny McCormack): Mar 09 03:34PM In article <q60d11$dtq$1@dont-email.me>, >> 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 <profesor.fir@gmail.com>: Mar 09 07:58AM -0800 W dniu sobota, 9 marca 2019 16:34:43 UTC+1 użytkownik Kenny McCormack napisał: > 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 <invalid@add.invalid>: Mar 09 02:20PM -0500 On 3/9/19 1:58 AM, Paavo Helde wrote: >> (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 <profesor.fir@gmail.com>: Mar 09 11:27AM -0800 W dniu sobota, 9 marca 2019 20:20:47 UTC+1 użytkownik Manfred napisał: > 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. 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 <Richard@Damon-Family.org>: Mar 09 03:15PM -0500 On 3/9/19 2:20 PM, Manfred wrote: > 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. 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 <profesor.fir@gmail.com>: Mar 09 02:51PM -0800 W dniu sobota, 9 marca 2019 21:15:56 UTC+1 użytkownik Richard Damon napisał: > 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. 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 <profesor.fir@gmail.com>: Mar 09 02:55PM -0800 W dniu sobota, 9 marca 2019 23:51:39 UTC+1 użytkownik fir napisał: > 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 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 |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment