Greg, > Yes, I'll commit to a commit. This is certainly the sort of thing I'm > eager to get in there. I wonder - is this only SGI, or all SMP-supported > platforms? > > By way of explaining myself, I've been working on a fairly large change to > make the GNU-based builds work with the MSVC compiler on Windows. I'm > doing this for two reasons. First, it makes it possible to develop OpenDX > under MSVC, for those that are more comfortable in that environment.
I could not get your current wrappers working under my Cygwin environment. Have you looked into ImageMagick 5.2.0 configure code? It does a very nice job of creating MSVC project files, without going through the pain of hacking wrappers. The source code for "configure.exe" in Image Magick 5.2 has ImageMagick sources directories hard coded. It can be, with a little efforts, tweaked to create MSVC project files for OpenDX too. I ended up creating dxconfig.h and project files for MSVC by hand. It took several trial and errors, but I think now I have a very good dxconfig.h and project files for MSVC 6.0. I also did several modification to source code on top of what you have added for MSVC in CVS. One problem I was facing was, if dxsamples.tar.gz was decompressed using Winzip, DX on Windows complain about corrupted data files. I added a few binary compability stuff in DX. > Second, though, is the big one: that it will enable me to fold back in the > changes I've made to run the DX executive in native-windows mode. This is > a big step forward, IMHO, because it supports ActiveDX (which > will be going > into open source as soon as the native-OpenDX is in). ActiveDX, in turn, > makes it possible to develop Windows applications that incorporate full > OpenDX functionality. > ActiveDX consists of a set of ActiveX components that are customized by > associating them with an OpenDX network, allowing you to create high-level > visualization components that can be used in any app that ActiveX > components are useful in - MSVC apps, Visual Basic... ActiveDX would be a great help for Windows users. If I understand correctly, users will still need MOTIF based UI (DXUI etc)? One of the other thing I am very interested is in BXDX for Linux from you. I might help DX community with some add-on package for DX using BX? > > While this has been going on, I haven't been too eager to incorporate > patches that involve changes to the configure/file header > structure. One > thing at a time. > > Believe me, I'm working hard on it. We know you had been working very hard to add new functionalities to OpenDX. >I suffered a bit of a setback when I > installed the newest Cygwin on my NT box - they seem to have messed up the > CRLF issues, making this a bit more painful than it should be. The good > news is that select() is working a whole lot better. That is because B20 was mounting files systems in "text" mode by default. Starting Cygwin v 1.0, the default mode was changed to "binary" for a better compability with Unices. If you had your files created under B20, they perhaps had \r\n at the end of lines. You either need to run them through a utility which would convert DOS file format to UNIX format or you could unmount Cygwin v 1.1.1 mounted filesystems, then remount them with -t option. BTW: I have one more question beside BXDX. What is best format for a loadable module on Windows. Should they be compiled as *.exe or *.dll? Regards Suhaib > > Greg > > > > Randall Hopper <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 05/31/2000 > 08:11:56 AM > > Please respond to [email protected] > > Sent by: [EMAIL PROTECTED] > > > To: [email protected] > cc: > Subject: [opendx-dev] Re: dxexec: 20% perf speedup > > > > Randall Hopper: > | From profiling dxexec, I've found that 20-25% of it's time in the > |single-process case is spent locking and unlocking mutex locks (on SGI). > |AFAICT these locks add unnecessary, avoidable overhead to the > |single-process case. > | > | I can cook a patch so that mutex locks are only used in dxexec when > |"nprocs > 1". But before I do, I'd like to find out whether the DX > |committers would be willing to commit this patch. > > Perhaps worth mentioning that I already have a patch and the > 20-25% savings > is real savings, not estimated from prof numbers. However the patch needs > refined to be ready for a commit. > > -- > Randall Hopper > [EMAIL PROTECTED] > >
