LR> I can see that DOS and even a VDM does not protect a program from
 LR> itself.

 LR> Isn't this also true of a native OS/2 program(task)?

Not nearly as much.  In DOS (or vdm) a random or NULL pointer can still be
read from/written to;  a native OS/2 program will trap right away.

Code segments are not writable.

You can't wonder past the end of a data segment.

System areas are hidden (for example, there is no way for an application to
muck around with memory arenas or device driver chains).


PF>program;  but I almost always develop and maintain 
PF>the code as an OS/2 progr
PF> because I know it will be better software in the 
PF> end.  I release the DOS ex

 LR> How do you know it will be "better" software, Peter?

Because it has proven itself in a less forgiving environment.


 LR> I am not sure I understand your meaning above when you say you
 LR> develop and maintain the DOS code as an OS/2 program?  Do you mean
 LR> developing and maintaining the DOS apps as a OS/2 program via VDM?

No;  what I mean is that even if the cusomer hires me to write a DOS program, 
 I write a native OS/2 program first,  then compile it for dos before delivery.


 LR> Why do get nervous when you use a DOS or Windows product?  Do you mean
 LR> that you get nervous when these types of apps run under OS/2?  Why

No,  I get nervous period.  I am nervous because I know a LOT about the
DOS/Windows environment, and the lack of safeguards and rules (and this is
exactly why dos crashes so often!!!)

 LR> should that make you feel nervous?  I do not understand why it would
 LR> make you less nervous if you knew they were developed in protected mode
 LR> (Using OS/2, right?)?

OS/2 is a fine example of a protected environment,  but it is not the only
one.  Must Unix's and NT are too.

 LR> Is it true that if you run a DOS or Windows apps under OS/2 you are
 LR> running under OS/2's protect mode so your other processes are protected
 LR> against these other types of app if they were to have un-found bugs in
 LR> them, right?

Yes,  for the most part  os/2 seems to protect itself and other
sessions from vdm/winos2 programs -- but these programs are not protected
from themselves.  In other words,  my accounting data (used with a dos
program that could be full of wandering pascal pointers) is vulnerable.


 LR> Would it be true to say all C++ compilers for OS/2 lack this Object
 LR> extensibility as well?

They are extendable,  but you need the source.  This is because it is left
to each compiler vendor to implement a code generator (this has nothing to
do with the C++ lang itself),  and they have all done it differently.

Note that SOM (system object model) DOES do what you want,  even between
languages.  So a pascal OS/2 program can use a SOM C++ object.   This is
all new,  and not yet embraced by MS,  so it may take a while to catch on
(and, If I am not mistaken,  Borland's cheap OS/2 compiler doesn't suppport
SOM).

IBM, Watcom and Metaware support SOM objects,  with the latter having the
new "Direct to SOM" which makes it even easier.  DtoSOM should be
available in Cset++ soon.


PF>Most of the time the OS is not even an issue -- the 
PF>customer wants something
PF>done and it just so happens I deliver it on OS/2, 
PF>because I know it will be
PF>better (safer) software than a DOS/Windows program.

 LR> Do you mean "safer" in that if the software you develop has a bug,
 LR> OS/2's protect mode will cancel your program and not bring down the
 LR> whole system?

Yes.  The idea here is that the Os/2 program is much more unlikely to fail
(than a dos program) because it doesn't have any wandering pointers (and if
it does,  it means it was not tested very well,  and will trap;but this is
GOOD.  A dos program in the same situation may appear to be running fine, 
but destroying data under the covers).

I am frequently called about to write unattended programs that NEVER fail. 
If left to itself (with no programs running at all),  I have demonstarted
that DOS will fail all by itself (this was with DOS 2.1,but today's dos
still runs with the same lax rules) after about 6 weeks (it slowly ate its
stack).

 LR> I am afraid that my customers would not appreciate it if my program
 LR> had such serious bugs that it killed DOS or aborted as a OS/2
 LR> process.

And since you are not programming in a protected environment,  you are much
more likely to deliver such a faulty program.

 LR> Either way, I think I would be inundated with angry customers wanting
 LR> their money back and likely ruining my companies reputation to boot.

You're really missing the point here -- the protected environment means
that your software is better tested before delivery, which means it it much
less likely to fail.  You seem to think that the protect environment will
CAUSE bugs.


--- Maximus/2 2.01