Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

nuclear war (Miscellaneous)

posted by kerravon E-mail, Sydney, Free World South, 10.11.2022, 23:45

> > I started programming in assembly with the
> > Commodore 64 in 1984. Not a proper assembler -
> > the equivalent of MSDOS "debug".
>
> OK — now try to get a self-hosted C compiler working on that.
Other people did that. But why would I personally
want to do that? I didn't say that that was
something I personally wanted to do. I didn't
even say that I wanted to program in C at all
on an 8-bit machine.

My 16-bit OS only really becomes practical with
about 2 MB of memory, so I need a 16:16 machine
with a 5-bit segment shift, or something similar
to the 80286 will also work, and that is my
interest and priority.

I just want a set of standards to work to for
all that.

> > > With all due respect, methinks you know not whereof you speak.
> ...
> > What I'm interested in is what to do if/when technology
> > reaches a 16:16 stage.
>
> Well, yes, if we end up in some universe where your idea might make sense,
> then ... your idea might actually make sense. Yes, yes, if you put it that
> way, Mr. Captain Obvious Tautology.
>
> The real question here is why you think there might be a snail's
> chance that your idea may make any sense. Because, you know, disasters
> have a way of not going according to our expectations or wishes.
> And that is partly what makes them disasters.

I've already outlined why - if the nuclear war goes
a certain way, new computers will be 8-bit, and when
new computers reach 16-bit, and memory availability
exceeds 64k, segmentation may well be chosen as a
solution. It's happened before.

> And nowhere do you explain
> - why this "standardization" is so important in a post-nuclear world
I'm not particularly claiming that it is "important".
I just want a standard to code to. POSIX doesn't cut it.

> - why your proposed standards are any good
I didn't claim that either.

> - or why existing standards or existing practices somehow fall short.
The only existing standard that I know of is POSIX,
and it falls short because it is not appropriate
for small computers like the 8086 because it
basically requires virtual memory to support crap
like fork(). If they remove fork() from POSIX and
only have posix_spawn(), that may be a step in the
right direction, but I'm not sure it is sufficient.

I would be interested in your opinion if you think
that is all that is required.

Existing practices I'm not actually aware of. I
never wrote DOS-specific software, I followed the
C90 standard, and still do. I do know that people
directly wrote to 0xb8000 and I also know that
Microsoft only supported the ANSI terminal in
Windows very recently, and I know for MSDOS they
only ever supported ANSI output, not keyboard
input.

So I know that standard wasn't being followed. I
follow it myself though, for fullscreen
applications that I support on PDOS/386 (and
recent Windows).

> On a somewhat unrelated tangent:
>
> > And you can add to that the fact that depending
> > on how you count, we've already had World War 3
> > (2 hot, 1 cold), won in our favor already. And
>
> Well, that certainly looks like a view of history straight out of the
> "Project
> for the New American Empire Century". It is easy to wax
> lyrical about how "we" are on the "winning" side — whatever that means
Yeah, some people like to pretend there was no winner
of the Cold War. If the Soviets had actually managed
to enslave the entire Europe, and you happened to be
living in Western Europe when they kicked down your
door, maybe you would understand the reality of what
it's like to lose the Cold War.

> — if "we" do not end up as collateral damage. And there was much
> needless collateral damage during the Cold War. But I digress.
Take it up with Mr Marx.

>> I should also point out that creating an API for small
>> (16:16) systems is not technically impossible. I have
>> already made an opening offer here:
>> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/pos.c

> Well... what is the niche your proposed "standard" is supposed to fill?
People coding int86(...) which looks bad and
doesn't work when upgrading to 32-bit and
64-bit and different processors like the
68000 that would otherwise be capable of
running your application.

> There is definitely already some sort of de facto common API that was
> implemented across the major compilers targeting MS-DOS — including Open
> Watcom, Microsoft C, and later versions of Borland C++.
> (Edit: and Digital Mars.)
> So what exactly does your new proposed standard offer?
Perhaps nothing. Is there any reason why OS/2 2.0
didn't use that same API? And 64-bit Windows? Or
rather - could it?

If there's nothing wrong with it, and the only issue
is that ISO isn't interested in publishing a formal
standard, so it needs to remain a "de facto common
API", so be it, I'll probably switch to that, and
write it in terms of Pos* calls. And perhaps write
another version that turns them into Windows calls,
and another version that turns them into OS/2 calls,
and another version that turns them into POSIX
calls.

Or it could be done the other way around - take the
Windows API and implement it for MSDOS, since
Windows doesn't use fork().

Or it could be none of the above. That's my question.

BFN. Paul.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22155 Postings in 2045 Threads, 396 registered users, 16 users online (0 registered, 16 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum