USB driver compatability for Apple M1, Java, and beyond

[Simon McNamara]

This post is only tangentially related to java, since the 3rd party API for the broken USB driver is in java.

Since I purchased an Apple M1 in late 2021 (Apple M1 Max 10/24, MacOS v12.3.1), I have twice encountered USB driver issues with 3rd party software that otherwise works!

This time around, I have a broken USB driver for an otherwise working java API from Ocean Insight for their USB type spectrometers. Perhaps some of you smart people here may think of something I haven't. Maybe there's a work-around.

OceanInsight provides a java API for their spectrometers here ( "OmniDriver+SPAM (Spectral Processing advanced math)" ): https://www.oceaninsight.com/support/software-downloads/omnidriver-and-spam/

The MacOS app won't launch at all. If I manually open the package contents (right click -> View Package Contents), I can manually run the OmniDriver or osx-intel Unix Executable File that I find inside the package.

When I try this, I get a terminal window with this output:

Last login: Thu Jul  7 09:55:06 on ttys000
/Users/.../Downloads/OmniDriver-2.682-macosx32-installer.app/Contents/MacOS/OmniDriver ; exit;
(base) ...@msi ~ % /Users/.../Downloads/OmniDriver-2.682-macosx32-installer.app/Contents/MacOS/OmniDriver ; exit;
zsh: bad CPU type in executable: /Users/.../Downloads/OmniDriver-2.682-macosx32-installer.app/Contents/MacOS/OmniDriver

Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]

Which suggests that the executable fails to identify or run an executable consistent with Apple M1 architecture. The osx-intel executable should work, given Apple’s use of the Rosetta compatibility layer. Plenty of other applications operate as the x86/intel versions on this same computer.

If I execute the Windows installer on a Windows machine, I can locate the java archive files (jars) in the installation directory. I can copy those to my MacOS development environment and import the jars into my java class. That code will compile with the jars in the build path. However, running this code results in this stack trace that suggests that there is no compatible USB driver for use on MacOS M1. This is that stack trace:

Exception in thread "main" java.lang.ExceptionInInitializerError
	at com.oceanoptics.uniusb.USB.<init>(USB.java:18)
	at com.oceanoptics.omnidriver.spectrometer.SpectrometerFactory.getAllSpectrometers(SpectrometerFactory.java:211) // API call
	at com.oceanoptics.omnidriver.api.wrapper.Wrapper.openAllSpectrometers(Wrapper.java:487) // API call
	at com.ioi.utilities.OceanOpticsSpectrometer.refreshSpectrometerList(OceanOpticsSpectrometer.java:75) // my class
	at com.ioi.utilities.OceanOpticsSpectrometer.<init>(OceanOpticsSpectrometer.java:96) // my class
	at com.ioi.utilities.OceanOpticsSpectrometer.main(OceanOpticsSpectrometer.java:464) // my class
Caused by: java.lang.RuntimeException: Failed to load any native library for USB.  Tried base filenames: NatUSBWin, NatUSBWin_64, NatUSBWin_32
	at com.oceanoptics.uniusb.UniWinUSB.<clinit>(UniWinUSB.java:131)
	... 6 more

I can locate the NatUSBWin_64 and NatUSBWin_32 dlls from the Windows installation directory and attempt to use those in my MacOS development build path, which also results in the same stack trace. It’s likely these drivers are Windows only anyway.

If the app fails to unpack on my M1 machine, is it possible to unpack it on an Intel mac, recover the USB driver dylib, and use that in my java project? I unfortunately don't have an Intel mac on hand .

The package contains a shell script which seems to indicate an execution path depending on CPU type. The original script is:

#!/bin/sh

os_version=`uname -r`
machine_platform=`uname -p`
if [ "${os_version:0:1}" == "6" ];then
    executable="none"
elif [ "${machine_platform}" == "i386" ];then
    executable="osx-intel"
else
    executable="none"
fi

if [ "$executable" == "none" ]; then
    echo "The current OS X version is not supported"
    exit 1
fi
            
        
if [ "${1}" == --help ] || [ "`id -u 2>/dev/null`" == "0" ];then
    "`dirname \"${0}\"`/$executable" "$@"
else
    "`dirname \"${0}\"`/SPAM" $executable "$@"
fi
                

If I modify this to be:

..
elif [ "${machine_platform}" == "i386" ];then
    executable="osx-intel"
else
    executable="osx-intel"
fi
..

The behavior is the same when I run this shell script in terminal (script replies with "Bad CPU type in executable").

Has anyone else encountered this type of compatibility issue? Any suggestions or tips would be very much appreciated.

Thanks,

[Tim Holloway]

I'd be really worried about using this outfit's products. They support IE, but not Edge? WARNING! WARNING! WARNING! Someone's not maintaining technological currency. IE is dead, dead, dead and Microsoft wants you to know, that in fact, IE is dead.

Also, the link to download for Linux 64-bit is a Windows ".exe" file. Nope. Don't think so.

They seem to be providing native Java classes for their target OS's. That's worrisome because native code classes are inherently NOT "write once/run anywhere". And that includes on differing releases of their host OS, much less different processor models.

It would have been far better if they had provided custom USB drivers for the target OS's themselves than supplying Java native code classes. For one thing, it would have given them a larger market share for less effort as the same drivers, when implementing a well-designed text or binary data protocol (for example, AT-code control). Such a driver could support Java, .Net, Python, all from the same driver.

As it is, if they provide source code, I'm afraid that your choices are to port that code to your latest MacOS or petition them to do so for you (which I'd have more hope for if their apparent software support wasn't already flashing warning signals). If they don't provide source code and won't provide an upgrade, you're stuck with holding onto your old systems until they die or looking for a more flexible product.

[Simon McNamara]

Thanks Tim, I am worried!

From my very limited knowledge of software engineering (I really only know java and some python), I keep thinking back to how the installer might be handling CPU architecture.

First, I'll note something I forgot to mention in my first post. The name of the installer is "OmniDriverSPAM-2.682-macosx32-installer.app". If this is intended for 32-bit intel-based Macs only, perhaps I'm SOL since MacOS ditched 32 bit support. I don't know if this will work with any Frankenstein compatibility layer out there. Maybe someone can set me straight.

Second, I wonder if there is a meaningful way to change the script "installbuilder.sh" so this thing will run. As I mentioned, the application doesn't even launch. The full contents is:

#!/bin/sh

os_version=`uname -r`
machine_platform=`uname -p`
if [ "${os_version:0:1}" == "6" ];then
    executable="none"
elif [ "${machine_platform}" == "i386" ];then
    executable="osx-intel"
else
    executable="none"
fi

if [ "$executable" == "none" ]; then
    echo "The current OS X version is not supported"
    exit 1
fi
            
if [ "${1}" == --help ] || [ "`id -u 2>/dev/null`" == "0" ];then
    "`dirname \"${0}\"`/$executable" "$@"
else
    "`dirname \"${0}\"`/OmniDriverSPAM" $executable "$@"
fi           

So if the host computer is

"${machine_platform}" == "i386"

then

executable="osx-intel"

But there is no call out for arm architecture.

Even if I could unpack this on a 32-bit i386 mac, would it be possible to know into which directories the dylibs should go on my MacOS M1 machine? Does the suggested 32-bit name make this installer totally useless no matter what? Will those dylibs be build for 32-bit operation only?

Thanks,

[Tim Holloway]

I am not at all optimistic. Even ARM systems like Raspberry Pi are beginning to drop 32-bit operations these days. I wish I could offer more help, but that's the problem with closed-source close-to-the-vest technology.

I've a perfectly good pair of PaperPort Vx document scanners. They stopped working when Windows 95 stopped working because they did weird things with the serial-port flow-control lines and had no documented data or control formats. Perfectly good units if all you needed was a compact desktop monochrome single-side manual feed scanner. But stuffed now in the back of a closet. These days I have a Brother scanner which I like, after going through HP (why do they always have at least one set of non-replaceable rollers in their devices?) and a Fujitsu (their non-replaceable feed rollers turn to sticky goo after a few years).