I know nothing about Java other than Windows sucks at it (or Sun sucked at Windows, depending on how you look at it, realistically, I'm sure Microsoft and Sun should share the blame on the fact that the language runs horribly in Windows). However, I was able to get this method working in Windows (XP). It took much longer than it should have if I had any clue what I was doing, but hey!
Anyway, I don't have a Win7 x64 machine with a FW device to test this with, so I'll leave that to someone else if anyone is willing.
Here's what needs done:
1) Get a copy of the FingerWorks folder from a Windows install and place it wherever you wish (in my case it's actually installed in C:\Program Files\Fingerworks, so I'll use that in my example)
2) Create a shortcut to java.exe (default path is %windir%\system32\java.exe, used in my example)
3) Get into the shortcut's properties and, in the "Target:" field, put this:
- Code: Select all
%windir%\system32\java.exe -classpath lib\jusb\jusb.jar;lib\FW_defaults.jar;lib\upgredit.jar;lib\jh.jar;lib\utility_help.jar;lib\jdom\xerces.jar;lib\jdom\jdom.jar;lax.jar fingerworks.firmup.UtilityLauncher
*Everything in the code box will technically be on one line, but the space lead to a line break due to the length of the command
4) In the "Start in:" field put this:
- Code: Select all
"C:\Program Files\FingerWorks"
*Quotes aren't necessary if no spaces are included in the path to your copy of the FingerWorks install directory
5) [Optional] Change the "Run:" field from "Normal window" to "Minimized" [This is going to be a command prompt running Java, not the multitouch utilities]
6) [Optional] Change the icon to the MultiTouch_Utilities.ico file in your copy of the Fingerworks install directory
7) [Optional] Rename the shortcut to "FingerWorks MultiTouch Utilities Java Launcher"
Note that I didn't set any of the environment variables listed in Dan's post. It might be wise to set them, but then you have to have a batch file or integrate them into your system configuration. They may only be necessary for Lion. Dan, do you care if I copy your source from github into the forum so there is another record of the variables involved?
I tested this in Windows XP using Java 6 Update 21 which returns this when given the -version parameter:
- Code: Select all
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing)
I confirmed that the configuration editor would pop up and the diagnostics would run. I did not test upgrading. When FingerWorks existed, they made us run a specific version of java. The version distributed with the FingerWorks drivers returns this when given the -version parameter:
- Code: Select all
java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode)
because others "weren't supported." Technically, none are supported now, but running a different version is at your own risk. This was installed, os well, but not in the add/remove programs list, so I doubt it was called. However, I also had this old version installed:
(J2SE Runtime Environment5.0 Update 13)
- Code: Select all
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode)
This did show up in add/remove programs and might have been automatically called somehow, in which case that could de another roadblock, but that's assuming that 1.5 would be more compatible with 1.4 than 1.6 for some reason.
Assuming an old version wasn't called, if you have both installed and want to use the original one, or some other older one more tweaking would be necessary, but I'm not sure how much. For instance, there is a -version:<value> parameter that might call up the old version if it is actually installed. That might allow you to leave the shortcut mostly the same and just call the version you want. Otherwise, it would be necessary to use the start in path of the old version of java and modify the "Target:" field to include absolute paths to each jar file, which may also involve using quotes on the -classpath option.
All of that having been said, has anyone tried XP mode on Win7 for this? I don't know whether or not that limits what kind of devices XP mode applications have access to when they are run in the 6.1 environment (instead of in the virtual machine where only certain devices can be passed through).
Finally, for the record, I don't know if the JAR files are any different for the various operating systems. It might be possible to copy the Windows files into Linux and do this just as easily. If not, it should still be possible to do this just as easily in Linux using a copy of whatever comes from the linux install package. I imagine Linux would use : instead of ; much like Unix (mac), though. I also imagine it would be easy to set the environment variables right on the command line too, meaning a shortcut or a shell-script would be a viable option for launching this stuff.
This ALL assumes Java can still access devices the same way, if an OS upgrade prevents that, bypassing the compiled executables and launching directly from Java won't be helpful.
EDIT: I had version info wrong above and have updated it (good news is I can now uninstall an old version of java I thought I left just for FingerWorks and my computer will be a bit more secure). Also, Dan has posted again to note a patch necessary to jusb in Unix(mac), something similar is likely necessary in Linux and Windows given that previous workarounds have required specific kernel versions or virtualization scenarios. Finally, the aforementioned environment variables are no longer listed as necessary in Dan's environment.