[omniORB] Windows string interpreted as Unix string

Wed Oct 23 20:34:00 2002

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--==_19414311665807==_
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27ACA.3F774A00"

------_=_NextPart_001_01C27ACA.3F774A00
Content-Type: text/plain;
	charset="iso-8859-1"

Thank for the replay. 
After sending the original e-mail I WAS working on some simple examples to
demonstrate the problem. Thanks to this exercise, I just found the cause of
the problem and it was not omniORB problem!!!
I use CORBA to integrate two third party systems. One of the applications is
causing the problem.  My DLL loads incorrect run-time libraries. When I
switched to a static linking for the run-time libraries problem disappeared.

One more time thanks,
Marzenna. 

----------------------------------------------------------------------------
Marzenna Kruczkowski - mkruczk@thestar.ca
 tel. 416 869-4606  fax. 416 869-4804
Corporate Information Technology 
Torstar Media Group

-----Original Message-----
From: Duncan Grisby [mailto:duncan@grisby.org]
Sent: October 22, 2002 10:14 AM
To: Kruczkowski, Marzenna
Cc: omniorb-list@omniorb-support.com
Subject: Re: [omniORB] Windows string interpreted as Unix string 

On Wednesday 16 October, "Kruczkowski, Marzenna" wrote:

> When I compile my windows DLL (CORBA client) with debug option everything
> runs beautify, but I switch to release (nodebug) mode suddenly windows
> strings are interpreted as UNIX strings, thus I have a problem with endl
and
> end of string character. The interesting thing is, I don't have a problem
> with CORBA Server.  I am running omniORB 4 on Win2000 using VC++ 6.0. I
had
> the same problem with omniORB 3.0.5, but I DID NOT have the problem when I
> was using mico ORB.

Can you give an example that demonstrates the problem?  I don't
understand what you are seeing, since at the C++ level, Unix and
Windows represent line endings in the same way. It's only when you
write strings to a text mode file that there's a difference.

Could it be an issue with mixing release application code with debug
omniORB libraries?

Cheers,

Duncan.

--
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --

------_=_NextPart_001_01C27ACA.3F774A00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [omniORB] Windows string interpreted as Unix string </TITLE>
</HEAD>
<BODY>

Thank for the replay. 
 After sending the original e-mail I WAS working on =
some simple examples to demonstrate the problem. Thanks to this =
exercise, I just found the cause of the problem and it was not omniORB =
problem!!!

I use CORBA to integrate two third party systems. One =
of the applications is causing the problem.&nbsp; My DLL loads =
incorrect run-time libraries. When I switched to a static linking for =
the run-time libraries problem disappeared.

One more time thanks,
 Marzenna.

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
-------------</FONT>
<BR><FONT SIZE=3D2>Marzenna Kruczkowski - mkruczk@thestar.ca</FONT>
<BR><FONT SIZE=3D2>&nbsp;tel. 416 869-4606&nbsp; fax. 416 =
869-4804</FONT>
<BR><FONT SIZE=3D2>Corporate Information Technology </FONT>
<BR><FONT SIZE=3D2>Torstar Media Group</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Duncan Grisby [<A =
HREF=3D"mailto:duncan@grisby.org">mailto:duncan@grisby.org</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: October 22, 2002 10:14 AM</FONT>
<BR><FONT SIZE=3D2>To: Kruczkowski, Marzenna</FONT>
<BR><FONT SIZE=3D2>Cc: omniorb-list@omniorb-support.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [omniORB] Windows string interpreted as =
Unix string </FONT>
</P>

<P><FONT SIZE=3D2>On Wednesday 16 October, &quot;Kruczkowski, =
Marzenna&quot; wrote:</FONT>
</P>

&gt; When I compile my windows DLL (CORBA client) =
with debug option everything
 &gt; runs beautify, but I switch to release =
(nodebug) mode suddenly windows
 &gt; strings are interpreted as UNIX strings, thus I =
have a problem with endl and
 &gt; end of string character. The interesting thing =
is, I don't have a problem
 &gt; with CORBA Server.&nbsp; I am running omniORB 4 =
on Win2000 using VC++ 6.0. I had
 &gt; the same problem with omniORB 3.0.5, but I DID =
NOT have the problem when I
 &gt; was using mico ORB.

Can you give an example that demonstrates the =
problem?&nbsp; I don't
 understand what you are seeing, since at the C++ =
level, Unix and
 Windows represent line endings in the same way. It's =
only when you
 write strings to a text mode file that there's a =
difference.

<P><FONT SIZE=3D2>Could it be an issue with mixing release application =
code with debug</FONT>
<BR><FONT SIZE=3D2>omniORB libraries?</FONT>
</P>

<P><FONT SIZE=3D2>Cheers,</FONT>
</P>

<P><FONT SIZE=3D2>Duncan.</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>&nbsp;-- Duncan =
Grisby&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --</FONT>
<BR><FONT SIZE=3D2>&nbsp; -- duncan@grisby.org&nbsp;&nbsp;&nbsp;&nbsp; =
--</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; -- <A HREF=3D"http://www.grisby.org" =
TARGET=3D"_blank">http://www.grisby.org</A> --</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C27ACA.3F774A00--

--==_19414311665807==_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Get to know us
http://www.thestar.com - Canada's largest daily newspaper online
http://www.toronto.com - All you need to know about T.O.
http://www.workopolis.com - Canada's biggest job site
http://www.torontostartv.com - Webcasting & Production
http://www.newinhomes.com - Ontario's Largest New Home & Condo Website
http://www.waymoresports.com - Canada's most comprehensive sports site
http://www.tmgtv.ca - Torstar Media Group Television

--==_19414311665807==_--