64bit version

[EvilDust]

QMP 5 beta are a big potential and I believe in it. I always prefered QCD to others media players. I have a little sugestion for future releases, a 64bit version. Windows XP and 2003 64bit edition are out now and miss 64bit media player. QCD and QMP work well in Windows XP x64 but can run better with a 64bit compiled version, and if you do it, you'll be ready for Windows Longhorn 64bit in 2006 before everyone.

[Tokelil]

Yer it would be great, but it's a bit complicated I think. For one thing, all plug-ins need to be rewritten for 64 bit. Also the mp3, ogg decoding libraries used probably aren't ported yet, though I haven't checked. (The XAudio isn't Im pretty sure)

[Rex_Mundi_Incarnit]

I doubt this will improve anything. Qcd is not a what you call a big application. It is not designed to eat lots of CPU cycles sooo...

[Toe]

Eh, it would be nice to have, but I wouldn't get too antsy about it.

There's other features being implemented that I would much rather take development time priority over a 64bit version. :)

[Psy]

Even if QMP is not 64bits, plugins can be converted, right?

[Tokelil]

Even if QMP is not 64bits, plugins can be converted, right?Im no expert on this, though I have read a few articles on the problems involved with going to 64bit. (Coding guidelines etc.)
I dont think it is possibel to map a 64bit dll into 32bit address space. I think 32/64 bit is per process and not per thread.

[Tokelil]

This from an "old" MSDN article. Its about Windows 64 for the IA-64 CPU though, but Im quite sure the same holds true for Windows x86-64. (The new WoW64 layer is probably a descendant of the one in Windows 64 for IA-64)

I mentioned earlier that 32-bit processes can't load 64-bit DLLs and 64-bit processes can't load 32-bit DLLs. You might be wondering why? Well, one of the reasons has to do with "thunking". By default, 64-bit applications can use 8 TB of user mode address space. You have the option to specify that all memory below 2 GB be allocated to the application. Because 32-bit DLL can't address memory space above 2GB, the thunk layer would have to copy all data into the low 2GB of the 64-bit application. Obviously, this won't work if the 64-bit application tries to pass a pointer to data that is larger than 2GB.

32-bit DLLs use x86 style exception handling and 4K pages. On an IA-64 processor, the native page size is 8K and the WOW64 emulator is responsible for simulating 4K pages. Because on an x86 machine exceptions do not "unwind" from user mode to kernel mode and back, WOW64 implements x86-style exception without switching from x86 code to IA-64 and back.

Finally, another reason why 64-bit and 32-bit processes can't load each other's DLLs is that system DLLs (kernel32.dll, user32.dll, and gdi32.dll) expect only one instance per process, 32-bit or 64-bit. If a process contained more than one instance of, say user32.dll, Win32k.sys will not be able to distinguish between them and wouldn't know which one to call.
http://www.microsoft.com/technet/community/columns/profwin/pw0801.mspx

[Psy]

I see. Its a shame because some dll perhaps can benefit from 64bit twecking, but agree that qmp core has little use of it.