kerravon86

Ah no, that doesn't constitute "proof" of the original statement. However, it does now introduce a burden on me to show one single example to prove that I have not (to date) dismissed everything that everyone said. Prior to this the burden was on the other person to demonstrate that I had dismissed everything everyone had said. And we can be generous and allow that there is an implied "during the period that I was a member of the group", as it is increasingly absurd that he "knows" what I did in a group that he isn't even a member of. Note that his statement is also an active rejection. So if someone said "Ok, I'm going to the beach" and I fail to reply at all, because I have no reason to dismiss that statement, that would also constitute a counter-example. It's quite normal to not make an effort to say "I agree/don't dispute" to every single sentence someone says. So if you give me a time period, I'll post a link to a message where there is no sign of me dismissing what they said.

Own implementation of MSVCRT.DLL (C library - just C90) and KERNEL32.DLL (subset) too, that do 32-bit MSDOS-like calls.

Source or binary?

In both cases - it depends.

PDOS/86 will certainly run some binaries. But if you say "what about xyz" the answer is likely "probably not".

I don't have a lot of interest in 16-bit, so it's there for demonstration purposes mainly.

My interest is 32-bit.

The biggest genuine task I do is getting GCC to compile itself with full optimization, which requires something like 23 MB of memory on the mainframe and something like 37 MB on a PC.

Far far below the 4 GiB barrier (or even 2 GiB barrier), but above even 16 MiB, nevermind 640k.

If it is source code you have, then it will require recompilation at a minimum. I made use of that fact to provide a C-defined API to wrap the INT calls, so at least nominally you need to use those C functions. But you may be able to get away with an existing int86x call (or even assembler instruction), as the interrupts do exist (ie even in 32-bit). If your MSDOS program is C90-compliant then that should work unchanged - but that is the case for any environment, not just MSDOS or PDOS/386.

The huge memory model supposedly has a 4% overhead in practice, cited by someone who did such programming under OS/2. Personally I wasn't able to detect any slowdown at all, which is not surprising, because you are normally expected to be bottlenecked on some application doing some calculation, not the OS.

I am not aware that I have any obsession with Unix. For PDOS/386, PDOS/86 and PDOS-generic I use an API inspired by MSDOS. For z/PDOS I use the MVS API. I specifically don't want anything to do with Posix which mandated fork() but didn't provide for simple memory allocation.

Exactly. Conventional wisdom said that the 16 MiB barrier was impossible to break. After that was broken, the next thing that was impossible to break was the 2 GiB barrier. That was broken too. I'm talking about 32-bit S/370 code. Obviously IBM independently broke the 2 GiB barrier by switching to 64-bit programming.

But in hindsight, a "properly-written" program from the 1970s would have been restricted to 16 MiB at that time, but magically turned into 2 GiB in the 1980s, and then magically turned into 4 GiB in I think the 2010s (but this is murkier about when you want to start counting - real hardware was only demonstrated in 2022 or 2023 - can't remember).

stdint is a fundamentally wrong thing to do. If people were doing int_least32_t or whatever, ok, maybe that fits in with the spirit of C. But not int32_t.

"long long" itself is a fundamental violation of the original language too. If you want some large value - 512 bits, 1024 bits, 1113 bits, whatever - that's what "long" is for.

I am writing in C, not Turtle Graphics. I'm happy for the entire PDOS suite to be rewritten in Pascal or any other language. But first I haven't even completed C90. And it is extremely difficult trying to get a C90-compliant compiler too. I still haven't determined whether I need to dumb down PDOS to the C90 subset that SubC provides.

There are now makefiles for the 2 executables that I previously only provided bat files for. The bat files themselves were trivial anyway and I would have converted them to shell script for you had you asked. In actual fact, those .bat files are already shell scripts as far as I know. You can rename .bat to .sh if you want.

And you don't need to use Windows/Linux anymore, PDOS is self-hosting, including the building of the tools.

Dismissing one phrase/sentence from one person is a different concept to dismissing everything from everyone. And I have counter-examples of people providing value information. Only one counter-example is required to dismiss the original claim. Quite apart from the fact that it's his burden to prove.

A guy turned up to the PDOS discord and said he had a mainframe, then after some discussion he invited another guy with a mainframe to join. Neither had hard disks though, so I had to IPL from (emulated) tape. There are photos in the hercules-380 (not os380) group.

What does the UK and Australia consider Shakespeare's "Macbeth" to be?

That's the concept, regardless of whether they (we) chose to name it differently.

I dismissed "everything" that "everyone" said? What nonsense. Some people on the list made extremely valuable contributions. Some even provided extremely valuable code. Whatever this stuff was that I allegedly unreasonably dismissed, it apparently didn't stop getting PDOS working. Note that that was predominantly a mainframe list, and PDOS now works on real z/Arch hardware. And accesses 4 GiB of memory instead of being limited to 2 GiB. On real hardware. Despite being almost entirely S/370 code (generated by a slightly modified GCC 3.2.3).

I am the main author of PDOS. I am not claiming to "know better" (or even know what that means). And I don't recognize your description of "PCs ought" as an accurate description of my views. Or even understand what that means either. If you ask a specific question I'll try to give an answer, based on my current understanding, but note that all my beliefs are tentative.