RomRaider

RomRaider will only run with a 32-bit JRE. The same applies to the installer, at least at present, but even if that gets solved, it only delays the inevitable: failure of RomRaider to operate correctly.

The Problem:

The issue here is the libraries. The libraries are pretty old. In fact, they're unchanged since my initial involvement with this project (Enginuity, at the time). The Windows DLLs and Linux SOs are all 32-bit. The 32-bit JVM runs is a 32-bit process, which can load these libraries. The 64-bit JVM is a 64-bit process, which is not permitted to load 32-bit libraries.

Even the installer fails for the same reason, at least on Windows. It's configured to use the 32-bit DLL that is needed for creating shortcuts. There is a 64-bit version parallel to it, but even ifinstallation can be made to work, RomRaider woiuld be installed in an an environment where it can't run. I haven't investigated that too far, but I think it would start up and look normal, but fail to connect at all to the serial ports. That matches the report here.

Solutions:

The most comprehensive solution is to bundle the JRE needed with the product. This would bloat RomRaider significantly. I haven't tallied up the required files for the JRE, but my initial estimate is probably 90MB. The current RomRaider package is about 18MB. This seems so disproportionate that I don't see this as a good solution.

Next, it would be possible to extend the installer software (another open source project) to detect the bitness of the JVM. The same logic used there should also be put in the intialization of RomRaider itself, in case someone installs from a zip file or similar. The effort here is more than trivial, although not major. One potential problem is that there may be variations of the architecture string returned by the JVM that would complicate the detection or cause it to fail.

The easiest solution is to put the incompatibility information more in the user's face. The release notes panel in the installer could have clear text near the top that describes this, and perhaps points to a URL here. Alternately, an additional message panel (the two right now are license and release notes) that states *only* this information (big, blinking red letters are possible, but probably a bit heavy-handed) could be added.

Comments? Additional ideas?

Checking 32/64 in a JVM is indeed trivial. The trouble with the libs is that they're likely loading from a static context, which means your static calls have to trump theirs in load order, which may or may not be easy/possible. Detecting it in the installer before the fatal shortcut plugin and just saying "no, sorry" is perfectly doable, though. Can you add another custom plugin for a panel that's first in line, something akin to maven enforcer, but in the installer? Likely most win users will be using the installer anyway, so that'll eliminate 90% of the problems straight up. You'd hope the other 10% will have the brains to figure it out :-)

The check is simple enough, but the most common method is to check the value of os.arch in use by the JVM. It's not clear to me that all JVMs will use the same convention, but I suppose it's a reasonably safe assumption to expect a Sun (Oracle) JRE. In the old days, IBM had one that was faster, but I'm not sure it's maintained any longer.

Certainly the easiest path is to avoid custom code. Currently, everything is done using standard panels. If we add custom code, that needs to be reconciled and perhaps ported to each upgrade of the base tool. I've been through that before (I customized bugzilla and then had to maintain it - thankfully, bugzilla finally added the features I'd wanted and I then only had to port our database to the new form) and would like to avoid it.

In the case of IzPack, they've been working on a major release for some time, and I'd like to at least get through with an interim measure until it's out. A custom panel would subclass their base panel. That might not change but then again, it might. I tried the beta of 5.0 and found (and filed) bugs that were indicative of under-the-covers refactoring.

The two options I see best for here and now are amending the readme to make this issue more prominent, or adding another info panel dedicated solely to it.

While I haven't stepped through any of this in a debugger, but I don't think it's an issue with static context. I think it's a simple matter of a 64-bit process being unable to load a 32-bit DLL. The Java code makes native calls through JNI, and the JVM itself loads the native libraries as needed. The Java code is calling Java methods, the native library is getting native calls. The go-between is the JVM itself, and if it can't load the library, it all falls flat on its face. The error may not even make it back to the Java caller.

I'd say that this, though true in the context mentioned, isn't generally true:

A simple and effective strategy for the time being could use this: http://izpack.org/documentation/panels. ... ocesspanel

Simply setup a class to do the check, and return silently if happy, and pop up a dialog with button "exit" appropriate message and "exit" attached to System.exit();


Waiting for releases is a bad idea. Always live in the now.


Sure, but updating such a thing for a new structure should fall into the category of "trivial". However I'd say it's not necessary.


A new info panel is a good idea :-) I doubt the readme would help much, though.


The .dll/.so has to be unpacked to disk before it can be used, this is done manually by the lib in question before use, not automatically by the system. Some do checks and complain/die at this point.

Fred.

I considered that. Such a class should be in the RomRaider code itself so that the logger and editor can use it in the same fashion.



Hence my desire to do something now, just not something major.


Sure, but updating such a thing for a new structure should fall into the category of "trivial". However I'd say it's not necessary.



I think that's going to be easiest. Sadly, much of the time I thought I'd spend working on RomRaider has instead been spent upgrading all the tools necessary to do so.



I think you're missing my point here. It doesn't matter though. I've been through similar issues with our test harness and the easiest thing to do is to not do it. Mismatched bitness doesn't work.

I've updated the installer and launcher software and updated the installer itself.

I added a new panel that comes up first in the installation sequence. It displays a warning about the JRE requirements and points to the RomRaider Troubleshooting forum for further information.

I committed the updates to git, and have sent a PM to Dale so that they can be integrated into the main codeline.

Fixed. If it were, from what I understand from reading through that page, you'd have to install the class first, before executing it. Though I may have it muddled up. In any case, due to what I explained about binary libraries and load mechanisms, it won't be much use in the app itself as it'll never get a chance to run, maybe unless called from an anonymous static block before any real RR code got to run.

