Hello,

As you may know, Windows x64 is almost released.

The calling convention for Windows API is totally different (parameters are passed in registers and not via the stack).

Is anyone working or plan to work in a library that allow us to do the standard:

invoke MessageBox, xx, xx, xx, ...

Instead of passing parameters by registers and avoid learning which registers are passed for each API? That's a real pain! :)

Thanks
Posted on 2005-02-23 03:40:18 by Alorent
Are you sure about this?
I remember reading on msdn that only some api functions will be changed to reflect the x64 requirements. Nothing was said about changing the whole calling convention.
Posted on 2005-02-23 08:58:09 by arafel
who uses ia-64 anyways? it has a total of like 2000 sales. parameters will still be passed through the stack for x64. as usual, but addresses must be qword aligned.
Posted on 2005-02-23 17:34:03 by Drocon
I think there is a lot of confusion between IA-64, AMD64 and EM64T and how they will work with Window XP 64-bit Edition. I'll admit I am a bit confused too.

Charles Petzold needs to write another book on Win64 on AMD64 / EM64T. But Microsoft is promoting .NET and Longhorn so much...

I bet Windows XP x64 Edition becomes very popular. I wonder how that will effect .NET and Longhorn.

The direction of things may be taking a turn here (I hope).
Posted on 2005-02-23 18:39:26 by Greg
.Net and Longhorn are all wrapped together and would include any x64 stuff. They will all be MS home base.
Posted on 2005-02-23 22:48:55 by drhowarddrfine
Are you sure about this?
I remember reading on msdn that only some api functions will be changed to reflect the x64 requirements. Nothing was said about changing the whole calling convention.

Check Win64 ASM example source code out.
Posted on 2005-02-24 01:55:11 by MazeGen
who uses ia-64 anyways? it has a total of like 2000 sales. parameters will still be passed through the stack for x64. as usual, but addresses must be qword aligned.

Itanium, IA-64, gets unsupported by Microsoft in last weeks. ML64 means ML x86-64. AFAIK there's no ML for Itanium, Microsoft distributes IAS (made by Intel) instead.
Posted on 2005-02-24 01:59:58 by MazeGen
.Net and Longhorn are all wrapped together and would include any x64 stuff. They will all be MS home base.


If I understand things correctly, and I may not, .NET will be the base API for Longhorn and Win32 (and Win64?) applications will have to be converted to .NET before they are executed. Very much like .NET applications have to be converted to Win32 now. I have read that .NET is 32-bit only at this time, but I'm sure they are working on 64-bit .NET.

What I was trying to say above is that native 64-bit code using Win64 on Windows XP x64 Edition may become so popular that things may take a turn away from .NET and Longhorn. Maybe they will end up like IA-64. I hope so anyway, I really don't like .NET / Longhorn.
Posted on 2005-02-24 14:37:05 by Greg
All dotNET code is eventually translated into the Win32 API. However it is "managed" at the .NET level before doing so. (To make a long explanation short).

Win32 code written in, say, C++ can be "managed" by the .NET framework or you can write it "unmanaged", that is, without using the .NET framework, just as most code is written today.
Posted on 2005-02-24 16:45:08 by drhowarddrfine

I though windows 64bit edition (for Itanium) and windows x64 are the same thing. Sorry for misunderstanding. :oops:
Posted on 2005-02-24 19:22:33 by arafel
Hello,

Yes, there are a lot of confusiong about AMD64, EMT64T and IA64.

This are my 2 cents:

AMD64 = EMT64T
--------------------


AMD64 is designed by AMD.
EMT64T is designed by Intel.

AMD64 and EMT64T should be almost equivalent. Well, they are as similar as current Pentium processors and AMD processors for 32 bits.

Their assembly code are referenced as x64 or x86-64.

So, Windows XP x64 and Windows 2003 Server x64 are the binary compatible version for this 2 new 64bits processors. They both can be called Win64.

They can also run in 32bit compatibility mode. So, they can run current 32bits versions of Windows without loosing performance.


Intel Itanium (IA64)
-----------------------

This is a completely different beast. The instruction set is completely different and it uses a RISC architecture. Nothing is similar to our beloved x86 assembly code.

My thoughts are that this Itanium processor will not be very expanded due to BIIIG prices . Also, to run our 32bits programs under Windows Server 2003 Itanium, they emulate each instruction. So, it will run Win32 apps much slower. I think this processor will be only use for big servers and not for home-use.

The Windows version for this processor is called Windows 2003 Server Itanium.


Summing up
--------------

I guess the future of our assembly code will be x64 (so called, x86-64 also). That's the assembly for AMD64 and EMT64T.


So, going back to my original question. You will see if you have a look at the following code for Win64 how MEssageBox and ExitProcess are called (they use registers parameters instead of the traditional stack)


