Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

PDOS-generic (Announce)

posted by marcov, 03.11.2021, 16:43

> > A good, industry wide solution for 386 apps in e.g. the early nineties
> > would have been welcomed, tools inclusive.
>
> GCC couldn't fit the bill?

DJGPP on extender V2 had its first release in 1996, by then the beginning of the end for Dos had already started.

Djgpp v1 was cumbersome and not selfhosted (needed licensed Borland compiler to compile)

Moreover gcc was only the toolchain side of the problem (if you liked C to begin with).

The core problem was not having a stable 32-bit application interface built into dos. DJGPP still thunks through the extender to access the old 16-bit interrupt calls. _NOW_ in 2021.

> Can you give an example
> of what would have been good and technologically
> possible?


Extender and long term stable 32-bit API built into dos.

> And whether the starting point would
> have needed to be before the 80386 came out in
> 1986.
Maybe having it early (before '90-92) would have created more of a driving force for 386 sales.

> Note that most of a 32-bit C compiler can
> be written without a specific 32-bit processor.
It is not just about the compiler.

> > I would take msdos 5 as more logical point at which a change should have
> > been forced. By then, new machines routinely were 1MB or more, and 386s
> > started to penetrate.
>
> Ok, so that's 1991. What specific change would
> you have forced?
Extender built in, 32-bits API (dos interface).

Note that to a certain degree this was the case (himem/emm386) for memory usage, but not for the rest.

> I think it is good for programmers to have a set
> of rules which are known to work cross-platform,
> and are accepted internationally, which only
> happened in 1990.
If you mean POSIX, the attempt at Unix reunification that was later rebranded as universal, that was first published in 1988, and was already in the works since 1995.

But the universality of that was always more a wish from the unix crowd than an absolute fact, and worse only about reuse of application in source form.

> > Before the standard, there was K&R, ..... if you were an Unix
> workstation
> > programmer. But in Dos, C was only emerging. Apple and Microsoft (both
> Unix
> > licensees and vendors!) switched to C, but the application programmers
> > despised it, because it too often was combined with abstraction layers
> that
> > were considered useless overhead.
>
> What abstraction layer are you talking about?
> fopen/fread?

32-bits alternatives for many used dos/bios calls.Though that would probably hit the roof of shared services and drivers and thus compatibility.

And that is probably all the reasons why this all didn't happen. The major vendors recognized this and had already embarked on quests for WinNT and OS/2.

> Was the complaint valid?

Yes. 16-bit code being tight was very important. 640kb simply wasn't enough.

> Was there
> a solution to the complaint that wouldn't have
> involved abandoning C entirely? (in favor of
> assembler I assume).
There was, but the resulting C would be a mix of HLL and assembler. IOW the C would be for productivity reasons only, and the result would not be portable.

That latter aspect only emerged in the mid nineties, and even then slowly.

> > Maybe it would have had an impact on Unix fragmentation, but I doubt it
> > would have affected dos that much.
>
> It took me a while to realize you meant "different
> versions of Unix" rather than "memory fragmentation
> within a particular Unix running instance". :-)
Hehe.

> > I do think maybe 32-bit could have emerged as the norm for applications
> > earlier (than 1995+ with win95), but that is only weakly correlated with
> C.
>
> Do you think that C wrappers for the MSDOS API,
> combined with a 32-bit version of MSDOS, would
> have achieved that and been a good thing?
A 32-bits API, memorymodel, and some associated toolchain.

> I have been writing wrappers for decades, but
> even without them, MSDOS C compilers did come
> with wrappers with similar functionality. Here
> is one of my wrappers:
I have been modifying and writing Pascal and Modula2 RTLs for decades, and they are the same. That is simply language runtime, not OS.

Except on Unix (or if you are charitable, POSIX) where the runtime is elevated to some magically status. But there are severe problems with that as I already described in earlier threads.

Post reply
 

Complete thread:

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