PS> I have a problem witch I will explain, but first, this 
 PS> is the file the "messed up" part of the program are 
 PS> suppose
 PS> to read (the lines by the probbs, there are several 
 PS> line before that, wich are commented out with "//", and a
 PS> few line after to...):

Damn, this one was hard to track down.  VERY annoying.  Not an annoying
bug, but annoying source code.  I'm going to recommend a few things to
clean this up.

 PS> When a was debugging, a made the program print every 
 PS> character it read, on the first line not commented out,
 PS> and when it had gotten to "Cls=" it craches (more on this
in the code).

 PS> Here is the important part of the code:

Question: have you tried running this more than once?  Does it ALWAYS crash
in the same place?

 PS> {
 PS>    ofstream error ("Errors.Log", ios::app);
 PS>    int *errorcode = new int;
 PS>    *errorcode = 0;
 PS>    char *ch = new char;
 PS>    *ch = ' ';
 PS>    int *state = new int;
 PS>    *state = 0;

What the HECK are you doing all this for?  You are using new to allocate a
single character... and the ch pointer is taking up 4 bytes just to point
at a single character!  Try:

int errorcode;
char ch;
int state;

Then don't dereference this.

 PS>    char *str = new char[200];

You're writing for OS/2.  Just put this on the stack.  I'll get back to the
reason later.

char str[200];

 PS>    ifstream ctl ("MaxNews.Ctl");
 PS>    if (ctl.fail())

Let's say that opening this fails.  (no such file, say)

 PS>    {
 PS>       ofstream error ("Errors.Log", ios::app);
 PS>       error << "Error: Unable to open MaxNews.Ctl
(Errorlevel 1)\n";
 PS>       error.close();
 PS>       ctl.close();
 PS>       return 1;     // Unable to open MaxNews.Ctl

You're returning 1, but NOT cleaning up the rest of your memory!  You
aren't deleting errorcode, ch, state, or str!  However, if they are on the
stack, as I proposed above, you don't have to clean it up - that's
automatic.

 PS>       ctl.get (*ch);

This would become ctl.get(ch);, for example.

 PS>       *state++;

Here's your bug.  *state++ is more explicitly parsed as:
   *(state++);

As you can see, you are incrementing the POINTER, not the value it points
at.  If you use state on the stack, it will simply increment this directly:

   state++; // what you want if you aren't using state as a pointer

 PS>       str[*state] = *ch;    // here is the bug, when 

Now that state is pointing somewhere other than where you want, it could be
pointing at a rather large number.

        str[125263]

is very likely to be outside your program space.  OS/2 doesn't like that,
and traps it.



--- Maximus/2 3.01