I know that when doing 32-bit development I push the parameters to the stack and use call to call the API.
But when doing 64-bit development it seems some parameters are passed to registers. How do I know which registers to use? Is there a reference?
Also are there some Win64 development guide?

Another question: I'm planning on installing Win XP 64 here to use the full power of my machine. Is this version as stable as Win XP (32 bits)?

Tomasz probably has move practical advice, but my own caveat would be "don't expect it to be as compatible as 32-bit Windows" (yet, if ever). Then again, Vista 32-bit ain't too compatible either. Oh well. At least 64-bit is faster (10% or so, supposedly).

http://www.jorgon.freeserve.co.uk/GoasmHelp/64bits.htm
http://www.agner.org/optimize/calling_conventions.pdf
If you install the Windows SDK from roughly
http://www.microsoft.com/downloads/details.aspx?FamilyId=484269E2-3B89-47E3-8EB7-1F2BE6D7123A&displaylang=en
you get a file called SWConventions.doc that has the x64 calling convention. If you're used to programming RISC machines the calling convention will seem quite natural, otherwise it may take some getting used to. It's much easier than 32-bit Windows because there is only one calling convention, and no name-mangling ala STDCALL (well, C++ still mangles, but that's different).

The only thing that has locked up my xp-x64 machine was when I was rewriting the Mandelbrot benchmark. If there was a bug in my code and it got hung in a loop the machine would be unusable until it was power-cycled. I think that was due to running multiple threads at realtime priority level and getting them all hung at once rather than any quality of x64. Probably putting 16 realtime priority threads in an infinite loop with the Win32 stuff set up (badly) as the Mandelbrot benchmark does in *32 code would hang the machine as well, but I haven't verified that.

Make sure that you have drivers for all your hardware before installing x64. You simply can't use 32-bit drivers in that environent. The big shocker after that is that DOS programs don't work in xp-x64, even though they worked in RISC versions of Windows NT under emulation!

If you do get 64-bit Windows installed, please try my x64 version of the Mandelbrot benchmark and post results to the appropriate thread. I still haven't collected results for many machines I am interested in.

Actually having only one thread running in real-time is enough to hung the computer. By real-time I mean having a thread in real-time priority and the process of that thread with a base priority high enough to make the thread really run at real-time.

PS: Well, maybe on multi-core systems you need more that one real-time thread to hung the system.

Using real time threads for any lengthy operation is just silly anyway. The computer still has to do the same amount of work no matter how you arrange the priorities. So any long running task should get a lower priority to allow the shorter tasks to complete earlier and not hang your system.

Although. I understand the code in question was merely for testing, but ... before jumping to RT one should test first at low priority to make sure it operates as expected. Then later when you are happy it works as desired you might see a small percentage improvement in run times once it is switched to RT.

I run on win64/ most things I want to run work. The only thing that bothered me is ollydbg didn't work properly until i found some script patches.

Hi OzzY,

The following blog goes over calling conventions: http://blogs.msdn.com/oldnewthing/archive/2004/01/14/58579.aspx

MSDN/Technet has some light details on amd64/x64 development, just google for it.

Windows XP x64 is based on Windows 2003 SP1 code base and not Windows XP x86, so in essence is just as stable as Windows 2003 Server. It is slightly quicker for most tasks as well., but you may not notice them except in instances when you are benchmarking.

PS. Calling conventions have been discussed here as well, http://board.flatassembler.net/topic.php?t=7050

The worst difficulty is to keep RSP (stack) aligned at dqword (search the forum for more)
params are passed in this order:
rcx, rdx, r8, r9, [rsp+8*4], [rsp+8*5], ... [rsp+8*X]
take a look into win64 samples included in FASM package