🚀 go-pugleaf

In article <883315925snz@wash.demon.co.uk>
           john$@wash.demon.co.uk "John Washington" writes:

>Ta to other contribs to this thread, sorry I'm late replying.

Er, me too ... I'm currently working away from a feed of demon.*

>IS> Reasonably std C ? How "std C" do you think Textwin is ?
>
>No idea.  Haven't noticed any "clever tricks", but I guess the
>compiler bug which GK spotted is being provoked by something that
>might / might-not be std but in any case isn't middle-of-the-road.

Having reproduced the bug with the smallest code snippet, it appears
to be down to the optimization of de-referenced struct pointers in
registers - it has little to do with the "std"-ness of the code.
Don't use -Oc with BC3.1 for production code is my advice - BC4.0+
appears to have fixed it.  (I forget the specifics but I can dig them
out for those interested - it was loading ES and then trying to use
the pointer that was previously in there leading eventually to a
movedata() call with random memory addresses in the line scroll
routine).

>BTW, Graham, since most visitors will
>be using 8.3 filenames, how about using .htm instead of the more
>purist .html?

Because I can remember when .html was the norm?  As long as the server
presents it as text/html, it's a client-specific issue, shirley? :)

>IS> I'd like that, *if* I could compile TW, but as it stands BC 2.0 and 3.0 
>IS> can't. Whatever "std C" TW's written in, I don't think anything earlier 
>IS> than BC 3.1 can talk it

I too would be interested to know more about this - the only problem
I've spotted so far is that BC4's CPP doesn't like C style 0x
constants in the inline asm.  ISTR seeing MSC conditionals in the
headers as well.

>PK's version in principle holds some attraction for me
>(tho I've never seen it) because he's been maintaining it for so
>many years (and therefore is likely to continue to do so).

Um, IIRC Phil's real mode version of Nov 95 was his last - AFAIK there
only was the one DJGPP version which lacks memory locking on the
interrupt code which is a serious shortcoming (it can crash during a
VM swap unless used only with the PMode DPMI provider under Dos -
allegedly Win95 has or had similar problems). The TNOS version has the
fixes in place. PK's version also lacks many of the bug fixes in the
DIS version although there are significant improvements to the TCP
code (some of which are in GremNOS) and the kernel is much better
which should improve performance with fast serial rates (this is
probably the Next Big Fix as it's the biggest obstacle in porting the
DIS version to DJGPP - some of GremNOS has been fixed/tested with
DJGPP, FYI).

Cheers, Graham.
-- 
Graham E. Kinns
Graham@grempc.demon.co.uk