ANN: EurekaLog 5.0.3 (Catch every Exception showing Line#)

[EurekaLog Team]

We are happy to announce the immediate availability of the new EurekaLog
5.0.3.

EurekaLog is the new add-in tool that gives to your Delphi/C++Builder
application (GUI, Console, Web, ...) the power to catch every exception,
generating a detailed log of call stack (with unit, class, method and line
#), showing and sending it back to you via email or Web message
(HTTP-S/FTP).


EurekaLog represents the most advanced exception logger technology
available for Delphi/C++Builder developers.


To learn more about EurekaLog, please visit our website at:

http://www.eurekalog.com


To download a demo, please visit:

http://www.eurekalog.com/downloads.php


If you would like to purchase a new license, please visit:

http://www.eurekalog.com/buy.php


To see the changes visit:

http://www.eurekalog.com/openfile.php?file=changelog.txt&title=Change%20Log
or simply
http://www.eurekalog.com/changelog.txt

--
Best regards.

The EurekaLog Team.

[Philip L Jackson]

All

This component has saved me countless hours of tracking issues down.

Highly recommended

Philip L Jackson

"EurekaLog Team" <[e-mail]> wrote in message
news:433040d8$***@newsgroups.borland.com...
> We are happy to announce the immediate availability of the new EurekaLog
> 5.0.3.
>
> EurekaLog is the new add-in tool that gives to your Delphi/C++Builder
> application (GUI, Console, Web, ...) the power to catch every exception,
> generating a detailed log of call stack (with unit, class, method and line
> #), showing and sending it back to you via email or Web message
> (HTTP-S/FTP).
>
>
> EurekaLog represents the most advanced exception logger technology
> available for Delphi/C++Builder developers.
>
>
> To learn more about EurekaLog, please visit our website at:
>
> http://www.eurekalog.com
>
>
> To download a demo, please visit:
>
> http://www.eurekalog.com/downloads.php
>
>
> If you would like to purchase a new license, please visit:
>
> http://www.eurekalog.com/buy.php
>
>
> To see the changes visit:
>
> http://www.eurekalog.com/openfile.php?file=changelog.txt&title=Change%20Log
> or simply
> http://www.eurekalog.com/changelog.txt
>
> --
> Best regards.
>
> The EurekaLog Team.
>

[Jonathan Neve[Microtec]]

Dear Philip

> All
>
> This component has saved me countless hours of tracking issues down.
>
> Highly recommended
>

Yes, definitely recommended. Saves time and increases product quality.
--
Best regards,
Jonathan Neve
_______________
CopyCat - advanced database replication
components for Delphi/C++Builder!
_______________________________________
Version 1.0 now available!
Web : http://www.microtec.fr/copycat

[Danijel Tkalcec (RealThinClient)]

Hi,

I have read the information on your web site and it looks like this is an
excellent tool for any developer, but I still have a few questions ...

1.) Are there any DLLs which have to be deployed with the application (like
it's the case with FastMM4) to get detailed debug information, or is
everything compiled into the exe file?

2.) How much does the basic EurekaLog code increase the exe file size?

3.) To get unit name and line number information, do applications have to
be compiled with TD-32 debug info or some other option which would radicaly
increase the exe file size (for example, RTC AppClient demo without TD-32
info compiles to 600KB and with TD-32 info to more than 4MB).

4.) Maybe this is a stupid question, but it was not clear from your
announcement :o)
Can EurekaLog also be used to debug DLLs (for example, ISAPI extensions for
a web server)?

Thank you!

--
Danijel Tkalcec

RealThinClient components
http://www.realthinclient.com
news://news.realthinclient.com

[Fabio Dell'Aria]

Danijel Tkalcec (RealThinClient) wrote:
> Hi,
>
> I have read the information on your web site and it looks like this is an
> excellent tool for any developer, but I still have a few questions ...
>
> 1.) Are there any DLLs which have to be deployed with the application (like
> it's the case with FastMM4) to get detailed debug information, or is
> everything compiled into the exe file?

Is everything compiled in the final .exe file.

>
> 2.) How much does the basic EurekaLog code increase the exe file size?
>

About 200Kb + 1% of original .exe file size.

> 3.) To get unit name and line number information, do applications have to
> be compiled with TD-32 debug info or some other option which would radicaly
> increase the exe file size (for example, RTC AppClient demo without TD-32
> info compiles to 600KB and with TD-32 info to more than 4MB).
>

EurekaLog did not requires the TD-32 debug option, and never other
option able to increases the final .exe size.

> 4.) Maybe this is a stupid question, but it was not clear from your
> announcement :o)
> Can EurekaLog also be used to debug DLLs (for example, ISAPI extensions for
> a web server)?
>

EurekaLog works from Console/GUI applications to CGI/ISAPI/IntraWeb
applications (included ActiveX/COM/COM+/DCOM Control Panel, NT Services,
and much, much more).

See the http://www.eurekalog.com/features.php page for further details.

> Thank you!

I hope to have answered to all your questions, otherwise don't hesitate
to recontact to me, ok? :)

--
Best regards...

Fabio Dell'Aria.

[Danijel Tkalcec (RealThinClient)]

Thank you, Fabio.

Sounds perfect for me :)

--
Danijel Tkalcec

RealThinClient components
http://www.realthinclient.com
news://news.realthinclient.com

[Fabio Dell'Aria]

Danijel Tkalcec (RealThinClient) wrote:
> Thank you, Fabio.
>
> Sounds perfect for me :)
>

;-)

--
Best regards...

Fabio Dell'Aria.

[Jason]

Why use Eureka instead of madexcept? Any differences?


"EurekaLog Team" <[e-mail]> wrote in message
news:433040d8$***@newsgroups.borland.com...
> We are happy to announce the immediate availability of the new EurekaLog
> 5.0.3.
>
> EurekaLog is the new add-in tool that gives to your Delphi/C++Builder
> application (GUI, Console, Web, ...) the power to catch every exception,
> generating a detailed log of call stack (with unit, class, method and line
> #), showing and sending it back to you via email or Web message
> (HTTP-S/FTP).
>
>
> EurekaLog represents the most advanced exception logger technology
> available for Delphi/C++Builder developers.
>
>
> To learn more about EurekaLog, please visit our website at:
>
> http://www.eurekalog.com
>
>
> To download a demo, please visit:
>
> http://www.eurekalog.com/downloads.php
>
>
> If you would like to purchase a new license, please visit:
>
> http://www.eurekalog.com/buy.php
>
>
> To see the changes visit:
>
> http://www.eurekalog.com/openfile.php?file=changelog.txt&title=Change%20Log
> or simply
> http://www.eurekalog.com/changelog.txt
>
> --
> Best regards.
>
> The EurekaLog Team.
>

[Fabio Dell'Aria]

Jason wrote:
> Why use Eureka instead of madexcept? Any differences?
>

I'm listing only some differences...

1)...128 bit debug data encryption (to protect from the cracking). You
can encrypt the debug data without saving the password in the .exe file,
the final call-stack will be sent to you encrypted. You'll can decrypt
it only using the EurekaLog Viewer inserting the just password.

2)...IDE crashes saves (allow to save modified files after unrecoverable
IDE crashes);

3)...Automatic search of error lines in modified sources(guarantee error
individuation in sources modified after the delivery);

4)...Advanced IDE/OS integrated Log Viewer (in the Projects menu);

5)...Printable PDF manual;

6)...Custom HTML template for HTML error page;

7)...Advanced Tree view of all running/calling threads call-stacks;

8)...Calling Threads full call-stack showing.

9)...Attach the last generated HTML page;

10)...Send an XML Log's copy;

11)...Send email/web message in a separated thread;


What do you think about? :)


--
Best regards...

Fabio Dell'Aria.

>
> "EurekaLog Team" <[e-mail]> wrote in message
> news:433040d8$***@newsgroups.borland.com...
>
>>We are happy to announce the immediate availability of the new EurekaLog
>>5.0.3.
>>
>>EurekaLog is the new add-in tool that gives to your Delphi/C++Builder
>>application (GUI, Console, Web, ...) the power to catch every exception,
>>generating a detailed log of call stack (with unit, class, method and line
>>#), showing and sending it back to you via email or Web message
>>(HTTP-S/FTP).
>>
>>
>>EurekaLog represents the most advanced exception logger technology
>>available for Delphi/C++Builder developers.
>>
>>
>>To learn more about EurekaLog, please visit our website at:
>>
>>http://www.eurekalog.com
>>
>>
>>To download a demo, please visit:
>>
>>http://www.eurekalog.com/downloads.php
>>
>>
>>If you would like to purchase a new license, please visit:
>>
>>http://www.eurekalog.com/buy.php
>>
>>
>>To see the changes visit:
>>
>>http://www.eurekalog.com/openfile.php?file=changelog.txt&title=Change%20Log
>>or simply
>>http://www.eurekalog.com/changelog.txt
>>
>>--
>>Best regards.
>>
>>The EurekaLog Team.

[Jason]

Oh great !

can you please explain me the "3" a bit more?

Thanks

"Fabio Dell'Aria" <***@eurekalog.com> wrote in message
news:43317f15$***@newsgroups.borland.com...
> Jason wrote:
>> Why use Eureka instead of madexcept? Any differences?
>>
>
> I'm listing only some differences...
>
> 1)...128 bit debug data encryption (to protect from the cracking). You can
> encrypt the debug data without saving the password in the .exe file, the
> final call-stack will be sent to you encrypted. You'll can decrypt it only
> using the EurekaLog Viewer inserting the just password.
>
> 2)...IDE crashes saves (allow to save modified files after unrecoverable
> IDE crashes);
>
> 3)...Automatic search of error lines in modified sources(guarantee error
> individuation in sources modified after the delivery);
>
> 4)...Advanced IDE/OS integrated Log Viewer (in the Projects menu);
>
> 5)...Printable PDF manual;
>
> 6)...Custom HTML template for HTML error page;
>
> 7)...Advanced Tree view of all running/calling threads call-stacks;
> 8)...Calling Threads full call-stack showing.
>
> 9)...Attach the last generated HTML page;
>
> 10)...Send an XML Log's copy;
>
> 11)...Send email/web message in a separated thread;
>
>
> What do you think about? :)
>
>
> --
> Best regards...
>
> Fabio Dell'Aria.
>
>>
>> "EurekaLog Team" <[e-mail]> wrote in message
>> news:433040d8$***@newsgroups.borland.com...
>>
>>>We are happy to announce the immediate availability of the new EurekaLog
>>>5.0.3.
>>>
>>>EurekaLog is the new add-in tool that gives to your Delphi/C++Builder
>>>application (GUI, Console, Web, ...) the power to catch every exception,
>>>generating a detailed log of call stack (with unit, class, method and
>>>line
>>>#), showing and sending it back to you via email or Web message
>>>(HTTP-S/FTP).
>>>
>>>
>>>EurekaLog represents the most advanced exception logger technology
>>>available for Delphi/C++Builder developers.
>>>
>>>
>>>To learn more about EurekaLog, please visit our website at:
>>>
>>>http://www.eurekalog.com
>>>
>>>
>>>To download a demo, please visit:
>>>
>>>http://www.eurekalog.com/downloads.php
>>>
>>>
>>>If you would like to purchase a new license, please visit:
>>>
>>>http://www.eurekalog.com/buy.php
>>>
>>>
>>>To see the changes visit:
>>>
>>>http://www.eurekalog.com/openfile.php?file=changelog.txt&title=Change%20Log
>>>or simply
>>>http://www.eurekalog.com/changelog.txt
>>>
>>>--
>>>Best regards.
>>>
>>>The EurekaLog Team.

[Fabio Dell'Aria]

Jason wrote:
> Oh great !
>
> can you please explain me the "3" a bit more?
>
> Thanks

Feature:
--------
3)...Automatic search of error lines in modified sources(guarantee error
individuation in sources modified after the delivery);


Explanation:
------------
EurekaLog is capable to save a call-stack including the procedure offset
line (so if the procedure start at line 100 and the line number of call
stack is at line 113 the procedure offset is 13 = 113 - 100).

Using this value and the procedure name, EurekaLog is capable to find
the correct source line in modified unit sources too, all automatically.

When you do a double click on a call-stack line (in the EurekaLog dialog
or EurekaLog Viewer software), EurekaLog check if the unit was modified
after the .exe compilation and if it's so then try to find the line
using the procedure name and offset otherwise use the absolute line
number, this is handled full automatically.

I hope to have answered to your question jason! ;)


--
Best regards...

Fabio Dell'Aria.


> "Fabio Dell'Aria" <***@eurekalog.com> wrote in message
> news:43317f15$***@newsgroups.borland.com...
>
>>Jason wrote:
>>
>>>Why use Eureka instead of madexcept? Any differences?
>>>
>>
>>I'm listing only some differences...
>>
>>1)...128 bit debug data encryption (to protect from the cracking). You can
>>encrypt the debug data without saving the password in the .exe file, the
>>final call-stack will be sent to you encrypted. You'll can decrypt it only
>>using the EurekaLog Viewer inserting the just password.
>>
>>2)...IDE crashes saves (allow to save modified files after unrecoverable
>>IDE crashes);
>>
>>3)...Automatic search of error lines in modified sources(guarantee error
>>individuation in sources modified after the delivery);
>>
>>4)...Advanced IDE/OS integrated Log Viewer (in the Projects menu);
>>
>>5)...Printable PDF manual;
>>
>>6)...Custom HTML template for HTML error page;
>>
>>7)...Advanced Tree view of all running/calling threads call-stacks;
>>8)...Calling Threads full call-stack showing.
>>
>>9)...Attach the last generated HTML page;
>>
>>10)...Send an XML Log's copy;
>>
>>11)...Send email/web message in a separated thread;
>>
>>
>>What do you think about? :)
>>
>>
>>--
>>Best regards...
>>
>>Fabio Dell'Aria.
>>
>>
>>> [...]

[madshi (Mathias Rauen)]

Sorry for posting in an EurekaLog thread. But since
there are some incorrect things posted here as
advantages of EurekaLog over madExcept, I do feel
the need to correct that, ok? :-)

> > Why use Eureka instead of madexcept? Any differences?
> I'm listing only some differences...

> 1)...128 bit debug data encryption (to protect from the
> cracking). You can encrypt the debug data without saving
> the password in the .exe file, the final call-stack will
> be sent to you encrypted. You'll can decrypt it only
> using the EurekaLog Viewer inserting the just password.

madExcept 3.0 has a different solution for this, which
however is even safer than that.

> 3)...Automatic search of error lines in modified sources
> (guarantee error individuation in sources modified after
> the delivery);

madExcept 3.0 supports that, too.

> 4)...Advanced IDE/OS integrated Log Viewer (in the
> Projects menu);

There's also a viewer for madExcept. (Which however
is not integrated into the IDE (yet)).

> 6)...Custom HTML template for HTML error page;

madExcept 2.x and 3.0 can do that, too (at runtime).

> 7)...Advanced Tree view of all running/calling threads
> call-stacks;

madExcept 3.0 lists all running threads, too.
(However, not in a tree view, but in a list view.)

> 11)...Send email/web message in a separated thread;

madExcept 3.0 supports that, too.

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[Jason]

Ehm, Im confused now ! Same price almost same features.


"madshi (Mathias Rauen)" <***@no-spam-madshi.net> wrote in message
news:43325839$***@newsgroups.borland.com...
> Sorry for posting in an EurekaLog thread. But since
> there are some incorrect things posted here as
> advantages of EurekaLog over madExcept, I do feel
> the need to correct that, ok? :-)
>
>> > Why use Eureka instead of madexcept? Any differences?
>> I'm listing only some differences...
>
>> 1)...128 bit debug data encryption (to protect from the
>> cracking). You can encrypt the debug data without saving
>> the password in the .exe file, the final call-stack will
>> be sent to you encrypted. You'll can decrypt it only
>> using the EurekaLog Viewer inserting the just password.
>
> madExcept 3.0 has a different solution for this, which
> however is even safer than that.
>
>> 3)...Automatic search of error lines in modified sources
>> (guarantee error individuation in sources modified after
>> the delivery);
>
> madExcept 3.0 supports that, too.
>
>> 4)...Advanced IDE/OS integrated Log Viewer (in the
>> Projects menu);
>
> There's also a viewer for madExcept. (Which however
> is not integrated into the IDE (yet)).
>
>> 6)...Custom HTML template for HTML error page;
>
> madExcept 2.x and 3.0 can do that, too (at runtime).
>
>> 7)...Advanced Tree view of all running/calling threads
>> call-stacks;
>
> madExcept 3.0 lists all running threads, too.
> (However, not in a tree view, but in a list view.)
>
>> 11)...Send email/web message in a separated thread;
>
> madExcept 3.0 supports that, too.
>
> --
> www.madshi.net
> high quality low level Delphi components
> extended exception handling
> API hooking, DLL injection

[Fabio Dell'Aria]

Jason wrote:
> Ehm, Im confused now ! Same price almost same features.
>

I have a good suggestion for you.

Download the trial version of both tools and verify to yourself what of
the two is best for your needs.

It's a really sage suggestion, no? ;)


--
Best regards...

Fabio Dell'Aria.

>
> "madshi (Mathias Rauen)" <***@no-spam-madshi.net> wrote in message
> news:43325839$***@newsgroups.borland.com...
>
>>Sorry for posting in an EurekaLog thread. But since
>>there are some incorrect things posted here as
>>advantages of EurekaLog over madExcept, I do feel
>>the need to correct that, ok? :-)
>>
>>
>>>>Why use Eureka instead of madexcept? Any differences?
>>>
>>>I'm listing only some differences...
>>
>>>1)...128 bit debug data encryption (to protect from the
>>>cracking). You can encrypt the debug data without saving
>>>the password in the .exe file, the final call-stack will
>>>be sent to you encrypted. You'll can decrypt it only
>>>using the EurekaLog Viewer inserting the just password.
>>
>>madExcept 3.0 has a different solution for this, which
>>however is even safer than that.
>>
>>
>>>3)...Automatic search of error lines in modified sources
>>>(guarantee error individuation in sources modified after
>>>the delivery);
>>
>>madExcept 3.0 supports that, too.
>>
>>
>>>4)...Advanced IDE/OS integrated Log Viewer (in the
>>>Projects menu);
>>
>>There's also a viewer for madExcept. (Which however
>>is not integrated into the IDE (yet)).
>>
>>
>>>6)...Custom HTML template for HTML error page;
>>
>>madExcept 2.x and 3.0 can do that, too (at runtime).
>>
>>
>>>7)...Advanced Tree view of all running/calling threads
>>>call-stacks;
>>
>>madExcept 3.0 lists all running threads, too.
>>(However, not in a tree view, but in a list view.)
>>
>>
>>>11)...Send email/web message in a separated thread;
>>
>>madExcept 3.0 supports that, too.
>>
>>--
>>www.madshi.net
>>high quality low level Delphi components
>>extended exception handling
>>API hooking, DLL injection

[madshi (Mathias Rauen)]

I think that's a very good suggestion! Try both and
choose the one you like more.

I think most users of madExcept and EurekaLog only
ever tried the one they're currently using. There
are only few people who tried both (I think). Why
is that? I guess they're both good enough, so when
you tried one, you don't feel the need to try the
other one... :-)

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[Ronaldo Souza]

madshi (Mathias Rauen) wrote:
> Why is that? I guess they're both good enough, so when
> you tried one, you don't feel the need to try the other
> one... :-)

Or... By the time a typical programmer decides to use any of these
*great* tools, he is very close to desperation and when, with their
help, he finally manages to fix the bug, he is so happy and behind
schedule that the last word he wants to read/say/write/think is
"exception"... :-)

{$DEFINE HATS_OFF}
Thanks both Mathias and Fabio for taking such good care of our sanity.
{$UNDEF HATS_OFF}

Ronaldo

[Fabio Dell'Aria]

Ronaldo Souza wrote:
> madshi (Mathias Rauen) wrote:
>
>> Why is that? I guess they're both good enough, so when
>> you tried one, you don't feel the need to try the other
>> one... :-)
>
>
> Or... By the time a typical programmer decides to use any of these
> *great* tools, he is very close to desperation and when, with their
> help, he finally manages to fix the bug, he is so happy and behind
> schedule that the last word he wants to read/say/write/think is
> "exception"... :-)
>
> {$DEFINE HATS_OFF}
> Thanks both Mathias and Fabio for taking such good care of our sanity.
> {$UNDEF HATS_OFF}
>
> Ronaldo

ehehehehe :P


--
Best regards...

