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
