I have the above compiler installed from the zip files (OS/2 host, all targets), but I've been unable to obtain a copy of the retail Watcom
11.x compiler. I assume this will limit me to compiling for 16-bit
DOS until the Open Watcom project concocts their own SDKs, etc., for Windows, OS/2, and extended DOS, correct?

No.

You can obtain the OS/2 Developers' Toolkit (which actually comes supplied with
some versions of OS/2) and use it with Watcom C/C++ pretty much as it stands, which will enable you to produce OS/2 programs.

You can obtain the Windows Software Development Kit from Microsoft, but you cannot use it without significant alterations to the header files and import libraries. This is because they are not very compiler-neutral at all and contain things that are highly specific to Microsoft's own C/C++ compiler. Eventually, there will exist a suite of patches that one can apply to the Windows SDK that will render it usable with the Watcom compiler.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

2. I have three programs (all quite similar to one another) that send output to the printer (stdprn).

Your programs are written to assume something to be true that is only in fact true on the MS/PC/DR-DOS operating systems. Your programs, as they stand at any rate, have thus locked themselves into MS/PC/DR-DOS.

Is it your intention to build DOS programs ? I suspect that it is not. Only when the target operating system is MS/PC/DR-DOS is it meaningful to make use of the macros "stdaux" and "stdprn" (analogous to the standard "stdin", "stdout", and "stderr" macros) in a program. If you are intending to create OS/2 programs, then your applications need to be rewritten to stop assuming something that isn't actually true on OS/2.

All three programs compile flawlessly under Turbo-C 2.0, [...]

That's because Turbo C targets the DOS operating system and your programs are written for DOS.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

Hi Sarah,

Replying to a message of Sarah Nunez to David Noon:

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

Nope--that's where I get the "No targets are installed" error. All
menu options are greyed out except "Create a Project". In fact, only
the three leftmost buttons are on the toolbar. The rest shown in the 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]

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

Well, I tried to make my code as portable and ANSI-standard as I could
(I think it was you who wrote the portability guidelines that used to 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.

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

I sympathize with you.

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

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

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

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.

Also, I'm using a lot of Epson printer
codes to do what needs to be done--how will a redirect from stdout
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)

Hi Sarah,

On 13-Jul-02, Sarah Nunez wrote to David Noon:

<snip>

Newer cuts of OS/2 have the DTK on the install media. Its
location varies with version, but will usually be located under a
directory named TOOLKIT.

I'm not finding it on my Warp 4 CDs. Can you give me some
filenames?

I've just gone through my WARP4 GA CD and it isn't on there
anywhere...

Once you introduce a C++ application framework you end up writing
a truckload of little subroutines and a little bit of glue code
to join them to the AF's common code. It looks butt-ugly, but it
is easy.

I'm already used to programming in a fairly modular fashion. Is
this what you mean

The three AFs that support OS/2 and Windows are all free for the
download. I suggest you try wxWindows, as it supports LINUX and
*BSD, as well as OS/2 and Windows.

Where do I download it?

I've got the YACL framework here, and there are a number of bugs in it
that I've identified, and I've not ploughed far enough through the
source to eradicate them (some are quite tricky). So that's one to
avoid, especially as the author devised it, wrote it up as a book and
then abandoned it :-(.

George

--- Terminate 5.00/Pro
# Origin: A country point under OS/2 (2:257/609.6)
* Origin: Baddog BBS (1:218/903)

Ahhh. . . I installed the OS/2 host stuff, not the Win16 host
stuff. Do I need the hosting files for all platform hosts?

I don't think so. The Win16 files account for most of the IDE's configuration, including most of the OS/2 and Win32 IDEs'
configurations. I think Watcom perceived Win16 as the lowest common denominator, and put the bulk of the common configuration data there.

Well, none of the ide*.cfg files are in the Win16 IDE zip files. That seems to

be the key that I'm missing.

So, you should have a fairly substantial BINP directory, a smallish
BINW directory and little or no BINNT directory.

I have exactly two files in the BINW directory: wcl.exe and wcl386.exe. Those

are the only ones that came on the zip files for OS/2 host and all targets that

are designated for that directory.

The only IBM-burnt CDs I have to hand are for MCP2. The installation program on those is x:\TOOLKIT\TKINSTAL.EXE, where "x" is your CD-ROM drive.

Well, my Warp CDs just got buried the other day by a mountain of boxes. (The movers delivered our furniture and other household goods from storage on Tuesday, and my apartment looks like a warehouse.) I'll have to look again at the CDs once I unbury them. (I can see them--I just can't get to them.)

It is getting there. Object methods are even more fragmented than conventional (i.e. FORTRAN-style) modular programming.

Perhaps I'll have a better understanding once I get to the C++ tutorial.

Start at http://www.wxwindows.org/ and choose whichever
implementations you need: OS/2, Win32, X11 (LINUX and *BSD), MacOS, whatever.

The only OS/2 downloads I found are via CSV, which I'm still trying to make sense of. (I did download an OS/2 CSV client or whatever the term is.) I emailed David Webster, who indicated that the whole shooting match (all platforms, perhaps? can I even select only OS/2?) runs about 100Mb. There's no way on God's green earth I can download 100Mb of stuff, especially without some sort of resume feature. I have a 56Kbps modem and my ISP limits me to four hours per session. There is an available CD-ROM, but from the description

it appears that the OS/2 implementation of wxWindows is NOT on the CD-ROM. I wish I could just ftp what I need and be done with it.

Sarah
trinityoaks@cfaith.com

... A handgun responds faster than 911 for crime problems.
---
# Origin: WordForce Mail-Only System (1:130/604)
* Origin: Baddog BBS (1:218/903)

05 Jul 02 09:45, Jonathan de Boyne Pollard wrote to Sarah Nunez:

The way to write to a parallel device as a C stream that will work on
both DOS and OS/2 is to open it with fopen(), write to it whatever is desired, and then close it with fclose().

So I treat the device like another file? (I haven't gotten to that part in the

tutorial yet. I'm learning this stuff as I go.)

Sarah
trinityoaks@cfaith.com

... A gun in the hand is better than 911 on the phone.
---
# Origin: WordForce Mail-Only System (1:130/604)
* Origin: Baddog BBS (1:218/903)

Hi Sarah,

Replying to a message of Sarah Nunez to David Noon:

Well, none of the ide*.cfg files are in the Win16 IDE zip files. That seems to be the key that I'm missing.

It sure seems to be the basic problem.

So, you should have a fairly substantial BINP directory, a smallish
BINW directory and little or no BINNT directory.

I have exactly two files in the BINW directory: wcl.exe and
wcl386.exe. Those are the only ones that came on the zip files for
OS/2 host and all targets that are designated for that directory.

Ok. I'll zip up the configuration files from my BINW directory and e-mail them to you.

Well, my Warp CDs just got buried the other day by a mountain of
boxes.

Well, George said he couldn't find it, so you perhaps need WSeB or later. [George, did you check the BonusPak CD too?]

It is getting there. Object methods are even more fragmented than
conventional (i.e. FORTRAN-style) modular programming.

Perhaps I'll have a better understanding once I get to the C++
tutorial.

It is quite simple: in FORTRAN and all "procedural" languages, subroutines and functions are either wholly public or wholly private. In OO languages, a method

is owned by a class of data, so for most method calls you need an instance of that class in order to call the method. This means that if two or more classes need to have the same functionality you end up coding the same stuff twice or more. Well, not really. You end up coding methods for each class, each of which

calls some other, abstracted function that implements the common parts. This means that one FORTRAN subroutine can become a multitude of much smaller C++ methods.

There are ways to ameliorate this to some extent, but they often make the design seem more complicated.

Start at http://www.wxwindows.org/ and choose whichever
implementations you need: OS/2, Win32, X11 (LINUX and *BSD), MacOS,
whatever.

The only OS/2 downloads I found are via CSV, which I'm still trying to make sense of.

Ah. I have am IBM-written PDF document somewhere that is a tutorial on CSV. I shall include it in the e-mail with the Watcom configuration files. Do you have

Acrobat or GSView? If neither I suggest you find a copy of Acrobat/2, as most of IBM's newer doco is distributed in PDF format.

I wish I could just ftp what I need and be done with it.

I have been considering building a Watcom-hosted implementation of wxOS2 and uploading it to Hobbes, perhaps sending it down the OS/2 filebone as well. Since both you and Mike Luther have expressed interest (and I expect there are some interested lurkers, too) this could be something useful for me to do in the next few weeks. Watch this space.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
# Origin: My other computer is an IBM S/390 (2:257/609.5)
* Origin: Baddog BBS (1:218/903)

21 Jul 02 17:39, David Noon wrote to Sarah Nunez:

Ok. I'll zip up the configuration files from my BINW directory and
e-mail them to you.

Thanks! I'll be looking for them.

Well, George said he couldn't find it, so you perhaps need WSeB or
later. [George, did you check the BonusPak CD too?]

I looked on both the installation CD and the bonus CD (is it called BonusPak under Warp 4, also?) before I asked you for filenames and didn't find anything that was obvious.

It is quite simple: in FORTRAN and all "procedural" languages,
subroutines and functions are either wholly public or wholly private.
In OO languages, a method is owned by a class of data, so for most
method calls you need an instance of that class in order to call the method.

Remainder saved for further rumination.

Ah. I have am IBM-written PDF document somewhere that is a tutorial on CSV. I shall include it in the e-mail with the Watcom configuration
files. Do you have Acrobat or GSView? If neither I suggest you find a
copy of Acrobat/2, as most of IBM's newer doco is distributed in PDF format.

I have Acrobat. Is 3.0 still the latest for OS/2?

I have been considering building a Watcom-hosted implementation of
wxOS2 and uploading it to Hobbes, perhaps sending it down the OS/2 filebone as well. Since both you and Mike Luther have expressed
interest (and I expect there are some interested lurkers, too) this
could be something useful for me to do in the next few weeks. Watch
this space.

Oh, that would be wonderful! Perhaps it'll be available by the time I return from vacation.

Sarah
trinityoaks@cfaith.com

... All who love liberty are enemies of the state.
---
# Origin: WordForce Mail-Only System (1:130/604)
* Origin: Baddog BBS (1:218/903)

Sarah Nunez wrote to David Noon on 07/19

Ahhh. . . I installed the OS/2 host stuff, not the Win16 host
stuff. Do I need the hosting files for all platform hosts?

I don't think so. The Win16 files account for most of the IDE's configuration, including most of the OS/2 and Win32 IDEs' configurations. I think Watcom perceived Win16 as the lowest common denominator, and put the bulk of the common configuration data there.

Well, none of the ide*.cfg files are in the Win16 IDE zip files.
That seems to be the key that I'm missing.

So, you should have a fairly substantial BINP directory, a smallish BINW directory and little or no BINNT directory.

I have exactly two files in the BINW directory: wcl.exe
and wcl386.exe. Those are the only ones that came on the
zip files for OS/2 host and all targets that are designated
for that directory.

The only IBM-burnt CDs I have to hand are for MCP2. The installation program on those is x:\TOOLKIT\TKINSTAL.EXE, where "x" is your CD-ROM drive.

Well, my Warp CDs just got buried the other day by a
mountain of boxes. (The movers delivered our furniture and
other household goods from storage on Tuesday, and my
apartment looks like a warehouse.) I'll have to look again
at the CDs once I unbury them. (I can see them--I just
can't get to them.)

It is getting there. Object methods are even more fragmented than conventional (i.e. FORTRAN-style) modular programming.

Perhaps I'll have a better understanding once I get to the C++
tutorial.

Start at http://www.wxwindows.org/ and choose whichever implementations you need: OS/2, Win32, X11 (LINUX and *BSD), MacOS, whatever.

The only OS/2 downloads I found are via CSV, which I'm still
trying to make sense of. (I did download an OS/2 CSV client or
whatever the term is.) I emailed David Webster, who indicated that
the whole shooting match (all platforms, perhaps? can I even
select only OS/2?) runs about 100Mb. There's no way on God's green
earth I can download 100Mb of stuff, especially without some sort
of resume feature. I have a 56Kbps modem and my ISP limits me to
four hours per session. There is an available CD-ROM, but from the
description it appears that the OS/2 implementation of wxWindows is
NOT on the CD-ROM. I wish I could just ftp what I need and be done
with it.

Sara, I assume you really mean CVS. If so, get a copy of jCVS from http://www.jcvs.org/ and go with that. It's a Java gui implementation
of CVS that takes much of the grief out of the Unix-ese needed to run
the command line CVS. Runs with Java 1.1.8 or 1.3.x. The command line
is great once you learn it but I can never remember all the gotchas
with update/checkout/commit <g>.

If you really meant CSV, then disregard all prior babbling. I'm
catching up after 3 weeks in Abilene and getting ready for another
month, so expect an answers except for emails.

Will Honea <whonea@codenet.net>

___
■ KWQ/2 1.2i ■ And on the 8th day God said, "OK Murphy, you take over"

--- Maximus/2 3.01
# Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)
* Origin: Baddog BBS (1:218/903)

The way to write to a parallel device as a C stream that will work on
both DOS and OS/2 is to open it with fopen(), write to it whatever
is desired, and then close it with fclose().

So I treat the device like another file?

Yes. In this particular case, _exactly_ like you would treat a file.

» JdeBP «

--- FleetStreet 1.22 NR
# Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
* Origin: Baddog BBS (1:218/903)

The only OS/2 downloads I found are via CSV, [...]

You mean "CVS" ("concurrent versions system"), I take it.

"Open Source" projects where the source isn't available as one single archive that one can download and unpack, are a pain.

» JdeBP «

--- FleetStreet 1.22 NR
# Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
* Origin: Baddog BBS (1:218/903)

Hi David,

On 21-Jul-02, David Noon wrote to Sarah Nunez:

Well, George said he couldn't find it, so you perhaps need WSeB or
later. [George, did you check the BonusPak CD too?

No, I'm not even sure where it is at present. However there is lots of
space on the WARP 4 CD (only 550Meg of files on it), so why would it
be put on the Bonus CD?

George

--- Terminate 5.00/Pro
# Origin: A country point under OS/2 (2:257/609.6)
* Origin: Baddog BBS (1:218/903)