---
mov r9d, 0 ; uType = MB_OK
lea r8, mytit ; LPCSTR lpCaption
lea rdx, mymsg ; LPCSTR lpText
mov rcx, 0 ; hWnd = HWND_DESKTOP
call MessageBoxA
mov ecx, eax ; uExitCode = MessageBox(...)
call ExitProcess

---

Annoying, isnt it? ;) I think that we should need a wrapper that converts our:

invoke ExitProcess, 1

to

mov ecx, 1
call ExitProcess

And the same for all the rest APIs ;)

Cheers
Posted on 2005-02-25 02:52:54 by Alorent
My 2 cents about the processor modes:

Legacy mode:
    [*]means functionality just like current x86-16 and x86-32 processors
    Long mode (only under 64-bit OS):
      [*]with compatibily mode: used to run x86-16 and x86-32 native applications under 64-bit OS
      [*]with 64-bit mode: supports all of new features

      BTW, this may be confusing: long mode (in AMD terminology) = IA-32e mode (in Intel terminology)
Posted on 2005-02-25 04:21:31 by MazeGen
I thought "long mode" didn't support 16bit apps?
Posted on 2005-02-25 04:25:10 by f0dder
I don't own x86-64 processor, I study AMD Programmer's Manual Volume 1 (I use revision 3.07), chapter 1.2.3 Compatibility Mode:

...allows 64-bit operating system to run existing 16-bit and 32-bit x86 applications. These legacy applications run in compatibility mode without recompilation.
Applications running in compatibility mode use 32-bit or 16-bit addressing and can access the first 4GB of virtual-address space. Legacy x86 instruction prefixes toggle between 16-bit and 32-bit address and operand sizes.
...

Intel says the same in a bit different words, with one note:

...
(However, legacy applications which were run in Virtual 8086 mode or use hardware tasm management will not work.)
...

It seems that there is almost 100% backward compatibility also in long mode.
Posted on 2005-02-25 04:39:00 by MazeGen

However, legacy applications which were run in Virtual 8086 mode or use hardware tasm management will not work.


that sounds to me like 16bit apps won't work, or will have to be emulated... or am I completely misunderstanding this?
Posted on 2005-02-25 11:34:29 by f0dder
No, just those that use V86 mode, such as DOS emulation. Old Windows applications should work fine, right? And you could probably switch it back to legacy mode to use V86 mode, if needed.
Posted on 2005-02-25 14:43:49 by Sephiroth3
Someone really needs to write a good book on programming Windows XP x64 Edition.

Here is some documentation on the Windows x64 Calling Convention, it's FASTCALL.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/64bitAMD_6ec00b51-bf75-41bf-8635-caa8653c8bd9.xml.asp

(later)
x87 and MMX code is not going to be allowed in a 64-bit app on Windows x64.
SSE/SSE2 only.
http://www.devx.com/amd/Article/20923

(even later)
Windows x64 will not run MS-DOS or 16-bit Windows applications.
http://www.winsupersite.com/reviews/windowsxp_x64_preview2.asp (third paragraph)


Big changes...
Posted on 2005-02-25 16:13:15 by Greg
Well, when I say 16bit apps, I mean dos - I guess I should have been specific here, as 16bit pmode (win3.x) is another case. I run more DOS apps than I run win3.x stuff :)

And as for switching back to legacy mode, humm... I think that would be too slow to be practical? So either DOS apps will be unsupported, or will have to be run in 100% CPU emulation mode (like dosbox) - eek!

Greg: WTF? No MMX in native mode? Are they out of their minds? O_o (ok, if the SSE2 versions of MMX are allowed, I guess this is okay... but still!)

I guess it's okay they're dropping 16bit (both DOS and win3.x) support. After all, these are not natively supported by hardware when in "long" mode (afaik), and most people don't need these anymore. And if they do, well, run a 32bit version of windows. Commandline tools can be rewritten to native win32/64 console applications, and DOS games ran like shit in emulation mode anyway :)

Even though my new box is going to be an amd64, I dunno when I will be running XP64... will probably take some time, wait until the product matures and such.
Posted on 2005-02-26 00:33:04 by f0dder
f0dder,

What I have been wondering about is how we are supposed to do
transcendental functions (trigonometric, logarithmic and exponential
functions) in Windows x64 if you can't use x87 instructions? For example how
can you calculate a Cosine on SSE/SSE2? Will they have to be done in
software? Talk about sloooow.

This is a Windows x64 limitation not an AMD64 or EM64T limitation. 64-bit
Linux can use x87 instructions.
Posted on 2005-02-26 18:51:54 by Greg
Are there any informations about it directly from Microsoft? I can't believe Win x64 won't support native functions of the processor...
Posted on 2005-02-27 00:39:28 by MazeGen