Fabio Dell'Aria.
----------------
http://www.eurekalog.com
Catch every BUG showing line n.

[Paul Dolen]

>I think most users of madExcept and EurekaLog only
>ever tried the one they're currently using. There
>are only few people who tried both (I think). Why
>is that? I guess they're both good enough, so when
>you tried one, you don't feel the need to try the
>other one... :-)

That's the case for me, I bought EurekaLog before I ever heard of your
product. Since yours is cheaper, if I was buying now, I might buy
yours. But, since I already have EurekaLog, I see no reason to bother
trying yours.

[Jouni Turunen]

Jason wrote:
> Ehm, Im confused now ! Same price almost same features.
>

Not exactly, madExcept is $99 with full source included.
EurekaLog is $99 without sources and $149 with sources.
I woudn't buy this kind of package without full source code.

I'm a very happy madExcept user but can't say bad about EurekaLog
either. I think that both are very good products. Download
trial versions and check which one feels better.


Regards,
Jouni

[Ivan Pastine]

I'm not really concerned about the $50 difference. For me the biggest
difference in price is the licensing scheme that allows you to use
madExcept free in non-commercial applications. I write some apps for an
academic audience and it is helpfully if people can recompile the
sources (they just need the $100 academic edition of Delphi). So with
madExcept I can use the same exception handler in both my commercial and
non-commercial apps.

Jouni Turunen wrote:

> Not exactly, madExcept is $99 with full source included.
> EurekaLog is $99 without sources and $149 with sources.
> I woudn't buy this kind of package without full source code.

[Kevin Powick]

Jason wrote:

> Ehm, Im confused now ! Same price almost same features.

Both are excellent products with excellent support and reputations.
For most, it will just come down to personal preference.

I don't think you can go wrong with either one.

As stated in this thread, download both and give them a try.

Personally, I use madExcept -- maybe only because I came across it
first when looking for this type of solution, but it has never given me
any reason to try something else.

--
Kevin Powick

[Jonathan Neve[Microtec]]

Kevin Powick wrote:

> Jason wrote:
>
> > Ehm, Im confused now ! Same price almost same features.
>
> Both are excellent products with excellent support and reputations.
> For most, it will just come down to personal preference.
>
> I don't think you can go wrong with either one.
>
> As stated in this thread, download both and give them a try.
>
> Personally, I use madExcept -- maybe only because I came across it
> first when looking for this type of solution, but it has never given
> me any reason to try something else.
>

Same here. I use EurekaLog, mainly because at the time when I looked
into it, madExcept had more limited C++Builder support (I think that
has changed now, but I'm not sure). I've been very satisfied with
EurekaLog, and so I've had no reason to need to consider the
alternative.
--
Best regards,
Jonathan Neve
_______________
CopyCat - advanced database replication
components for Delphi/C++Builder!
_______________________________________
Version 1.0 now available!
Web : http://www.microtec.fr/copycat

[Fabio Dell'Aria]

Hi Mathias,
I'm happy to see you here! ;)

madshi (Mathias Rauen) wrote:
> Sorry for posting in an EurekaLog thread. But since
> there are some incorrect things posted here as
> advantages of EurekaLog over madExcept, I do feel
> the need to correct that, ok? :-)
>

No problem. :)

>
>>>Why use Eureka instead of madexcept? Any differences?
>>
>>I'm listing only some differences...
>
>
>>1)...128 bit debug data encryption (to protect from the
>>cracking). You can encrypt the debug data without saving
>>the password in the .exe file, the final call-stack will
>>be sent to you encrypted. You'll can decrypt it only
>>using the EurekaLog Viewer inserting the just password.
>
>
> madExcept 3.0 has a different solution for this, which
> however is even safer than that.
>

How MadExcept handle this?

>
--
Best regards...

Fabio Dell'Aria.

[madshi (Mathias Rauen)]

Hi Fabio,

> > > 1)...128 bit debug data encryption (to protect from the
> > > cracking). You can encrypt the debug data without saving
> > > the password in the .exe file, the final call-stack will
> > > be sent to you encrypted. You'll can decrypt it only
> > > using the EurekaLog Viewer inserting the just password.
> > madExcept 3.0 has a different solution for this, which
> > however is even safer than that.
> How MadExcept handle this?

You can (optionally) compile madExcept with only very
minor map file information (just the entry points of
all functions). No function/unit names are included
in the exe this way, no line number information, either.
Obviously nobody can crack information which is not even
in the exe. So I consider this to be VERY safe.

The bug report looks a bit strange that way, it contains
things like "public%637". The developer has a tool which
can then "compile" such a bug report to a real bug report
by filling the missing information back in with the help
of the original map file. The tool automatically finds
the correct map file in a folder full of map files, so
it's also comfortably to use. I plan to integrate this
all into the next version of my viewer to make it as
easy to use as possible.

It's a different solution to yours. I think yours might
be a bit more comfortable, because your users don't need
to store the map files. But my solution should be a bit
more safe. E.g. I believe the line number information
is not protected by EurekaLog. Also with my solution
the exe is smaller, but I think the size is not very
important.

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[madshi (Mathias Rauen)]

P.S: Just for clarification: I'm not even sure myself
which solution I like more. Both have pros and cons.
I also thought about implement a similar solution to
yours, but I didn't find a good way to protect the
line number information, so I chose the solution I'm
using now.

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[Jason]

Does madexcept 3 will tell me the line code even if i make changes to source
code?


"madshi (Mathias Rauen)" <***@no-spam-madshi.net> wrote in message
news:43327f2f$***@newsgroups.borland.com...
> Hi Fabio,
>
>> > > 1)...128 bit debug data encryption (to protect from the
>> > > cracking). You can encrypt the debug data without saving
>> > > the password in the .exe file, the final call-stack will
>> > > be sent to you encrypted. You'll can decrypt it only
>> > > using the EurekaLog Viewer inserting the just password.
>> > madExcept 3.0 has a different solution for this, which
>> > however is even safer than that.
>> How MadExcept handle this?
>
> You can (optionally) compile madExcept with only very
> minor map file information (just the entry points of
> all functions). No function/unit names are included
> in the exe this way, no line number information, either.
> Obviously nobody can crack information which is not even
> in the exe. So I consider this to be VERY safe.
>
> The bug report looks a bit strange that way, it contains
> things like "public%637". The developer has a tool which
> can then "compile" such a bug report to a real bug report
> by filling the missing information back in with the help
> of the original map file. The tool automatically finds
> the correct map file in a folder full of map files, so
> it's also comfortably to use. I plan to integrate this
> all into the next version of my viewer to make it as
> easy to use as possible.
>
> It's a different solution to yours. I think yours might
> be a bit more comfortable, because your users don't need
> to store the map files. But my solution should be a bit
> more safe. E.g. I believe the line number information
> is not protected by EurekaLog. Also with my solution
> the exe is smaller, but I think the size is not very
> important.
>
> --
> www.madshi.net
> high quality low level Delphi components
> extended exception handling
> API hooking, DLL injection

[Danijel Tkalcec (RealThinClient)]

"Jason" wrote:
> Does madexcept 3 will tell me the line code even if i make changes to
> source code?

It looks like this was what Mathias said in his post. From what I read here,
I guess the main differences between your implementations for this feature
are:

1) EurekaLog includes line numbers in exe, madExcept doesn't. This is why
executables compiled with maxExcept will be smaller than those compiled with
EurekaLog.

2) EurekaLog will atomaticaly detect changes in source code using
information stored in the exe file, while madExcept uses an external MAP
file (probably from the old exe) to do this.

I gess, both methods can be used to achieve the same goal. One is easier to
use, the other one produces smaller executables. I don't know whether safety
plays a big role in this, since I would guess that you are able to use some
king of encryption in EurekaLog to "hide" line number information in exe
files.

--
Danijel Tkalcec

RealThinClient components
http://www.realthinclient.com
news://news.realthinclient.com

[Danijel Tkalcec (RealThinClient)]

"Matthew Jones" wrote:
>> encryption in EurekaLog to "hide" line number information
>
> I'm not sure that line number information is particularly valuable either.
>
> "Goodness, there's a line 503 in the source. So that's how they do it!"

You're probably right about that, if it was a naive kid playing arround with
someone else's code.

But it still depends on what exactly is stored in the exe file. I guess it
has to be more than a simple array of line numbers to make sure that the
appropriate line number really belongs to a specific
method/event/procedure/function. It is more likely that procedure, function,
class and method names are stored in that exe.

Since I don't know what or how EurekaLog this does this (nor madExcept), I
am only speculating on how this could have been done to guarantee that
correct line of code will be mapped to changed source files. I would also
guess that EurekaLog is able to encrypt that information, since that info
has to be stored separately from executable code anyway (most likely
somewhere at the end of the executable file).

On the other hand ... if some hacker wanted to encrypt any information
stored in the exe file, he will most likely find a way to do it (only a
matter of time). If someone is so worried about his code being
dis-assembled, he might as well find himself some other job, because there
is absolutely no protection against exe file cracking or hacking (that is,
if the right person is doing it). Every application can be hacked/broken (by
the right person).

When it comes to disasembling, I would have to agree with Mathias that the
best way to hide something is to avoid including it in your deployed
application. If application can work without that additional source code
information, there's no safer way than this.

--
Danijel Tkalcec

RealThinClient components
http://www.realthinclient.com
news://news.realthinclient.com

[Fabio Dell'Aria]

Danijel Tkalcec (RealThinClient) wrote:
> "Matthew Jones" wrote:
>
>>>encryption in EurekaLog to "hide" line number information
>>
>>I'm not sure that line number information is particularly valuable either.
>>
>>"Goodness, there's a line 503 in the source. So that's how they do it!"
>
>
> You're probably right about that, if it was a naive kid playing arround with
> someone else's code.
>
> But it still depends on what exactly is stored in the exe file. I guess it
> has to be more than a simple array of line numbers to make sure that the
> appropriate line number really belongs to a specific
> method/event/procedure/function. It is more likely that procedure, function,
> class and method names are stored in that exe.
>
> Since I don't know what or how EurekaLog this does this (nor madExcept), I
> am only speculating on how this could have been done to guarantee that
> correct line of code will be mapped to changed source files. I would also
> guess that EurekaLog is able to encrypt that information, since that info
> has to be stored separately from executable code anyway (most likely
> somewhere at the end of the executable file).
>
> On the other hand ... if some hacker wanted to encrypt any information
> stored in the exe file, he will most likely find a way to do it (only a
> matter of time). If someone is so worried about his code being
> dis-assembled, he might as well find himself some other job, because there
> is absolutely no protection against exe file cracking or hacking (that is,
> if the right person is doing it). Every application can be hacked/broken (by
> the right person).
>
> When it comes to disasembling, I would have to agree with Mathias that the
> best way to hide something is to avoid including it in your deployed
> application. If application can work without that additional source code
> information, there's no safer way than this.

Yes, it's so.
But if the time to decrypt the data is of about
11.000.000.000.000.000.000.000 years (see my next threads for further
details) then the result is the same, no? :)

--
Best regards...

Fabio Dell'Aria.

[Danijel Tkalcec (RealThinClient)]

As for me, I never had any problems with hacked or disassembled applications
in my life, not counting one time when I asked one of my hacker-friends to
hack my accounting app, simply being curious to see how long it would take
(it took him less than 5 minutes to override my protection).

Anyway ... I wouldn't really bother with such "security" issues, if I'm not
writing some high-security algorithms worth a couple of billion bucks whoose
disasembling could eliminate most of earth's population.

--
Danijel Tkalcec

RealThinClient components
http://www.realthinclient.com
news://news.realthinclient.com

[Matthew Jones]

> encryption in EurekaLog to "hide" line number information

I'm not sure that line number information is particularly valuable either.

"Goodness, there's a line 503 in the source. So that's how they do it!"

/Matthew Jones/

[Jonathan Neve[Microtec]]

Matthew Jones wrote:

> > encryption in EurekaLog to "hide" line number information
>
> I'm not sure that line number information is particularly valuable
> either.
>
> "Goodness, there's a line 503 in the source. So that's how they do
> it!"

:)

I agree.
--
Best regards,
Jonathan Neve
_______________
CopyCat - advanced database replication
components for Delphi/C++Builder!
_______________________________________
Version 1.0 now available!
Web : http://www.microtec.fr/copycat

[Jonathan Neve[Microtec]]

madshi (Mathias Rauen) wrote:

> Yeah, it's somewhat questionable whether protecting
> line numbers is really that important. However,
> just think about someone creating a full disassembling
> of a little dll of yours. Now if the disassembling
> also contains line numbers, it might be a very small
> help for understanding the disassembly. It's really
> a small thing and protecting function names is surely
> much more important. But I think for someone who is
> paranoid about reverse engineering, protecting line
> numbers might be an added value.
>
> Personally, I'm not using this security functionality
> in any of my own projects. But there were several
> customers asking for improved reverse engineering
> security.

Yes, some people really /are/ paranoid. ;)
--
Best regards,
Jonathan Neve
_______________
CopyCat - advanced database replication
components for Delphi/C++Builder!
_______________________________________
Version 1.0 now available!
Web : http://www.microtec.fr/copycat

[madshi (Mathias Rauen)]

Heh... :-P

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[madshi (Mathias Rauen)]

Yeah, it's somewhat questionable whether protecting
line numbers is really that important. However,
just think about someone creating a full disassembling
of a little dll of yours. Now if the disassembling
also contains line numbers, it might be a very small
help for understanding the disassembly. It's really
a small thing and protecting function names is surely
much more important. But I think for someone who is
paranoid about reverse engineering, protecting line
numbers might be an added value.

