0

I am using windows 32 bit VLC media player in 64 bit pc. It is working fine. but my question is that won't it allocate memory according to 32 bit structure? That means though i have 64 bit PC, i wouldn't get advantage of it. Simply 64 bit might have good memory allocation in register than 32 bit. Sorry for the simple question but, i am new at Computer Organization Architecture.

EDITED : my point : using a 32bit VLC player in my 64bit OS (4GB RAM) will run like a 32bit player running on 32bit system.. so it doesn't make any sense whether you've 64 bit System or 32 bit system , because it's running like a simple 32bit system. Thanks in advance.

PS. i want it in technical terms, but i have to answer in NON TECHNICAL TERMS.(a general user can understand your answer).so try in general meaning at the end of your answer. thanks for help ..

Karan Patel
  • 1
  • 2
  • 1
    I’m pretty sure this has been asked at least a few times already. Try the search-box in the upper-right corner. For the record, yes, 32-bit VLC will only be able to allocate up to 4GB of memory because it uses 32-bit pointers—in practice, it’s actually not even that much due to other factors. (Of course I can’t imagine a real-life scenario in which a video-player would even need to allocate that much.) You can also see some other difference besides memory in [this question](http://superuser.com/questions/183201/). – Synetech Aug 24 '13 at 20:09
  • What "advantage of it" are you talking about? Most of the advantages only require a 64-bit OS. – David Schwartz Aug 24 '13 at 20:17

2 Answers2

0

By default an 32Bit application can also only use 2GB of memory. Only if the application is compiled with the IMAGE_FILE_LARGE_ADDRESS_AWARE flag the 32Bit application can use 4GB memory.

magicandre1981
  • 97,301
  • 30
  • 179
  • 245
  • `> The /LARGEADDRESSAWARE option tells the linker that the application can handle addresses larger than 2 gigabytes.`   I wonder what that means; unsigned pointers? I don’t see how the program can use >2GB pointers if the OS isn’t using the `/3G` switch. I guess I just found a yet another project: trying to write such a program. `¬_¬` – Synetech Aug 24 '13 at 20:51
  • @Synetech "I don’t see how the program can use >2GB pointers if the OS isn’t using the /3G switch." You're forgetting that 32-bit applications can run on 64-bit OSes. (Also, everyone is forgetting about [AWE](http://msdn.microsoft.com/en-us/library/windows/desktop/aa366527%28v=vs.85%29.aspx).) – David Schwartz Aug 24 '13 at 21:31
  • @DavidSchwartz,   `You're forgetting that 32-bit applications can run on 64-bit OSes.`   We’re not talking about 64-bit platforms. If a program is meant to be run on 64-bit and is going to be specially compiled for it, then it may as well just be a full 64-bit program, thus rendering the `/LARGEADDRESSAWARE` flag pointless.     `Also, everyone is forgetting about AWE.`   There’s no mention of the requirements for AWE to work, so I assume it’s for 32-bit programs running on 32-bit, non-Server editions of Windows. It kinds of reminds me of segment-offset addressing in DOS. – Synetech Aug 24 '13 at 22:28
  • 1
    @Synetech "If a program is meant to be run on 64-bit and is going to be specially compiled for it, then it may as well just be a full 64-bit program, thus rendering the /LARGEADDRESSAWARE flag pointless." That makes no sense at all. Whether compiled as 32-bit or 64-bit, a program should still take advantage of whatever platform it happens to run on. And the `/LARGEADDRESSAWARE` flag helps on 32-bit OSes too. There are plenty of programs that don't provide 64-bit builds (for a variety of reasons) but can still benefit from access to more virtual memory on 64-bit platforms. – David Schwartz Aug 25 '13 at 00:09
  • `And the /LARGEADDRESSAWARE flag helps on 32-bit OSes too.`   @DavidSchwartz, you’ve got it backwards, the flag is *specifically for 32-bit programs*. It has no point for a 64-bit program since any (sane) developer who is compiling a program to run on a 64-bit system would just make it 64-bit to begin with. There is little point to compiling a 32-bit version of a program but then adding the flag to support large pointers (save for perhaps a program that must use 32-bit only libraries). – Synetech Aug 25 '13 at 03:21
  • `There are plenty of programs that don't provide 64-bit builds (for a variety of reasons) but can still benefit from access to more virtual memory on 64-bit platforms.`   Yes, if it is running on a 64-bit system, [not on a 32-bit system](http://superuser.com/questions/636255/using-32bit-application-in-64bit/636257?noredirect=1#comment794777_636257). – Synetech Aug 25 '13 at 03:22
  • @Synetech Yeah, that part was incorrect. The rest is correct. In particular, it often makes a lot of sense to make a 32-bit build but also put some effort into getting access to as much memory as possible on both 32-bit and 64-bit operating systems. Unless your 32-bit build cannot run on 64-bit operating systems for some reason, there is no reason not to make it run better on 64-bit operating systems if that's doable. – David Schwartz Aug 25 '13 at 03:24
  • @DavidSchwartz, sure that would be ideal, but like I said, *what does “application [that] can handle addresses larger than 2 gigabytes” mean? unsigned pointers?” and *I don’t see how the program can use >2GB pointers if the [32-bit] OS isn’t using the /3G switch.* – Synetech Aug 25 '13 at 03:28
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/10300/discussion-between-david-schwartz-and-synetech) – David Schwartz Aug 25 '13 at 03:29
0

A 32-bit program running on a 64-bit OS will in general not be able to access more memory. There are several barriers;

Note that there are 64-bit builds of VLC for windows available. They are marked experimental, but I've built and used VLC on other 64-bit platforms without problems.

Roland Smith
  • 1,958
  • 12
  • 14