Serial.list() hangs if 32bit export is run under 64bit Windows

Processing Electronics (Arduino, etc.)
1

Serial.list() hangs in exported apps if the exported 32bit version is started unter 64bit Windows (the exported 64bit version works under 64bit Windows).

Is there any way to fix this on my side, short of distributing two versions for 32bit and 64bit?

The file “jssc.txt” in the exported app states “This is using a modified version of Java Simple Serial Connector by Alexey Sokolov”. Is there a better version?

System:
Processing 3.4
Windows 8.1 64bit
java -version
java version “1.8.0_181”
Java™ SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot™ 64-Bit Server VM (build 25.181-b13, mixed mode)

1 Like
2

By the way, doubleclicking “jscc.jar” presents “Error: Invalid or corrupt jarfile” - but unpacks fine.

3

Same problem with Processing 3.5.3. This time I installed the 32bit version of Processing (under 64bit Windows) to see if maybe that version one could export a 32bit app that runs under 64bit Windows. Serial.list() still hangs. The exported 64bit app works.

I remember having had the opposite problem with older Processing versions that used rxtx.dll instead of jssc.dll: Exported apps didn’t work until rxtx.dll was replaced (back in those days it worked under Windows 32bit and not under Windows 64bit, now vice versa).

4

hi, i try to follow, and i think that i am actually NOT answering your question,
still i want show what i try here:

  • i have a old PC with win7 / 64bit
  • i use Processing 3.5.3 ( 64bit ) but for this test i add install also ( 32bit version)
  • i have a not fitted JAVA version on the PC but it does not matter as Processing comes with its own JAVA
    but that means i must export processing apps WITH JAVA.

Embed Java for Windows (nn-bit)

now i use following sketch:

import processing.serial.*;
Serial myPort;      // The serial port
String portName;
int bdrate = 9600;
int whichKey = -1;  // Variable to hold keystoke values
int inByte = -1;    // Incoming serial data

void setup() {
  printArray(Serial.list());
  portName = Serial.list()[0];                  // select index for your device
  myPort = new Serial(this, portName, bdrate);
}

void draw() {
  background(0);
  text("Last out: " + whichKey, 10, 20);
  text("Last in : " + inByte,   10, 40);
}

void serialEvent(Serial myPort) {
  inByte = myPort.read();        // Get incomming
}

void keyPressed() {
  whichKey = key;
  myPort.write(whichKey);         // Send the keystroke out:
}

and it runs under processing 3.5.3 32 and 64 bit on this PC
even without any device connected ( [0] COM 1 )

when i export it from the 64bit processing only the 64bit app runs, the 32bit app has no Java, try to use the PC Java and fails.

when i export it from the 32bit processing only the 32bit app runs, the 64bit app has no Java, try to use the PC Java and fails.

so to have both versions incl their nn bit Java
i need to copy
the 32bit app from the 32bit processing export and
the 64bit app from the 64bit processing export

well as i said, that answers your question only insofar

  • that the combined / both run under a 64bit windows
    ( but as you mentioned you actually not want deliver both apps )
  • NOT tested on a 32bit windows
1 Like
5

but as you mentioned you actually not want deliver both apps

It’t less a matter of not wanting but one of not being able to do that (hundreds of customers and each gets his/her own downloaad with individually licensed Mac/Win/Android/Linux apps => that already adds up to gigabytes). I’m running out of web space. Bundling Java would be totally out of the question.

I think I have found a solution:

What works is taking the jSSC-2.8.0-Release from 2014 (!) from github (Releases · scream3r/java-simple-serial-connector · GitHub). Either replace the jscc.jar in the exported Processing app with the one from 2014 (and delete jscc.dll in the exported app because that’s in the 2014 jar) - or just replace the jscc.dll with the 32bit version from 2014 (using the name jSSC-2.8.dll, not the old name jSSC-2.8_x86.dll).

Now it works (i.e. the win32 executable works under win64; not yer tested under win32). The funny thing is that now even freshly exported 32bit Processing apps with serial functions work under 64bit Windows, without replacing anything. It guess this old jar has installed the jssc dll somewhere on my system where it overrides the dll in the exported apps (?).

the 32bit app has no Java, try to use the PC Java and fails

I don’t have that specific problem.

6

I used SerialDuplex in the examples to test this.

If I export with 32-bit Processing 3.4 (or 3.5.3) I am prompted with this:
Capture%2032
Two folder are created:
application.windows64 Does not contain a folder named java.
application.windows32 Exported a 32-bit version with a folder named java and works.

If I export with 64-bit Processing 3.4 (or 3.5.3) I am prompted with this:
Capture64
Two folder are created:
application.windows64 Exported a 64-bit version with a folder named java and works.
application.windows32 Does not contain a folder named java.

I did observe that the two folder are created each time and the previous contents are lost.

This was tested on a 64-bit W10 PC.

Do a search for “file: jssc*.dll” and see what turns up.

:slight_smile:

1 Like