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 kerravon E-mail, Ligao, Free World North, 02.11.2021, 22:00

> > With the benefit of hindsight, the 80386 was coming
> > out in 1986. 32-bit OS/2 2.0 was released in 1992.
>
> Note that in 1992/93 286s were still sold new, and 386sx (and DX even more
> so) were still high end.
Thanks for the info.

> > Assume people have the application source code in C
> > available, and that a 32-bit C compiler was also
> > made available in a timely manner, and that people
> > are happy to produce 2 versions of their software
> > for people who have memory constraints.
>
> 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? Can you give an example
of what would have been good and technologically
possible? And whether the starting point would
have needed to be before the 80386 came out in
1986. Note that most of a 32-bit C compiler can
be written without a specific 32-bit processor.

> > By 1985, 512K memory was US$210, which is probably
> > a point where you shouldn't be making design
> > decisions based on saving m*oney on RAM.
>
> 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?

> > Another consideration is that the C standard wasn't
> > actually ratified until 1989-1990, so there is some
> > difficulty exporting a C library to applications.
>
> The C standard has nothing to do with any of this.
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.

> > With the benefit of hindsight we know what the C
> > standard is, and it is something that could have
> > been written in 1980.
>
> 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? Was the complaint valid? Was there
a solution to the complaint that wouldn't have
involved abandoning C entirely? (in favor of
assembler I assume).

> > Let's assume that we had the
> > C standard and appropriate compilers and libraries
> > in 1980, and we were just waiting for someone to
> > authorize the writing of MSDOS 2.0 with a fresh
> > API, to be delivered in 1983.
>
> > Hold the use of the 8086 and the 80386 constant.
> > Hold the C90 standard constant, but backdated to
> > 1980. Hold memory prices constant. What could have,
> > or should have been done, with the benefit of
> > hindsight, and flexibility in software choices?
> > ie what options did humanity have available, but
> > missed?
>
> 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". :-)

> 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?

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:

int PosFindFirst(char *pat, int attrib)
{
union REGS regsin;
union REGS regsout;
struct SREGS sregs;

regsin.h.ah = 0x4e;
regsin.x.cx = attrib;
#ifdef __32BIT__
regsin.d.edx = (int)pat;
#else
regsin.x.dx = FP_OFF(pat);
sregs.ds = FP_SEG(pat);
#endif
int86x(0x21, &regsin, &regsout, &sregs);
if (regsout.x.cflag)
{
return (regsout.x.ax);
}
else
{
return (0);
}
}


BFN. Paul.

Post reply
 

Complete thread:

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