Im running TWS on 64 bit Win7 since a few month now. Installed without any problems. I think i have both 32 and 64 bit java installed. I can double check that tomorrow, the 64 bit machine is at my office.
I use IE8 32 bit with java 32 bit and everything works fine on my 64 bit machine. Everything has to match. IE8 64 with Java 64 worked fine also for TWS, but Flash was buggy in this setup (other applications) so I went back to 32 bit. Once Flash truly has 64 bit support, I'll switch everything over to 64 bit
Due to the large number of charts I use (multi-contract, multi-timeframe, market indicators on six monitors), the memory leak in TWS was killing the platform after a few hours. Someone here suggested setting the java Heap higher, so I found -Xmx1024M works much better, but it was still slowing down by the afternoon. Couldn't load with Xmx higher than 1024M. To get around this, I threw hardware at it. An i7 920 with 12G and 64 bit Win7 to use it. Windows 7 64. Installed in order: Java jre 32 bit 6 Update 23 Java jre 64 bit, 6 Update 23 TWS Standalone 913.6 Worked right away. Other posts say the order of install is crucial. So I gave it -Xmx3072M to ensure it stays happy. Testing in paper account showed no slowdown. Live on a busy day, and there's some slowdown after 2:00 in the platform getting the order out. But, I was getting a message at TWS login: "The ddedll.dll file required for Excel integration is either missing or out of date.The dll can be refreshed with the most up-to-date version can by downloading and installing the API Software from our web site." IB support solution was change the shortcut to point TWS at 32-bit Java (it was defaulting to 64-bit java, running fine except for this message). This gets rid of the API Excell message, but now I'm back to a Xmx limit of 1024. So, it's fine in that I can run TWS under Win7 64 bit. It's not fine that I can't use the memory I went to Win7 64 bit to get.
Hello, I tried various ways of installing the 64bit Internet Explorer, 64 bit java runtime and then tried to install IB locally. Everytime IB looks on the local setup fo find the java 32 bit installed.. and it did not work, because of the only 64 bit java... /anbd want to be shure, that IB is really using 64 bit java with all that memory, I give him..) my trick: install the java 64 bit runtime into the 32 bit java default directory (there the local IB installation looking for..) C:\Windows\system32\ then it works! Doing so, you have do do an individual installation of java64bit..not the default installation.. ATTENTION after installation you have to give IB more memory that IB is not freezing any more, because java has too less environment.. rightklick on the local IB desktop Icon, change -Xmx512M -XX:MaxPermSize=128M to -Xmx1024M -XX:MaxPermSize=2048M Explanation: (java -Xms<initial heap size> -Xmx<maximum heap size>) you can use 2048 / 4096 as well... it all is tested and work perfect on my computer.. again - my computer has 16GB RAM, Windows7 Ultimate, 64 bit us installed... hope this helps, if you have questions - no probs at all I can attach a file, if there are more explanations needed Dieter
something a bit odd My understanding is that 64-bit software uses "Program Files" and System32; 32 bit software on a 64-bit system is supposed to use "Program Files (x86)" and SysWOW64. The SysWOW64 ("Windows on Windows 64-bit"), contains all the 32-bit files which run on top of the 64 bit system. SysWOW64 is the 32-bit version of a 64-bit Windows' "system32" folder. When running a 32-bit application, which runs under the WOW64 32-bit emulator, any access to the System32 folder and the WOW64 emulator transparently redirects the request to the SysWOW64 folder. when I installed, in order: Java jre 32 bit 6 Update 23 Java jre 64 bit, 6 Update 23 the 32 bit Java was put into Program Files (x86)\Java\gre6\bin and then installed to C:\Windows\SysWOW64\javaw.exe the 64 bit Java was put into Program Files\Java\gre6\bin and then installed to C:\Windows\System32\javaw.exe and, confirmed by, pointing TWS at SysWOW64 limits -Xmx to 1024 pointing TWS at System32 (as the shortcut comes) -Xmx3072M is fine Perhaps if you do a system wide search for "javaw.exe" you can see where the sources reside, and by matching their size, see where they are installed to (SysWOW64 vs. System32).
Been running TWS for a bit, and it keeps running out of memory on a 32-bit Vista machine, so I decided to get some new computers anyway and installed 64-bit Windows 7, knowing that I could get the 64-bit Java and get at least 3GB of ram for the VM. Then the problems started... after reading this string of notes and elsewhere on the web, here is my summary of the problem and solutions. The problem is in the *installer* of TWS. Scenario: install new clean Windows 7 64-bit OS. Install the 64-bit Java from Sun (JRE or JDK), then download and install the TWS client from IB. This installer complains that your Java version is 0 instead of 1.6 and therefore quits. This appears to be from just laziness or a bug in the IB TWS installer. In should be looking at a different place in the registry or in the file system to determine what version of Java is installed, but it is failing to recognize the 64-bit installation. So, we have some choices: Workaround 1: install both the 32bit and 64bit Java runtimes. This will allow the TWS installer to see the 32bit one and finish the install. At that point, you can actually uninstall the 32bit runtime. You may have to right-mouse the TWS shortcut and change the properties. It should start with "C:\Windows\System32\javaw", since that is the 64-bit version. Workaround 2: install only the 64bit and copy java files around until the TWS installer finds something it likes. This is messy and might not work if it is using the registry or something to determine the Java version. Some people say this works, but they may have had a browser or other application that already installed some components on their machine. On a clean install that I just did, I was unable to fake out TWS installer by simply copying java files from C:\Windows\System32 to C:\Windows\SysWOW64. Workaround 3: install 64-bit Java, but just copy the C:\jts folder from another running computer. This probably works fine... with possibly the shortcut properties needing some adjustment. Anyway, this is something that many others are going to run into, because having several positions active with charts and firing up some of the analytics during the trading session (especially Risk Navigator), it really isn't possible for the application to work well in the small memory limit of 32-bit Java. Buying $40 of RAM and $130 OS was a nobrainer, but this installer bug wasted my Sunday morning. :-(
I still just unzip the Unix archive and copy it in c:\JTS manually. This has worked well for the last several years. See my opening post. It's still sort of embarrassing that IB cannot figure out to make an installer that works with 64 bit java. Personally, I don't have a choice, as my core trading platform needs 64 bit java.
Hear, hear. Now, here's my experience of it. Following the recommendations from this thread, I first installed - install 32-bit Java - install 64-bit Java - install TWS - repoint TWS shortcut on the desktop from C:\Windows\System32\javaw.exe to C:\Windows\SysWOW64\javaw.exe All good up until now. Next - uninstall 32-bit Java Now, the weird thing is that this uninstall removed java from C:\Windows\SysWOW64\ and obviously TWS canât launch. What the heck??...