The google groups ban finally caused me to
prioritize my newsreader software.

Here is the pure C90 code used to post this message:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/pdpnntp.c

(and I can also read using that, but it's another
level of pain).

So I'm still using google groups to read.

Replies are going to be difficult I guess.

I run this program under PDOS/386. With qemu
giving me a traditional serial port, and PDOS/386
giving the application a bog-standard C90 stream
to that serial port.

BFN. Paul.

Paul Edwards <mutazilah@gmail.com> writes:

> Replies are going to be difficult I guess.

There is a lot of bureaucracy in the headers if you want to get
everything right. Sending the reply via e.g. Netcat/Telnet is no
alien magic.

--
Stay ommmmmmptimistic!

Paul Edwards <mutazilah@gmail.com> writes:

> The google groups ban finally caused me to
> prioritize my newsreader software.
>
> Here is the pure C90 code used to post this message:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/pdpnntp.c
>
> (and I can also read using that, but it's another
> level of pain).
>
> So I'm still using google groups to read.
>
> Replies are going to be difficult I guess.
>
> I run this program under PDOS/386. With qemu
> giving me a traditional serial port, and PDOS/386
> giving the application a bog-standard C90 stream
> to that serial port.

Amazing. How do you compose the messages sent by pdpnntp? Does it read
from the STDIN? Do you always write it to a file first?

Do you use Google Groups with a browser that runs on PDOS?

On 06/12/23 02:22, Julieta Shem wrote:
> Paul Edwards <mutazilah@gmail.com> writes:
>
>> The google groups ban finally caused me to
>> prioritize my newsreader software.
>>
>> Here is the pure C90 code used to post this message:
>>
>> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/pdpnntp.c
>>
>> (and I can also read using that, but it's another
>> level of pain).
>>
>> So I'm still using google groups to read.
>>
>> Replies are going to be difficult I guess.
>>
>> I run this program under PDOS/386. With qemu
>> giving me a traditional serial port, and PDOS/386
>> giving the application a bog-standard C90 stream
>> to that serial port.
>
> Amazing. How do you compose the messages sent by pdpnntp?

The micro-emacs text editor. I'm using a later
version still, but I have an earlier public
domain version available too. I didn't know
the latter even existed until a few months ago.

> Does it read from the STDIN?

I don't have redirection working on PDOS.

> Do you always write it to a file first?

Yes. And I found out just a couple of weeks ago
that when replying to an existing message I need
to manipulate the references too.

> Do you use Google Groups with a browser that runs on PDOS?

No. I don't have a browser for PDOS.

My plan is to import the newsgroup messages into
Fidonet technology which is already working on PDOS
(msged etc).

But Google Groups is going to stop supporting
newsgroups on February 15, 2024.

Other development effort (using PDOS-generic to
run Win32 executables on OS/2 2.0+) has resulted
in me installing ArcaOS and I noticed that it
installed a newsreader (Thunderbird).

So I have now switched to that for a much better
user experience! But yeah - ultimately I want to
return to msged, and having it invoke micro-emacs
as an external editor. It's been a very long road
just to get back to where I already was.

BFN. Paul.

Paul Edwards <mutazilah@gmail.com> writes:

> On 06/12/23 02:22, Julieta Shem wrote:
>> Paul Edwards <mutazilah@gmail.com> writes:
>>
>>> The google groups ban finally caused me to
>>> prioritize my newsreader software.
>>>
>>> Here is the pure C90 code used to post this message:
>>>
>>> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/pdpnntp.c
>>>
>>> (and I can also read using that, but it's another
>>> level of pain).
>>>
>>> So I'm still using google groups to read.
>>>
>>> Replies are going to be difficult I guess.
>>>
>>> I run this program under PDOS/386. With qemu
>>> giving me a traditional serial port, and PDOS/386
>>> giving the application a bog-standard C90 stream
>>> to that serial port.
>>
>> Amazing. How do you compose the messages sent by pdpnntp?
>
> The micro-emacs text editor. I'm using a later
> version still, but I have an earlier public
> domain version available too. I didn't know
> the latter even existed until a few months ago.
>
>> Does it read from the STDIN?
>
> I don't have redirection working on PDOS.
>
>
>> Do you always write it to a file first?
>
> Yes. And I found out just a couple of weeks ago
> that when replying to an existing message I need
> to manipulate the references too.
>
>> Do you use Google Groups with a browser that runs on PDOS?
>
> No. I don't have a browser for PDOS.
>
> My plan is to import the newsgroup messages into
> Fidonet technology which is already working on PDOS
> (msged etc).
>
> But Google Groups is going to stop supporting
> newsgroups on February 15, 2024.
>
> Other development effort (using PDOS-generic to
> run Win32 executables on OS/2 2.0+) has resulted
> in me installing ArcaOS and I noticed that it
> installed a newsreader (Thunderbird).
>
> So I have now switched to that for a much better
> user experience! But yeah - ultimately I want to
> return to msged, and having it invoke micro-emacs
> as an external editor. It's been a very long road
> just to get back to where I already was.

Do you enjoy that? It seems such a laborious way to post messages.

On 20/12/23 11:42, Julieta Shem wrote:

>> Other development effort (using PDOS-generic to
>> run Win32 executables on OS/2 2.0+)

I got this to work a few hours ago.
See win32os2 at http://pdos.org

>> So I have now switched to that for a much better
>> user experience! But yeah - ultimately I want to
>> return to msged, and having it invoke micro-emacs
>> as an external editor. It's been a very long road
>> just to get back to where I already was.
>
> Do you enjoy that? It seems such a laborious way to post messages.

Neither msged nor micro-emacs are laborious. But
I don't have that for usenet yet.

It's more a question "if you only have public
domain code - what can you do?".

And I want to see the limits of that, ensure
the protocol works, and then I can go offline
or whatever and "fill the gaps".

If for some reason you only had access to public
domain software, how much devastation would that
cause to you?

I don't specifically know what circumstances that
situation may arise in. Maybe Fujitsu or whoever
wants to do a clean room development of something
and to put them in the best position they insist
that their engineers cannot use anything without an
explicit PD notice.

What I DO know is that almost all freeware developers
are very insistent on not releasing ownership of
their software. Of course that's their right, but
whatever it is they're reluctant to give up is
exactly what I want to make sure SOMEONE gives up,
even if that someone ends up being me a lot of
the time.

So yeah - it's not that I like doing it - it's that
any work I do I am always conscious of "how will I
do that task if I only have PD software?". That's
one of the reasons I stick with the command prompt.
I believe I can replace all the work I do at the
command prompt with PD software.

There is some quibbling when it comes to the
C compiler. ie C90 compliance remains a dream -
sort of. There is cc64 and SubC. And a dream.

BFN. Paul.

Paul Edwards <mutazilah@gmail.com> writes:

> On 20/12/23 11:42, Julieta Shem wrote:

[...]

>>> So I have now switched to that for a much better
>>> user experience! But yeah - ultimately I want to
>>> return to msged, and having it invoke micro-emacs
>>> as an external editor. It's been a very long road
>>> just to get back to where I already was.
>>
>> Do you enjoy that? It seems such a laborious way to post messages.
>
> Neither msged nor micro-emacs are laborious. But
> I don't have that for usenet yet.
>
> It's more a question "if you only have public
> domain code - what can you do?".
>
> And I want to see the limits of that, ensure
> the protocol works, and then I can go offline
> or whatever and "fill the gaps".
>
> If for some reason you only had access to public
> domain software, how much devastation would that
> cause to you?

Not being able to run the GNU EMACS would be a major upset, but I'm glad
to hear you're running micro-emacs. I guess you have a public domain C
compiler.

> There is some quibbling when it comes to the
> C compiler. ie C90 compliance remains a dream -
> sort of. There is cc64 and SubC. And a dream.

I'd be happy with C89.

Anyway, your project seems interesting. Are you documenting your
experience somewhere online? ``The Public Domain Survival Guide''?

On 23/12/23 04:15, Julieta Shem wrote:
> Paul Edwards <mutazilah@gmail.com> writes:
>
>> On 20/12/23 11:42, Julieta Shem wrote:
>
> [...]
>
>>>> So I have now switched to that for a much better
>>>> user experience! But yeah - ultimately I want to
>>>> return to msged, and having it invoke micro-emacs
>>>> as an external editor. It's been a very long road
>>>> just to get back to where I already was.
>>>
>>> Do you enjoy that? It seems such a laborious way to post messages.
>>
>> Neither msged nor micro-emacs are laborious. But
>> I don't have that for usenet yet.
>>
>> It's more a question "if you only have public
>> domain code - what can you do?".
>>
>> And I want to see the limits of that, ensure
>> the protocol works, and then I can go offline
>> or whatever and "fill the gaps".
>>
>> If for some reason you only had access to public
>> domain software, how much devastation would that
>> cause to you?
>
> Not being able to run the GNU EMACS would be a major upset, but I'm glad
> to hear you're running micro-emacs. I guess you have a public domain C
> compiler.

It took me around 35 years to find that
micro-emacs was public domain at one point.
And I spent the effort to find the last
public domain version and that is working -
to some extent. I still haven't switched
to it for my daily use until the deficiencies
are resolved.

>> There is some quibbling when it comes to the
>> C compiler. ie C90 compliance remains a dream -
>> sort of. There is cc64 and SubC. And a dream.
>
> I'd be happy with C89.

