Subj : Open Watcom compiler
To   : Sarah Nunez
From : David Noon
Date : Thu Jun 27 2002 08:28 pm

Hi Sarah,

Replying to a message of Sarah Nunez to David Noon:

 DN>>  You then need to create a target (a
 DN>> .tgt file) within that project; select Target|New Target from the
 DN>> menu bar if the New Project dialogue does not take you through
 DN>> target creation (it should).

 SN> Nope--that's where I get the "No targets are installed" error.  All
 SN> menu options are greyed out except "Create a Project".  In fact, only
 SN> the three leftmost buttons are on the toolbar.  The rest shown in the
 SN> tutorial are simply not there.

This would seem to indicate an installation problem.

This error message, in that context, indicates that the IDE cannot determine 
what compiler/linker target platforms have been installed. At a bare minimum I 
would have expected the 12 OS/2 platform targets:

   16-bit OS/2 full-screen;
   16-bit OS/2 VIO;
   16-bit OS/2 PM;
   16-bit OS/2 DLL;
   16-bit OS/2 library;
   32-bit OS/2 full-screen;
   32-bit OS/2 VIO;
   32-bit OS/2 PM;
   32-bit OS/2 DLL;
   32-bit OS/2 library;
   OS/2 .INF document
   OS/2 .HLP help file

There might also be entries for 16-bit PDD and 32-bit VDD.

Since these are missing, it would seem that your IDEX.CFG file is either 
missing from your x:\WATCOM\BINP directory or is trashed. It is a simple text 
file. Here is a copy of mine:

============================ CUT ======================================
IncludeFile ideos232.cfg
IncludeFile ideos2.cfg
IncludeFile idedos32.cfg
IncludeFile idedos.cfg
IncludeFile idew32.cfg
IncludeFile idewin.cfg
IncludeFile idew386.cfg
IncludeFile idemfc32.cfg
IncludeFile idemfc16.cfg
IncludeFile idenlm.cfg
IncludeFile ideads.cfg
IncludeFile ideqnx32.cfg
IncludeFile ideqnx16.cfg

Project
  Editor "epmlink" DLL
  Browse wbrg wbrw
  Help ide.hlp

MsgLog
  Help .c, wccerrs.hlp, 20000
  Help .cpp, wpperrs.hlp, 20000
  Help .for, wfcerrs.hlp, 20000

HostMask ????@
============================ CUT ======================================

The other .CFG files define specific targets and are grouped by platform. The 
first two, above, contain the 32-bit and 16-bit OS/2 target configurations, 
respectively.

[snip]
 DN>> Turbo C is a very non-standard implementation of C. It is so old as
 DN>> to be useless in a modern context.

 SN> Well, I tried to make my code as portable and ANSI-standard as I could
 SN> (I think it was you who wrote the portability guidelines that used to
 SN> float around the FidoNet C echoes).

Actually, I think Peter Fitzsimmons (former moderator of this echo and 
all-around OS/2 guru) wrote that several years ago.

 SN>  And until now, Turbo C was all I had available.

I sympathize with you.

 DN>> For example, "stdprn" is *not* a standard I/O stream and never has
 DN>> been. The only standard streams are stdin, stdout and stderr. I
 DN>> suggest you use stdout for printing and redirect it to a printer
 DN>> using the command line redirection symbol (>). Then use stderr to
 DN>> report errors to the console.

 SN> You lost me here.  Are you saying that the *user* will need to
 SN> redirect?  I'm not comfortable with that--the users of my programs
 SN> will often be nearly computer-illiterate.

No, you can do that with a 1-line wrapper for the shell.

 SN>  I'm not about to even mention command lines to them.

How do you plan for the users to run the program? From what you have described 
so far you are writing for a command-line environment.

 SN> Also, I'm using a lot of Epson printer
 SN> codes to do what needs to be done--how will a redirect from stdout
 SN> affect that?

Not at all. "Bytes is bytes."

You are tying your users to using Epson hardware. Have you looked at OS/2's 
printing API? It is part of the Graphics Programming Interface (GPI). It 
permits the programmer to create printer-independent print streams and then 
have the hardware-specific printer driver convert them to the appropriate PDL 
at unspooling time. It is a far more satisfactory printing solution.

Are you actually writing an OS/2 program? I see a message from Jonathan asking 
much the same question. Much of what you have written so far appears to be very 
DOS-centric in its design. This makes it very difficult to produce either OS/2 
or Win32 programs, except for command-line interface ones.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
 * Origin: My other computer is an IBM S/390 (2:257/609.5)

.