C Compiler

[Hubert Cater]

If I wanted to insert some C code that I believe will invoke the C-compiler to load floating point libraries for a finalized Eiffel executable, where would a good place be to do this?

I've tried doing this in recreating one of the *.lib files that my executable is loading but it does not seem to be doing the trick... so I am thinking that perhaps it would need to go into one of the c files that is generated in the W-Code directory but this doesn't seem to do the trick either.

Thanks in advance,
Hubert

[Colin LeMahieu]

This sounds like a complicated request.

By invoke, are you talking about calling a C function at runtime?  If this
is the case will the inline feature syntax be sufficient?

feature
feat
external
"C inline use %"header1.h%", %"header2.h%""
alias
"[
c_call1();
return c_result_var;
]"

Do you want to link against a .lib file?  Look at Project Settings -> Target
-> Advanced -> Externals -> Add Library

On Mon, Oct 12, 2009 at 11:11 AM, hubertcater <[hidden email]>wrote:

>
>
> If I wanted to insert some C code that I believe will invoke the C-compiler
> to load floating point libraries for a finalized Eiffel executable, where
> would a good place be to do this?
>
> I've tried doing this in recreating one of the *.lib files that my
> executable is loading but it does not seem to be doing the trick... so I am
> thinking that perhaps it would need to go into one of the c files that is
> generated in the W-Code directory but this doesn't seem to do the trick
> either.
>
> Thanks in advance,
> Hubert
>
>  
>

[Non-text portions of this message have been removed]

[Hubert Cater]

If not complicated at least it is one that is giving me quite a few
headaches.

I'm having a problem where my finalized EXE, once wrapped with a Digital
Rights Management application fails at runtime complaining that it
cannot find the necessary floating point library.

It is an R6002 error and here is some info on it from MSDN:
http://msdn.microsoft.com/en-us/library/k1x26e0x(VS.71).aspx

Long story short, it seems that the Digital Rights Management wrapping
to my EXE is attempting to make a call at runtime requiring a floating
point library that has been excluded from my original Eiffel executable
due to the C compilation optimizations.

Under 5.6 I didn't have this issue but under 6.4 and my guess is this is
because of the latest Microsoft C compiler via the SDK, it appears that
the compilation optimizations don't include the necessary floating point
library unless it is explicitly needed.  My EXE doesn't seem to need it
but the wrapped EXE does.  Hopefully this makes sense?

So what I have been trying to do with limited success is to trick my
compiled Eiffel EXE into including the needed floating point library and
not to exclude it when it optimizes the EXE generation.  I'm guessing
including a simple line like the following will do the trick:

float f = 1.0f;

That being said I suspect calling a C function at runtime would not work
as I think this needs to be *known* by the C compiler before it even
compiles the EXE.

As it is now, I'm a little stuck :(
Hubert




Colin LeMahieu wrote:

> This sounds like a complicated request.
>
> By invoke, are you talking about calling a C function at runtime?  If this
> is the case will the inline feature syntax be sufficient?
>
> feature
> feat
> external
> "C inline use %"header1.h%", %"header2.h%""
> alias
> "[
> c_call1();
> return c_result_var;
> ]"
>
> Do you want to link against a .lib file?  Look at Project Settings -> Target
> -> Advanced -> Externals -> Add Library
>
> On Mon, Oct 12, 2009 at 11:11 AM, hubertcater <[hidden email]>wrote:
>
>>
>> If I wanted to insert some C code that I believe will invoke the C-compiler
>> to load floating point libraries for a finalized Eiffel executable, where
>> would a good place be to do this?
>>
>> I've tried doing this in recreating one of the *.lib files that my
>> executable is loading but it does not seem to be doing the trick... so I am
>> thinking that perhaps it would need to go into one of the c files that is
>> generated in the W-Code directory but this doesn't seem to do the trick
>> either.
>>
>> Thanks in advance,
>> Hubert
>>
>>  
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.421 / Virus Database: 270.14.12/2431 - Release Date: 10/12/09 13:01:00
>

