www.digitalmars.com         C & C++   DMDScript  

c++.rtl - beg for rtl dll version

reply "nyra" <nyra sohu.com> writes:
It's a sad day! Something make me sad deeply!
All is dll, I can't build my own stlport dll, can't build boost thread
library!
They all need the rtl dll, the library named "snd.lib"

I beg you, Great Walter! please put "snd.lib" in downloadable package!
I promise I'd like to buy the CD version, but it's hard to do!

I'm chinese, far far from US.

PLEASE GIVE ME AND ALL SUCH A SMALL PIECE OF CAKE!
Jul 23 2003
parent reply "Walter" <walter digitalmars.com> writes:
The CD is so inexpensive, only $25, and has the dll's in it. I've made it
available at such a low cost so anyone can afford it.

"nyra" <nyra sohu.com> wrote in message
news:bfnap9$2je1$1 digitaldaemon.com...
 It's a sad day! Something make me sad deeply!
 All is dll, I can't build my own stlport dll, can't build boost thread
 library!
 They all need the rtl dll, the library named "snd.lib"

 I beg you, Great Walter! please put "snd.lib" in downloadable package!
 I promise I'd like to buy the CD version, but it's hard to do!

 I'm chinese, far far from US.

 PLEASE GIVE ME AND ALL SUCH A SMALL PIECE OF CAKE!
Jul 23 2003
next sibling parent "Greg Peet" <admin gregpeet.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bfnp0c$30ta$1 digitaldaemon.com...
 The CD is so inexpensive, only $25, and has the dll's in it. I've made it
 available at such a low cost so anyone can afford it.
This is true. nyra, do you know how the cost of everything (on digital mars cd): tools, modified api's, support, etc. compares to Intel, MS, Borland, and others' prices? I bought it and only had to do it once. Upgrades are free. I am not sorry that I made such a small investment (in terms of money) for such a large investment (the development tools).
Jul 24 2003
prev sibling parent reply "Nic Tiger" <tiger7 progtech.ru> writes:
CD is really inexpensive, but it may be little difficult to order it from
such countries as Russia or China.
I had to ask Doug Huffman to buy CD and then send it to me  via air-mail.
At that time only PayPal was acceptible for buying Digital Mars CD, but it
didn't permit to register users from Russia, for example.
Now VeriSign is avalable, but have never tried it and cannot guaratee that
it accepts users (and VISA cards!) from any country.

I really love Digital Mars. DMC CD is in fact invaluable. And about
prices... MSVC6 for $1500 is much, much worser than Digital Mars C++ fo $25.
Anything that is comparable to DMC is MSVC6 + IntelCompiler ($1500 + $500
respectivly), but it is 80 times more expensive.

Nic Tiger.

"Walter" <walter digitalmars.com> wrote in message
news:bfnp0c$30ta$1 digitaldaemon.com...
 The CD is so inexpensive, only $25, and has the dll's in it. I've made it
 available at such a low cost so anyone can afford it.

 "nyra" <nyra sohu.com> wrote in message
 news:bfnap9$2je1$1 digitaldaemon.com...
 It's a sad day! Something make me sad deeply!
 All is dll, I can't build my own stlport dll, can't build boost thread
 library!
 They all need the rtl dll, the library named "snd.lib"

 I beg you, Great Walter! please put "snd.lib" in downloadable package!
 I promise I'd like to buy the CD version, but it's hard to do!

 I'm chinese, far far from US.

 PLEASE GIVE ME AND ALL SUCH A SMALL PIECE OF CAKE!
Jul 25 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Nic Tiger" <tiger7 progtech.ru> wrote in message
news:bfrs2r$mql$1 digitaldaemon.com...
 CD is really inexpensive, but it may be little difficult to order it from
 such countries as Russia or China.
 I had to ask Doug Huffman to buy CD and then send it to me  via air-mail.
 At that time only PayPal was acceptible for buying Digital Mars CD, but it
 didn't permit to register users from Russia, for example.
 Now VeriSign is avalable, but have never tried it and cannot guaratee that
 it accepts users (and VISA cards!) from any country.
We take checks too! Interestingly, people buy DMC from all over the world. Sometimes even the postal clerks have never heard of the country!
 I really love Digital Mars. DMC CD is in fact invaluable. And about
 prices... MSVC6 for $1500 is much, much worser than Digital Mars C++ fo
$25.
 Anything that is comparable to DMC is MSVC6 + IntelCompiler ($1500 + $500
 respectivly), but it is 80 times more expensive.

 Nic Tiger.
There's no reason to pay such high prices!
Jul 25 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Well, yes and no.

I'm a big fan of DMC++, as you know, but I'm very glad to have access to the
Visual C++ IDE (although I must point out that I use VS 97 & 98 - I can't
stand what they've done to efficient non-mouse-needing coders with the
VB-swill that is VS.NET!), and obviously anyone working for a company where
$2000 is no big deal will (and should) by VS + Intel.

I would like to see two things happen:

1. DMC++ be plugable with VS. (I have in fact plans to do this myself - part
of the way there - but it's a time thing, so not likely before the end of
the year.)

2. the DMC++ IDDE scrapped, and an open-source IDDE for both C++ & D (and
pluggable so we can put other compilers into it) started (or built from the
existing IDDE if Walter can open-source it). If DMC++ had a killer IDDE -
COM and/or Python plug-ins for wizards, syntax highlighting, code
inspection, etc. etc. As long as it's managed properly, I find it hard to
believe that this community could not provide all that and more.

I guess the argument against is that Walter earns a (perfectly reasonable)
modest income from the CD, and I would not want to be the cause of that
drying up.



"Walter" <walter digitalmars.com> wrote in message
news:bfs92n$12gi$1 digitaldaemon.com...
 "Nic Tiger" <tiger7 progtech.ru> wrote in message
 news:bfrs2r$mql$1 digitaldaemon.com...
 CD is really inexpensive, but it may be little difficult to order it
from
 such countries as Russia or China.
 I had to ask Doug Huffman to buy CD and then send it to me  via
air-mail.
 At that time only PayPal was acceptible for buying Digital Mars CD, but
it
 didn't permit to register users from Russia, for example.
 Now VeriSign is avalable, but have never tried it and cannot guaratee
that
 it accepts users (and VISA cards!) from any country.
We take checks too! Interestingly, people buy DMC from all over the world. Sometimes even the postal clerks have never heard of the country!
 I really love Digital Mars. DMC CD is in fact invaluable. And about
 prices... MSVC6 for $1500 is much, much worser than Digital Mars C++ fo
$25.
 Anything that is comparable to DMC is MSVC6 + IntelCompiler ($1500 +
$500
 respectivly), but it is 80 times more expensive.

 Nic Tiger.
There's no reason to pay such high prices!
Jul 26 2003
parent reply "Nic Tiger" <tiger7 progtech.ru> writes:
Well, I think Visual Studio is the matter of taste. As for me, I hate it. I
had to use it several times and I think it is very unconvenient.
And resource editors in Visual Studio is real suxx.

I liked IDE made by Borland for Turbo C++ 3.0. It was the most convenient
IDE I ever saw. Borland C Builder's IDE comes near, it is certainly better
than VS,
but it is poorer than old Turbo C++ IDE.

Now I use Far+Colorer(for Win32), NC+BC3(as editor under DOS) and
smake+makefiles and it suits me very well.
Also it gives me possibility to have lower requirements for libraries used
by me: I can always turn GCC's makefiles into DMC's ones manually in about
30 min
and than everything works. How do I do it if I used to VS?

As for debugger, my opinion is: it is usefult for novices, for those who
want to understand how (particular) compiler works or for fighting minor
bugs.
For anything else it is useless. If you write DirectX exclusive-mode
application, you cannot use debugger. It is not the only example.
The main debugger should remain in developer's head. This is the most
advanced method of debugging.

And usual debugger is useful when human brain cannot understand program's
behaviour. But it takes place mainly due to compiler bugs.
I think I better will use bugless DMC than buggy VC6 and will not need
integrated debugger most times.

Nic Tiger.

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bfu5vh$44$1 digitaldaemon.com...
 Well, yes and no.

 I'm a big fan of DMC++, as you know, but I'm very glad to have access to
the
 Visual C++ IDE (although I must point out that I use VS 97 & 98 - I can't
 stand what they've done to efficient non-mouse-needing coders with the
 VB-swill that is VS.NET!), and obviously anyone working for a company
where
 $2000 is no big deal will (and should) by VS + Intel.

 I would like to see two things happen:

 1. DMC++ be plugable with VS. (I have in fact plans to do this myself -
part
 of the way there - but it's a time thing, so not likely before the end of
 the year.)

 2. the DMC++ IDDE scrapped, and an open-source IDDE for both C++ & D (and
 pluggable so we can put other compilers into it) started (or built from
the
 existing IDDE if Walter can open-source it). If DMC++ had a killer IDDE -
 COM and/or Python plug-ins for wizards, syntax highlighting, code
 inspection, etc. etc. As long as it's managed properly, I find it hard to
 believe that this community could not provide all that and more.

 I guess the argument against is that Walter earns a (perfectly reasonable)
 modest income from the CD, and I would not want to be the cause of that
 drying up.



 "Walter" <walter digitalmars.com> wrote in message
 news:bfs92n$12gi$1 digitaldaemon.com...
 "Nic Tiger" <tiger7 progtech.ru> wrote in message
 news:bfrs2r$mql$1 digitaldaemon.com...
 CD is really inexpensive, but it may be little difficult to order it
from
 such countries as Russia or China.
 I had to ask Doug Huffman to buy CD and then send it to me  via
air-mail.
 At that time only PayPal was acceptible for buying Digital Mars CD,
but
 it
 didn't permit to register users from Russia, for example.
 Now VeriSign is avalable, but have never tried it and cannot guaratee
that
 it accepts users (and VISA cards!) from any country.
We take checks too! Interestingly, people buy DMC from all over the
world.
 Sometimes even the postal clerks have never heard of the country!

 I really love Digital Mars. DMC CD is in fact invaluable. And about
 prices... MSVC6 for $1500 is much, much worser than Digital Mars C++
fo
 $25.
 Anything that is comparable to DMC is MSVC6 + IntelCompiler ($1500 +
$500
 respectivly), but it is 80 times more expensive.

 Nic Tiger.
There's no reason to pay such high prices!
Jul 26 2003
next sibling parent "Greg Peet" <admin gregpeet.com> writes:
"Nic Tiger" <tiger7 progtech.ru> wrote in message
news:bfukpj$dla$2 digitaldaemon.com...
 Well, I think Visual Studio is the matter of taste. As for me, I hate it.
I
 had to use it several times and I think it is very unconvenient.
 And resource editors in Visual Studio is real suxx.
I don't much care for it either now. My school made me use it for the programming courses (vs6ent). While on that same note, I also had to take a couple VB courses...puke!
 I liked IDE made by Borland for Turbo C++ 3.0. It was the most convenient
 IDE I ever saw. Borland C Builder's IDE comes near, it is certainly better
 than VS,
 but it is poorer than old Turbo C++ IDE.
The turbo C IDE was my first IDE. I loved it, though I do not have any access to it now. When I was a heavy borland fan, I was in love with BCB's IDE. I have some angry remarks about their faulty code-completion utility (the ctrl+space), though you have to be a pretty lazy coder to rely on it.
 Now I use Far+Colorer(for Win32), NC+BC3(as editor under DOS) and
 smake+makefiles and it suits me very well.
Where do you get Far+? Sounds interesting!
Jul 27 2003
prev sibling parent reply Paul McKenzie <paul paul.net> writes:
Nic Tiger wrote:
 As for debugger, my opinion is: it is usefult for novices, for those who
 want to understand how (particular) compiler works or for fighting minor
 bugs.
 For anything else it is useless.
A debugger is useless? Tell that to the thousands of software professionals that rely on debuggers to solve complex problems and issues. If you write DirectX exclusive-mode
 application, you cannot use debugger. It is not the only example.
 The main debugger should remain in developer's head. This is the most
 advanced method of debugging.
The more complex software gets, the human brain cannot remember every module, every line, and every conceivable path of execution a program can take. Maybe if you are developing a toy program, or a program that is so limited in scope, it does a specific number of things, then a debugger may not be necessary, but for today's large scale applications, the debugger is a necessity, not a luxury.
 And usual debugger is useful when human brain cannot understand program's
 behaviour. But it takes place mainly due to compiler bugs.
Debuggers are used mostly to solve programming bugs, not compiler bugs.
 I think I better will use bugless DMC than buggy VC6 and will not need
 integrated debugger most times.
 
 Nic Tiger.
 
DMC is a very good compiler, and yes, it can be less buggy than VC 6.0. But a compiler suite without a debugger (note, I am not referring to DMC), regardles of how bugless the compiler may be, is still a *major* shortcoming. This is especially the case if the compiler is going to be used in a production environment to create large scale applications. Paul McKenzie
Aug 04 2003
parent reply Jan Knepper <jan smartsoft.us> writes:
Paul McKenzie wrote:

 Nic Tiger wrote:
 As for debugger, my opinion is: it is usefult for novices, for those who
 want to understand how (particular) compiler works or for fighting minor
 bugs.
 For anything else it is useless.
A debugger is useless? Tell that to the thousands of software professionals that rely on debuggers to solve complex problems and issues.
"Software Professionals" should know that using a debugger requires things as optimization to be turned off. It also requires extra data to be added to the executable for the debugger to work with and have a reference to the source code. These things more often than not happen to cover up serious problems as not-intialized pointers, not-initialized data and quite a few more with the cute result that a program runs fine in the debugger, but seriously fails in release versions. So, for some people debuggers have some use... for other people debuggers have no use... 'No-use' for instance comes with Real Time systems that have to perform on high performance dealing with hundreds if not thousands if not tens of thousands of events per second. Believe me, for debugging those systems debuggers have basically no use... They add complexity and more often than not disallow proper testing.
 application, you cannot use debugger. It is not the only example.
 The main debugger should remain in developer's head. This is the most
 advanced method of debugging.
The more complex software gets, the human brain cannot remember every module, every line, and every conceivable path of execution a program can take. Maybe if you are developing a toy program, or a program that is so limited in scope, it does a specific number of things, then a debugger may not be necessary, but for today's large scale applications, the debugger is a necessity, not a luxury.
Unit testing... Write small units and test them separately. Than put them all together in a large well designed program. I do not know how large the systems are you are working on that seem to require a debugger. Again for some people/projects they work for other people/projects they do not. There are several large systems that are being build and have been build (successfully) without the use of any debugger... Jan
Aug 05 2003
parent reply Paul McKenzie <paul paul.net> writes:
Jan Knepper wrote:

 Paul McKenzie wrote:
 
 
Nic Tiger wrote:

As for debugger, my opinion is: it is usefult for novices, for those who
want to understand how (particular) compiler works or for fighting minor
bugs.
For anything else it is useless.
A debugger is useless? Tell that to the thousands of software professionals that rely on debuggers to solve complex problems and issues.
"Software Professionals" should know that using a debugger requires things as optimization to be turned off. It also requires extra data to be added to the executable for the debugger to work with and have a reference to the source code. These things more often than not happen to cover up serious problems as not-intialized pointers, not-initialized data and quite a few more with the cute result that a program runs fine in the debugger, but seriously fails in release versions.
This is not true for today's Windows debuggers, especially the one that comes with Visual C++. All you need to do is to build a release version with debugging information turned on in the compiler and linker. You *are* getting a release version, with the added benefit that you can run the program under the debugger. Paul McKenzie
Aug 07 2003
parent reply Jan Knepper <jan smartsoft.us> writes:
 This is not true for today's Windows debuggers, especially the one that
 comes with Visual C++.  All you need to do is to build a release version
 with debugging information turned on in the compiler and linker.  You
 *are* getting a release version, with the added benefit that you can run
 the program under the debugger.
If this were TRULY the case you would get an assembler display while debugging. If you get the sources you do not REALLY have a RELEASE version. I would suggest you study a few more things on debug/release and other modes. -- ManiaC++ Jan Knepper
Aug 07 2003
next sibling parent reply "Greg Peet" <admin gregpeet.com> writes:
"Jan Knepper" <jan smartsoft.us> wrote in message
news:3F331A3A.64EAABF5 smartsoft.us...
| > This is not true for today's Windows debuggers, especially the one that
| > comes with Visual C++.  All you need to do is to build a release version
| > with debugging information turned on in the compiler and linker.  You
| > *are* getting a release version, with the added benefit that you can run
| > the program under the debugger.

I don't really agree with that statement. Isn't the term "Release Version"
synonymous with "Build lacking symbols/etc"? If you are doing that then you
are just making a debug-enabled version, which defeats the purpose of it
being a commercial release.
Aug 07 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 "Jan Knepper" <jan smartsoft.us> wrote in message
 news:3F331A3A.64EAABF5 smartsoft.us...
 | > This is not true for today's Windows debuggers, especially the one
that
 | > comes with Visual C++.  All you need to do is to build a release
version
 | > with debugging information turned on in the compiler and linker.  You
 | > *are* getting a release version, with the added benefit that you can
run
 | > the program under the debugger.

 I don't really agree with that statement. Isn't the term "Release Version"
 synonymous with "Build lacking symbols/etc"? If you are doing that then
you
 are just making a debug-enabled version, which defeats the purpose of it
 being a commercial release.
I'm having a hard time with this conv, since it seems that positions are being argued out of conviction than common-sense. And by such smart folks too !?! A release build is whatever you release to your clients. If it's got debug symbols in it, that's ok, you've chosen to help yourself should your product crash. You've also reduced the likelihood of experiencing a release-only crash, which (along with its pervese sibling the debug-only crash) is a total PITA to fix. If it is appropriate to your deployment circumstances, then this is a good thing to do, Using a debugger marks you out as neither hopelessly reliant on a mental crutch for GUI cissys, nor terribly more modern than those sad cmd-line stuck-in-the-80s UNIX die-hards. It's horses for courses. Debuggers are great for learning about code. Debuggers can be integral to the development of a non-trivial quality product. Debuggers can get in the way of what's really happening. Debuggers can actually be impossible to use in certain circumstances. If you're developing a complex GUI a debugger is good, except where menus are concerned, in which case you'll have to use lots of tracing. If you're developing shell extensions, a debugger is very useful, but it can be a real pain to keep killing Explorer.exe (esp on WinNT 4) If you're developing a server using IO Completion Ports, a debugger is completely useless. If you're trying to fix a bug in your prematurely released template library component, then a debugger is almost mandatory Basically, like everything else in SW, it depends. Let's have a good debugger for DMC++ (and DMD!!), and let's also have language support and develop skills that facilitate debugging the "old" way, i.e. tracing/logs The Grinch that ate C++
Aug 07 2003
next sibling parent reply "Greg Peet" <admin gregpeet.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bgvg6k$1vgt$1 digitaldaemon.com...
| A release build is whatever you release to your clients. If it's got debug
| symbols in it, that's ok, you've chosen to help yourself should your
product
| crash. You've also reduced the likelihood of experiencing a release-only
| crash, which (along with its pervese sibling the debug-only crash) is a
| total PITA to fix. If it is appropriate to your deployment circumstances,
| then this is a good thing to do,

This is true. But what about products that have been fully tested (such as
commercial games). In cases where a problem may occur, wouldn't a simple
static assert be applied rather than increasing the executable size of your
application? Why should my new Advanced Dungeons and Dragons tag an extra
couple MB to the exe when I have no way to debug it myself (minus assembly
steps)?
Aug 08 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Greg Peet" <admin gregpeet.com> wrote in message
news:bgvjgc$233o$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bgvg6k$1vgt$1 digitaldaemon.com...
 | A release build is whatever you release to your clients. If it's got
debug
 | symbols in it, that's ok, you've chosen to help yourself should your
 product
 | crash. You've also reduced the likelihood of experiencing a release-only
 | crash, which (along with its pervese sibling the debug-only crash) is a
 | total PITA to fix. If it is appropriate to your deployment
circumstances,
 | then this is a good thing to do,

 This is true. But what about products that have been fully tested (such as
 commercial games). In cases where a problem may occur, wouldn't a simple
 static assert be applied rather than increasing the executable size of
your
 application? Why should my new Advanced Dungeons and Dragons tag an extra
 couple MB to the exe when I have no way to debug it myself (minus assembly
 steps)?
It shouldn't. I wasn't saying that all released code should have debug info included; far from it. Just that some do. As I said, it all depends. I don't release debug info in the shell extensions (http://shellext.com/) because it is important that they are small, and - inviting bug reports by the 1000s - they have proved sufficiently robust that they don't need it. When I ship serious pieces of kit, and they are fat GUIs anyway, then I often do ship debug info. Case-by-case, mi auld mucker!
Aug 08 2003
prev sibling parent reply Paul McKenzie <paul paul.net> writes:
Matthew Wilson wrote:

 I'm having a hard time with this conv, since it seems that positions are
 being argued out of conviction than common-sense. And by such smart folks
 too !?!
 
 A release build is whatever you release to your clients. If it's got debug
 symbols in it, that's ok, you've chosen to help yourself should your product
 crash. You've also reduced the likelihood of experiencing a release-only
 crash, which (along with its pervese sibling the debug-only crash) is a
 total PITA to fix. If it is appropriate to your deployment circumstances,
 then this is a good thing to do,
 
If you ever have the opportunity to do remote debugging to a client site running your software, the release build with symbols is a must.
 Debuggers can get in the way of what's really happening. Debuggers can
 actually be impossible to use in certain circumstances.
 
 If you're developing a complex GUI a debugger is good, except where menus
 are concerned, in which case you'll have to use lots of tracing.
 If you're developing shell extensions, a debugger is very useful, but it can
 be a real pain to keep killing Explorer.exe (esp on WinNT 4)
 If you're developing a server using IO Completion Ports, a debugger is
 completely useless.
In that case, you have log files and tracing. There are multiple ways to attack a problem, depending on the type of problem you're trying to solve. A debugger is somewhat useless if you're trying to debug a multi-thread issue. However, I initially got into this discussion when I felt that the debugger is being dismissed by some (or at least one here) as a tool for incompetent, beginner, or lazy programmers. Paul McKenzie
Aug 08 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Paul McKenzie" <paul paul.net> wrote in message
news:bh0rdt$6pc$1 digitaldaemon.com...
 Matthew Wilson wrote:

 I'm having a hard time with this conv, since it seems that positions are
 being argued out of conviction than common-sense. And by such smart
folks
 too !?!

 A release build is whatever you release to your clients. If it's got
debug
 symbols in it, that's ok, you've chosen to help yourself should your
product
 crash. You've also reduced the likelihood of experiencing a release-only
 crash, which (along with its pervese sibling the debug-only crash) is a
 total PITA to fix. If it is appropriate to your deployment
circumstances,
 then this is a good thing to do,
If you ever have the opportunity to do remote debugging to a client site running your software, the release build with symbols is a must.
 Debuggers can get in the way of what's really happening. Debuggers can
 actually be impossible to use in certain circumstances.

 If you're developing a complex GUI a debugger is good, except where
menus
 are concerned, in which case you'll have to use lots of tracing.
 If you're developing shell extensions, a debugger is very useful, but it
can
 be a real pain to keep killing Explorer.exe (esp on WinNT 4)
 If you're developing a server using IO Completion Ports, a debugger is
 completely useless.
In that case, you have log files and tracing. There are multiple ways to attack a problem, depending on the type of problem you're trying to solve. A debugger is somewhat useless if you're trying to debug a multi-thread issue.
Indeed. This is the point we all agree on.
 However, I initially got into this discussion when
 I felt that the debugger is being dismissed by some (or at least one
 here) as a tool for incompetent, beginner, or lazy programmers.
I think your interpretation was well-founded, and I agree with your contending the point. Horses for courses dear chaps!
 Paul McKenzie
Aug 08 2003
prev sibling parent reply Paul McKenzie <paul paul.net> writes:
Greg Peet wrote:

 "Jan Knepper" <jan smartsoft.us> wrote in message
 news:3F331A3A.64EAABF5 smartsoft.us...
 | > This is not true for today's Windows debuggers, especially the one that
 | > comes with Visual C++.  All you need to do is to build a release version
 | > with debugging information turned on in the compiler and linker.  You
 | > *are* getting a release version, with the added benefit that you can run
 | > the program under the debugger.
 
 I don't really agree with that statement. Isn't the term "Release Version"
 synonymous with "Build lacking symbols/etc"? If you are doing that then you
 are just making a debug-enabled version, which defeats the purpose of it
 being a commercial release.
 
 
I believe that my original words have been twisted into "it's OK to distribute your commercial products with debug information". What I'm trying to say is that you can debug a release version of your software, if you use a compiler/linker that supports this (VC++ does). The release version with debug symbols will run *no differently* than a release version without debug symbols. It is not going to suffer from "the debug build initializing variables automatically" or the "guard bytes around allocated areas" that "real debug" versions do. For the VC++ compilers, the real "debug version" (for lack of a better term) *does* auto-initialze variables to NULL or 0, put extra checks in for memory corruption, etc. However, the "release" versions, which do not do these checks, can also be debugged, just like the "debug" version by turning on the symbol generation for the release build. Paul McKenzie
Aug 08 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Paul McKenzie" <paul paul.net> wrote in message
news:bh0qc7$5pv$1 digitaldaemon.com...
 Greg Peet wrote:

 "Jan Knepper" <jan smartsoft.us> wrote in message
 news:3F331A3A.64EAABF5 smartsoft.us...
 | > This is not true for today's Windows debuggers, especially the one
that
 | > comes with Visual C++.  All you need to do is to build a release
version
 | > with debugging information turned on in the compiler and linker.
You
 | > *are* getting a release version, with the added benefit that you can
run
 | > the program under the debugger.

 I don't really agree with that statement. Isn't the term "Release
Version"
 synonymous with "Build lacking symbols/etc"? If you are doing that then
you
 are just making a debug-enabled version, which defeats the purpose of it
 being a commercial release.
I believe that my original words have been twisted into "it's OK to distribute your commercial products with debug information".
They probably have. When you get three shy bashful types like Jan, Greg and me, that's all too probable ... ;)
 What I'm trying to say is that you can debug a release version of your
 software, if you use a compiler/linker that supports this (VC++ does).
 The release version with debug symbols will run *no differently* than a
 release version without debug symbols.  It is not going to suffer from
 "the debug build initializing variables automatically" or the "guard
 bytes around allocated areas" that "real debug" versions do.
This is practically true in most cases, but as you'll no doubt agree, it is not theoretically correct. Different memory footprint !== identical execution.
 For the VC++ compilers, the real "debug version" (for lack of a better
 term) *does* auto-initialze variables to NULL or 0, put extra checks in
 for memory corruption, etc.  However, the "release" versions, which do
 not do these checks, can also be debugged, just like the "debug" version
 by turning on the symbol generation for the release build.
AFAIK, no-one's disputing this. I'm certainly not.
Aug 08 2003
parent reply "Greg Peet" <admin gregpeet.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh14bg$fom$1 digitaldaemon.com...
| > I believe that my original words have been twisted into "it's OK to
| > distribute your commercial products with debug information".
|
| They probably have. When you get three shy bashful types like Jan, Greg
and
| me, that's all too probable ... ;)

Yup I misinterpreted your words. Sorry about that. I have been reading a
thread in comp.unix.programmer regarding this topic and figured I could make
the same argument here...to save me words =P
Aug 08 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Yup I misinterpreted your words. Sorry about that. I have been reading a
 thread in comp.unix.programmer regarding this topic and figured I could
make
 the same argument here...to save me words =P
LOL! That's about the lamest de-flaming excuse I've ever heard. Greg, you are the god of disingenuousness. I bow in your presence.
Aug 08 2003
parent "Greg Peet" <admin gregpeet.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh193m$kkt$1 digitaldaemon.com...
| LOL! That's about the lamest de-flaming excuse I've ever heard.
|
| Greg, you are the god of disingenuousness. I bow in your presence.

It's a shame my "sport's masters" didn't teach me better =P AHAHAH lol
Aug 08 2003
prev sibling parent reply Paul McKenzie <paul paul.net> writes:
Jan Knepper wrote:
 
 If this were TRULY the case you would get an assembler display while
debugging. If
 you get the sources you do not REALLY have a RELEASE version.
 
I am strictly talking about "debugging a release version". Of course you don't ship a version with debug symbols, but a release version with debug symbols is no different, in terms of execution, than a release version without debug symbols. Please go to the page below and scroll down to "Turn on Symbols". It shows exactly how to accomplish what I'm trying to convey to you. http://www.codeproject.com/debug/survivereleasever.asp
 I would suggest you study a few more things on debug/release and other modes.
After programming for 23 years, and currently developing and maintaining commercial software, I am well-versed in release and debug modes, thank you. Paul McKenzie
Aug 08 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Paul McKenzie" <paul paul.net> wrote in message
news:bh0ov7$4kd$1 digitaldaemon.com...
 After programming for 23 years, and currently developing and maintaining
 commercial software, I am well-versed in release and debug modes, thank
you. You must be almost as ancient as I <g>.
Aug 08 2003
next sibling parent reply Paul McKenzie <paul paul.net> writes:
Walter wrote:

 "Paul McKenzie" <paul paul.net> wrote in message
 news:bh0ov7$4kd$1 digitaldaemon.com...
 
After programming for 23 years, and currently developing and maintaining
commercial software, I am well-versed in release and debug modes, thank
you. You must be almost as ancient as I <g>.
I started young :) Paul McKenzie
Aug 08 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Paul McKenzie" <paul paul.net> wrote in message
news:bh0std$8m1$1 digitaldaemon.com...
 Walter wrote:

 "Paul McKenzie" <paul paul.net> wrote in message
 news:bh0ov7$4kd$1 digitaldaemon.com...

After programming for 23 years, and currently developing and maintaining
commercial software, I am well-versed in release and debug modes, thank
you. You must be almost as ancient as I <g>.
I started young :)
Ah, if we count teen-stuff, then you can include me as a 23-year vet. Sigh ...
Aug 08 2003
parent "Greg Peet" <admin gregpeet.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh14is$g2q$1 digitaldaemon.com...
| > > You must be almost as ancient as I <g>.
| > >
| > >
| >
| > I started young :)
|
| Ah, if we count teen-stuff, then you can include me as a 23-year vet. Sigh
Bah, I'm a young-un then. no fun =(
Aug 08 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Paul McKenzie" <paul paul.net> wrote in message
news:bh0std$8m1$1 digitaldaemon.com...
 Walter wrote:
 "Paul McKenzie" <paul paul.net> wrote in message
 news:bh0ov7$4kd$1 digitaldaemon.com...
After programming for 23 years, and currently developing and maintaining
commercial software, I am well-versed in release and debug modes, thank
you. You must be almost as ancient as I <g>.
I started young :)
My first programming job was for General Lee. With my Battlefield Simulator (tm), I convinced him that Pickett's Charge was a good idea. After my reputation on that one, I didn't get another job for 30 years!
Aug 08 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bh0sdu$899$1 digitaldaemon.com...
 "Paul McKenzie" <paul paul.net> wrote in message
 news:bh0ov7$4kd$1 digitaldaemon.com...
 After programming for 23 years, and currently developing and maintaining
 commercial software, I am well-versed in release and debug modes, thank
you. You must be almost as ancient as I <g>.
You guys are babies. I've just been blown away by the wisdom and switched-on-ness of Robert L Glass, and he's 71. Rock on Rob!!
Aug 08 2003
parent "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh14hh$g1t$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:bh0sdu$899$1 digitaldaemon.com...
 "Paul McKenzie" <paul paul.net> wrote in message
 news:bh0ov7$4kd$1 digitaldaemon.com...
 After programming for 23 years, and currently developing and
maintaining
 commercial software, I am well-versed in release and debug modes,
thank
 you.

 You must be almost as ancient as I <g>.
You guys are babies. I've just been blown away by the wisdom and switched-on-ness of Robert L Glass, and he's 71. Rock on Rob!!
Bah! I designed the Brooklyn Bridge on the world's first autocad system.
Aug 08 2003
prev sibling parent reply Jan Knepper <jan smartsoft.us> writes:
Paul,

