Interesting you should mention this; I and a few others have been working on a
32-bit Protected Mode DOS-style kernel (see the Night group forum
[here](https://groups.google.com/forum/?hl=en#!forum/night-dos-kernel) for more
info) for a while now. While I never got too deep into DPMI (and therefore
don't know how much help I would be to you) I'm interested in taking a look at
your project. Since it seems we have a similar goal, maybe there's a nugget or
two of info that can be shared to help both projects along.
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 6, 2018 7:54 PM, Paul Edwards <mutazi...@gmail.com> wrote:
> Hi. About 30 years ago, someone made a comment
> on a group saying "until DOS is made 32-bit, DOS
> extenders are just a kludge".
>
> I didn't know much about DOS-specifics back then
> to even understand the comment.
>
> Microsoft abandoned the MSDOS API, but what
> would a 32-bit version of the MSDOS API look
> like if they hadn't abandoned it?
>
> Since 1994, off and on, I have been working on
> PDOS/386, which is designed to be a 32-bit
> version of MSDOS/Freedos.
>
> I have recently just completed relocation of OS
> and app so that they can both run in a flat address
> space, meaning that applications can directly
> manipulate the hardware, e.g. by going
> *(char *)0xb8000 = 'X';
> With that change now in place, it is working to
> my satisfaction technically (I want to return to
> the days when blindingly fast applications could
> be written by manipulating the hardware), and
> I would like to solidify the API. What would a
> 32-bit MSDOS API ideally look like? My current
> thinking is that both int86() and some wrapper
> functions should be made available, which I
> have already done here:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/pos.h
>
> Note that this is all working, but I am interested
> in tweaking the design/interface before lots of
> 16-bit MSDOS programs get ported to 32-bit, so
> I am open to suggestions. E.g. I was thinking
> that the PosAllocMem() should instead be put
> on a different AH code and take extra parameters,
> mainly a "location" which can be set to 20 to
> request memory in the first 1 MiB, or 32 for the
> full 4 GiB space, and in the future support 64.
>
> PDOS/386 is explicit public domain (no license)
> and written mostly in C, with a bit of assembler.
> The way it works is that the OS and apps are
> pure 32-bit protected mode, but when a service
> like reading from disk is required, it converts the
> protected mode BIOS interrupt into a real mode
> interrupt. This conversion to real mode is
> transparent to the OS and apps.
>
> As a test, I tried porting micro-emacs from 16-bit
> DOS to 32-bit DOS, and very few changes were
> required. He was previously writing to the screen
> buffer at 0xb8000 using an "int *" and I needed
> to change that to "short *". I was thinking that
> all the Freedos utilities could be similarly ported
> so that I don't need to rewrite everything.
>
> I don't need any code written. I just need peer
> review of the design/API. Hopefully someone
> can offer some opinions.
>
> Thanks. Paul.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