--
Fury Software
http://www.furysoftware.com

Battlefront.com
http://www.battlefront.com

[Colin LeMahieu]

Have you attempted to add floating point operations on the Eiffel side?  In
your root creation procedure try adding:

local
val1: DOUBLE
val2: DOUBLE

val2 := 60.0
if val2 = val1 then do_nothing end

A way to force the compiler to consider a class and/or feature as reachable
is with an option in Project Settings.
Project Settings -> Target -> Groups -> Clusters -> (Cluster) -> Advanced ->
Visible Classes
Then add the class that should be "visible" then under the class add a
feature that should be "visible".  This is typically used for forcing Eiffel
to include code that's only referenced from C through Cecil or force a
feature to be available in a DLL.

On Mon, Oct 12, 2009 at 4:06 PM, Hubert Cater <[hidden email]>wrote:

>
>
> If not complicated at least it is one that is giving me quite a few
> headaches.
>
> I'm having a problem where my finalized EXE, once wrapped with a Digital
> Rights Management application fails at runtime complaining that it
> cannot find the necessary floating point library.
>
> It is an R6002 error and here is some info on it from MSDN:
> http://msdn.microsoft.com/en-us/library/k1x26e0x(VS.71).aspx
>
> Long story short, it seems that the Digital Rights Management wrapping
> to my EXE is attempting to make a call at runtime requiring a floating
> point library that has been excluded from my original Eiffel executable
> due to the C compilation optimizations.
>
> Under 5.6 I didn't have this issue but under 6.4 and my guess is this is
> because of the latest Microsoft C compiler via the SDK, it appears that
> the compilation optimizations don't include the necessary floating point
> library unless it is explicitly needed. My EXE doesn't seem to need it
> but the wrapped EXE does. Hopefully this makes sense?
>
> So what I have been trying to do with limited success is to trick my
> compiled Eiffel EXE into including the needed floating point library and
> not to exclude it when it optimizes the EXE generation. I'm guessing
> including a simple line like the following will do the trick:
>
> float f = 1.0f;
>
> That being said I suspect calling a C function at runtime would not work
> as I think this needs to be *known* by the C compiler before it even
> compiles the EXE.
>
> As it is now, I'm a little stuck :(
> Hubert
>
>
> Colin LeMahieu wrote:
> > This sounds like a complicated request.
> >
> > By invoke, are you talking about calling a C function at runtime? If this
> > is the case will the inline feature syntax be sufficient?
> >
> > feature
> > feat
> > external
> > "C inline use %"header1.h%", %"header2.h%""
> > alias
> > "[
> > c_call1();
> > return c_result_var;
> > ]"
> >
> > Do you want to link against a .lib file? Look at Project Settings ->
> Target
> > -> Advanced -> Externals -> Add Library
> >
> > On Mon, Oct 12, 2009 at 11:11 AM, hubertcater <[hidden email]<hcater%40furysoftware.com>
> >wrote:
> >
> >>
> >> If I wanted to insert some C code that I believe will invoke the
> C-compiler
> >> to load floating point libraries for a finalized Eiffel executable,
> where
> >> would a good place be to do this?
> >>
> >> I've tried doing this in recreating one of the *.lib files that my
> >> executable is loading but it does not seem to be doing the trick... so I
> am
> >> thinking that perhaps it would need to go into one of the c files that
> is
> >> generated in the W-Code directory but this doesn't seem to do the trick
> >> either.
> >>
> >> Thanks in advance,
> >> Hubert
> >>
> >>
> >>
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> > ----------------------------------------------------------
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.5.421 / Virus Database: 270.14.12/2431 - Release Date:
> 10/12/09 13:01:00
> >
>
> --
> Fury Software
> http://www.furysoftware.com
>
> Battlefront.com
> http://www.battlefront.com
>  
>

[Non-text portions of this message have been removed]

[Hubert Cater]

Hi Colin,

> local
> val1: DOUBLE
> val2: DOUBLE
>
> val2 := 60.0
> if val2 = val1 then do_nothing end

I will try this as well since to be honest, after looking at all the C
side suggested solutions, I forgot that I might be able to achieve this
on the Eiffel side as well.

> A way to force the compiler to consider a class and/or feature as reachable
> is with an option in Project Settings.
> Project Settings -> Target -> Groups -> Clusters -> (Cluster) -> Advanced ->
> Visible Classes
> Then add the class that should be "visible" then under the class add a
> feature that should be "visible".  This is typically used for forcing Eiffel
> to include code that's only referenced from C through Cecil or force a
> feature to be available in a DLL.

Thank you for this suggestion as well as I've never really understood
what the "visible" classes clause implied.  If I do this would the
suggestion be to ensure that my root creation procedure is included as a
visible feature or is this not necessary for what you've suggested
above, i.e. this is more of a general suggestion to better understand
the power of "visible"?

Thanks,
Hubert

--
Fury Software
http://www.furysoftware.com

Battlefront.com
http://www.battlefront.com

[Emmanuel Stapf]

The Eiffel runtime has a bunch of floating point operations included so it would
be suprising that will solve Hubert's problem. Hubert, have you tried to run under
the C debugger when this exception occurs and send the stack trace to your vendor,
as they are more likely to know how to solve the problem than we are.

Regards,
Manu

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Colin LeMahieu
> Sent: Monday, October 12, 2009 2:18 PM
> To: [hidden email]
> Subject: Re: [eiffel_software] C Compiler
>
> Have you attempted to add floating point operations on the Eiffel side?
> In
> your root creation procedure try adding:
>
> local
> val1: DOUBLE
> val2: DOUBLE
>
> val2 := 60.0
> if val2 = val1 then do_nothing end
>
> A way to force the compiler to consider a class and/or feature as
> reachable
> is with an option in Project Settings.
> Project Settings -> Target -> Groups -> Clusters -> (Cluster) -> Advanced
> ->
> Visible Classes
> Then add the class that should be "visible" then under the class add a
> feature that should be "visible".  This is typically used for forcing
> Eiffel
> to include code that's only referenced from C through Cecil or force a
> feature to be available in a DLL.
>
> On Mon, Oct 12, 2009 at 4:06 PM, Hubert Cater
> <[hidden email]>wrote:
>
> >
> >
> > If not complicated at least it is one that is giving me quite a few
> > headaches.
> >
> > I'm having a problem where my finalized EXE, once wrapped with a
> Digital
> > Rights Management application fails at runtime complaining that it
> > cannot find the necessary floating point library.
> >
> > It is an R6002 error and here is some info on it from MSDN:
> > http://msdn.microsoft.com/en-us/library/k1x26e0x(VS.71).aspx
> >
> > Long story short, it seems that the Digital Rights Management wrapping
> > to my EXE is attempting to make a call at runtime requiring a floating
> > point library that has been excluded from my original Eiffel executable
> > due to the C compilation optimizations.
> >
> > Under 5.6 I didn't have this issue but under 6.4 and my guess is this
> is
> > because of the latest Microsoft C compiler via the SDK, it appears that
> > the compilation optimizations don't include the necessary floating
> point
> > library unless it is explicitly needed. My EXE doesn't seem to need it
> > but the wrapped EXE does. Hopefully this makes sense?
> >
> > So what I have been trying to do with limited success is to trick my
> > compiled Eiffel EXE into including the needed floating point library
> and
> > not to exclude it when it optimizes the EXE generation. I'm guessing
> > including a simple line like the following will do the trick:
> >
> > float f = 1.0f;
> >
> > That being said I suspect calling a C function at runtime would not
> work
> > as I think this needs to be *known* by the C compiler before it even
> > compiles the EXE.
> >
> > As it is now, I'm a little stuck :(
> > Hubert
> >
> >
> > Colin LeMahieu wrote:
> > > This sounds like a complicated request.
> > >
> > > By invoke, are you talking about calling a C function at runtime? If
> this
> > > is the case will the inline feature syntax be sufficient?
> > >
> > > feature
> > > feat
> > > external
> > > "C inline use %"header1.h%", %"header2.h%""
> > > alias
> > > "[
> > > c_call1();
> > > return c_result_var;
> > > ]"
> > >
> > > Do you want to link against a .lib file? Look at Project Settings ->
> > Target
> > > -> Advanced -> Externals -> Add Library
> > >
> > > On Mon, Oct 12, 2009 at 11:11 AM, hubertcater
> <[hidden email]<hcater%40furysoftware.com>
> > >wrote:
> > >
> > >>
> > >> If I wanted to insert some C code that I believe will invoke the
> > C-compiler
> > >> to load floating point libraries for a finalized Eiffel executable,
> > where
> > >> would a good place be to do this?
> > >>
> > >> I've tried doing this in recreating one of the *.lib files that my
> > >> executable is loading but it does not seem to be doing the trick...
> so I
> > am
> > >> thinking that perhaps it would need to go into one of the c files
> that
> > is
> > >> generated in the W-Code directory but this doesn't seem to do the
> trick
> > >> either.
> > >>
> > >> Thanks in advance,
> > >> Hubert
> > >>
> > >>
> > >>
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > > ----------------------------------------------------------
> > >
> > >
> > > No virus found in this incoming message.
> > > Checked by AVG - www.avg.com
> > > Version: 8.5.421 / Virus Database: 270.14.12/2431 - Release Date:
> > 10/12/09 13:01:00
> > >
> >
> > --
> > Fury Software
> > http://www.furysoftware.com
> >
> > Battlefront.com
> > http://www.battlefront.com
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

