Setting up Fantom, getting a " ERROR: Cannot read registry: SOFTWARE\JavaSoft\Java Runtime Environment CurrentVersion " message when I try to run "fan -version".

I want to debug this and I see that in the source under launcher/java.cpp we use readRegistry( ... ) to find the key, but under dotnet.cpp we use RegOpenKeyEx( ... ). I know RegOpenKeyEx comes from Windows.h, but where does the readRegistry() function come from?

Its just a C function in util.c.

I think the new JREs are doing things differently, all that launcher crap is such a pain in the ass on Windows.

Ah I see now, Thanks. Just waiting for Visual Studios to finish downloading and I can tinker more.

So I got passed the readRegistry() problem, it was a matter of reading from a 64-bit registry, the fix was in RegOpenKeyEx. You just had to add another flag: |KEY_WOW64_64KEY. (I'll send you a diff If I get this working)

Also it might be worth mentioning I'm doing this with all 64-bit stuff.

My next error is interesting. First, it came back with Cannot Load Library: C:\..\Client\jvm.dll . Well I noticed in the new jdk's there is no \client\jvm.dll, there is only a server\jvm.dll. In sys\config.props I added java.jvm=..\server\jvm.dll, yet I still get the same error message (Cannot Load Library).

Any Ideas? I feel at this point it's some kind of permissions issue/ 64 bit issue.

So installed 32-bit jdk, and now it works fine (minus the missing msvcr71.dll but thats an easy fix)

Would really like to figure out whats going on with 64-bit jdk though.

Me too -- I've run into these same issues, but haven't figured it out. So far I don't actually need 64-bit, but would rather it worked -- we're using 64-bit windows server, so might as well be enabling the capacity from the start.

I'm not actually convinced that either Sun or Oracle have an actual copy of Windows -- I think they cross-compile from solaris and call it good; and JRE install has never been what you'd call well-done.

Maybe check what they do: https://github.com/poidasmith/winrun4j

https://github.com/poidasmith/winrun4j/blob/master/WinRun4J/src/java/VM.cpp

I think the whole idea of using a compiled exe to launch sucks. And we still have no good way to run Fantom as Windows Service. It is amazing how much Windows sucks in this department, especially with 32-bit vs 64-bit. As bad as Bash is, makes me appreciate how much better it is than Windows.

The avenue I wanted to explore was if we could create a new launcher infrastructure using PowerShell - my understanding is that should be on just about every version of Windows since XP. And I think it would give us the power we lack in Batch to handle proper setup and launch of both console, desktop, and daemon (Windows Service).

Is anybody up for exploring that option?

Are there any reason not to use winrun4j directly? The only difference is that it misses .Net support, but that can be added I think.

On a somewhat related subject, I've often thought it would be nice if their was a Fantom installer.

I was thinking a JNLP(fantom code wrapped as a standalone java webstart jar) could work well since we require java anyway. with fallback to java -jar for command line mode.

Basic idea is that it would:

• You just need java to run it
• ask you where is the jdk to use (default to the one used to run jnlp)
• it would ask you where you want to install fantom and extract it there and create proper lunch scripts
• setup permissions and the like (unixsetup)
• download and install proper swt jar for platform, extra pods etc...

Ideally that could be reused easily (build target) to create custom fantom app installers that would:

• Find existing fantom install or install new one if needed
• Install that app extra pods (maybe using fanr / repo)
• create init script if it's a server process
• maybe provide auto-updater (fanr)

and so on ....

I had actually wrote down "specs" and started a project shell for this but never got to it ;-)

@Brian I agree, I think we need a new Windows launcher. I might take a crack at it when I can find time during my break.

It was a pain trying to compile with cl.exe because for some reason the new include/lib/bin for the 2010 SDK wouldn't work. I had to roll back to .NET 2.0 SDK and VS 2008. But now that this is settled, the ability to make my own .exe's from my own pods the "right way" is pretty sweet. I think ironing out a new Window launcher to make this process more pleasant would be nice. (Maybe one that destroys that pesky console window as an option)

@tcolar Pre-compiled binaries are the bee's knees.

@KevinKelley I agree I'm not sure what's going on and where the inconsistencies are coming from. In theory the 64-bit's bin/server/jvm.dll should work because the only differences between the two seem to be coming from the way they are optimized. I'll try and tinker with this soon enough.

• 64-bit jvm.dll can be loaded only by 64-bit exe
• to avoid console window we also need separate exe (like java & javaw)

So, to cover all the cases 4 different exes are needed.

@Yliu I guess but then you have to maintain, update and test a bunch of binaries for several platforms and even different version of platforms which is a pita(as you juts proved) Also you even have to own such platforms to be able to build them.

If only "write once, run everywhere" had ever happened ;)

On the other hand I really think Fantom could use a proper installer, that's what that JNLP stuff was about ... or maybe leverage an existing java app installer that alreday does all the hard work.

Are there any reason not to use winrun4j directly?

Might be good idea. Not sure if license is compatible though.

What I want to avoid is having both 32-bit and 64-bit exe for every program like fan, fant, fanp, etc. That is why I was thinking a script format like PowerShell might be better and then allow people to tweak easily like bash script for Unix.

