RE: [opendx-dev] problem compiling import module under Windows
I finally figured out my problem making a Windows module. Even though my Windows modules linked correctly, I was using the wrong library, and it is important to use the correct one. I know this is review, but I got it mixed up, so I'll write it here, like detention at the chalkboard. For a standalone program manipulating DX data, use DXLite.lib. For a standalone program also executing DX modules, use DXCallm.lib. For a program talking to DX over DXLink, use DXL.lib. For a loadable module, use DXexec.lib. DXExec.lib, unlike the others, is just an import stub for dxexec.exe, meaning that your module, once compiled, will call DXAllocate and other functions in DXExec.exe, itself. This is good news on Windows because it means that your code will use the same C runtime as DXexec.exe in the places where it needs to use the same runtime. If you set DX to use the native Windows exec, then you should compile against dxexec-native.lib instead of dxexec.lib. The only difference is a few X and Windows functions: DXDisplayX DXDisplayX12 DXDisplayX24 DXDisplayX4 DXDisplayX8 DXCatchWinopenErrors __dxfCreateWindow __dxfProcessEvents __dxfSetXError __dxfXErrorHandler DXInitializeWindows DXMain I don't see the in the html help files the difference between DX.lib and DXCallm.lib, but the symbol tables show the following differences: --DX.lib DXCacheDelete DXCacheInsert DXCacheInsertObject DXCacheSearch DXCompareModuleId DXCopyModuleId DXDeleteTaskGroup DXExecuteTaskGroupNoWait DXGetIntVariable DXGetModuleCacheStr DXGetModuleCacheStrLen DXGetModuleComponentName DXGetModulePath DXGetModulePathLen DXGetVariable DXLoadMDFFile DXLoadMDFString DXLoopDone DXLoopFirst DXOutboard DXPrintCurrentModule DXRegisterCallbackHandler DXSaveForId DXSetIntVariable DXSetVariable DXWinFork DXMain __dxf_ExReadXRCFiles _m_DXLInputNamed _m_SetDXLInputNamed --DXCallm.lib DXInitModules DXInitializeXMainLoop DXInputAvailable DXqwrite DXsqmessage DXSetOutputs DXPrintMemoryInfo DXSetOutputs DXIsInputAvailable DXFreeInputs DXCallOutboard DXCheckRIH DXCompareModuleMacroBase DXGetInputs Drew
RE: [opendx-dev] problem compiling import module under Windows
Hi David, I think the problem is that dxexec.exe uses a different C runtime from dll modules built with dxexec.lib and dxlite.lib. I used the C runtime memory allocation hooks to see that I get crashes when AutoColor tries to free memory allocated during MyConstruct (a Construct module recompiled as a loadable dll). The dependencies I see are the following: dxexec.exe - C:\windows\system32\msvcrt.dll MyConstruct.dll - links to dxlite.lib - Requires imports from Dll versions of C runtime msvcrt.lib - which loads msvcrt71.dll or msvcrt80.dll. There are two ways to fix this. One is to link dxexec.exe to the same version of the C runtime that people have to use when they make loadable dlls. The other is to separate all DXLite.lib functionality into a dll which is called by both dxexec.exe and any loadable modules. dxexec.exe - dxlite.dll - any crt it pleases MyConstruct.dll - dxlite.dll - any crt it pleases I think that's the key, but I'll talk with my peeps on the hallway to see if there is some way around it. Drew -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Thompson Sent: Wednesday, December 14, 2005 5:54 PM To: opendx2-dev@lists.berlios.de Subject: RE: [opendx-dev] problem compiling import module under Windows I've already seen where VS 2003 can't compile a file within OpenDX. I've reported the bug to Microsoft but never got anywhere with it. It's still there. The other thing I think I may be running into is that the compiler may be picking up headers from vc6 when it shouldn't be. I've thought about un-installing all the development environment and just using VS 2005 and see what happens. Will probably try this after I get the next version released. I don't believe that I have any of the cygwin stuff creeping in--but I wouldn't guarantee it. Please report if you figure it out. David
RE: [opendx-dev] problem compiling import module under Windows
If you figure it out, can you give me some ideas how to fix it? I'm more than happy to try and get it all sorted out. On a similar topic, I've got everything compiling with VS2003 (cl v13.10.3077). Everything seems to be working pretty well, except: Our code links with BINMODE.OBJ to turn all reads and writes to binary. But now, the writes to stdout are in binary. From what I read on MSDN, this shouldn't happen (doesn't with vc 6 version), but it does with this compiler. Any idea how to fix it without having to add all the _fmode statements? I guess I could send a question to the VS team. David Hi David, I think the problem is that dxexec.exe uses a different C runtime from dll modules built with dxexec.lib and dxlite.lib. I used the C runtime memory allocation hooks to see that I get crashes when AutoColor tries to free memory allocated during MyConstruct (a Construct module recompiled as a loadable dll). The dependencies I see are the following: dxexec.exe - C:\windows\system32\msvcrt.dll MyConstruct.dll - links to dxlite.lib - Requires imports from Dll versions of C runtime msvcrt.lib - which loads msvcrt71.dll or msvcrt80.dll. There are two ways to fix this. One is to link dxexec.exe to the same version of the C runtime that people have to use when they make loadable dlls. The other is to separate all DXLite.lib functionality into a dll which is called by both dxexec.exe and any loadable modules. dxexec.exe - dxlite.dll - any crt it pleases MyConstruct.dll - dxlite.dll - any crt it pleases I think that's the key, but I'll talk with my peeps on the hallway to see if there is some way around it. Drew -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Thompson Sent: Wednesday, December 14, 2005 5:54 PM To: opendx2-dev@lists.berlios.de Subject: RE: [opendx-dev] problem compiling import module under Windows I've already seen where VS 2003 can't compile a file within OpenDX. I've reported the bug to Microsoft but never got anywhere with it. It's still there. The other thing I think I may be running into is that the compiler may be picking up headers from vc6 when it shouldn't be. I've thought about un-installing all the development environment and just using VS 2005 and see what happens. Will probably try this after I get the next version released. I don't believe that I have any of the cygwin stuff creeping in--but I wouldn't guarantee it. Please report if you figure it out. David -- . David L. Thompson Visualization and Imagery Solutions, Inc. mailto:[EMAIL PROTECTED]5515 Skyway Drive, Missoula, MT 59804 Phone : (406)756-7472
RE: [opendx-dev] problem compiling import module under Windows
Hi David, If linking with binmode.obj fails, does setting the global _fmode = _O_BINARY still work correctly? It should do the same thing. Neither binmode.obj nor the _fmode global are supposed to affect stdout, stderr, and stdin. That's a definite bug. You could set the default fmode to binary but then execute setmode( fileno( stdout ), _O_TEXT ); setmode( fileno( stdin ), _O_TEXT ); setmode( fileno( stderr ), _O_TEXT ); I'm glad things are running. I recall doing a full build was a real pain, so that's great. Drew -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Thompson Sent: Thursday, December 15, 2005 5:59 PM To: opendx2-dev@lists.berlios.de Subject: RE: [opendx-dev] problem compiling import module under Windows If you figure it out, can you give me some ideas how to fix it? I'm more than happy to try and get it all sorted out. On a similar topic, I've got everything compiling with VS2003 (cl v13.10.3077). Everything seems to be working pretty well, except: Our code links with BINMODE.OBJ to turn all reads and writes to binary. But now, the writes to stdout are in binary. From what I read on MSDN, this shouldn't happen (doesn't with vc 6 version), but it does with this compiler. Any idea how to fix it without having to add all the _fmode statements? I guess I could send a question to the VS team. David
RE: [opendx-dev] problem compiling import module under Windows
I've been playing around with it a bit. Linking with binmode.obj
works, the problem is that stdout for some reason is writing out text
in binary. I tried using the setmode route but it doesn't change. I'm
wondering if for some reason something else is going on. Here is a
snippet of the code
if (!_dxd_exRemoteSlave) {
char tmpbuf[80];
sprintf(tmpbuf,
Memory cache will use %ld MB (%ld for small items, %ld for
large)\n\n,
((large_size + small_size) 20),
(small_size 20), (large_size 20));
write(fileno(stdout), tmpbuf, strlen(tmpbuf));
}
And the output is coming out as garbled.
Do you thing the sprintf might be expecting two byte characters?
David
Hi David,
If linking with binmode.obj fails, does setting the global _fmode =
_O_BINARY still work correctly? It should do the same thing. Neither
binmode.obj nor the _fmode global are supposed to affect stdout, stderr,
and stdin. That's a definite bug. You could set the default fmode to
binary but then execute
setmode( fileno( stdout ), _O_TEXT );
setmode( fileno( stdin ), _O_TEXT );
setmode( fileno( stderr ), _O_TEXT );
I'm glad things are running. I recall doing a full build was a real
pain, so that's great.
Drew
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David
Thompson
Sent: Thursday, December 15, 2005 5:59 PM
To: opendx2-dev@lists.berlios.de
Subject: RE: [opendx-dev] problem compiling import module under Windows
If you figure it out, can you give me some ideas how to fix it? I'm
more than happy to try and get it all sorted out.
On a similar topic, I've got everything compiling with VS2003 (cl
v13.10.3077). Everything seems to be working pretty well, except:
Our code links with BINMODE.OBJ to turn all reads and writes to
binary. But now, the writes to stdout are in binary. From what I read
on MSDN, this shouldn't happen (doesn't with vc 6 version), but it
does with this compiler. Any idea how to fix it without having to add
all the _fmode statements? I guess I could send a question to the VS
team.
David
--
.
David L. Thompson Visualization and Imagery Solutions, Inc.
mailto:[EMAIL PROTECTED]5515 Skyway Drive, Missoula, MT 59804
Phone : (406)756-7472
Re: [opendx-dev] problem compiling import module under Windows
Drew, I haven't seen anything like this. I did just recompile yesterday the entire tree with VS 2003 and used vc7, and couldn't produce a runnable version of DX. Have you tried compiling with just VS6 based tools? David Hi All, I'm compiling the Crystal modules (XTM) for OpenDX under Windows, and its ImportStructure module compiles and runs but causes later modules to crash. The ImportStructure code looks good, so I tried making very simple import modules, and even the simplest import module under Windows fails to run correctly. For instance, I copied the source for the dxexec Construct module into a version called MyConstruct. When I run it as a dynamically-loaded dll module under Windows, the module runs, but dxexec crashes some time later when other modules try to read the data generated by MyConstruct. I've written a few dynamic modules for OpenDX using Windows before. Generally, they were output modules, so they read OpenDX data structures and write files or write to sockets. These work fine. However, I've now made three or four versions of modules using MakeGridPositions and MakeGridConnections or simply adding arrays called positions and connections following the simpleimport.c example file, and these types of modules produce fine-looking output according to Print -rd and Verify, but they cause the pipeline to crash later in various places, like Mark or Image. Has anyone seen something like this before? It's very strange. I'm using Visual Studio 2005 on Windows XP Professional and OpenDX 4.3.2000 from 28 Oct 2003. Drew Dolgert Cornell Theory Center -- . David L. Thompson Visualization and Imagery Solutions, Inc. mailto:[EMAIL PROTECTED]5515 Skyway Drive, Missoula, MT 59804 Phone : (406)756-7472
RE: [opendx-dev] problem compiling import module under Windows
Hi David, I was considering moving from VS 2005 to VS 2003, but using VS6 sounds drastic. I don't have that installed anywhere any more, and the C compiler has gotten much more correct since then. If anything, the more recent compilers should be improvements. The kinds of errors I see cause signal 11 (sigsegv) or heap corruption messages. Random hard failures are typical of heap corruption. Is it possible that you (and I) are linking against any code that was compiled in Cygwin and, therefore, uses stdcall convention instead of cdecl? I'm reaching for this one. I see that dxlite.lib and dxexec.lib were linked against the dll version of the Microsoft C runtime, so they aren't using Cygwin. Because DXLite.lib and DXExec.lib are linked to the import stubs for the dll C runtime, I think I can use the memory-debugging features of the debug runtime to help establish when things go south. Thanks, Drew -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Thompson Sent: Wednesday, December 14, 2005 4:16 PM To: opendx2-dev@lists.berlios.de Subject: Re: [opendx-dev] problem compiling import module under Windows Drew, I haven't seen anything like this. I did just recompile yesterday the entire tree with VS 2003 and used vc7, and couldn't produce a runnable version of DX. Have you tried compiling with just VS6 based tools? David
RE: [opendx-dev] problem compiling import module under Windows
I've already seen where VS 2003 can't compile a file within OpenDX. I've reported the bug to Microsoft but never got anywhere with it. It's still there. The other thing I think I may be running into is that the compiler may be picking up headers from vc6 when it shouldn't be. I've thought about un-installing all the development environment and just using VS 2005 and see what happens. Will probably try this after I get the next version released. I don't believe that I have any of the cygwin stuff creeping in--but I wouldn't guarantee it. Please report if you figure it out. David Hi David, I was considering moving from VS 2005 to VS 2003, but using VS6 sounds drastic. I don't have that installed anywhere any more, and the C compiler has gotten much more correct since then. If anything, the more recent compilers should be improvements. The kinds of errors I see cause signal 11 (sigsegv) or heap corruption messages. Random hard failures are typical of heap corruption. Is it possible that you (and I) are linking against any code that was compiled in Cygwin and, therefore, uses stdcall convention instead of cdecl? I'm reaching for this one. I see that dxlite.lib and dxexec.lib were linked against the dll version of the Microsoft C runtime, so they aren't using Cygwin. Because DXLite.lib and DXExec.lib are linked to the import stubs for the dll C runtime, I think I can use the memory-debugging features of the debug runtime to help establish when things go south. Thanks, Drew -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Thompson Sent: Wednesday, December 14, 2005 4:16 PM To: opendx2-dev@lists.berlios.de Subject: Re: [opendx-dev] problem compiling import module under Windows Drew, I haven't seen anything like this. I did just recompile yesterday the entire tree with VS 2003 and used vc7, and couldn't produce a runnable version of DX. Have you tried compiling with just VS6 based tools? David -- . David L. Thompson Visualization and Imagery Solutions, Inc. mailto:[EMAIL PROTECTED]5515 Skyway Drive, Missoula, MT 59804 Phone : (406)756-7472
