PDOS/386

[Paul Edwards]

I was just made aware of this group and I am

wondering whether there is room for

collaboration. I have created a 32-bit

MSDOS-like operating system called PDOS/386,

and you can see the project page here:

http://pdos.sourceforge.net

It is all working, but I would like to refine

the API before cutting an official release.

The current API can be found here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/pos.h

but also a traditional int86() API works.

The code is all public domain, so you can

take anything you want and put it into your

GPL Night DOS project (but not vice-versa).

Issues like a C library and C compiler have

already been addressed. I've only tested

FAT-16 myself, but another volunteer has

recently added FAT-32.

PDOS/386 works by dropping down to

real mode to do BIOS calls, but this is

transparent to applications which operate

purely in 32-bit mode. PDOS/386 is good

enough that I was able to get micro-emacs

to run, using the DOS target. Only minor

changes were needed, e.g. when it was

writing to 0xb8000 it used "int *" and I

needed to change that to "short *".

Let me know your thoughts!

Thanks. Paul.

[Mercury Thirteen]

Hi, Paul! I've had a lot going on in the realm of real life (outside of my Code Life lol) which hasn't left me with a whole lot of time as of late. As soon as I get a few moments, I'll take a look at your project.

In the mean time, what did you have in mind for an API? Will it include any windowing system? Interprocess communication? I'm interested in hearing your plans thus far.

[Paul Edwards]

My plan was limited to producing a 32-bit

version of MSDOS. MSDOS itself does

not have a vast number of features, and

limiting it to this means that I am more

likely to have a product that actually

works.

What I'd then like to be able to do is write

a device driver that allows me to connect

to the internet to exchange newsgroup

or Fidonet messages.

BFN. Paul.

[Mercury Thirteen]

On Sunday, July 8, 2018 at 7:30:45 PM UTC-4, Paul Edwards wrote:

My plan was limited to producing a 32-bit

version of MSDOS. MSDOS itself does

not have a vast number of features, and

limiting it to this means that I am more

likely to have a product that actually

works.

What I'd then like to be able to do is write

a device driver that allows me to connect

to the internet to exchange newsgroup

or Fidonet messages.

BFN. Paul.

Keep in mind I haven't browsed much of your code yet, but so far as a driver interface, your API would need a call to allow a driver to query the list of devices installed and see if there are any it can handle. Writing a driver, then, would be similar to writing any other application, just setting up handlers for the functions the driver has so that when the NIC fires an interrupt upon getting some data, the OS passes control on to your driver application for appropriate handling.

This is the technique Night will employ, but of course that's just one of many methods.

[Antony]

Hi,

That's not "a" driver, but a series of drivers.

You will need a network adapter driver and TCP/IP stack. The most open source card is probably the NE2000, followed by whatever is emulated in VirtualBox, BOCHS, QEMU, VMWare, and Parallels.

Even though you are going to use TCP/IP, I believe you need a good portion of the NDIS stack especially if you decide to just use what is available in the Win32 (WfW) space. Winsock (by Trumpet) should be available especially if you can find an old SimTel archive, or access to the old Microsoft FTP site (for the official Microsoft WINSOCK)

-Tony

On Sunday, July 8, 2018 at 7:30:45 PM UTC-4, Paul Edwards wrote:

[Paul Edwards]

On Saturday, 7 July 2018 17:38:15 UTC+10, Paul Edwards wrote:

I was just made aware of this group and I am

wondering whether there is room for

collaboration. I have created a 32-bit

MSDOS-like operating system called PDOS/386,

and you can see the project page here:

http://pdos.sourceforge.net

 

After a 12 year gap I have finally published an

update to this, release 0.90.

The most major change is that as well as a

32-bit MSDOS-like API, it also supports a

subset of the 32-bit Windows API, so it runs

some Windows console-mode applications.

So it has been renamed PD-Windows.

I'm actually interested in hiring some students

or hobbyists to work on the system. I'm

looking to pay US$50/month for a few hours

work per week that doesn't interfere with

their studies. Please let me know if you know

of anyone interested.

Thanks. Paul.

[Mercury Thirteen]

Hi Paul!

I looked over the description of PDOS and saw "it isn't really the MSDOS API, it is a theoretical 32-bit MSDOS API". What does that mean exactly? Does PDOS implement all functions supported by MSDOS or a limited subset?

[Maarten Vermeulen]

Reading that same part at the website, I think it's a subset in the way that it supports as much as possible in the 32-bit API.

It's an interesting project though, I may take a look at some open issues or something next week. Never did anything with autocomplete before (issue #7), so that may be interesting. Don't keep me to that though lol.

--
You received this message because you are subscribed to the Google Groups "Night Kernel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to night-dos-kern...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/night-dos-kernel/3a586b93-8606-47ba-998a-2e71e80bea38%40googlegroups.com.

[Paul Edwards]

Hi Mercury.

PDOS/86 is a subset of the real MSDOS API.

PDOS/386 is a subset of a theoretical 32-bit MSDOS

API, if Microsoft had decided to produce a 32-bit

version of MSDOS. So in 32-bit mode you can

call INT 21H AH=3FH to do a read file, and you

can pass it a 32-bit pointer in EDX and a 32-bit

length in ECX.

PD-Windows has been grafted on top of PDOS/386

(similar to how Win 95 was grafted on top of the

16-bit MSDOS), and provides a kernel32.dll that

simply makes calls to the relevant PDOS/386 calls.

The main thing that has been implemented is the

calls used by the C90-compliant runtime library,

so that all C90 programs work. And I have made

e.g. GCC 3.2.3 C90-compliant, so GCC works.

Let me know if that is still not clear.

BFN. Paul.

[Mercury Thirteen]

Yes, that helps. This should prove very useful once we get to the DOS compatibility section of the project. Thanks for the information!

[Paul Edwards]

PDOS/386 became self-hosting a couple of weeks ago,

ie you can use PDOS/386 to develop PDOS/386.

That's the version in git, I haven't cut a new release yet.

BFN. Paul.

[Mercury Thirteen]

Thanks for the update!

[muta...@gmail.com]

Within the last 24 hours, Freedos+HX+doslfn+PDPCLIB-msvcrt.dll

has become the 32-bit system I (now know I) wanted when the

80386 came out in 1986 (ie Win32 executables dependent on

msvcrt.dll).

I now wish for PDOS/386 to match that Freedos++ combination.

You may wish to read this:

http://pdos.org

BFN. Paul.

[mercur...@gmail.com]

Thanks for the update!

[muta...@gmail.com]

There are several bugs in PDOS/386.

If anyone would like to fix a bug I care about, I'm willing

to pay US$50 per bug fix.

http://pdos.org

Thanks. Paul.

[muta...@gmail.com]

There has been a new version of PDOS/386 released

that is capable of running GCC, so now PDOS/386 is

a mini Windows dev environment.

Usual spot - http://pdos.org

BFN. Paul.

[muta...@gmail.com]

I now have a completely public domain disk image

for PDOS/386 and another for PDOS/86. Both have

the ability to compile C programs, but it is a subset

of C90 that SubC is capable of.

http://pdos.org

BFN. Paul.