How about we resurrect the dotnet fantom runtime, and use that to build the launchers?

Using scripts to launch, whether bat or bash or even Powershell, is fine for developer tools and whatnot, but it doesn't seem to me like it's a good delivery mechanism for products. On unix, scripts can be marked executable and will thereafter show up as such, but on windows, all you see in task-manager (for example) is "cmd" or "java", or whatever the actual executable file is named, rather than the actual name of the application. So, being able (with fantom) to easily build an actual executable file, is good. Of course you also want to be able to compile in its icon and splash screen and so on, its set of runtime resources.

I don't know how up-to-date fantom's dotnet runtime is; I think it hasn't got any attention for quite a while, but it's still there, and probably ought to work.

All the 32- vs. 64-bit issues on windows, that I know of, come down to native-code. As long as you're in managed code, that doesn't matter -- problems come from drivers being JNI wrappers around native code; and from the launcher being native code. I don't think we should perpetuate the problem; far as I know, all the stuff we actually write could perfectly well be portable. There's just the few basic core things (like sys, concurrent, and inet) that need runtime support, and those things seem to already exist, if maybe not well-exercised.

So... @Brian, do you know any show-stoppers? Maybe for production system (like skyspark) we need to be running on a consistent JVM platform, but even there, does it make sense to build a launcher using fantom.net, rather than C++?

I've had enough of headaches from cross-platform and native issues; I'd really like to be able to write code in a minimum number of languages, and be able to easily target a stable, self-contained, installable, deliverable.

winrun4j looks like a pretty good, complete, solution for making executable wrappers around JVM products; and it's under the CPL. It uses the same pre-compiled, configurable launcher exe method, as Apache Procrun (which I've used) does. Seems like winrun4j's launcher is built in Delphi; Procrun's is C. I don't know if we even need that, though, if fantom.net could already do basically the same thing.

Inno Setup looks like a good, open-source way to build an installer. Here again there's a lot of options and complexity, and I find myself wishing for a single simple way to build portable programs.

Kevin, I think you are talking about the same Fantom installer / application bundler I was talking about. I've thought there is a need there for a long time.

I also agree that ideally it should be 99% Fantom code. However I don't really see how fantom.net would help there because it's still not going to build you a binary launcher. That one has to be done natively to the platform, wether it's custom made or one of the things you proposed(winRun4J etc...).

Personally I would rather see a small windows exe, just a fantom launcher nothing more, and everything else (installer/bundler tool) all in Fantom.

If somebody does the windows Fantom launcher part, I'm willing to work on the rest, I was thinking about it anyway.

Okay, I'm in and out with holiday stuff or I'd be done already, but I'll work on the launcher idea I've got. I think mostly the pieces are already there, just that the system needs a little love on the windows side.

So do I take it that, as of this moment, Fantom 1.0.64 is goosed on Win 64-bit?

Or is there a workaround I can use in the mean time?

Steve.

Oh, and Happy New Year!

I'm working on this, the launcher-on-windows thing. Holiday stuff and moving my office has slowed me down... expect to have something useful shortly though.

What I want to do -- and I think it'll work okay -- is to get rid of the C code entirely from the src/launcher/ directory. It's only apparently used on Windows, and these days there's always going to be some level of .NET pre-installed on any Windows system I'm likely to care about. (Win7 and Win2008r2 both come with .NET 3.5, and older systems can get there from windows update).

So to me it makes sense to write the launchers in managed-code. It'll be a lot easier to keep them up to date -- no longer will need a whole C compiler install just to build a little launcher executable. Wouldn't even need a Visual Studio install at all -- the dotnet runtime has the compiler built in, so we could avoid a whole lot of setup issues.

Next issue is finding a usable Java installation -- there's a stackoverflow discussion about that, and it seems there's half a dozen standard registry locations that need to be checked -- taking into account the "normal" registry, and the SysWoW3264 thing (a mirror registry for 32-bit windows apps running on 64bit windows); and the fact that a "registered" jre may have been moved.

Also there's the Windows Service issue -- again a registry thing, but requires that there be an actual invokable executable...

More later. Happy holidays all. (I realize I didn't answer the question)

Was any progress made on this ?

Hey, yes, the concept seems fine, my idea of using a little C# launcher program, that finds the JVM from registry keys and runs 64-bit if available.

I can compile it for "anycpu", and the exe should then run anywhere; so no need for separate 32-bit and 64-bit launchers. I haven't tested on other systems yet, but I can verify that on 64bit windows 7, launcher compiled for anycpu, it does execute the 64 bit JRE, no problem.

I got a little bit bogged down in the fan-substitutes stuff, which needs to be dealt with before the official launchers could be replaced... mostly because I'm not real happy about how that works. Should stick to one thing at a time, I guess...

Is there an estimated completion date for the Windows build?

If you just want to run Fantom on a Win 64 bit machine, delete (or rename) %FAN_HOME%/bin/fan.exe and replace it with %FAN_HOME%/bin/fan.cmd:

@java -cp %FAN_HOME%\lib\java\sys.jar fanx.tools.Fan %*

I do have a patch to switch to batch files, but in order to switch over I need to spend some serious time getting bootstrap to work that way (freaking pain in the ass)