[Hubert Cater]

Hi Manu,

Actually I haven't and to be honest here as well I've never done so.

In the past I've seen the option, i.e. once the application fails, to
open it in the debugger but this option is not available on my current
system for this application when the R6002 error pops up.

If I can ask, can you offer a quick suggestion on how to go about this?

I have VS 2002 .NET installed as well as 2008 Studio Express and of
course the latest SDK for Windows XP.

Also, just for experimental purposes, is there a way for me to add a c
line somewhere in the generated c files that will be included in the
finalized EXE.

Thanks,
Hubert


Emmanuel Stapf [ES] wrote:

> The Eiffel runtime has a bunch of floating point operations included so it would
> be suprising that will solve Hubert's problem. Hubert, have you tried to run under
> the C debugger when this exception occurs and send the stack trace to your vendor,
> as they are more likely to know how to solve the problem than we are.
>
> Regards,
> Manu
>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Colin LeMahieu
>> Sent: Monday, October 12, 2009 2:18 PM
>> To: [hidden email]
>> Subject: Re: [eiffel_software] C Compiler
>>
>> Have you attempted to add floating point operations on the Eiffel side?
>> In
>> your root creation procedure try adding:
>>
>> local
>> val1: DOUBLE
>> val2: DOUBLE
>>
>> val2 := 60.0
>> if val2 = val1 then do_nothing end
>>
>> A way to force the compiler to consider a class and/or feature as
>> reachable
>> is with an option in Project Settings.
>> Project Settings -> Target -> Groups -> Clusters -> (Cluster) -> Advanced
>> ->
>> Visible Classes
>> Then add the class that should be "visible" then under the class add a
>> feature that should be "visible".  This is typically used for forcing
>> Eiffel
>> to include code that's only referenced from C through Cecil or force a
>> feature to be available in a DLL.
>>
>> On Mon, Oct 12, 2009 at 4:06 PM, Hubert Cater
>> <[hidden email]>wrote:
>>
>>>
>>> If not complicated at least it is one that is giving me quite a few
>>> headaches.
>>>
>>> I'm having a problem where my finalized EXE, once wrapped with a
>> Digital
>>> Rights Management application fails at runtime complaining that it
>>> cannot find the necessary floating point library.
>>>
>>> It is an R6002 error and here is some info on it from MSDN:
>>> http://msdn.microsoft.com/en-us/library/k1x26e0x(VS.71).aspx
>>>
>>> Long story short, it seems that the Digital Rights Management wrapping
>>> to my EXE is attempting to make a call at runtime requiring a floating
>>> point library that has been excluded from my original Eiffel executable
>>> due to the C compilation optimizations.
>>>
>>> Under 5.6 I didn't have this issue but under 6.4 and my guess is this
>> is
>>> because of the latest Microsoft C compiler via the SDK, it appears that
>>> the compilation optimizations don't include the necessary floating
>> point
>>> library unless it is explicitly needed. My EXE doesn't seem to need it
>>> but the wrapped EXE does. Hopefully this makes sense?
>>>
>>> So what I have been trying to do with limited success is to trick my
>>> compiled Eiffel EXE into including the needed floating point library
>> and
>>> not to exclude it when it optimizes the EXE generation. I'm guessing
>>> including a simple line like the following will do the trick:
>>>
>>> float f = 1.0f;
>>>
>>> That being said I suspect calling a C function at runtime would not
>> work
>>> as I think this needs to be *known* by the C compiler before it even
>>> compiles the EXE.
>>>
>>> As it is now, I'm a little stuck :(
>>> Hubert
>>>
>>>
>>> Colin LeMahieu wrote:
>>>> This sounds like a complicated request.
>>>>
>>>> By invoke, are you talking about calling a C function at runtime? If
>> this
>>>> is the case will the inline feature syntax be sufficient?
>>>>
>>>> feature
>>>> feat
>>>> external
>>>> "C inline use %"header1.h%", %"header2.h%""
>>>> alias
>>>> "[
>>>> c_call1();
>>>> return c_result_var;
>>>> ]"
>>>>
>>>> Do you want to link against a .lib file? Look at Project Settings ->
>>> Target
>>>> -> Advanced -> Externals -> Add Library
>>>>
>>>> On Mon, Oct 12, 2009 at 11:11 AM, hubertcater
>> <[hidden email]<hcater%40furysoftware.com>
>>>> wrote:
>>>>
>>>>> If I wanted to insert some C code that I believe will invoke the
>>> C-compiler
>>>>> to load floating point libraries for a finalized Eiffel executable,
>>> where
>>>>> would a good place be to do this?
>>>>>
>>>>> I've tried doing this in recreating one of the *.lib files that my
>>>>> executable is loading but it does not seem to be doing the trick...
>> so I
>>> am
>>>>> thinking that perhaps it would need to go into one of the c files
>> that
>>> is
>>>>> generated in the W-Code directory but this doesn't seem to do the
>> trick
>>>>> either.
>>>>>
>>>>> Thanks in advance,
>>>>> Hubert
>>>>>
>>>>>
>>>>>
>>>>
>>>> [Non-text portions of this message have been removed]
>>>>
>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 8.5.421 / Virus Database: 270.14.12/2431 - Release Date:
>>> 10/12/09 13:01:00
>>> --
>>> Fury Software
>>> http://www.furysoftware.com
>>>
>>> Battlefront.com
>>> http://www.battlefront.com
>>>
>>>
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.421 / Virus Database: 270.14.12/2431 - Release Date: 10/12/09 13:01:00
>

--
Fury Software
http://www.furysoftware.com

Battlefront.com
http://www.battlefront.com

[Emmanuel Stapf]

> If I can ask, can you offer a quick suggestion on how to go about this?

Start VisualStudio, open your .exe and do `Ctrl + Alt + E' and select all
exceptions. Then start your program (F5) and wait for the exception to occurs and
select `Break'. Then you should see the callstack and hopefully it will be
meaningful. If it is not, try with the workbench version of your .exe and update
relink it with the /DEBUG option, i.e.:
- open a DOS prompt
- edit the .lnk file of your program and add /DEBUG at the end of the first line
- type `link @program.lnk' where `program' stands for the name of your .exe
This is the temporary version of getting .exe with debug symbols. The permanent
solution is explained at http://dev.eiffel.com/Debug_generated_C_code

> Also, just for experimental purposes, is there a way for me to add a c
> line somewhere in the generated c files that will be included in the
> finalized EXE.

Using a C inline external that you call from your creation procedure you are
guaranteed that this will be included in the C generated code, however it is not
clear whether or not the underlying C compiler will keep it, if it finds out it
doesn't do anything.

Regards,
Manu

[Colin LeMahieu]

The root creation procedure is implicitly visible.  The dead-code removal
step creates a reachability graph from the root creation procedure and
removes functions that aren't referenced.  Adding something to "visible"
essentially adds another root and reachability graph.

On Mon, Oct 12, 2009 at 4:26 PM, Hubert Cater <[hidden email]>wrote:

>
>
> Hi Colin,
>
>
> > local
> > val1: DOUBLE
> > val2: DOUBLE
> >
> > val2 := 60.0
> > if val2 = val1 then do_nothing end
>
> I will try this as well since to be honest, after looking at all the C
> side suggested solutions, I forgot that I might be able to achieve this
> on the Eiffel side as well.
>
> > A way to force the compiler to consider a class and/or feature as
> reachable
> > is with an option in Project Settings.
> > Project Settings -> Target -> Groups -> Clusters -> (Cluster) -> Advanced
> ->
> > Visible Classes
> > Then add the class that should be "visible" then under the class add a
> > feature that should be "visible". This is typically used for forcing
> Eiffel
> > to include code that's only referenced from C through Cecil or force a
> > feature to be available in a DLL.
>
> Thank you for this suggestion as well as I've never really understood
> what the "visible" classes clause implied. If I do this would the
> suggestion be to ensure that my root creation procedure is included as a
> visible feature or is this not necessary for what you've suggested
> above, i.e. this is more of a general suggestion to better understand
> the power of "visible"?
>
> Thanks,
> Hubert
>
> --
> Fury Software
> http://www.furysoftware.com
>
> Battlefront.com
> http://www.battlefront.com
>  
>

[Non-text portions of this message have been removed]

[Hubert Cater]

Gentlemen, thank you and I will experiment over the next few days as I
unfortunately do not wrap the executables myself but have to send them
out to be *protected* which ultimately slows down my "finding a solution
process".

Manu, if I can also ask, any idea what might have changed from 5.6 to
6.4 that would cause this issue where the c compiler does not seem to
load the floating point libraries?  As mentioned it worked Ok previously
and this error only popped up when I converted to 6.4.  For example, I
still maintain older projects under 5.6 and occasionally need them
wrapped with this 3rd party DRM... and there is still no issue so it
doesn't appear to be a change on the DRM side that would be causing the
problem.

I've searched but have not been able to find anything meaningful and I
am just curious if you might possibly have further insight with your
experience using the various compilers over the years.

Thanks,
Hubert


Colin LeMahieu wrote:

