Project

General

Profile

Bug #658

Audacious for Windows 64 bit

Added by Carlo Bramini over 7 years ago. Updated over 7 years ago.

Status:
Rejected
Priority:
Minor
Assignee:
-
Category:
-
Target version:
-
Start date:
August 08, 2016
Due date:
% Done:

0%

Estimated time:
Affects version:

Description

I was able to compile and play Audacious for 64 bit on Windows Seven 64.
I had to do only a little fix to acinclude.m4 because, obviously, "-march=i686" cannot be used.
I attached the patch here, it should be applied to both audacious and audacious-plugins.

Sincerely.

x86_64-windows.txt (458 Bytes) x86_64-windows.txt Carlo Bramini, August 08, 2016 18:35

History

#1 Updated by John Lindgren over 7 years ago

Why would you even want to do this? All major versions of Windows support the 32-bit API, and there is no reason a music player would ever need >4 GB of RAM.

#2 Updated by Carlo Bramini over 7 years ago

John Lindgren wrote:

Why would you even want to do this? All major versions of Windows support the 32-bit API, and there is no reason a music player would ever need >4 GB of RAM.

Well, at least on Windows you can access more that 4GB of RAM even on 32 bit versions of the OS... but in my opinion, there are other reasons for doing it. I remember that a similar question was arisen at the time when Windows 95 was released: why should be we compiling a 32 bit version of the software if 16 bit version can run on both Win 3.1x and Win32 through WOW layer? Win 9x could handle up to 512 MB and NT4 up to 4GB, but XMS driver could handle up to 64 MB of RAM, which was much more than the physical memory available at that time.

I think that an user should always search for the more appropriate build for his platform, if he owns a 64 bit OS, then he should get the 64 bit application: from my experience and like other users, I found the newer microcode is usually faster than legacy code. Otherwise, we had not seen products like MPCHC, VLC, 7Zip and many others slowly migrate to the new platform.

My personal reason: it is also true that 32 bit can run through WOW64, but this does not happens for free. The reason (at least one of them) because Windows 64 is eating much more memory is that it is technically running two operating systems, one 32 bit and one 64 bit. Sadly, starting from hardware manufacturers with their utilities built as 32 bit applications, nowadays it is still mostly impossible to see a pure 64 environment.

In my opinion, there is not reason to prevent the user from compiling a 64 bit executable.
If he wants, why should not he be able to do that?
The correction for allowing it is so small...

Sincerely.

#3 Updated by John Lindgren over 7 years ago

  • Status changed from New to Rejected

That was a lot of words just to say that a 64-bit build might run faster or more efficiently. Speed is not really a priority for the Windows version right now. Reliability, ease of use, and eventually feature parity with the Linux version are the priorities, in that order.

I don't think I will add x86-64 detection or any other support for custom Windows builds to our build system. This doesn't "prevent" you from making your own builds, with any changes you like. But the only officially supported Windows target for now will be 32-bit MinGW (the old one, not mingw-w64).

Also available in: Atom PDF