Personally, I'm not using this security functionality
in any of my own projects. But there were several
customers asking for improved reverse engineering
security.

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[Fabio Dell'Aria]

madshi (Mathias Rauen) wrote:
> Hi Fabio,
>
>
>>>>1)...128 bit debug data encryption (to protect from the
>>>>cracking). You can encrypt the debug data without saving
>>>>the password in the .exe file, the final call-stack will
>>>>be sent to you encrypted. You'll can decrypt it only
>>>>using the EurekaLog Viewer inserting the just password.
>>>
>>>madExcept 3.0 has a different solution for this, which
>>>however is even safer than that.
>>
>>How MadExcept handle this?
>
>
> You can (optionally) compile madExcept with only very
> minor map file information (just the entry points of
> all functions). No function/unit names are included
> in the exe this way, no line number information, either.
> Obviously nobody can crack information which is not even
> in the exe. So I consider this to be VERY safe.
>
> The bug report looks a bit strange that way, it contains
> things like "public%637". The developer has a tool which
> can then "compile" such a bug report to a real bug report
> by filling the missing information back in with the help
> of the original map file. The tool automatically finds
> the correct map file in a folder full of map files, so
> it's also comfortably to use. I plan to integrate this
> all into the next version of my viewer to make it as
> easy to use as possible.
>
> It's a different solution to yours. I think yours might
> be a bit more comfortable, because your users don't need
> to store the map files. But my solution should be a bit
> more safe. E.g. I believe the line number information
> is not protected by EurekaLog. Also with my solution
> the exe is smaller, but I think the size is not very
> important.

To decrypt the EurekaLog data without the password is need to do a
brute-force attack.
Using a supercomputer able to execute 1.000.000.000 attacks/sec you need
about 11.000.000.000.000.000.000.000 years to can obtain the password.
Also with the EurekaLog solution the developer did not save the .MAP file.
So I think that this is a comfortable and VERY SAFE solution, no? ;)

However, these are two solutions of the same problems, and no one is
better of other.

At the final users the final conclusion! :)

--
Best regards...

Fabio Dell'Aria.

[Danijel Tkalcec (RealThinClient)]

I wouldn't really bother with this issue, Fabio. This "security" thing is
really irrelevant.

But just for your information ... there is no code which can not be broken
in a normal time period, by using combined forces of millions of computers
on the internet. You should check some of the "crack-the-key" contests done
by the RSA Security on www.reasecurity.com before you say that you have one
unbreakable encryption algorithm ;)

--
Danijel Tkalcec

RealThinClient components
http://www.realthinclient.com
news://news.realthinclient.com

[Fabio Dell'Aria]

Danijel Tkalcec (RealThinClient) wrote:
> I wouldn't really bother with this issue, Fabio. This "security" thing is
> really irrelevant.
>
> But just for your information ... there is no code which can not be broken
> in a normal time period, by using combined forces of millions of computers
> on the internet. You should check some of the "crack-the-key" contests done
> by the RSA Security on www.reasecurity.com before you say that you have one
> unbreakable encryption algorithm ;)
>

;-)

--
Best regards...

Fabio Dell'Aria.

[madshi (Mathias Rauen)]

Fabio, if I understand EurekaLog right, I think
you protect the function names with a password
that the programmer can choose (and which is not
stored in the exe), while the line number
information is only protected by a program
generated password, or am I wrong?

I believe to remember when I tested the EurekaLog
protection functionality that the bug report
did contain line number information even though
I had not entered the password. So it seems to
me that EurekaLog can get access to the line
number information without needing the user
defined password. Or am I wrong?

Not totally sure, please correct me if I got
it wrong.

If I got it right, the line number information
is not too well protected, cause a program
generated password is rather easy crackable,
especially if the hacker has access to the
EurekaLog source code!

Another thing I've been wondering about: You
probably protect each function name seperately,
is that correct? In that case the protection
might also suffer, because just by looking at
the source code it might be easy to figure out
some function names like e.g. "initialization".
If you have both the real name and the encrypted
name, might it not be easier to calculate the
password? I'm not sure, I'm not really an
encryption expert. But I could imagine that
protecting several hundreds/thousands of
relatively short function names with the very
same password could eventually be somewhat
crackable. (Perhaps you could work around it
by altering the password after each encrypted
name a bit?). But as I said, I'm not an expert
here, I might be totally off.

What do you think?

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[Danijel Tkalcec (RealThinClient)]

Hi Mathias,

I'm sure it is possible to crack EurekaLog, but this is really irrelevant.
If a hacker wants to crack an application, he surely won't expect to find
source code info in the file. And for that, he won't really care even if it
is there. So, what the heck. Even if there is totaly unencrypted line number
information in files produced by EurekaLog, it really makes no difference to
a hacker.

Btw ... I have just purchased a licensed copy of madExcept, even though I
was thinking about ordering EurekaLog a few hours before. For me, there were
two reasons for choosing madExcept over EurekaLog:

1) you said madExcept produces smaller executables because of less source
code information stored in them, which is very important in my case, since I
deploy my applications over the internet.

2) I liked your form design better than that of EurekaLog. Even though it
has absolutely nothing to do with your products functionality, it was one
decision-maker for me.

3) I liked your price better than that of EurekaLog. And this was the most
important decision-maker for me.

I guess, there will be a number of developers which will have other criteria
for choosing between EurekaLog and madExcept, but for me, as long as both do
their job (show detailed call stack on exception, which can be sent to me by
E-Mail with a screenshot), I doubt there will ever be any technical issue
becaue of which someone would choose one component over the other.

PS. there was one thing that dissapointed me in your order process, Mathias.
I think that it's not very nice to charge 16% more to your contrymen ;) I'm
selling my components using ShareIt also, but I chose to pay those 16% VAT
myself by geting less cache from the customer, rather than telling them to
pay VAT if they are from EU. I was close to not making the order, just
because of that "discrimination". I know the Tax-Laws, but still ... it
doesn't look nice :P Anyway ... since your product was still less expensive
than EurekaLog, I guess I will have to live with it.

--
Danijel Tkalcec

RealThinClient components
http://www.realthinclient.com
news://news.realthinclient.com

[madshi (Mathias Rauen)]

Hi Danijel,

> If a hacker wants to crack an
> application, he surely won't expect to find source
> code info in the file. And for that, he won't really
> care even if it is there. So, what the heck.

I do not necessarily disagree with you. But both Fabio
and I do have several customers for whom protection
from reverse engineering is important. Maybe they're
paranoid, but it's not my call to make. Several
customers asked, so I implemented it. I guess it was
the same for Fabio.

> 1) you said madExcept produces smaller executables
> because of less source code information stored in
> them, which is very important in my case, since I
> deploy my applications over the internet.

Well, the smaller executable is mainly there, if you
do use the extra security feature to not deploy the
map file information at all. In that case you'll get
a smaller executable file, but you'll lose a bit of
comfort. I'm not totally sure whether madExcept or
EurekaLog give you smaller file sizes when you don't
use the extra security feature.

> PS. there was one thing that dissapointed me in your
> order process, Mathias. I think that it's not very
> nice to charge 16% more to your contrymen ;)

I'm sorry for that.

Hmmmm... Maybe I should raise overall prices 16% and
drop VAT for german customers in turn to make it more
fair... :-)

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[Fabio Dell'Aria]

Danijel Tkalcec (RealThinClient) wrote:
> Hi Mathias,
>
> I'm sure it is possible to crack EurekaLog, but this is really irrelevant.
> If a hacker wants to crack an application, he surely won't expect to find
> source code info in the file. And for that, he won't really care even if it
> is there. So, what the heck. Even if there is totaly unencrypted line number
> information in files produced by EurekaLog, it really makes no difference to
> a hacker.

:)

> Btw ... I have just purchased a licensed copy of madExcept, even though I
> was thinking about ordering EurekaLog a few hours before. For me, there were
> two reasons for choosing madExcept over EurekaLog:
>
> 1) you said madExcept produces smaller executables because of less source
> code information stored in them, which is very important in my case, since I
> deploy my applications over the internet.

Just as information *and not for polemics*:

I have create a Delphi 7 empty project and compiled it with MadExcept 3
(with "include minimal debug info only" actived) and after with
EurekaLog 5, following the results:

MadExcept 3: 711 Kb;
EurekaLog 5: 618 Kb;

> 2) I liked your form design better than that of EurekaLog. Even though it
> has absolutely nothing to do with your products functionality, it was one
> decision-maker for me.
>
> 3) I liked your price better than that of EurekaLog. And this was the most
> important decision-maker for me.
>
> I guess, there will be a number of developers which will have other criteria
> for choosing between EurekaLog and madExcept, but for me, as long as both do
> their job (show detailed call stack on exception, which can be sent to me by
> E-Mail with a screenshot), I doubt there will ever be any technical issue
> becaue of which someone would choose one component over the other.
>
> PS. there was one thing that dissapointed me in your order process, Mathias.
> I think that it's not very nice to charge 16% more to your contrymen ;) I'm
> selling my components using ShareIt also, but I chose to pay those 16% VAT
> myself by geting less cache from the customer, rather than telling them to
> pay VAT if they are from EU. I was close to not making the order, just
> because of that "discrimination". I know the Tax-Laws, but still ... it
> doesn't look nice :P Anyway ... since your product was still less expensive
> than EurekaLog, I guess I will have to live with it.
>


--
Best regards...

Fabio Dell'Aria.
----------------
http://www.eurekalog.com
Catch every BUG showing line n.

[madshi (Mathias Rauen)]

