Re: define_c_func/proc and 64-bit return types

new topic     » goto parent     » topic index » view thread      » older message » newer message
petelomax said...
jimcbrown said...

where are you getting this from?

There's a pattern, as matt said, but if it has to break I can cope.

I see it now. Doesn't seem to have been documented, but in retrospect it's obvious.

petelomax said...
jimcbrown said...
petelomax said...

As far as Ansi/Unicode versions of dll routines go, don't we just leave that up to the programmer? Should 64-bit really be any different?

I don't understand what you mean. Leave what up to the programmer?

When you run things on 64-bit Windows, 32-bit programs load dlls from C:\Windows\SYSWOW64 whereas 64-bit applications load them from C:\Windows\system32 (just to maximise confusion). True, that should make no difference, but I suspect it probably will.

I have no doubt that new kinds of DLL Hell will be discovered. But yes, creating and maintaining 32bit vs 64bit versions of a dll should be left up to the programmer ... even so, why not make life as easy and simple as possible for that programmer?

petelomax said...
jimcbrown said...
petelomax said...

as well as changing C_INT from #01000004 on 32-bit to #01000008 on 64-bit.

Why? C's int is still 4 bytes on gcc/linux/gnu .. What would be the point? What platform has 8 byte sized ints such that the C compiler has sizeof(int) == 8?

Oh. size_t is however 8.

I have no problems with an additional include that mimics types.h that adds a C_SIZE_T and C_INTPTR_T and so on.

petelomax said...

My only experience with 64-bit was writing a kernel mode driver, utterly blind, no debugging facilities whatsoever (until very late in the day when I figured out how to squirt things down a named pipe that another program could then display). So that code chucks a few 8 byte ints at routines that probably (I will never know) only read 4 bytes (thank god for little endian). One thing I can tell you is that the 64-bit version of that code is utterly and completely different to the 32-bit code that preceded it. Now that someone has said it, I will concede that OpenEu has a translator in the middle (which I did not have in C++) to do some and possibly all of the mangling.

Pete

petelomax said...

Edit: I just found this, see table N2 in http://www.viva64.com/en/a/0004/#ID0ERG

That's an interesting read. Read world ILP64 systems seem to be rare.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu