GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) (01/31/91)
Hi,
I want your opinion. I'm writing a machinelevel debugger for Amiga.
When it is ready I would like to commercialize it. To make my
product better known a demo version would be nice, but I don't really
know how to make a demo version of a debugger. It is very easy
to make a demo version of an editor, simply remove the 'save' option
and the problem is useles while you still can test the power of the
editor (look at the TurboText demo). But my debugger simply does not
have a 'save' command (It has, but this 'save' command is not that
useful). What should I remove, or what should I do to make the
program unusable. You should still be able to see how powerful it is.
I have the following suggestions :
- Set limits on the program (only debug programs smaller than 5 K,
no debugging on mondays :-), only allow some 100 commands in one
debug session, ...). The big problem with this approach is that
these limits are generally easy to remove (for a hacker, he could
even use my debugger :-).
- Remove some vital things (like the 'trace' command (to singlestep)).
The problem with this approach is that the debugger looses power.
Some features will be more difficult to demonstrate.
- Replace all commands in the debugger with dummy commands that generate
a possible sample of output but not the real output for your system.
The problem here is that this is a lot of work to program and it is
more difficult to demonstrate the power of the program.
If you have any suggestions, please mail me or post it in the newsgroup.
Jorrit Tybergheincmw1725@tamsun.tamu.edu (Christopher Walton) (02/01/91)
My first thought was to make an interactive demo of yourself debugging something and upload that. It shows what the debugger can do, by the one who know how to use it most. You could do this with a io catcher/saver, or just make a text file of a session. I would rather have a demo that puts up a screen and asks what I want to know about (which feature), I click on it, it shows you doing that function to it's highest degree. Just a thought. Christopher Walton cmw1725@tamsun.tamu.edu n074ev@tamuts.tamu.edu
ridder@elvira.enet.dec.com (Hans Ridder) (02/01/91)
In article <91031.112859GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: >It is very easy to make a demo version of an editor, simply remove the >'save' option and the problem is useles while you still can test the >power of the editor (look at the TurboText demo). But my debugger simply >does not have a 'save' command.... How about disabling the 'load' command (if it has one), and have a built in program with a bug in it (causes a Guru or some such). Then only allow that program, and maybe a few other places in memory to be examined/modified/traced, like the task structure for the "broken" task, and some system structures.... When the user trys to examine an area outside of the boundaries, give a nice error message about buying the non-demo version. Of course someone could use another debugger to "fix" your debugger, possibly allowing full or nearly full functionality, but there's some level of risk you're going to have take to get the benefit of the publicity of the demo. > Jorrit Tyberghein -hans ------------------------------------------------------------------------ Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
jsmoller@jsmami.UUCP (Jesper Steen Moller) (02/03/91)
In article <2438@shodha.enet.dec.com>, Hans Ridder writes: > In article <91031.112859GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: > >It is very easy to make a demo version of an editor, simply remove the > >'save' option and the problem is useles while you still can test the > >power of the editor (look at the TurboText demo). But my debugger simply > >does not have a 'save' command.... > > How about disabling the 'load' command (if it has one), and have a built > in program with a bug in it (causes a Guru or some such). Then only > allow that program, and maybe a few other places in memory to be > examined/modified/traced, like the task structure for the "broken" task, > and some system structures.... When the user trys to examine an area > outside of the boundaries, give a nice error message about buying the > non-demo version. Good idea... > Of course someone could use another debugger to "fix" your debugger, > possibly allowing full or nearly full functionality, but there's some > level of risk you're going to have take to get the benefit of the > publicity of the demo. Well, not really. If you remove a command like load, which is (I guess) is a rather longish one, nobody can replace it. If you put a kludge in to remove load, it's not good enough. Exclude it by something like: void load(void) { #ifdef DEMO printf("Can't load - It's just a demo"); #else .... /* stuff for loading or whatever - choose a long and hard to imitate command... */ .... #endif (or use a comditional assembly directive in assembler) I used the same scheme for a commercial project of mine, and nobody can make a save-routine work, if it isn't there. Many good crackers can, however, remove the "5K max", or "ten minutes only, and never of the 1st of April"-limitations. :-) /Jesper > > Jorrit Tyberghein > -hans -- __ Jesper Steen Moller /// VOICE: +45 31 62 46 45 Maglemosevej 52 __ /// USENET: cbmehq!cbmdeo!jsmami!jsmoller DK-2920 Charl \\\/// FIDONET: 2:231/84.45 Denmark \XX/ OPINIONS: Certainly!
ccplumb@rose.uwaterloo.ca (Colin Plumb) (02/06/91)
For a demo version of a debugger, how about small, fixed-size symbol tables. It would be useful on toy code, but nothing over, say, 50 lines (if that was the size of the compiled-in table). Diking out all of the table-allocation code is a bit more work than removing a save command, but still not that much work. -- -Colin
steed@digitm.UUCP (Steed Kulka) (02/06/91)
In article <1991Feb2.204031.2084@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Adam Hill) writes: >How about a demo copy being put up at ab20? Aye, I wish we had a true Internet access here :-( Actually we are restricted to upload/download to/from nodes included in the commodore.com dominion; but a demo disk is on the way to a friend of us in the States - and *he* is on Internet... ;-) Sometimes I feel to be in the wrong place at the wrong time (well, not when it comes to gourmet food & wine :-) :-) :-) ). -- _ _ _ ___ __ (_) | \|/ _| | |_ /\ |\/| Steed Kulka ----- |_/|\_/| | |__/--\| | BIX: digiteam UUCP: {uunet|pyramid|rutgers}!cbmvax!cbmehq!cbmita!digitm!steed
steed@digitm.UUCP (Steed Kulka) (11/22/91)
In article <91031.112859GHGAQA4@cc1.kuleuven.ac.be> GHGAQA4@cc1.kuleuven.ac.be (Tyberghein Jorrit) writes: >... >I don't really know how to make a demo version of a debugger >... Make it suitable for 68000 only (i.e. do not include code ops for higher cpus), disable log options, disable multitasking (breaking the Golden Rule may be permitted in such cases, I guess), make demo executable only under NOFASTMEM, enable small user-definable symbol tables. All things that leave much of the original flavour, but don't make a demo a useful & friendly tool. Do not compile routines which are not intended to be used in the demo. We are currently giving away a demo/test version of our paint program Art Nouveau which does not save pictures/clips/c-data/icons/patterns etc. - but we did not include the actual code responsible for data saving, if we had done such a foolness as: bra .this_is_a_demo ... (saving routines here) ... this_is_a_demo: rest of proggie hackers surely would have cracked it at once. Good luck - we need good debuggers (sigh) ;-) -- _ _ _ ___ __ (_) | \|/ _| | |_ /\ |\/| Steed Kulka ----- |_/|\_/| | |__/--\| | BIX: digiteam UUCP: {uunet|pyramid|rutgers}!cbmvax!cbmehq!cbmita!digitm!steed