Porting RM libraries to Mac OS X

[alex750]

I've been having problems getting RM 1.99b to work in Windows. It runs just fine in Linux (Ubuntu 10.04) and on the Mac (OS X 10.6.4), so the problem isn't a corrupted download.

I suspected something was amiss when I double-clicked the Setup.vbs and got the following (in a "Windows Script Host" alert box):

Code: Select all

Script:  C:\Program Files\JP1\rm199b\Setup.vbs
Line:    37
Char:    1
Error:   Invalid root in registry key "HKCR\jar_auto_file\shell\open\command\"
Code:    80070002
Source:  WshShell.RegRead

I can run RM via the command line, so I may just create a couple of .bat files and link the icons to those instead, so I don't have to open a command prompt every time.

I'm guessing the real problem may be with some of my anti-spyware programs (particularly Spybot-SD); I've never been able to run RM by double-clicking on RemoteMaster.jar either...the result in that case is always a Spybot alert box stating "Nothing found"!

[gfb107]

Replace your Setup.vbs with this test version of Setup.vbs and try again.

[gfb107]

Any luck?

[alex750]

Any luck?

Sorry for the delay...Works just fine, thank you. No problems from Spybot, either. Granted, I've also updated Java to 6.21...

Off topic: Since FTDI has a driver for Mac OS X, and RM (and RMIR) run just fine there, is anyone game for porting DecodeIR--the sole remaining piece needed for IR functionality, AFAIK--to the Mac? (One would also need Tommy's JP1.x cable and JP1.x-to-JP1 adapter, since Delcom's Mac driver has apparently been removed, no Mac since the now-ancient Beige G3 models has a serial port, and, apart from some of-historic-interest-only custom configurations, no Mac has ever had a parallel port.)

[gfb107]

Glad to hear the new Setup.vbs has resolved your issues. It'll be rolled into the next release.

As for OS X support, we need help. The first thing we need is for someone to copy'n'paste the contents of RMIR's Help > About dialog into a post.

You say RMIR runs fine on OS X, but does that include up/downloading? Have you installed the FTDI driver for OS X?

I've read that there's a chance the Linux builds of DecodeIR and possibly even the JP1.X interface code will work on OS X.

[alex750]

You say RMIR runs fine on OS X, but does that include up/downloading? Have you installed the FTDI driver for OS X?

"Runs fine in OS X" means that RMIR will load, edit and save IR files, and of course also load, edit and save RM/KM upgrades and add them to (or remove them from) RMIR. Also, the edited IR files can then be moved back into my Windows VM (or a real Windows PC), opened in RMIR (or IR), and uploaded into a remote. I haven't installed the FTDI driver, since I don't have Tommy's cable and adapter (both my remotes, a URC-6800 and URC-8910, are EEPROM-based, so I would need both). I'm using the Delcom cable.

From what I've seen, Tommy's stuff is slick, and a single solution for JP1 and JP1.x would be nice, but $50 is a little beyond my means at the moment.

I've read that there's a chance the Linux builds of DecodeIR and possibly even the JP1.X interface code will work on OS X.

