Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

32-bit MSDOS (Announce)

posted by kerravon E-mail, Ligao, Free World North, 01.07.2021, 13:39

> > I don't know any of those terms, but GCCWIN is
> > a 3 MB executable and hardly "trivial". It's
> > 400,000 lines of C code.
>
> But most don't touch OS.
Sure. That's the class I support.

> > > Of course since TLS is related to threading it might be less relevant
> on
> > a
> > > single threaded OS like dos. But the subset of Windows binaries (even
> > > commandline) that will run decreases because of it.
> >
> > My focus is on getting C90-compliant programs
> > to work. The onus is on applications to be
> > written in such a way that in an environment
> > that doesn't support threading, the code base
> > produces a sensible executable.
>
> Count me out then, I'm not interested in C programming, except for when I
> absolutely can't avoid it in embedded situations.
>
> The compiler I'm working on is not C nor one its derivatives (C++/D), but
> firmly in the Wirthian realm.
To date I haven't considered other languages.
But maybe now is the time to start doing that.
I know I can make C90 applications work on
PDOS/386.

What is required to get Pascal to work? Starting
with println('hello, world')
or whatever it is in Pascal.

> > But access to what segments? I only have one
> > usable selector and the segment registers are
> > already set correctly. If any DPMI application
> > intends to inspect or modify those, it isn't
> > going to work. ie DOS32A won't work when it
> > starts looking at ES expecting a parameter
> > there.
>
> As said most assume an Unix model where ds=es.

Those ones won't have a problem then. BTW, I
can't remember if I mentioned it, but for
DOS32A, they muck around with "es" here:

http://dos32a.narechk.net/manual/index.html

Not sure what they're hoping to set es to.
There's only one selector available. If they
don't actually touch es, and assume ds = es,
then everything will be fine.

> Other selectors are sometimes used to map in the 16-bit dos 1MB and even
> rare for the VESA 2.0 linear framebuffer.
>
> > So with 2 out of the 3 above things being doable,
> > does that enable anything existing to run?
>
> No, but it could be fairly trivial. E.g. for go32v2 (*) memory buffers have
> to be transfer from 32-bit space to 16-bit space before calling an integer,
> e.g. a filename or filebuffer.
Ok, I provide an API to get memory below
1 MiB already, so if they unnecessarily
copy memory down there, that shouldn't
actually be a problem.

> But still, it requires modification, maintaining an extra target etc etc.
> The question is why would anybody. But I already asked that in a different
> post.
You don't have a Win32 target already for your
Pascal compiler/programs?

> (*) The extender that DJGPP but also FPC or Free Basic uses. Afaik this one
> has been the choice of most for the last decade, but I might be mistaken.
> It would make sense to focus on that first.
I may well be able to support it, but it would
seem strange to do so when you can produce a
Win32 executable that runs, or can run, on
almost every single computer and OS since
around 1990.

Linux has Wine. Freedos/MSDOS has HX. PDOS/386
has it. Even Microsoft support it. Can't remember
the name of their shitty product. Something-11
I think I heard. :-)

BFN. Paul.

Post reply
 

Complete thread:

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