Categories & Tags

Unity 3.4 web player for 64-bit Windows

July 28, 2011 in Technology by

Update Dec. 4 2012: The unsupported 64-bit Windows web player is not currently in working state in Unity 4.0.

While we have been developing Unity 3.4, we have ported the Unity runtime to the x86_64 architecture on Windows. You may have noticed that the Unity 3.4 editor allows “Windows 64-bit” as a new build option in the Standalone build. We have also ported the Unity Web Player to Windows 64-bit. This allows you to play Unity content in Microsoft Internet Explorer 64-bit or in 64-bit builds of Mozilla Firefox. Any Unity web content built with Unity 3.x should play in the 64-bit plugin. Content built with Unity 2.x will not work, as the 2.x runtime has not been ported to x86_64!

Since 64-bit browsers are not yet very widespread on Windows, the 64-bit web plugin has received limited testing coverage during our 3.4 beta. For that reason, we have decided to make this plugin available on an experimental basis for anyone who wishes to test or run Unity content in a 64-bit Windows browser. It is not yet available on our our main Web Player download page and the default JavaScript we supply for embedding Unity content will not link to it, so you have to manually download the installer. If 64-bit browsers become more common on Windows in the future, we will change this and release it as a fully supported product.

Without further ado, here it is!

Even though this is an unsupported product, please use the bug reporter which comes with Unity to report any issues you might have with the plugin!




Windows 64-bit plugin screenshot

Share this post

Comments (16)

Comments are closed.

Richard Fine
28 Jul 2011, 10:14 am

Ah, interesting. I remember chatting to someone about why Unity wasn’t 64-bit already, and the suggestion was that it was being blocked by some dependencies on third-party code. If you’ve resolved those dependencies enough to get the runtime 64-bit on Windows, does that mean that a 64-bit Mac player isn’t going to be far behind?

And then, perhaps, a 64-bit build of the Editor… ;-)

Jonas Echterhoff
28 Jul 2011, 10:21 am


yes, this does get us closer to both 64-bit Mac and 64-bit editor builds (which is part of the reason we did it — porting the runtime to 64-bit is a necessary subset of porting the editor). But both still have a lot of additional non-trivial work to be done first. The editor has much more code, and many more dependencies to third-party libraries then the runtime. And with Mac OS X, the biggest problem is that Apple has removed a whole lot of APIs from the 64-bit versions of their SDKs. Yes, these APIs have been deprecated for a while, but since we support running Unity as far back as Mac OS X 10.4, we are forced to still use many of these deprecated APIs. So we either have to support two code paths, or remove support for old OS versions to get 64-bit support on the Mac.

28 Jul 2011, 11:14 am

Exciting stuff, thanks!

28 Jul 2011, 11:29 am

28 Jul 2011, 12:33 pm

Supporting two code paths is a wrong way, imho. Many Mac developers are iPhone developers too so they are using 10.6+.

Jonas Echterhoff
28 Jul 2011, 12:43 pm


This is about the runtime as well, so if we want to remove the old code, we’d have to remove support for old OS versions for end users.

Richard Fine
28 Jul 2011, 9:20 pm


I see – makes sense.

Thanks very much for the info btw – one of the more frustrating aspects of Unity not supporting 64-bit is that there’s not been, to my knowledge, very much information about what the holdup is. It’s good to get a bit of concrete info, and to know that it’s not just that nobody inside UT thinks it’s worth doing :-)

Richard Fine
28 Jul 2011, 9:23 pm

Incidentally, while I understand that you probably can’t publicly name many of the non-64-bit packages you’re dependent on for business-relationship reasons, are there any open-source packages that are holding you up in the same way that maybe you *could* point at?

Perhaps there are some devs in the community who want 64-bit and are willing to put the time into getting those packages to where you need them to be. Just a thought.

Jonas Echterhoff
1 Aug 2011, 6:35 am


We have source code to all our dependencies at we are building most of the libraries ourselves. So none of this is out of our reach, it’s just a lot of work to be done. I actually don’t have an overview of which libraries are and which aren’t 64-bit compatible, but even for those which are, it is still a matter of updating our build process, sometimes finding out how to build them for stuff we haven’t updated in a while, etc. All that work x2 (Mac and Win) for over 20 external libraries adds up.

7 Aug 2011, 9:55 am

Could anyone explain briefly what’s the benefits of 64-bit web player? Or it’s just for compatibility with 64-bit browsers for those who use it?

Jonas Echterhoff
7 Aug 2011, 10:23 am


Mainly compatibility with 64-bit browsers, yes. Also, the ability to access more the 4 GB of memory, but as long as the editor and all user browsers are not 64-bit, this generally won’t help you, because you don’t want to make content which runs out of memory everywhere else. But as memory gets larger and computers get faster, this will eventually become the common standard.

Sunny Davis
11 Aug 2011, 7:05 am

Symantec detects it as “Suspicious.Cloud”. You guys should contact them about this false positive.

12 Aug 2011, 8:03 pm

Hi ,

@ Jonas Echterhoff ,

you mentioned that : “You may have noticed that the Unity 3.4 editor allows “Windows 64-bit” as a new build option in the Standalone build”
so did you mean we can now export our Windows Stand Alone (.Exe) file with 2 options ???!!!

both 32 bit and 64 bit ??? or is that feature only for the web Player??


20 Aug 2011, 7:42 am

baran salan4747

2 Sep 2011, 4:00 am

@Jonas Echterhoff I believe backwards compatibility is important (as long as it doesn’t hinder progression)
However yes, 64-bit computing is not there yet. So good decision on still maintaining the deprecated APIs.

30 Sep 2011, 1:52 pm

Unity web player for LINUX please!! there is a Mac Os X version, so it uses OpenGL, then the portability to Linux should be easier.

Leave a Reply

Comments are closed.