> I have create a Delphi 7 empty project and compiled
> it with MadExcept 3 (with "include minimal debug info
> only" actived) and after with EurekaLog 5, following
> the results:
> MadExcept 3: 711 Kb;
> EurekaLog 5: 618 Kb;

While a test with an empty app is certainly interesting
(it mainly shows that madExcept currently has a somewhat
bigger code footprint), the size benefit of the "include
minimal debug info only" option only really shows with
applications which have bigger map files than an empty
app. With an empty app the benefit of the option is only
30kb. With a 5.5MB app the benefit is already 200-300kb.
Basically with the option turned off the exe size grows
to the original size + code footprint + some percent on
top of the original size for the map file info. With the
option turned on the final exe size is basically only
the exe size plus the code footprint. So the bigger the
app is, the bigger is also the benefit of turning that
option on.

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[Fabio Dell'Aria]

madshi (Mathias Rauen) wrote:
>>I have create a Delphi 7 empty project and compiled
>>it with MadExcept 3 (with "include minimal debug info
>>only" actived) and after with EurekaLog 5, following
>>the results:
>>MadExcept 3: 711 Kb;
>>EurekaLog 5: 618 Kb;
>
>
> While a test with an empty app is certainly interesting
> (it mainly shows that madExcept currently has a somewhat
> bigger code footprint), the size benefit of the "include
> minimal debug info only" option only really shows with
> applications which have bigger map files than an empty
> app. With an empty app the benefit of the option is only
> 30kb. With a 5.5MB app the benefit is already 200-300kb.
> Basically with the option turned off the exe size grows
> to the original size + code footprint + some percent on
> top of the original size for the map file info. With the
> option turned on the final exe size is basically only
> the exe size plus the code footprint. So the bigger the
> app is, the bigger is also the benefit of turning that
> option on.

Yes, I understand.
It's reasonable. :)

--
Best regards...

Fabio Dell'Aria.
----------------
http://www.eurekalog.com
Catch every BUG showing line n.

[Fabio Dell'Aria]

madshi (Mathias Rauen) wrote:
> Fabio, if I understand EurekaLog right, I think
> you protect the function names with a password
> that the programmer can choose (and which is not
> stored in the exe), while the line number
> information is only protected by a program
> generated password, or am I wrong?
>
> I believe to remember when I tested the EurekaLog
> protection functionality that the bug report
> did contain line number information even though
> I had not entered the password. So it seems to
> me that EurekaLog can get access to the line
> number information without needing the user
> defined password. Or am I wrong?
>
> Not totally sure, please correct me if I got
> it wrong.

Yes, the line number it isn't protect as the unit/procedure names, but
this because the line numbers alone are unusable (at least I think). :)

>
> If I got it right, the line number information
> is not too well protected, cause a program
> generated password is rather easy crackable,
> especially if the hacker has access to the
> EurekaLog source code!
>
> Another thing I've been wondering about: You
> probably protect each function name seperately,
> is that correct? In that case the protection
> might also suffer, because just by looking at
> the source code it might be easy to figure out
> some function names like e.g. "initialization".
> If you have both the real name and the encrypted
> name, might it not be easier to calculate the
> password? I'm not sure, I'm not really an
> encryption expert. But I could imagine that
> protecting several hundreds/thousands of
> relatively short function names with the very
> same password could eventually be somewhat
> crackable. (Perhaps you could work around it
> by altering the password after each encrypted
> name a bit?). But as I said, I'm not an expert
> here, I might be totally off.
>
> What do you think?

I think that the utility of cracked information are not comparable to
the time needed to cracked them.

PS: Mathias with my previous thread I don't wanted create a comparison
war, and now we staying comparing our two good tool at microscope! :(

--
Best regards...

Fabio Dell'Aria.

[madshi (Mathias Rauen)]

> the line numbers alone are unusable (at least
> I think). :)

Might very well be true. I'm not really sure
about it myself!

> PS: Mathias with my previous thread I don't
> wanted create a comparison war, and now we
> staying comparing our two good tool at
> microscope! :(

Ok, let's drop it. I'm sorry, if I've gone too
far...

It's just that I was thinking about using a
similar approach you're using, too, when I
implemented mine. So I just shared my thoughts
which I had back then.

In the end I still think that your approach
is more comfortable and mine a very little
bit more safe. So in the end I'm still not
sure which approach is better...

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[Fabio Dell'Aria]

madshi (Mathias Rauen) wrote:
>>the line numbers alone are unusable (at least
>>I think). :)
>
>
> Might very well be true. I'm not really sure
> about it myself!
>
>
>>PS: Mathias with my previous thread I don't
>>wanted create a comparison war, and now we
>>staying comparing our two good tool at
>>microscope! :(
>
>
> Ok, let's drop it. I'm sorry, if I've gone too
> far...
>
> It's just that I was thinking about using a
> similar approach you're using, too, when I
> implemented mine. So I just shared my thoughts
> which I had back then.
>
> In the end I still think that your approach
> is more comfortable and mine a very little
> bit more safe. So in the end I'm still not
> sure which approach is better...

Yes, it's so! :)

--
Best regards...

Fabio Dell'Aria.
----------------
http://www.eurekalog.com
Catch every BUG showing line n.

[Matthew Jones]

> In the end I still think that your approach
> is more comfortable and mine a very little
> bit more safe

I look forward to both products getting both options in the future. I
think this has been very healthy competition, and great for Delphi
developers. I hope you two are making a good living from it.

/Matthew Jones/

[madshi (Mathias Rauen)]

> I look forward to both products getting both
> options in the future.

Hmmmm... Not sure whether I'll do that. After all
most people here expressed the opinion that the
added security isn't really worth it at all. So
I rather think one option for added security is
good enough, don't you think so?

> I think this has been very healthy competition,
> and great for Delphi developers.

Yeah, Fabio and I are constantly pushing each
other. Maybe we should agree to not add brand
new features so fast in the future, so that we
can enjoy life a bit more... :-)

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[Fabio Dell'Aria]

madshi (Mathias Rauen) wrote:
>>I look forward to both products getting both
>>options in the future.
>
>
> Hmmmm... Not sure whether I'll do that. After all
> most people here expressed the opinion that the
> added security isn't really worth it at all. So
> I rather think one option for added security is
> good enough, don't you think so?
>
>
>>I think this has been very healthy competition,
>>and great for Delphi developers.
>
>
> Yeah, Fabio and I are constantly pushing each
> other. Maybe we should agree to not add brand
> new features so fast in the future, so that we
> can enjoy life a bit more... :-)
>

Sage words, Mathias! :)

--
Best regards...

Fabio Dell'Aria.
----------------
http://www.eurekalog.com
Catch every BUG showing line n.

[Jim McKay]

Fabio Dell'Aria said...

>PS: Mathias with my previous thread I don't wanted create a comparison war, and
> now we staying comparing our two good tool at microscope! :(

Doesn't read that way to me, rather just very informative thread.

AFAIC, you two guys handling of this conversation sets a high bar compared
to other such conversations I've seen here.

I tip my hat to the both of you.

--
Regards:
Jim McKay

"If English was good enough for Jesus Christ, it's
good enough for us."

- Miriam Amanda "Ma" Ferguson (1875-1961),
Governor of Texas (1925-1927, 1933-1935)

From speech advocating barring foreign language teaching

Posted with XanaNews: Ver: 1.17.6.3

[Jonathan Neve[Microtec]]

Jim McKay wrote:

> Fabio Dell'Aria said...
>
> > PS: Mathias with my previous thread I don't wanted create a
> > comparison war, and now we staying comparing our two good tool
> > at microscope! :(
>
> Doesn't read that way to me, rather just very informative thread.
>
> AFAIC, you two guys handling of this conversation sets a high bar
> compared to other such conversations I've seen here.
>
> I tip my hat to the both of you.

Yes, definitely. Competitors are seldom so courtious.
--
Best regards,
Jonathan Neve
_______________
CopyCat - advanced database replication
components for Delphi/C++Builder!
_______________________________________
Version 1.0 now available!
Web : http://www.microtec.fr/copycat

[madshi (Mathias Rauen)]

Thank you, Jim and Jonathan! :-P

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[Fabio Dell'Aria]

madshi (Mathias Rauen) wrote:
> Thank you, Jim and Jonathan! :-P
>

Thank you from me too! ;)

--
Best regards...

Fabio Dell'Aria.
----------------
http://www.eurekalog.com
Catch every BUG showing line n.

[Raymond Schappe]

I agree - what an informative and refreshing thread!!!

I have been meaning to purchase one of your solutions for quite some
time... but something else always needs attention first.

Maybe now is the time ;)

A question, I use ASPack (for size and very slight protection) - will
both MadExcept and EurekaLog work with ASPack?

Are there any problems or limitations?

Thank you,
-Raymond

>
> Thank you from me too! ;)
>

[madshi (Mathias Rauen)]

I think both products will work fine with ASPack.

--
www.madshi.net
high quality low level Delphi components
extended exception handling
API hooking, DLL injection

[Fabio Dell'Aria]

Raymond Schappe wrote:
> I agree - what an informative and refreshing thread!!!
>
> I have been meaning to purchase one of your solutions for quite some
> time... but something else always needs attention first.
>
> Maybe now is the time ;)
>
> A question, I use ASPack (for size and very slight protection) - will
> both MadExcept and EurekaLog work with ASPack?
>
> Are there any problems or limitations?
>
> Thank you,
> -Raymond
>
>>
>> Thank you from me too! ;)

EurekaLog works 100% with ASPack in Win 9X/ME/200X/NT and XP systems.

Works 100% also with ASProtect, Armadillo, ICELicense, UPX and much more
EXE compression/protection tools.

--
Best regards...

Fabio Dell'Aria.
----------------
http://www.eurekalog.com
Catch every BUG showing line n.

[Jens Fudickar]

I second this !!!

Jim McKay wrote:
> Fabio Dell'Aria said...
>
>> PS: Mathias with my previous thread I don't wanted create a comparison war, and
>> now we staying comparing our two good tool at microscope! :(
>
> Doesn't read that way to me, rather just very informative thread.
>
> AFAIC, you two guys handling of this conversation sets a high bar compared
> to other such conversations I've seen here.
>
> I tip my hat to the both of you.
>

--
___________________________________________________________
Softwareentwicklung Jens Fudickar
Fuchstanzweg 34 * 65760 Eschborn
Tel. [phone] * Fax [phone]

Home of OraTool - http://www.oratool.de

[Ronaldo Souza]

Jens Fudickar wrote:
> I second this !!!

Agree 100%!!!!

[Jason]

It start getting tired...


"Jim McKay" <***@yahoo.com> wrote in message
news:4332d326$***@newsgroups.borland.com...
Fabio Dell'Aria said...

>PS: Mathias with my previous thread I don't wanted create a comparison war,
>and
> now we staying comparing our two good tool at microscope! :(

Doesn't read that way to me, rather just very informative thread.

AFAIC, you two guys handling of this conversation sets a high bar compared
to other such conversations I've seen here.

I tip my hat to the both of you.

--
Regards:
Jim McKay

"If English was good enough for Jesus Christ, it's
good enough for us."

- Miriam Amanda "Ma" Ferguson (1875-1961),
Governor of Texas (1925-1927, 1933-1935)

From speech advocating barring foreign language teaching

Posted with XanaNews: Ver: 1.17.6.3