RomRaider

Both. The Logger is the heaviest user of 32bit libraries. The primary of which is RXTX which provides the interface between Java and the OS serial ports. Most all logging plugins use serial ports to access data from the external devices, so the desire to exit the Logger if you execute the Logger on a 64bit system is to avoid issues the user will experience when the serial ports won't show up. This also applies to the primary ECU connection interface, typically a FTDI based device (VAG-COM & Tactrix 1.x cable) which shows up as a virtual COM port on Windows or a USBtty on Linux. Again, this requires RXTX.
If you are not using an FTDI cable then you probably use a Tactrix Openport 2.0, which is Windows only as far as I know.


I implemented JNA to interface with the Openport 2.0 native .dll on Windows.
I have some highly experiment code which interfaces with the FTDI.dll or libfdti.so. I'm far from being ready to commit it though. And it doesn't get around the fact that people will use non-FDTI (Silicon Labs and Prolific) serial-USB cables.

As for Mac OS. There is a thread here somewhere detailing the steps to get a secondary sourced 64bit version of RXTX running. I'd like to investigate using it also with 64bit Windows systems. We'll have to expand the build system to create architecture dependent distributions for the users to install. I think we'd end up with:

• Window x86
• Windows amd64
• Linux X86
• Linux amd64
• Mac (would this be 64 bit only?)

I'd like to suggest a repo directory structure like this for the arch dependent libraries.



We have the source so we *maybe* be able to port it, or possibly replace it???

OK, fair enough, then.

About Mac, mine is 10.6.7 and:



So yes, probably 64 only, I guess. No point supporting the old stuff, really.

About this:


I'd like to suggest that there are no libraries in the repo at all! :-) But...

That's not difficult. The different file packs need to be defined, but it's relatively straightforward if the same installation technology is maintained. If something Mac-specific is required (such as a dmg with drag-to-install built in) then it becomes more complicated, in that it would likely require a Mac to build the Mac distribution.



But what? You're free to clone the repository, code this yourself, and then present it to the RomRaider Dev Team. The Team may (but is not obliglated to) accept the submission for inclusion in the product.

I'm currently working on testing the x86 & amd64, installer & standalone builds to see if it all works out correctly.
Then I'll test them on my x86 and amd64 systems to make sure they install properly.
Then test them to make sure the plugins load and can communicate with the ECU.

If it works, I'll submit changes in small batches so nothing is broken during structure migration. If not then we'll have some work to do to make amd64 viable.

I now see two reports of installation/operation problems on Win8, so another problem to tackle.

I saw the one Win8 report, but never got answers to my questions about it. I'll look for the other. I haven't got Win8 at home, but we've got a few variations in the test bed at work that I could check out. I wouldn't want to install any drivers and they're 24 floors above any cars, but I could at least check out installer issues.

That would be a start at least, thanks.

I've got some VMs running Win8 and we're setting up some physical machines with 32-bit and 64-bit Win8 as well. There are some techincal issues that mean VMs are not good enough for everythign we need to do. That means that we should have a variety of hosts available soon.

Since the installer only adds files, but doesn't muck with the registry, I can do some installer testing without corrupting my dev and test machines. Hopefully, we'll get some more information in one or both of those threads so we can narow things down with minimal wasted effort.

I see Win 8 Pro is available for $40 till the end of Jan/2013. I'll just get a copy of 32bit and that will allow me to test going forward. I think in the last few years I've spent well over $2,000 in test gear (donations, software, ECUs, WBO2 hardware, etc.) to do RomRaider testing and dev work with, another $40 won't matter much.
Oh and my time...

And much appreciated - I hope some of it has come back in donations. I'm not sure if everybody appreciates how time consuming this stuff is...

...you already knew that.



ADMIN: edited content << This is a joke.

I really hope you are not going to do that until we've had a change to review the work you've done and we can make sure it will provide the distributions that our users want and need.

Put it up on a branch or completely separate repo first please.

I certainly will do that provided that it doesn't break anything in the process, which it simply can't... Stop making so many gross assumptions about what "doing that" might actually be, or not.

And thanks for the board warning :-) I hope you fired one off to the reptile too. If his totalitarian attitude didn't overflow into the forum there would be nothing to reply to. Keep that in mind.

Fred.

Thanks

Is it possible that a declaration can be made regarding "official" development tools at the current time? I can understand the frustration of returning to a project to see one's contributions and methods lose relevancy to newer methods, but the direction I'm seeing RomRaider (continue) to take looks positive from the development standpoint. I've maintained SVN servers and repos for years and readily dismiss it in favor of Git, an all around superior revisioning system that all the younger developers I encounter are completely entrenched in. Also, Maven and Eclipse are extremely powerful tools with a healthy backing--the former making library dependency handling a breeze without clogging up the repo. Supporting modern development tools that are likely to attract up and coming developers is a complete win in my book at staying relevant and progressive. So if we're mostly happy with the tools being used right now, perhaps a formal statement can be made about what's preferred for core development?

This is off-topic, I realize, but I think a thread regarding tools and necessary debates/changes would be best started by a lead dev.


-Jeff

There are this and this already. If another thread is required, OK, though I don't see the need?