Worse, though, IF I read correctly, which I may not have: It would leave RR classes installed which might give the user the impression that they could work.

Assuming I read right: Better to copy a tiny standalone jar to tmp/, do the check, fail or install, done.


I think you might be missing mine, actually...


If you need some help, just say so ;-) https://github.com/RomRaider/RomRaider/network (it's not there)

Uber quick git howto:


This assumes that you cloned your own copy and your ssh keys are setup correctly and you're on the right branch, etc.

Fred.

I haven't used that panel before, so I'd want to test it first. It *does* document that it executes after installation, so I think it's probably less than ideal for this situation. I won't be pursuing that option at this time.

The problem is the same for both the installer and the application, so common code would be a preferable solution.

I have coded detection and notification into the application, although I'll want to research a bit more to be sure that the detection mechanism does not rely on a specific JVM. I also want to refactor it a bit, but I do have it working.


No, I get it. We're referring to different scopes here. I'm talking about a more fundamental problem. It still doesn't matter unless you intend to do the work.



I followed the setup instructions on the "Getting Started" page, but they seem to be much as they were long ago; a way to get set up to make modifications. They don't cover attempting to contribute.

I cloned from the master, as the instructions directed. I did not branch.

It looks like Dale was using Eclipse and had similar problems, so I PM'd him. The Eclipse integration is not the most intuitive, particularly if not familiar with the *git* way of doing things. Still, it's an IDE, and I'd like the "I" part of that to work.

I'm going to set up the command line tools now and see how that goes.

I didn't spot the "after" installation thing. You're likely right, my suggestion was no good at all.

Re 32/64, the "more fundamental problem" goes without saying.

Re git: You can do the same things from within eclipse :-)

Attempting to contribute instructions should roughly be:

setup github account (you already did this)
click fork on github RR page (you already did this some hours ago)
git clone your own fork of RR (unsure if you did this, if not, you can just tweak config, no need to reclone)
<ensure you're up to date with latest HEAD, get there if not>
<add unit tests for intended changes>
<make changes until all tests pass>
git add files (with or without an IDE)
git commit (with or without an IDE)
git push <remote> <refspec>:<refspec> (or less explicitly, depending on what you did before this point)
<recheck latest HEAD, rebase if not current>
<send pull request and/or pm and/or email and/or forum post>

If Dale feels like it, he could add a bit of copy like the above on how to get your changes back in.

Fred.

The command line utils worked. They always do

Yes, I should be able to do this from within Eclipse, but it's not immediately clear what's wrong. I have my suspicions, and will look into them later.

I'm now going to look at refining the arch detection in ECUExec. A few years back I added code to dump the environment to the log file for debugging and support. I think that's the best place to detect, and bomb out if necessary - right after the log gets written, with an extra message indicating why we exited.

This is entirely unrelated to the installer. It applies only to the application itself.

It's simple to have ECUExec terminate if an incompatible JRE is detected, but is this *always* the right thing to do? Sure, it'll fail if any logging is attempted, but what about editing maps? Consider the following use case:

I use a laptop computer used for logging, reflashing etc. but would prefer to edit the maps more comfortably with my workstation. I never connect that to the car because it's in my office, high atop the luxurious RomRaider Tower, while my car is in the Bat Cave below, being detailed by my minions. Editing maps is possible with RomRaider running in a 64-bit JVM, but logging is not.

While we would like to prevent the user from attempting something that is doomed from the start, we may not want to prevent all use, as some functions are not dependent on the architecture of the JVM.

So, here are possibilities when RomRaider detects it is in a 64-bit JVM:

1) Bomb out immediately
2) Warn immediately, but let the user continue to attempt any usage
2) Warn immediately, bomb out when logger is started
3) Do nothing until logger starts, then bomb out

By "bomb out" I mean that RomRaider would display a message similar to the one attached, then exit.

Is a pull request though github preferred? It seems best to me, in that there is tracking with commentary.

If PM, then who has permission in the master repository to perform this operation?

If forum posts are preferable, a sticky thread in the Development subforum just for pull requests might be the best way to keep them from being lost or overlooked.

I'm currently favoring an "unsupported" warning on starting application, and an "incompatible" error (fatal) when the logger is invoked.

Up to the person involved. I prefer instant message/phone calls for mine :-)


Only Dale and I, though I don't actually do anything, as I don't feel that it's my place to. I'm unsure if he's receiving your pull requests. I did ask him, but he never answered me. It might pay to send the pull requests to his account instead of the RR one.


Not a bad idea, gives forum-level visibility to it. You could always do a github PR and then link it in such a thread. Then it doesn't matter that it's too the RR account, Dale will see it here regardless.

Hope that helps.

+1 on the warn at first, die with logger approach.

Fred.

If my job mandated that, I'd find another job

Systems should function without bothering me. It seems that since RomRaider has moved to github, and is using the issue tracking there, a single point of maintenance (one of my favorite mantras) is preferable. I had commit privileges to the old Assembla repository and didn't need to bother anyone whenever I had changes, so this is a significant philosphical change.



I think it disingenuous to say you do nothing. You reviewed the pull requests I made previously and questioned me on them, but did pull them to the master. Thanks for that.

Perhaps it's best to wait until Dale returns from his New Year's holiday (I'm assuming that's why he's been away) and establish a uniform means of getting these processed.



Somewhat, but we still need the Gatekeeper to chime in. If everything must go through him, it's only fair to see what'll work best for him.



That seemed the best compromise. I filed an issue on this at github (I'm guessing that the Assembla issues are forgotten - perhaps not, but that's the safer assumption) and proposed the solution there. I've even coded it, but may wait for Dale to resurface before committing it. In any case, I'll sleep on it and see if it still seems a good idea after that.