[comp.unix.questions] porting C programs from UNIX to VMS

todd@stiatl.UUCP (Todd Merriman) (05/31/90)

In article <1990May30.190325.17541@athena.mit.edu> seaotter@athena.mit.edu (Mike) writes:
>	I am looking for advice/tips/suggestions for porting some fairly
>simple c programs from UNIX (4.3 BSD) to VMS.  Some use curses, some don't.

Rule No. 1:  don't bother trying to get VMS Curses to work like Berkely
Curses.  I just ain't going to happen.

   ...!emory!SalesTech.com!todd
   ...!emory!stiatl!todd
   Todd Merriman * 404-841-4000 * Atlanta, GA

phd_ivo@gsbacd.uchicago.edu (06/01/90)

>Rule No. 1:  don't bother trying to get VMS Curses to work like Berkely
>Curses.  I just ain't going to happen.

Rule No. 2: never trust the library routines.

Rule No. 3: in particular, never trust the stdio libraries. The weird
character I/O schemes on VMS wreak all kind of havoc. (Also, I found a
bug in qsort() once!)

Hint No. 1: the debugger---although generally quite nice---can't restart
a program :-(

/ivo welch	ivo@next.agsm.ucla.edu

mdchaney@bronze.ucs.indiana.edu (M Darrin Chaney) (06/01/90)

In article <9528@tank.uchicago.edu> phd_ivo@gsbacd.uchicago.edu writes:
>Hint No. 1: the debugger---although generally quite nice---can't restart
>a program :-(

Hmm, I can't figure out what you're trying to say with this.  If you mean
VMS doesn't dump a core, you need to use the command "Set Process/Dump".
In order to debug that dump file, you need to use "Analyze/Proc/Full file".
Of course, to get any real debugging pleasure, you have to compile and
link for debugging, but it works just fine otherwise.

>/ivo welch	ivo@next.agsm.ucla.edu

	Darrin

mdchaney@iubacs
mdchaney@bronze.ucs.indiana.edu
mdchaney@rose.ucs.indiana.edu

wallyk@tekfdi.FDI.TEK.COM (Wally Kramer) (06/01/90)

In article <46365@iuvax.cs.indiana.edu> mdchaney@bronze.ucs.indiana.edu
(M Darrin Chaney) writes:
> In article <9528@tank.uchicago.edu> phd_ivo@gsbacd.uchicago.edu writes:
> >Hint No. 1: the debugger---although generally quite nice---can't restart
> >a program :-(
> 
> Hmm, I can't figure out what you're trying to say with this.  ...

I think what "phd_ivo" means is you can't re-run the program as though it
just started from within the debugger.  This is nice to do if you accidently
step past the procedure that commits the dastardly deed you're looking for.

It implies the debugger can reset the program being debugged to its initial
state, including all (program) files closed, variables back to their initial
value, etc.

Of course, you could always exit the debugger and restart, but then you'd
lose your nice window layout, patches, modes, definitions, breakpoints,
watchpoints, etc., etc.

Debugger maniacs:  go get a copy of Turbo C++ Professional.  I don't know
if it's generally available, but I got advance notice (as a Turbo C
Professional owner).  The debugger is claimed to support "backwards single
stepping" where it reverses the effects of the step!!  I don't have any
details as yet, but this is another solution for starting over.  Turbo
Debugger, naturally, has always had program restart (Ctrl-F2).  (IMHO,
Turbo C plus a PC [cost:  $150 + $800+] is such a productive development
environment that any medium to large VMS development is best started there.
Disclaimer:  I'm just a very satisfied customer.)

wallyk@tekfdi.fdi.tek.com (Wally Kramer) 503 627 2363
Contractor from Step Technology, Inc.  503 244 1239

kassover@jupiter.crd.ge.com (David Kassover) (06/01/90)

In article <46365@iuvax.cs.indiana.edu> mdchaney@bronze.ucs.indiana.edu (M Darrin Chaney) writes:
>In article <9528@tank.uchicago.edu> phd_ivo@gsbacd.uchicago.edu writes:
>>Hint No. 1: the debugger---although generally quite nice---can't restart
>>a program :-(
>
>Hmm, I can't figure out what you're trying to say with this.  If you mean
>VMS doesn't dump a core, you need to use the command "Set Process/Dump".
>In order to debug that dump file, you need to use "Analyze/Proc/Full file".
>Of course, to get any real debugging pleasure, you have to compile and
>link for debugging, but it works just fine otherwise.


Some debuggers I have seen, and I am not experienced with them,
and no they weren't for VMS, or Unix, either, have the ability to
restart the program from the beginning.

I'm sure there's a reason the VMS Debugger does not have this
feature (a minor inconvenience), good bad indifferent or ugly.

If anyone reading this *knows* the reason, I'm sure we'd all like
to hear about it.


As long as we are pounding on the debugger, does anyone know,
perhaps, if in a future version the user will be able to control
the symbol table load algorithm?  On my "favorite" image to
debug, it takes about 10-20 minutes from my entering run/debug
until I see the DBG> prompt.  DEC's current answer, via my sysop,
is "Add more memory/raise the working set".  I'm surprised they
didn't suggest a 9000  8-)

--
David Kassover             "Proper technique helps protect you against
kassover@ra.crd.ge.com	    sharp weapons and dull judges."
kassover@crd.ge.com			F. Collins