In that case, all we need is someone with an Intel Mac and the cable for testing. (Ideally, this person would also have Windows or Linux, in case his/her remote's contents got mangled and needed a restore.)

Porting to the Mac is complicated by the fact of two--no, three architectures: PowerPC (the old G3/G4/G5 boxes; these run earlier versions of OS X, from 10.2.8 "Jaguar" to 10.5.8 "Leopard"), 32-bit x86 (the very first Intel Macs, using Core Solo/Duo; these can run the current "Snow Leopard," albeit in 32-bit mode), and 64-bit x86 (aka amd64; all current Macs, starting with the Core2 Duo-based machines). The 64-bit machines can use 32-bit drivers and libraries, but must be booted in 32-bit mode to do so.

The good news is, since the Linux libraries are already available in both 32- and 64-bit flavors, that part is done...assuming they will work at all. (PPC Macs would be SOL here.) I don't know if the FTDI driver is "universal" or not; if so (or if separate 32- and 64- bit versions are included), then that hurdle is cleared as well.

[gfb107]

OK.

You could test if the linux DecodeIR works under RMIR on OS X, which would answer a lot of question.

Again, the first thing is to post what is displayed in RMIR's Help > About panel.

[alex750]

As stated above, in Snow Leopard, RMIR will run OK, edit IR files, etc., but no interfaces are available in the "Remote" menu, and the "upload" and "download" buttons are grayed out. Here's what the About Box shows:

RemoteMaster v1.99b

Written primarily by Greg Bush, now accepting donations at
http://sourceforge.net/donate/index.php?user_id=735638

RDFs loaded from /Users/(redacted)/RemoteMaster/rdfs

Images and Maps loaded from /Users/(redacted)/RemoteMaster/maps

DecodeIR is not available!

System Properties:
•java.version = "1.6.0_20"
•java.vendor = "Apple Inc."
•os.name = "Mac OS X"
•os.arch = "x86_64"

Libraries loaded from /Users/(redacted)/RemoteMaster/Mac OS X-x86_64

I took a look at the rmaster.err file; from it, I surmised that (a) RMIR wanted to use the 64-bit libraries, (b) it expected to find them in a folder called "Mac OS X-x86_64", and (c) it expected them to have an extension of ".jnilib". I changed the file and folder names accordingly, and re-ran RMIR. Here's what I found at the end of rmaster.err:

Code: Select all

libraryFolder=/Users/(redacted)/RemoteMaster/Mac OS X-x86_64
Loading /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp1parallel.jnilib
Unable to create JP1Parallel object: /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp1parallel.jnilib:  no suitable image found.  Did find:  /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp1parallel.jnilib: unknown file type, first eight bytes: 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00
Loading /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp12serial.jnilib
Unable to create JP12Serial object: /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp12serial.jnilib:  no suitable image found.  Did find:  /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp12serial.jnilib: unknown file type, first eight bytes: 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00
Loading /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp1usb.jnilib
Unable to create JP1USB object: Can't load library: /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp1usb.jnilib
Loading /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libDecodeIR.jnilib
DecodeIR JNI interface not found!

Again, since Macs have no provision for a parallel port, the "libjp1parallel.jnilib" file would be unnecessary. OTOH, the Delcom-based interface would probably require writing a new driver from scratch.

If the source for the Linux libraries is available, would a simple recompile in OS X do the trick? I do have Xcode and the gcc/gcc++ suite installed, and could probably generate the 32- and 64-bit Intel (and possibly the PPC) binaries.

[gfb107]

Alright, we've learned some things.

I would start with try to compiling DecodeIR. The source is available here.

The reason I suggest DecodeIR is that to my knowledge it has no platform specific code in it all (such as port names and numbers).

[alex750]

Got the source code and took a look at it. Apart from the actual C++ files and their headers, a folder called "com" which contains some Java stuff (the glue code for RM, I'm guessing), and a Unix-style makefile, there were several files starting with "DecodeIR" of unknown purpose that, on further examination, turned out to be MS Visual C++ project files. I'm assuming these are unnecessary for our purpose.

Anyway, the makefile was as follows:

Code: Select all

NAME=DecodeIR
JAVA_INCLUDE=/usr/lib/jvm/java-6-sun/include
INCLUDES=-I$(JAVA_INCLUDE) -I$(JAVA_INCLUDE)/linux -Icom/hifiremote/decodeir

all:	lib$(NAME).so

clean:
	rm lib$(NAME).so

lib$(NAME).so:	$(NAME).cpp
	g++ -shared -fPIC -o $@ $(INCLUDES) $?

Here I ran into a snag. Mac OS X keeps its Java libraries elsewhere, which I discovered to be /System/Library/Frameworks/JavaVM.framework. In there are no fewer than seven symlinks, plus a directory called "Versions" with yet more symlinks--and one folder called "Current".

Chasing these symlinks, I found what I believed to be the proper paths, and edited the makefile accordingly:

Code: Select all

NAME=DecodeIR
JAVA_INCLUDE=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
INCLUDES=-I$(JAVA_INCLUDE)/include -I$(JAVA_INCLUDE)/lib -Icom/hifiremote/decodeir

all:	lib$(NAME).jnilib

clean:
	rm lib$(NAME).jnilib

lib$(NAME).jnilib:	$(NAME).cpp
	g++ -shared -fPIC -o $@ $(INCLUDES) $?

opened the Terminal, went to the DecodeIR source directory and ran "make". This was the result:

Code: Select all

g++ -shared -fPIC -o libDecodeIR.jnilib -I/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/include -I/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib -Icom/hifiremote/decodeir DecodeIR.cpp
In file included from DecodeIR.cpp:4:
StdAfx.h:17:21: error: windows.h: No such file or directory
StdAfx.h:18:20: error: crtdbg.h: No such file or directory
DecodeIR.cpp:16:21: error: JNIUtil.h: No such file or directory
In file included from DecodeIR.cpp:5:
DecodeIR.h:43: error: expected initializer before ‘DecodeIR’
DecodeIR.h:57: error: expected initializer before ‘ProtocolSupportLevel’
DecodeIR.h:59: error: expected initializer before ‘EnumerateProtocols’
DecodeIR.h:61: error: expected initializer before ‘Version’
DecodeIR.cpp:681: error: expected initializer before ‘compare’
DecodeIR.cpp: In member function ‘void Signal::decodeX(int)’:
DecodeIR.cpp:734: error: ‘_ASSERT’ was not declared in this scope
DecodeIR.cpp: In member function ‘void Signal::decodeX2(int)’:
DecodeIR.cpp:749: error: ‘_ASSERT’ was not declared in this scope
DecodeIR.cpp: In member function ‘int Signal::checkDecodeX(int, int, float, float, float)’:
DecodeIR.cpp:763: error: ‘_ASSERT’ was not declared in this scope
DecodeIR.cpp: In member function ‘int Signal::decodeRaw(int)’:
DecodeIR.cpp:791: error: ‘_ASSERT’ was not declared in this scope
DecodeIR.cpp: In member function ‘void Signal::tryGap()’:
DecodeIR.cpp:1089: error: ‘_ASSERT’ was not declared in this scope
DecodeIR.cpp: In member function ‘void Signal::tryTDC()’:
DecodeIR.cpp:3169: warning: format not a string literal and no format arguments
DecodeIR.cpp: At global scope:
DecodeIR.cpp:5302: error: ‘BOOL’ does not name a type
DecodeIR.cpp:5379: error: expected initializer before ‘EnumerateProtocols’
DecodeIR.cpp:5681: error: expected `}' at end of input
make: *** [libDecodeIR.jnilib] Error 1

Note that "windows.h" on line 4--what's the Mac equivalent of that?

EDIT: I've looked at the source files; it looks as if I'll need to add additional "ifdef" sections for Mac. Trouble is, I have no clue how to translate these.

[gfb107]

Generally speaking, OS X should be very similar to Linux for our needs.

You might be able to get away with changing all

#ifdef __linux
to
#ifndef _MSC_VER

and

#ifndef __linux
to
#ifdef _MSC_VER

[alex750]

You might be able to get away with changing all

#ifdef __linux
to
#ifndef _MSC_VER

and

#ifndef __linux
to
#ifdef _MSC_VER

Done. Re-ran "make", and actually got a finished libDecodeIR.jnilib, but with this warning:

Code: Select all

DecodeIR.cpp: In member function ‘void Signal::tryTDC()’:
DecodeIR.cpp:3169: warning: format not a string literal and no format arguments

When I ran RemoteMaster with the new library in place, I checked the about box...It now says "DecodeIR version 2.41", as it should.

Now, since I don't yet have libjp12serial.jnilib (or libjp1usb.jnilib!), how do I check to see if DecodeIR is working properly? Perhaps I could try cutting-and-pasting a raw EEPROM dump (from the "Raw" tab in IR.exe or RMIR) from Windows?

[gfb107]

Just open a .ir or .rmdu that contains learned signals possibly that you downloaded from a remote on your windows system and transferred to your Mac.

If you want to take the next step, the jp12serial source is available here

I doubt there will ever be a jp1usb library for any non-windows OS

[mathdon]

Done. Re-ran "make", and actually got a finished libDecodeIR.jnilib, but with this warning:

Code: Select all

DecodeIR.cpp: In member function ‘void Signal::tryTDC()’:
DecodeIR.cpp:3169: warning: format not a string literal and no format arguments

That line in DecodeIR calls sprintf but with only two arguments. This normally would be done with the second argument being a string literal, and the effect would be the same as strcpy. In this case the second argument is a conditional expression that evaluates to a string, which is equally valid. I think the warning is really suggesting that with only two arguments it would have been better to use strcpy instead of sprintf. This is true, it would have been better. I don't know why I used sprintf - I suspect that at some point I was doing things differently and did use format arguments instead of the long and complicated conditional expression it uses now.

Try replacing "sprintf" by "strcpy". Just that, without changing anything else in that statement. My guess is that the warning will disappear.

If it all works, I will want to make the necessary changes (including this one) in the master copy of the source file. Did you do anything other than what Greg suggested, and now mine as well?

[alex750]

Try replacing "sprintf" by "strcpy". Just that, without changing anything else in that statement. My guess is that the warning will disappear.

Done. It now compiles without error. Other than that, the changes suggested by gfb107, and the changes to the makefile noted above, only one other change was made to the makefile: an "-arch" option was added to the last line invoking gcc++, for compiling 32-bit Intel ("-arch i386") and PowerPC ("-arch ppc") versions on my 64-bit Intel ("-arch x86_64") MacBook.

I have tested DecodeIR with learned signals using the F12, JVC, NEC1 and NEC2 protocols, cross-checked with IR.exe. So far, so good.

The modified source is here.

The binaries (for all three architectures stated above) are here.

EDIT: Above link to binaries now points to current version, which includes jp12serial.