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, 06:37

> If you plan to offer an alternative to Windows,
I don't quite understand the meaning of this.
Are you talking about an alternative API (and
if so, at the application programming level or
the executable level?) or a different implementation
of the same Windows API?

> you cannot say "but apps
> are not allowed to use segments"
I can tell you that the Win32 executables that
I currently produce on Windows, for Windows, do
not use segments.

And if someone else uses segments in their
Win32 executables, that won't work if they try
to run their Win32 executable on PDOS/386.

> and you cannot say "but networking has to
> be done with another OS", obviously.
Currently I don't have networking. I've only
just reached the point of getting a working
toolchain, and even that has some remaining
bugs to work out.

You can simply directly call the 32-bit BIOS
to access INT 14H and speak to a serial port
though, but that's not something apps should
be doing. It's just there as proof of concept.

> I do not understand why you believe that setting segment registers at all
> would be too privileged.
I wish to have a flavor of PDOS that runs as a
normal (unprivileged) application under normal
Windows 10.

That PDOS will in turn load other Win32 executables,
all running at native speed.

In that environment I cannot demand particular
addresses, cannot set segment register at all,
and cannot set interrupt vectors.

Fortunately Win32 executables (at least the ones
I produce) don't require any of those things to
be set.

> In protected mode, those registers contain
> selectors and the selectors refer to descriptor tables which define where
> in your physical or virtual RAM the actual data is.
Yes, and the 32-bit applications should just
assume they have already been set correctly
and not have to worry about them.

> Editing those tables is something which usually is privileged, which is why
> it is managed through API provided by the OS or similar, for example DPMI,
> unless you want to give your apps full control over everything, which is
> uncommon in protected mode OS.
I don't want my 32-bit applications to require
either of those things to be done. I just want
them to be segment-unaware.

Win32 executables (at least the ones I build)
are *already* segment-unaware. This is not new
technology I invented. It's normal as far as I
know.

> Yes, you can trigger a GPF by trying to set CS, SS, ES, DS, FS or GS to a
> value which is beyond your privileges or which simply does not exist in the
> tables. But you are totally free to use multiple segments in apps as long
> as you have permissions for all used segment selector values.
PDOS/386 only gives you one usable segment
register and it is all that is required. At
least to run a toolchain.

> You can also trigger GPF by setting the offset of any RAM access outside
> the allowed range of the applicable segment, but you cannot interpret that
> as "using pointers is a privileged operation and must be avoided to keep
> apps simple".
I am not making that argument and I do not think
they are the same thing. A better analogy would
be to say "you are not allowed to directly write
to 0xb8000". And that is in fact exactly correct.
If you want to draw on the screen I expect you
to use ANSI escape sequences, and I intend for
PDOS/386 to support those sequences in the
future.

Until then, you can in fact write directly to
0xb8000, which is how I got micro-emacs up and
running without ANSI being ready yet.

> So segments are a lot less evil than you think. And as others have said
> here before, if your OS does not support any apps without having to
> recompile them, then the market for this OS will be very small.
It DOES support apps without having to recompile
them - Win32 console mode apps.

What it doesn't support without recompilation is
*specific* *interpretations* of "32-bit MSDOS".
I have my own interpretation of what a clean
32-bit MSDOS looks like, which is similar, but
not identical, to DOS32A.

There's no rule to say that Watcom are allowed
to invent a 32-bit MSDOS but I'm not allowed to.

> Given that you like the idea of "just offering a protected mode int 21", I
> think that accepting the style deviation of supporting DOS32A (and DOS4GW)
> style protected mode int 21 and accepting that some apps need DPMI would be
> an acceptable cost (the price would be that you might encounter segments)
> compared to suddenly having significantly more apps running on your OS
> without recompiling.
Note that I don't really want people to even use
my own INT 21H vision of MSDOS. So I don't want
people to recompile to use my INT 21H interface.
If they're going to recompile, it should be to
produce Win32 executables, which ALSO work on
both PDOS/386 and Freedos+HX.

However, if people want to recompile "for fun"
to use my 32-bit MSDOS, that's fine.

And I am indeed interested in supporting other
people's vision of "32-bit MSDOS", depending on
their requirements.

Adding an INT 31H handler is no big deal. Converting
an attempt to call a 16-bit MSDOS via a 32-bit
INT 31H call, and having it be redirected to
32-bit MSDOS instead, is actually a fun thing
to do.

But supporting applications (DOS32A) that expect me
to set a particular segment register (es) to a
particular value (a parameter) is not very nice.

However, since I'm not using es for anything
anyway, I guess I could accommodate this
behavior.

Is there a lot of demand for running DOS32A
style applications?

Rather than running Win32 applications.

BFN. Paul.

Post reply
 

Complete thread:

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