Glucofacts and Linux... :-/

I’m new here in TuDiabetes :slight_smile:
I’m a happy Slackware Linux user, so there is a little part of a geek in me (enough to be a member of this group? :smiley: )

My question:
anybody managed to run Bayer’s Glucofacts software on Linux?
It’s a Java software but something makes it not working with Linux. :frowning:

Did you download the latest version? I know they just updated it recently. According to someone in Bayer…

The update, version 2.08.03, now available offers:

  • Additional compatibility* with Java version 17, 18, 19 and 20
  • Additional compatibility* with Mac OS® 10.6.3 (Snow Leopard)
  • Additional enhancements that improve functionality

I tried the Glucofacts version inside the Contour USB meter…

I try to download the update now. Thank you

No, it doesn’t work correctly…

The main problem is now:

"This software has detected a meter already connected to this computer, please unplug the first meter and reconnect the 2nd.

Your Contour USB meter will be put in charge only mode"

This is what I get trying to launch Glucofacts.jar (first I installed the .exe with Wine and then I ran Glucofacts.jar with java). The same if I unplug the meter.

I can’t even get the software to try it out… If someone could send it to me I could try it out, I am somehow a java geek…


P.S.: There is no Java 17, 18, 19 or 20.

I just got a Contour USB and tried to get Glucofacts working under Linux, and have run into several problems. Hopefully, someone here has some ideas about how to fix it…

  1. Even though it’s Java, it appears to have some Win/Mac-specific DLLs for talking to the meter, and as a result won’t work natively unless we can get Bayer to provide a Linux binary for it :frowning:
  2. From what I’ve seen elsewhere, the directory name “GLUCOFACTS Deluxe” is hardcoded all over the place, and the space in the dir name isn’t handled properly on Linux. Not sure why it’s not, but it could definitely be a problem.
  3. I can get it to run under WINE, but only after I manually figured out what environment variables were set on my Windows VM (where I currently have it running) and created my own batch file to launch the software. However, it says “Ports in use” and doesn’t see the monitor.
  4. At least on my distro (Fedora 13), the device shows up as /dev/usb/hiddev0, which I’m not sure how to handle making this appear properly to WINE so Glucofacts can see it. I tried setting com1=/dev/usb/hiddev0, but that didn’t do anything (nor did I really expect it).

Any ideas? TIA for any and all assistance.

Now lets get some things clear…

  1. If it is written in Java, this doesn’t mean it can run anywhere… Application must be tagged as 100% pure Java, to be able run everywhere. Problem is that JVM - Java Environment in which application is run is limited, it has for example no access to hardware devices directly, which mean it NEEDS libraries which are operating systems specific.
  2. Now this one is easy, bad programming… When using files in java one must be little cautious on how to create/access directories, in some cases this means converting paths from one format to another, we usually don-t use Windows paths (), but we use linux/unix/java paths (/), but they probably send a rookie to do this…

Since I haven’t seen the application yet (I was really busy last few weeks) I can’t say what could be problem, but there is probably native “dll” missing. This could be problem with your OS. Application might have x32 version of dll, which for example wouldn’t work if you have x64, or if you use kernel with very much different code. If we knew which library it is, we could for example rebuild dll file (which would be .so file in linux).

I am going to vacation now, but I will look at this application when I return (end of next week).
Take care,

Extracting Glucofacts.jar I found two libraries for linux:

Why these two files if Linux is not officially supported? -__-

(Enjoy your vacation Andy :wink: )

Andy, thanks for your reply. I’m quite aware of the limitations on Java and hardware access, but since I’m new here there’s no way you could have known that :slight_smile: I know what DLL is required to talk to the Contour USB (BayerHID00.dll), and since it’s available for both Mac and Windows, but it’s also the only one available for Mac, I’m assuming the other 2 Mac libraries (BMI.dll and BMI_jni.jnilib, known as BMI_jni.dll on Windows) are also required (all of this is located in the ‘dcf’ directory tree, which has Mac and WIn dir, with 32- and 64-bit subdirs). So unless we can get Bayer to provide Linux .so libraries, this may require a ‘clean room’ reverse-engineering effort, which is well beyond my ability to lead though I’m willing to help if I can (I’m a Linux sysadmin, so I can dabble in programming but it’s not my specialty).

As to the directory name space issue, I know about the conventions, but since it works on a Mac that’s why I don’t know why it doesn’t on Linux - after all, OSX is essentially a *NIX variant under the hood… Once you get back and take a look at it, if there’s anything I can do to help you with either testing or data-gathering, let me know. FYI, I downloaded the full install version 2.07.02, in case it matters…

Thanks for the response!

Ok. I am back and I have taken a look at this software…

Bayer decided to go with solution to create dll (library) for each meter (or group of meters), which is pretty thoughtless thing to do. When creating your own libraries you automatically limit your users to use whatever you give them. Now most of older Bayer devices can be read through serial port access, which is what I did in my diabetes application GGC (I am using java). So for example to support application (reading of serial device) I just need to supply library to end users (or they can even build it themselves) and thats it… They will now need to port their libraries to all OSes…

I am not familiar with this new meters Contour USB, Diget, which might be required to use just this library in order to access data, but for old devices more commonly used serial library could be used (I use rxtx serial api library, since it’s most widely used at this time).

Now most immediate solution would be to ask people at bayer to make this .so files for “us”. Out of diabetes companies making meters, they are the most reasonable bunch…

As for reverse engineering, I am afraid it is almost impossible to RI .dll files. I have no problem to get java files from class ones, but .dll is binary, which makes RI much harder.

Directory namespace could be problem, because of bug in code. If they treated Mac separately and Linux and Windows together, this could be problem… Linux should be treated as Mac (at least file system wise).


You say Bayer is the most reasonable - do you have any idea who to contact to request .so libraries for Linux? I would be happy to do so, and work with them to get Linux supported at least for the new USB models, but I’m not sure where to start that won’t just toss me into an endless loop of tech support people who tell me that Linux isn’t supported and I should use something else…

Thanks for looking into this. There probably is a way to reverse-engineer it, but I never said it would be easy, and I’m not the person to do it so I can’t say much more than that anyway…

No… In old times I usually found an email address and send my request there… When I was trying to get comunication protocols for meters. I have sent them an email yesterday, to see if they could supply me with new protocols for Didget and Contour USB, no answer so far…

But since we have .lib files, maybe we just need to link them and make .so file, but we are missing a few I think. I talked to gib yesterday, and error report he sent me shows that his application tried to load native library for BMI and failed. I have to try this on my machine (I use Ubuntu x64) which I will do over weekend.

Take care for now,

I suspect that the .lib files don’t actually handle the meter communication, since there’s a BMI dll and a dll per meter type. But I’m just a sysadmin, not a programmer (and I have -zero- Java experience), so we’re starting to get over my head here :slight_smile:

Problem is that software uses a lot of native libraries (I mean native as c native), and not all of them are available for all platforms... I good case scenario this shouldn't matter much, but since programmers were not that good, now this poses problem... You might have problems with getting data from Contour USB, because access to that device needs a lot of native libraries...

Programmers took a shortcut. Instead of making 100% pure java application they made application that uses a lot of native code, which makes problems for non-windows people... Since I haven't got my hands on CU to test it myself I am not 100% sure... this might be problem with device itself... Maybe device doesn't support any other access (USB devices can be problematic sometimes)...

As for file types. Libs are used for compiling, but at runtime you need .dll for windows, .so for linux and .dynlib for Mac (not sure about last one)... Lib file could be used to create such library, I am just not sure how exactly.