🚀 go-pugleaf

previously Roger Burton West <roger@firedrake.avertspam.demon.co.uk> wrote:
>DJGPP source for the latest KA9Q (not with Demon extensions, of course)
>is available at http://people.qualcomm.com/karn/ . May I respectfully

It has been for a while, and suffers from the slight drawback, as with
anything compiled by DJGPP, in that it won't run on sub 386's.
Personally this would render it less useful to myself and less widely
useful generally IMHO.

>suggest that this would be an _ideal_ code base for future upgrades? No
>more shell-memory problems; long filenames if run under Win95...

Long filenames are available under OpenDOS on any 8x86 machine.
/* well at least the 8086, 8088 and 80286 I've tried it on */
-- 
RobertM
Demon Internet Ltd
            "Trust the computer the computer is your fiend"

In article <881886281snz@wash.demon.co.uk>
   john$@wash.demon.co.uk (John Washington) writes:
> On 11 Dec, in article
>      <slrn68ujte.qs4.robm@desade.noc.demon.net> robm@demon.net
>      "Robert Mortimer" wrote:
[snip]
> RM> It has been for a while, and suffers from the slight drawback, as with
> RM> anything compiled by DJGPP, in that it won't run on sub 386's.
> OK, so that's a (dis)advantage of that compiler.  I've not seen
> that source, but is it reasonably std C?  If so, would it be
> a good base to take and add another 'make' file for BCC?

It is "reasonably" standard C, but from discussions on the nos-bbs
mailing list when the idea of moving to a GCC compile for jnos, as has
already happened for tnos, it would seem that changing between BCC and
GCC is far from being a smop.

> No doubt there'd need to be some condit compile, e.g. ksubr.c
> is presumably rather different.  But do people think it would
> be much more than that?

As I say from reports of the person who maintains tnos, the answer is
yes, but I couldn't swear that the same wouldhold true of another
version of KA9Q. On the other hand there are other free compilers that
will compile for syb 386's. /* can't remember the URL off the top of
my head */
 
[snip]
> What is the 'Karn' source?  Is it really by the great man himself,
> and does he still have the time to make a good job of it?

It is by Phil Karn himself, the 16bit version is no longer maintained,
he's still working on the GCC compile version. It does seem to be
quite reasonable, BUT if you can find any documentation for it
especially the new features, like say sound blaster support, you're
doing a much better job than me. I beleive there is a copy on
ftp.demon.co.uk, but I can't remember where.

> Is it responsively maintained, amalgamating best ideas from
> elsewhere?  Or are there other versions around that would be
> better to track?

It his own version, it's got in it what he'd like. There are some good
features in it, by US ecnryption restirctionc prevent them from being
released. Jnos and Tnos are both more actively miantained and used as
far as I can tell.

-- 
RobM
       "Trust the computer The computer is your fiend"
          http://www.ka9q.demon.co.uk/index.html

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

>On 11 Dec, in article
>     <slrn68ujte.qs4.robm@desade.noc.demon.net> robm@demon.net
>     "Robert Mortimer" wrote:
>
>RM> It has been for a while, and suffers from the slight drawback, as with
>RM> anything compiled by DJGPP, in that it won't run on sub 386's.
>
>OK, so that's a (dis)advantage of that compiler.  I've not seen
>that source, but is it reasonably std C?  If so, would it be
>a good base to take and add another 'make' file for BCC?

DJGPP was written explicitly as a port of Gnu C for DOS. In other words,
it's probably _more_ standard than BCC in most respects.

>No doubt there'd need to be some condit compile, e.g. ksubr.c
>is presumably rather different.  But do people think it would
>be much more than that?

This should certainly be doable. Personally, I should _very much_ like
to be able to compile under DJGPP _as well_ - because of the shell
memory issue, the long filename support, and so on.

Also... let's put it this way. I've written a bunch of game utility
programs that are available on my homepage (for a game that runs on any
PC with a VGA card). Each of them says in the documentation, "you need a
386; if you don't have one, get in touch". No-one has done so. Just how
big an issue is this? (I _am_ prepared to be convinced.)

>What is the 'Karn' source?  Is it really by the great man himself,
>and does he still have the time to make a good job of it?

The former, certainly; the latter, well, the archive I pulled is dated
12 August 96, so possibly not...

Cheers,

Roger (who is currently using Ian@isis' Yan, and is _very_ happy with
it...)

--
 /~~\_/~\ BEWARE ,,,  |~) _  _  _  _  |~)    __|_ _  _  \    / _  __|_
|  #=#======of==#   | |~\(_)(_|(/_|   |_)|_||  | (_)| |  \/\/ (/__\ |
 \__/~\_/ FILKER ```         _|          roger@firedrake.demon.co.uk
Vote Chris Bell for TAFF in 1998    http://www.firedrake.demon.co.uk/

In article <882061832snx@ka9q.demon.co.uk>
           robm@ka9q.demon.co.uk "Robert Mortimer" wrote:

>It is "reasonably" standard C, but from discussions on the nos-bbs
>mailing list when the idea of moving to a GCC compile for jnos, as has
>already happened for tnos, it would seem that changing between BCC and
>GCC is far from being a smop.

BC (especially with assembler) to gcc is a _lot_ harder than the other
direction.

Roger

--
 /~~\_/~\ BEWARE ,,,  |~) _  _  _  _  |~)    __|_ _  _  \    / _  __|_
|  #=#======of==#   | |~\(_)(_|(/_|   |_)|_||  | (_)| |  \/\/ (/__\ |
 \__/~\_/ FILKER ```         _|          roger@firedrake.demon.co.uk
Vote Chris Bell for TAFF in 1998    http://www.firedrake.demon.co.uk/

On Friday, in article <881886281snz@wash.demon.co.uk>
     john$@wash.demon.co.uk "John Washington" wrote:

> On 11 Dec, in article
>      <slrn68ujte.qs4.robm@desade.noc.demon.net> robm@demon.net
>      "Robert Mortimer" wrote:
> 
> RM> It has been for a while, and suffers from the slight drawback, as with
> RM> anything compiled by DJGPP, in that it won't run on sub 386's.
> 
> OK, so that's a (dis)advantage of that compiler.  I've not seen
> that source, but is it reasonably std C?  If so, would it be
> a good base to take and add another 'make' file for BCC?
> No doubt there'd need to be some condit compile, e.g. ksubr.c
> is presumably rather different.  But do people think it would
> be much more than that?

Reasonably std C ? How "std C" do you think Textwin is ?

So far as I know, nobody does DJGPP >> BC conversions, and the reasons 
are probably (a) it'd be seen as a retrograde step and (b) it's not easy 
at all.
I think that I've tried all of the main KA9Q flavours and the Karn/TNOS 
versions don't stand out. In fact none of them *function* that much 
better than the bog standard DIS 2.16d and most are well behind GEK's 
latest and greatest. Most have bells and whistles lacking in Demon's, 
and even Graham's, finest, but none actually work better, ie no faster 
or less flaky.
Why not just give in and track gremNOS ? It works fine, is a real 
advance and the code appears to be "std C", which is more than you can 
say for TW :(

> The way I'd like to go with TextWin is (regardless of whether we
> use the Karn source or not) to abandon the present method of
> issuing a set of replacement source modules.  Instead provide
> a utility (plus script files) that would take a given ka9q
> source and attempt to generate the extensions for TW.

I'd like that, *if* I could compile TW, but as it stands BC 2.0 and 3.0 
can't. Whatever "std C" TW's written in, I don't think anything earlier 
than BC 3.1 can talk it and I'd be amazed if any non-Borland compiler 
could either.

> The intended benefit is that release of a new ka9q could then
> have TW immediately bolted in without brain-work.  Of course,
> it would rely on ka9q upgrades not being too major.

Hmmm, I think that's where it dies. TW is essentially just an interface 
and that is one of the areas in which the later Karn efforts have 
changed rather dramatically. The one thing I did like was the screen 
scroll-back, but the surgery looked beyond my motivation and, probably, 
ability.

> What is the 'Karn' source?  Is it really by the great man himself,
> and does he still have the time to make a good job of it?

Source written by Karn ? The "export" version, I'd imagine.
As for the other question; yes and probably. Any the wiser ?
The better question might be, has he done a useful job ?  For my 
purposes, no.

> Is it responsively maintained, amalgamating best ideas from
> elsewhere?  Or are there other versions around that would be
> better to track?

Oh dear, who decides what's best ? Responsive to who ?
Face it, all of the main versions are Ham Radio driven. I expect that 
the best Ham ideas are there and in that sense it's responsively 
maintained, but my, and probably your, needs are not the same as Ham 
Radio operators.

Why worry ? My impression is that GEK has already been there and done 
that. His efforts may not exactly fit your requirements, but riding on 
his back has far more advantages than disadvantages. The main gain (for 
me at least) being that he's a far better programmer than I am.
My advice stands; take Graham's latest and bolt on your goodies.

> Hey, if it doesn't have AMcC's TextWin in it, how can it
> possibly be any good?  ;-)

It could have all the features that the DIS KA9Q and TW lack :)
This, presumably, is the point of the exercise and it begs the question;
what do you think is missing from DIS/TW ?

Ian.
-- 

  |  Ian Smith             |  "The Moving Finger writes;
  |  ian@isis.demon.co.uk  |   and, having writ, Moves on."

In article <Snews.971213.194821.roger.12615@firedrake.demon.co.uk>,
Roger Burton West <roger@firedrake.avertspam.demon.co.uk> writes
>
>Also... let's put it this way. I've written a bunch of game utility
>programs that are available on my homepage (for a game that runs on any
>PC with a VGA card). Each of them says in the documentation, "you need a
>386; if you don't have one, get in touch". No-one has done so. Just how
>big an issue is this? (I _am_ prepared to be convinced.)

Well people have said here that a lack of a non-386 version would be a
problem, so it certainly is a real issue rather than an imagined one
(though how big I wouldn't dare say). There's a reasonable argument
suggesting that a lot of KA9Q users are using it simply because their PC
would not sensibly cope with a Windows package (although I would expect
that the majority here are using it through choice).

From my own POV there's a lot that could be done with KA9Q if it had
more memory. Running a mailing list is a typical example - at present I
have KA9Q (well, YAN - like Roger I am very impressed with it)
configured to connect on its own every morning. Tim Illingowrth's
SmofList then processes the incoming mail, and (usually) results in some
outgoing mail. The only-slightly-modified (TM) demon.bat file spots this
(ie it looks for ~\mqueue\*.wrk) and then re-runs YAN. Total connect
time typically three or four minutes. Cost: 2* minimum call charge. If
SmofList could be run from a shell once incoming mail connections had
closed, I could probably halve my phone bill. It would need
modifications to both KA9Q and SmofList, I expect, but if there were a
well supported 386+ version of KA9Q then there would probably be the
demand to do it. [There are other ways of doing the same job, of-course;
that was just an example. Although useful suggestions as to other
methods gratefully received...]

-- 
Mark Rogers (Software Engineer)       -o-      mark@controlware.demon.co.uk
2M_ControlWare, Yaxley, Peterborough, ENGLAND.

In article <KOPzbKAilnl0IwJe@controlware.demon.co.uk>
   Mark Rogers <mark-news@controlware.demon.co.uk> writes:
> In article <Snews.971213.194821.roger.12615@firedrake.demon.co.uk>,
> Roger Burton West <roger@firedrake.avertspam.demon.co.uk> writes
> >Also... let's put it this way. I've written a bunch of game utility
> >programs that are available on my homepage (for a game that runs on any

Just a small point that might screw your sample somewhat, but out of
interest are this utilities available via other mechanisms? Becsue if
nor actually aquiring them from your web page may be somwhat less than
trivial for aforementioned sub 386 user, as there are few web browsers
that will work happily/well on a sub 386.

> >PC with a VGA card). Each of them says in the documentation, "you need a
> >386; if you don't have one, get in touch". No-one has done so. Just how
> >big an issue is this? (I _am_ prepared to be convinced.)
> Well people have said here that a lack of a non-386 version would be a
> problem, so it certainly is a real issue rather than an imagined one
> (though how big I wouldn't dare say). There's a reasonable argument

I for one would from time to time find the lack of a sub 386 version
somewhat awkward, as I was using a 286 and ka9q for DNS, routing and
as a console just the other day. /* superceded by a headless unix box
due to lack of monitors */

One alternative route might be to compile it using a large or huge
model and then run it undeer something like go32.exe or some such.
Which in theory at least should allow a better usage of memory without
prevnting sub-386 compiles.

[snip]
-- 
RobM
       "Trust the computer The computer is your fiend"
          http://www.ka9q.demon.co.uk/index.html

In article <882349157snx@ka9q.demon.co.uk>
           robm@ka9q.demon.co.uk "Robert Mortimer" wrote:

>> In article <Snews.971213.194821.roger.12615@firedrake.demon.co.uk>,
>> Roger Burton West <roger@firedrake.avertspam.demon.co.uk> writes
>> >Also... let's put it this way. I've written a bunch of game utility
>> >programs that are available on my homepage (for a game that runs on any
>
>Just a small point that might screw your sample somewhat, but out of
>interest are this utilities available via other mechanisms?

Yup - also available via my mailserver, and advertised as such on the
relevant newsgroup. No responses.

>I for one would from time to time find the lack of a sub 386 version
>somewhat awkward, as I was using a 286 and ka9q for DNS, routing and
>as a console just the other day. /* superceded by a headless unix box
>due to lack of monitors */

Fair enough; I said I was prepared to be convinced that there was a
demand for this, and I have been. Though I'd still like to be able to
compile under djgpp in protected mode (for memory, and especially for
long filenames, e.g. for mailboxes); and I have to reiterate that my
experience of porting software between djgpp and Borland C has been
quite good. (The only real problem I've had, as with KA9Q, is assembler
that has to be run in real mode. Snews has some too, for reasons I
haven't been able to fathom.)

Cheers,

Roger

--
 /~~\_/~\ BEWARE ,,,  |~) _  _  _  _  |~)    __|_ _  _  \    / _  __|_
|  #=#======of==#   | |~\(_)(_|(/_|   |_)|_||  | (_)| |  \/\/ (/__\ |
 \__/~\_/ FILKER ```         _|          roger@firedrake.demon.co.uk
Vote Chris Bell for TAFF in 1998    http://www.firedrake.demon.co.uk/

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

On Saturday, in article <883833096snz@wash.demon.co.uk>
     john$@wash.demon.co.uk "John Washington" wrote:

> On Friday, in article <883677104snz@grempc.demon.co.uk>
>      Graham@grempc.demon.co.uk "Graham E Kinns" wrote:
> 
> ..
> GK> >BTW, Graham, since most visitors will
> GK> >be using 8.3 filenames, how about using .htm instead of the more
> GK> >purist .html?
> GK> 
> GK> Because I can remember when .html was the norm?  As long as the server
> GK> presents it as text/html, it's a client-specific issue, shirley? :)
> 
> But the client then has to alter the relevant links in docs it
> downloads, else offline browsing doesn't work.  And as further
> docs are downloaded in later sessions it would need to search
> files already downloaded to adjust those links too.  A SMoP, but
> more than I fancy trying in any client I might write; your
> Airplane Mileage May Vary, shirley?             :-)

What are you using to fetch the pages and browse them ?  All of the DOS 
"browsers" I've tried handle .html in the same way that the DOS 
retrieval agents do - they knock off all suffix letters after the third. 
Navigation between pages works seamlessly. The only way I can see your 
problem arising is if you fetch and save under the DOS convention and 
view under something else.

> Actually the best way to tackle this IMO, is to write a proxy
> server that keeps track of the real URLs and the corresponding
> local filenames.  However, until all of us have one of those
> handy...

Collect the pages and view them under the same convention. Zero cost and 
available now :).

Ian.
-- 

  |  Ian Smith             |  "The Moving Finger writes;
  |  ian@isis.demon.co.uk  |   and, having writ, Moves on."

In article <883833096snz@wash.demon.co.uk>,
John Washington <john$@wash.demon.co.uk> wrote:
> 
> But the client then has to alter the relevant links in docs it
> downloads, else offline browsing doesn't work.  And as further
> docs are downloaded in later sessions it would need to search
> files already downloaded to adjust those links too.  A SMoP, but
> more than I fancy trying in any client I might write; your
> Airplane Mileage May Vary, shirley?             :-)
> 
> Actually the best way to tackle this IMO, is to write a proxy
> server that keeps track of the real URLs and the corresponding
> local filenames.  However, until all of us have one of those
> handy...

See http://www.gedanken.demon.co.uk/wwwoffle/index.html

(It works. Very well, too.)

-- 
'Anyone who slaps a "this page is best viewed with Browser X" label on
 a Web page appears to be yearning for the bad old days, before the
 Web, when you had very little chance of reading a document written on
 another computer, another word processor, or another network.' - T.B.L.