Noting that C89 and C90 are identical other
than seemingly gratuitous section number
changes.

> Anyway, your project seems interesting. Are you documenting your
> experience somewhere online? ``The Public Domain Survival Guide''?

Yes - I started a vlog to demonstrate my use
of PDOS/386 for actual development. Or maybe
UC386 - that's what is purely public domain.

That was at a time when I thought the development
effort had come to a logical conclusion.

But I think advances from others (a public domain
linker that supported PE), made me switch back to
my more productive development environment as I
don't want to jeopardize that.

And the breakthroughs keep on happening. The linker
started to support 64-bit which brought it into
range of cc64 (in this group - from Bart).

And there has been a constant stream of breakthroughs
(I consider them to be, anyway) such that I am still
not able to return to my PDOS-on-real-hardware funny
vlog to demonstrate what is possible.

Anyway, the vlog is at the bottom of http://pdos.org

I have no idea what the entertainment value is.

BFN. Paul.

On 2023-12-22, Julieta Shem <jshem@yaxenu.org> wrote:
> Paul Edwards <mutazilah@gmail.com> writes:
>
>> On 20/12/23 11:42, Julieta Shem wrote:
>
> [...]
>
>>>> So I have now switched to that for a much better
>>>> user experience! But yeah - ultimately I want to
>>>> return to msged, and having it invoke micro-emacs
>>>> as an external editor. It's been a very long road
>>>> just to get back to where I already was.
>>>
>>> Do you enjoy that? It seems such a laborious way to post messages.
>>
>> Neither msged nor micro-emacs are laborious. But
>> I don't have that for usenet yet.
>>
>> It's more a question "if you only have public
>> domain code - what can you do?".
>>
>> And I want to see the limits of that, ensure
>> the protocol works, and then I can go offline
>> or whatever and "fill the gaps".
>>
>> If for some reason you only had access to public
>> domain software, how much devastation would that
>> cause to you?
>
> Not being able to run the GNU EMACS would be a major upset, but I'm glad
> to hear you're running micro-emacs. I guess you have a public domain C
> compiler.
>
>> There is some quibbling when it comes to the
>> C compiler. ie C90 compliance remains a dream -
>> sort of. There is cc64 and SubC. And a dream.
>
> I'd be happy with C89.

C89 is a mostly nice language, but there are a few things
you might if working in C89.

- cannot initialize aggregates with with non-constant expressions.

void do_something_with_rect(int x, int y)
{
struct rect r = { x, y }; // no-go in C89
/* ... */
}

- library: no snprintf, numerous math functions.

- Things like implementation-defined truncation for / and %, when
one operand is negative.

- preprocessor: no variadic macros.

Sometimes when people say they would be happy with C89, they really mean
GNU89: the language accepted by GCC with -std=c89, without -pedantic.

And of course, they want free use of all the available library
functions; those must not go away just because the dialect is older.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <433-929-6894@kylheku.com> writes:

> On 2023-12-22, Julieta Shem <jshem@yaxenu.org> wrote:
>> Paul Edwards <mutazilah@gmail.com> writes:
>>
>>> On 20/12/23 11:42, Julieta Shem wrote:
>>
>> [...]
>>
>>>>> So I have now switched to that for a much better
>>>>> user experience! But yeah - ultimately I want to
>>>>> return to msged, and having it invoke micro-emacs
>>>>> as an external editor. It's been a very long road
>>>>> just to get back to where I already was.
>>>>
>>>> Do you enjoy that? It seems such a laborious way to post messages.
>>>
>>> Neither msged nor micro-emacs are laborious. But
>>> I don't have that for usenet yet.
>>>
>>> It's more a question "if you only have public
>>> domain code - what can you do?".
>>>
>>> And I want to see the limits of that, ensure
>>> the protocol works, and then I can go offline
>>> or whatever and "fill the gaps".
>>>
>>> If for some reason you only had access to public
>>> domain software, how much devastation would that
>>> cause to you?
>>
>> Not being able to run the GNU EMACS would be a major upset, but I'm glad
>> to hear you're running micro-emacs. I guess you have a public domain C
>> compiler.
>>
>>> There is some quibbling when it comes to the
>>> C compiler. ie C90 compliance remains a dream -
>>> sort of. There is cc64 and SubC. And a dream.
>>
>> I'd be happy with C89.
>
> C89 is a mostly nice language, but there are a few things
> you might if working in C89.
>
> - cannot initialize aggregates with with non-constant expressions.
>
> void do_something_with_rect(int x, int y)
> {
> struct rect r = { x, y }; // no-go in C89
> /* ... */
> }

That's a bit sad. Similarly perhaps, we can't also declare counters
inside a for look as in C99

for (int i = 0; i < 10; ++i)
;

But we can sort of live with that.

> - library: no snprintf, numerous math functions.

We can live without snprintf by writing it ourselves? Which math
function would be out?

> - Things like implementation-defined truncation for / and %, when
> one operand is negative.
>
> - preprocessor: no variadic macros.

To live with that, we can do like DJB did it once. When he needed one
more argument, he'd define a new longer macro and expanded the
underlying function with an extra argument --- if you know what I mean.

> Sometimes when people say they would be happy with C89, they really mean
> GNU89: the language accepted by GCC with -std=c89, without -pedantic.
>
> And of course, they want free use of all the available library
> functions; those must not go away just because the dialect is older.

You got a point.

On 23/12/23 04:43, Kaz Kylheku wrote:

> C89 is a mostly nice language, but there are a few things
> you might if working in C89.

There are a few things I miss when I can't
even program in C89!

> - cannot initialize aggregates with with non-constant expressions.
>
> void do_something_with_rect(int x, int y)
> {
> struct rect r = { x, y }; // no-go in C89
> /* ... */
> }
>
> - library: no snprintf, numerous math functions.
>
> - Things like implementation-defined truncation for / and %, when
> one operand is negative.
>
> - preprocessor: no variadic macros.

For the work that I do (developing a portable
public domain operating system and tools -
quibbling possible on some of this), I haven't
missed any of those things. I've never attempted
to go beyond C90 anyway.

My problem is whether I can continue with C90
or whether I need to go down to SubC level.

I can recompile all my infrastructure with
cc64 on a 64-bit platform, but on 32-bit I
am a bit stuck. Also, cc64 may be considered
binary-only (generated C code).

There is something I am missing in my work.
A define for ESC.

I wish to use ANSI X3.64 on top of C90, so
that I can support fullscreen apps in a
standard manner. I went to an enormous amount
of effort (still not complete, still subject
to some debate (*)) to get the mainframe to
support EBCDIC ANSI too.

I have a semi-proposal to add

#define ESC_CHAR 0x1b
#define ESC_STR "\x1b"

to a C90+ "standard". But haven't had sufficient
feedback as to the best way of doing that (to
achieve what I want - not what others want).

Putting a \e puts a burden on the compiler
that I suspect should be avoided (much easier
to edit someone's stdio.h or ctype.h to add
a couple of defines).

BFN. Paul.

(*) While I can connect an EBCDIC ANSI terminal
(no physical thing exists to my knowledge, but
mfterm in PDOS/386 provides the emulated conceptual
thing) to both Hercules/380 and zPDT, I am failing
to connect to the OSA-ICC I believe because qemu
is sending packets with one character (as a result
of me using the COM port) rather than a complete
packet that telnet negotiation normally sees. I
have a plan for a TCP/IP application (see modem.c
in ozpd) that would use XOFF (instead of the
previous plan to use a timeout) to consolidate a
packet before sending. But I'm waiting for access
to a real OSA-ICC to test the theory. Currently it
is only a theory that this is why the OSA-ICC is
dropping the connection (to qemu). Once that is
working I intend to use a physical null modem
cable so that PDOS/386 really does connect to a
mainframe (effectively) via a serial port - using
native EBCDIC ANSI - not ASCII ANSI emulating a
3270 or whatever is currently being used.

On Sat, 23 Dec 2023 05:30:33 +0800, Paul Edwards wrote:

> There is something I am missing in my work.
> A define for ESC.

Give that so many escape sequences have “[” as the next character, maybe
you want one for CSI as well.

On 2023-12-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 23 Dec 2023 05:30:33 +0800, Paul Edwards wrote:
>
>> There is something I am missing in my work.
>> A define for ESC.
>
> Give that so many escape sequences have “[” as the next character, maybe
> you want one for CSI as well.

Well, CSI is two characters: ESC and '['.

That's the 7 bit compatible CSI. Turns out there is another CSI in the
spec that is one byte: U+009B. I didn't even know that until fairly
recently.

I think that is rarely used, and offers no advantage if it happens
to be encoded into two bytes of UTF-8.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 29/12/23 12:37, Lawrence D'Oliveiro wrote:
> On Sat, 23 Dec 2023 05:30:33 +0800, Paul Edwards wrote:
>
>> There is something I am missing in my work.
>> A define for ESC.
>
> Give that so many escape sequences have “[” as the next character, maybe
> you want one for CSI as well.

It is unclear to me what should be in the/a
C/language standard and what should be left
to a popular third-party library.

What's the mathematical equation that proves
that one way or another?

ESC has to go in because it is system-dependent.

CSI can be constructed in a portable manner by
a 3rd party library.

"portable" for me is the ASCII character set,
even if encoded in EBCDIC code points.

I doubt that the C library author should be
burdened with sin() etc. There should be some
minimal set of functions. I think.

BFN. Paul.