There are a lot of things that came up. Like the link error that arises if you use the precompiled xfree86 libs - _ctype_ or something like that. Which I worked around by compiling my own, which in turn revealed a compile problem having to do with some variables mis-typed as HINSTANCE rather than HANDLE (or vice versa - I don't recall right now) in several junk.c files in the xfree86 source tree. I also used the dx.c executable rather than hacked versions of the dx and dxworker scripts.
Greg Suhaib Siddiqi <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 11/28/2000 01:55:12 PM Please respond to [email protected] Sent by: [EMAIL PROTECTED] To: "'[email protected]'" <[email protected]> cc: Subject: RE: [opendx-users] Proposed - A new Windows binary (was: Importin g data in OpenDX) Greg, What are those tid bits you used for installing? Would you mind emailing me directly? I cannot promise anything before the mid of January. I will be on vacations for whole december then had a surgery for cyst planned for the first week of January. If it is an integration issue with Xceed, then it might become more trouble some because Exceed 7.0 had a completely different user directory area and registry entries - bummber-- also full of 1000s of bugs. Suhaib > -----Original Message----- > From: Gregory D Abram [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 28, 2000 1:05 PM > To: [email protected] > Subject: [opendx-users] Proposed - A new Windows binary (was: > Importing > data in OpenDX) > > > > After reading your note, rather than Lloyd's followup, it > looks like we're > missing the point. The real problem is that OpenDX is simply > not working > right. > Whats really going on here is this. When you use the Import > Data... button > on that little startup menu, the prompter starts, gathers > some info, then > starts DX in editor mode with a very simple default network. > The DX VPE > (dxui.exe) runs as a separate process from the initial > startup UI run, run > via the DXLink interface. The DX VPE, in turn, starts the DX exec > (dxexec.exe), which is the workhorse that does the bulk of the data > processing, then tries to link to it via a socket. Thats > whats not working > - the VPE is waiting for the exec to start and do a little > handshake, and > its not. > > Of course, the interesting question really is why not, and > thats not easy > to figure out. It depends on OpenDX being installed correctly. That > includes the values of various environment variables, maybe > the registry, > and the directory structure of the OpenDX files. > Unfortunately, this is > being set up for you by the binary you downloaded, which may > in fact not be > correct. Typically these binaries are created by helpful > participants and > made available, but without adequate testing or sufficient > generality to > cover all the cases that can be found on end-user's machines. > Windows is > certainly the most difficult platform to get this right on, > and people have > had lots of problems. > > Good news is that I have a binary version here that I've put > on a bunch of > machines around our lab in various states of Windows versions > and software > installs. It installs with InstallShield just like a "real" > Windows app. > It has netcdf, cdf, hdf, ImageMagick and JavaDX support. > > Bad news is that, for sound legal reasons, I can't distribute > it outside of > IBM. Of course, I can share all the little bits of magic I > had to figure > out along the way, so I was wondering - anyone out there want > to team up to > create a new possibly definitive Windows binary? > > Greg >
