-=> Quoting Luns Tee to Phil Crown <=- 

 PC> Anybody see any obvious problems with the following code?  Calling
 PC> free(Track_Buffer) under OS/2 causes SYS3175, under DOS there are no
 PC> apparent problems.
 LT> 
 LT> Works fine when I build it under C/Set++ 2.0 after removing the
 LT> reference to dos.h, and making the fopen mode "r" rather
than "rt"
 LT> (IBM doesn't accept the t, but it's the default anyway). 
 LT> A few comments though.. why bother with

I think it may be a bug in BCOS2 now.  It works under EMX 0.9a too.

 LT> 
 LT> #define ONE_HALF(x)       (x*50/100)
 LT> 
 LT> when putting x/2 or x>>1 is already quite readable? Also, while I

Good idea, I noticed that too after writing the macro. :-)

 LT> don't know what this program is leading to, your calls of tslice()
 LT> worry me - why are you sleeping after each and every character? A

Its supposed to be the scroll back buffer in my terminal program.  Obviously
it will be bigger than 40 bytes... :-)  Also it can be used for watching for
strings like "What is your name?" and "Password?" for scripting.

My Vio terminal program is about done and works great (on my machine).  It
has a script learner that will learn a mail run type script and a speciality
feature for doing remote Wildcat!(tm) File-Sysop Maintenance, i.e. tagging
and moving inbound files to the proper area.  Am working on a PM terminal
program now, but just printing chars to the client window and scrolling the
window is complicated in the GPI.  I am trying to figure out how to make the
auto-sizing fonts so when the window is resized the font adjusts so that it
all fits into the client window.  I think I may need to use a bitmap font?

tslice is only there to slow it down so I can see what's happening.

 LT> program that has real work to do should just do it - OS/2 will grab
 LT> the CPU when it's needed elsewhere. Lastly, just a style comment -
 LT> the use of gloabls makes it easy to break things since on reading over
 LT> a function that uses them, you don't know from the context where
 LT> they've been and what other code might have done to them. Better as a
 LT> habit to pass into a function everything that it's going to be using.
 LT> That way, once you have the function working, if on using it
 LT> elsewhere, something breaks, you know to look at what you're passing
 LT> it rather than having to step your way through the function again to
 LT> figure out what it's using.

I found out the problem with global variables as you mentioned through
experience.  I had a program that had nothing but globals, after it grew a
bit I started having problems remembering what was what, and other things.
Globals are fine for some things, but I wouldn't declare everything as a
global again! :-)

         ////
        (o o)
----oOO--(_)--OOo----   phil.crown{at}bluecafe.com | Fido 1:124/6108.2

--- Blue Wave/Max v2.20