A very simple example like this:

char    str [ 2 ];

for ( int  i = 0 ; i < 3 ; ++i )
   *( str + i ) = 'A' + i;

Could fail in a true optimized release build and work fine in a release build
with
debugging info and in a bug version.

If your release build with debug info would optimize there is change that you
would not
see this loop at all, but rather:

*( str + 0 ) = 'A';
*( str + 1 ) = 'B';
*( str + 2 ) = 'C';

It would be pretty difficult for a debugger to refer to a line of code that
ain't there
anymore...

 I am strictly talking about "debugging a release version".  Of course
 you don't ship a version with debug symbols, but a release version with
 debug symbols is no different, in terms of execution, than a release
 version without debug symbols.
I still contest that although M$'s C-- compiler might not truely optimize and for that reason indeed generate the same code. Other... There very well might be serious difference...
 Please go to the page below and scroll down to "Turn on Symbols".  It
 shows exactly how to accomplish what I'm trying to convey to you.

 http://www.codeproject.com/debug/survivereleasever.asp
No time to do that... I am currently working on stuff were there is also no debugger available... Besides, I try not to promote or use M$ software any more than I have to. ;-)
 I would suggest you study a few more things on debug/release and other modes.
After programming for 23 years, and currently developing and maintaining commercial software, I am well-versed in release and debug modes, thank you.
Well, I am almost as ancient with about 18 years... I have developed and maintained commercial software for the last 18 years or so. A couple of those product are freely available... http://www.currency-calculator.net/ Download it for free ftp://ftp.currency-calculator.net/free/CUCAStdIS.exe http://www.imagener.com/ Download it for free http://www.imagener.com/Download.html Both of them build without using a debugger... ;-) -- ManiaC++ Jan Knepper
Aug 08 2003
parent reply Paul McKenzie <paul paul.net> writes:
Jan Knepper wrote:

 It would be pretty difficult for a debugger to refer to a line of code 
 that ain't there anymore...
 
Yes. This is the disadvantage of debugging optimized code. No argument there.
 I am strictly talking about "debugging a release version".  Of course
 you don't ship a version with debug symbols, but a release version with
 debug symbols is no different, in terms of execution, than a release
 version without debug symbols.
I still contest that although M$'s C-- compiler might not truely optimize and for that reason indeed generate the same code. Other... There very well might be serious difference...
I've never run into any differences. Everything is the same (at least with my experience) if you add symbols or not. If it crashes in the release without symbols and optimization on, it will crash in the release with the symbols and optimization on in the same area of code (of course, given that the input to the program is the same for both versions, and you run both versions on the same machine)
 Please go to the page below and scroll down to "Turn on Symbols".  It
 shows exactly how to accomplish what I'm trying to convey to you.

 http://www.codeproject.com/debug/survivereleasever.asp
No time to do that... I am currently working on stuff were there is also no debugger available... Besides, I try not to promote or use M$ software any more than I have to. ;-)
Yes, I understand. I've had to do that with older compilers that can compile my code, but cannot use a debugger due to the large library sizes that are generated. I'm no Microsoft promoter by any means (I'm mad as heck at VC++ 6.0 for not supporting member templates) -- I just wanted to bring up how MS accomplishes debugging. Since 32-bit VC++, MS stores the debug info in PDB (Program Database) files and not the executable. By storing all the debug information in seperate files, the "real" EXE stays intact with next to no extra information (a stub is added to the EXE, telling where the path of the PDB file is located). Maybe Walter has thought of this type of a setup if he or someone else plans to upgrade the DMC debugger.
 I have developed and maintained commercial software for the last 18 
 years or so.
 
 A couple of those product are freely available...
 
 http://www.currency-calculator.net/
 Download it for free  
 ftp://ftp.currency-calculator.net/free/CUCAStdIS.exe
 
 http://www.imagener.com/
 Download it for free  
 http://www.imagener.com/Download.html
 
 Both of them build without using a debugger... ;-)
  
Walter's "Related Sites" page at www.digitalmars.com/related.html lists one of my products (DTWAIN). And yes, a debugger was used, but mostly to debug what a non-compliant TWAIN drivers is doing wrong :) Paul McKenzie
Aug 08 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Walter's "Related Sites" page at www.digitalmars.com/related.html lists
 one of my products (DTWAIN).  And yes, a debugger was used, but mostly
 to debug what a non-compliant TWAIN drivers is doing wrong :)
Hey Walter, Can you link in http://shellext.com in related sites. Some of these were built with a debugger, and some not. ;)
Aug 08 2003
parent "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh14nh$g5i$1 digitaldaemon.com...
 Can you link in http://shellext.com in related sites. Some of these were
 built with a debugger, and some not. ;)
Done!
Aug 08 2003