The problem is there is PE32 and PE64 formats. And what I need is to make exe that runs cpu detection and runs 32/64bit code for the specific cpu. If there's no possible way, maybe inner process is the solution? Or in-memory 64bit exe execution. I really don't know how can it (ever) be done. Will be useful if someone gives me idea.

EXE has to be flagged as 32bit or 64bit, and won't run on other subsystem anyway.

that was my question, can it be done with some kind of subprocesses

I strongly doubt this is possible. It would have to be sme VERY nasty trick IMHO

well which is possible?:
1. some kind of threads
2. in-memory pe64 exe running
3. loading 64bit dll

two executables

I just got kicked off the family computer for programming in NotePad lol, so when I get a 64-bit processor in the oncoming weeks I'll have to switch my language.. Is there anyway of running 32-bit code on Vista? I haven't checked, but I might just have XP sp2 running on a 64-bit machine. When I do I can answer that question with my tears lol..

Sucks, I make my living programming in NopePad.


yes, WOW64. google it.

Not to mention that there's 32bit versions of Vista.

In general, I would say that no, you can't run 64bit code from a 32bit executable - without some tricks. But it is possible, for instance vmware can run XP64 virtual machine on a XP32 host...

but vmware translates the 64bit opcodes to 32bit and run them, that's not what I need. whatever, do somebody know how to run executable from buffer?

One little correction before my topic: VMware doesn't translate 64-bit
code to 32-bit but rather emulates 64-bit instructions with 32-bit code.

That said I'm actually having a bit of the same problem. http://board.flatassembler.net/topic.php?t=7770
but not getting very far. The problem is that Windows seems to support
both 64 and 32 at first look, but then suddenly it puts a wall between
them. You actually can't summon a 32-bit process from a 64-bit nor vice
versa.

The *tricks* people talk about here are very nasty like:
1) emulating the whole thing.
2) Writing your own "secondary executable" while running and starting it
up through batch scripts (which can't be done natively).

well which is possible?:
1. some kind of threads
2. in-memory pe64 exe running
3. loading 64bit dll
These are all impossible because Windows allows only one subsystem
at a time! The problem is different address-space, which is explained in
some articles aswell.

You will understand easily that translate >4GB space into tinier space is
impossible (though plausable in some cases), but the other way is also
rather impossible because of all the instructions changed and disabled.
AAM, AAD, short forms of INC/DEC are only some of them.

Madis731: how much does Windows isolate 32- and 64-bit processes?

It should be possible at least to communicate with sockets, but what about pipes? can't you map views of a named memory mapped file between 32- and 64-bit?

@f0dder: very-very-much Seems that there have been no thoughts what so ever on making communication between 32/64 sane AND POSSIBLE!!!

If some say that COM is the way to go - good luck. Even SetPixel/GetPixel is better coding. At least Set/Get on pixels is faster. When both applications know what pixel(s) they are referring to.

OR - I could put up an FTP server on localhost and communicate over that

Here come the results:
WM_COPYDATA - NOT POSSIBLE! (Only DWORD at a time can be copied, the message ID)
WM_SENDMESSAGE - NOT POSSIBLE! (At least I couldn't make any use of it)
Sockets - POSSIBLE! (Sockets are slow and setup takes time)
Memorymapped files - VIRTUALLY IMPOSSIBLE! (The address-spaces are too different and I cannot find a way to exchange the handles if say I want to create a file in memory and map it to a lower address <2GB. First tests failed, but I wouldn't rule that out yet)
Pipes - POSSIBLE! (The best way if you ask me, setup is easy and you can use Read/WriteFile operations on pipes. I cannot recommend it speedwise, though.)