> The root creation procedure is implicitly visible.  The dead-code removal
> step creates a reachability graph from the root creation procedure and
> removes functions that aren't referenced.  Adding something to "visible"
> essentially adds another root and reachability graph.
>
> On Mon, Oct 12, 2009 at 4:26 PM, Hubert Cater <[hidden email]>wrote:
>
>>
>> Hi Colin,
>>
>>
>>> local
>>> val1: DOUBLE
>>> val2: DOUBLE
>>>
>>> val2 := 60.0
>>> if val2 = val1 then do_nothing end
>> I will try this as well since to be honest, after looking at all the C
>> side suggested solutions, I forgot that I might be able to achieve this
>> on the Eiffel side as well.
>>
>>> A way to force the compiler to consider a class and/or feature as
>> reachable
>>> is with an option in Project Settings.
>>> Project Settings -> Target -> Groups -> Clusters -> (Cluster) -> Advanced
>> ->
>>> Visible Classes
>>> Then add the class that should be "visible" then under the class add a
>>> feature that should be "visible". This is typically used for forcing
>> Eiffel
>>> to include code that's only referenced from C through Cecil or force a
>>> feature to be available in a DLL.
>> Thank you for this suggestion as well as I've never really understood
>> what the "visible" classes clause implied. If I do this would the
>> suggestion be to ensure that my root creation procedure is included as a
>> visible feature or is this not necessary for what you've suggested
>> above, i.e. this is more of a general suggestion to better understand
>> the power of "visible"?
>>
>> Thanks,
>> Hubert
>>
>> --
>> Fury Software
>> http://www.furysoftware.com
>>
>> Battlefront.com
>> http://www.battlefront.com
>>  
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.421 / Virus Database: 270.14.12/2431 - Release Date: 10/12/09 13:01:00
>

--
Fury Software
http://www.furysoftware.com

Battlefront.com
http://www.battlefront.com

[Emmanuel Stapf]

> Manu, if I can also ask, any idea what might have changed from 5.6 to
> 6.4 that would cause this issue where the c compiler does not seem to

I believe this is an issue with the different version of the Microsoft C++
compiler we require. You used VC6 with 5.6 and now using VC8 with 6.4.

> I've searched but have not been able to find anything meaningful and I
> am just curious if you might possibly have further insight with your
> experience using the various compilers over the years.

My experience is that when some C libraries are compiled in a specific mode (e.g.
/MD vs /MT) it is quite annoying for the users of those libraries. This is the C
compiler's fault to provide too many incompatible options.

Keep us informed of your progress.

Regards,
Manu

[Hubert Cater]

Hi Manu,

Thanks for all the info and unfortunately nothing seems to work as I
tried the C inline suggestion and even Colin's suggestions and those did
not make any difference to the floating point errors I receive.

I've tried compiling the EXE as you suggested below and if I attempt to
debug this EXE before it is protected with DRM this is fine, but once
the DRM is included the debug process simply does not work returning
constant 'unhandled exceptions' and my guess is that this is related to
the EXE wrapping process that apparently encrypts the EXE or something
similar.

Looks like my only way around all of this is to try and compile with the
suggested /MD.  I realize this is a lot to ask but if you could point me
in the right direction on how to recompile all the C dependencies to /MD
so I can compile my EXE with /MD that would be very helpful.

Thanks,
Hubert


Emmanuel Stapf [ES] wrote:

>> If I can ask, can you offer a quick suggestion on how to go about this?
>
> Start VisualStudio, open your .exe and do `Ctrl + Alt + E' and select all
> exceptions. Then start your program (F5) and wait for the exception to occurs and
> select `Break'. Then you should see the callstack and hopefully it will be
> meaningful. If it is not, try with the workbench version of your .exe and update
> relink it with the /DEBUG option, i.e.:
> - open a DOS prompt
> - edit the .lnk file of your program and add /DEBUG at the end of the first line
> - type `link @program.lnk' where `program' stands for the name of your .exe
> This is the temporary version of getting .exe with debug symbols. The permanent
> solution is explained at http://dev.eiffel.com/Debug_generated_C_code
>
>> Also, just for experimental purposes, is there a way for me to add a c
>> line somewhere in the generated c files that will be included in the
>> finalized EXE.
>
> Using a C inline external that you call from your creation procedure you are
> guaranteed that this will be included in the C generated code, however it is not
> clear whether or not the underlying C compiler will keep it, if it finds out it
> doesn't do anything.
>
> Regards,
> Manu
>

--
Fury Software
http://www.furysoftware.com

Battlefront.com
http://www.battlefront.com