> Sounds good.  I haven't looked at the current version (I'll 
 > wait for the new version; make sure it gets into the 
 > Fernwood stream).

Now for a question that's sure to show my ignorance of Fernwood: How's
that work?

 >      1) The source code for everything that is required to link the
 >        application should be included.  Ie: If there is a set of
 >        worker/wrapper functions,  or a set of extended controls,
 >        all of the source code should be included.

Well, everything but the code for the toolbar and status bar controls
are there. (I didn't put that in there, because it was ugly! It's in
the class lib though, and looks (works) better.) That's one thing I
didn't like too much about Guidelines, was all of those calls to a
mysterious set of "Gui" this and that functions that I didn't find any
source for.

 >      2) (this is a very hard one) An isolated programmer should be able
 >        to design simple apps without first having a demo performed by
 >        someone familiar with the product.

That shouldn't be a problem. This product isn't very comprehensive,
but it IS easy to get a window to appear on the screen, and a few
right-clicks here and there on the window will get things going pretty
fast. It's hard to write a program and then approach it as if I'm
totally unfamiliar with it, but this one is pretty simple.

 >      3) IBM Cset should be supported.  This is the OS/2 standard
 >         compiler.

That's my biggest concern. I definitely want to support _at the very
least_ IBM, Watcom, MetaWare, GCC, and Borland (in that order). Are
there others?

 >      4) the product itself should be compiled with a stable compiler
 >         (IBM/Watcom/Metaware).

I'm getting ready to buy another compiler, just for that purpose.
Watcom's price looks like the best, and hopefully it will run on this
"puny" 8-meg machine. I'd get IBM C/Set++, but I would need a
supercollider to run the blasted thing, from what I'm told.

 > You might try calling them -- I know Watcom often gives compilers
 > to product  developers.   

Really??? Seriously??? (Tears of joy...) Wow. that would be great!
I'll definitely call them!

 > I noticed you didn't list Borland -- which 
 > means you are probably developing your product with it;   IMO,  this
 > is the last compiler you should bother  supporting if you want to
 > capture the  commercial/professional software developer.  If you are 
 > going after the hobbyist,  however,  I guess you'll want to  support
 > it.

Yeah, I might as well support it, (that's the easy part, since it was
written using it), but, ironically, it's probably the least important
one of the bunch to support.  

 > IBM and Watcom are so cheap,  if you plan to support them 
 > you should probably just buy them.  It's called capital 
 > investment :-).

I agree. That, and a couple of hard drives, some more RAM, some
day.... :)

 > I have IBM Cset++ 2.1 and Watcom 10.0a (both the must 
 > current).  JdeP has Metware.  I will look at your stuff as 
 > long as it doesn't take TOO much time.

That would be great... I still need to make sure there are no
Borlandisms lurking in there that will cause trouble. I'm sure there
are plenty.

 >       Some non-ansi,  yet defacto standard (msc/ibm/watcom) functions
 >       have been deformed or have different behavior.  Example
 >       _beginthread(), the whole c....() library (cprintf(), etc).

I ought to be okay there. Not much of that going on in the library. A
few calls to sprintf() here and there, but pretty basic. 

I _really_ wish Borland would stop trying to be the anti-matter ANSI,
and just play ball with everyone else.

 >      - Few of the compilers support the same #pragma's,  so avoid
 >        using them.

Okay. I'm only using ones of the kind that I see in the Toolkit's
header files, from IBM, and trying to stay away from the
Borland-specific ones.

 >        Therefore,  it is best to have all of the functions you wish to
 >        export from a LIB/DLL prototyped with something that overrides
 >        the default calling convention.  For example,  you could use the
 >        EXPENTRY define.

The problem I see here is with mangled names. How does one do that? 
"class _EXPORT EXPENTRY MyClass"?  That doesn't work, does it? 

 >      - #include all non-standard *.h files in one place,  so they
 >        can easily be fixed.  Examples:
 > 
 >         alloc.h
 >         malloc.h
 >         dir.h
 >         direct.h
 >         dos.h
 >         mem.h
 >         memory.h

Right! It was only recently that I discovered that Borland is
apparently the only one who uses mem.h and not memory.h, for one.

 >      - If (as you are) releasing source to be compiled by other
 >        people, release a MAKEFILE for each compiler that works with the
 >        MAKE that comes with that compiler.

Will do.

 >      - Look at GUIDELINES support for each compiler -- pay attention
 >        to the way they allow you to set the LIB/INCLUDE, etc,  directories
 >        from within guidelines.

Good idea. 

Thanks a lot for your suggestions. I'll get to work on this.

Regards,
Kelly

___
 X KWQ/2 1.2g NR X This tagline stolen by KWQ Mail/2.

--- Maximus/2 2.02