• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

USB driver compatability for Apple M1, Java, and beyond

 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:



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:



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:



If I modify this to be:



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,
 
Saloon Keeper
Posts: 27919
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:



So if the host computer is

then



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
Saloon Keeper
Posts: 27919
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
 
reply
    Bookmark Topic Watch Topic
  • New Topic