OSDev.org

Sorry for the sequential posts, but I never got around to giving links for the FreeDOS, FreeDOS-32, and FreeDOS-64 projects. I forgot to mention the FreeDOS-32 project, which AFAIK is still active currently. Also, it looks like there has been some activity on the 64-bit project as of two years ago, which I hadn't been aware of, though I don't know just how much.

I don't know if they are really relevant to Kerravon's plans or not, but I am hoping that at least knowing about those might be of use.

kerravon wrote:

linguofreak wrote: But 32-bit DPMI basically *is* a 32-bit DOS. DPMI had its start within Microsoft.

From the 32-bit application's point of view, it looks like a 32-bit DOS, but it isn't. It's a kludge, still running a 16-bit DOS. I want DOS itself to be 32-bit.

DPMI is an API. It can have anything behind it, including MS-DOS, a 32-bit operating system for which DPMI calls are native system calls and real-mode DOS calls are thunked (my understanding is that this was bascially where DOS kernel Windows had ended up by the time of Windows ME), Windows NT (ntvdm), Linux (DOSEmu), or a multi-platform application (DOSBox).

linguofreak wrote:

kerravon wrote:

linguofreak wrote: But 32-bit DPMI basically *is* a 32-bit DOS. DPMI had its start within Microsoft.

From the 32-bit application's point of view, it looks like a 32-bit DOS, but it isn't. It's a kludge, still running a 16-bit DOS. I want DOS itself to be 32-bit.

DPMI is an API. It can have anything behind it, including MS-DOS, a 32-bit operating system for which DPMI calls are native system calls and real-mode DOS calls are thunked (my understanding is that this was bascially where DOS kernel Windows had ended up by the time of Windows ME), Windows NT (ntvdm), Linux (DOSEmu), or a multi-platform application (DOSBox).

Thanks for that interesting comment regarding a potential 32-bit operating system having DPMI as native system calls. But I took another look at that:
http://www.delorie.com/djgpp/doc/libc-2.02/ and as an example there is __dpmi_get_segment_base_address. What business does a 32-bit application have requesting such information from a 32-bit operating system? It doesn't seem to be a match to me. It's a match for a DOS extender messing around with segment registers and needing this service provided by another bit of software. But under a pure 32-bit operating system, where applications are not even aware that they are using segment registers, nor are they supposed to touch them, I don't see the relevance. Am I missing something?

kerravon wrote: http://www.delorie.com/djgpp/doc/libc-2.02/ and as an example there is __dpmi_get_segment_base_address. What business does a 32-bit application have requesting such information from a 32-bit operating system? It doesn't seem to be a match to me. It's a match for a DOS extender messing around with segment registers and needing this service provided by another bit of software. But under a pure 32-bit operating system, where applications are not even aware that they are using segment registers, nor are they supposed to touch them, I don't see the relevance. Am I missing something?

Well, DPMI exposes how the CPU works and lets the programmer use the CPU features in basic ways.
If you use segments not starting at virtual/linear address 0, you may sometimes need to convert the offset to one.
Especially in 16-bit DPMI programs.

Say, you want to program the DMA (for disk or sound). The classical PC DMA chip takes a 24-bit physical address, AFAIR. So, on a 80286 you'd convert your sel:ofs into the virtual/linear address which is equal to the physical address. It's not the best example or the best way to do things, but it's a way. The best would be to do it the other way around and use page translation/mapping, but it requires a 80386. Yet another would be to just have a buffer below 1MB, perhaps allocated before enabling DPMI, whose linear/virtual and physical addresses are the same.

You could also create protected views of memory (and perhaps share those between several DPMI programs running under the same DPMI host in the same address space; never needed this, don't know if it works) as segments and you need to have the segment base and size for a segment descriptor in the GDT/LDT.

Just some thoughts.

kerravon wrote: Thanks for that interesting comment regarding a potential 32-bit operating system having DPMI as native system calls. But I took another look at that:
http://www.delorie.com/djgpp/doc/libc-2.02/ and as an example there is __dpmi_get_segment_base_address. What business does a 32-bit application have requesting such information from a 32-bit operating system? It doesn't seem to be a match to me. It's a match for a DOS extender messing around with segment registers and needing this service provided by another bit of software. But under a pure 32-bit operating system, where applications are not even aware that they are using segment registers, nor are they supposed to touch them, I don't see the relevance. Am I missing something?

Flat address space does not imply "pure 32-bit operating system". Intel fully intended that it be possible to build 32-bit operating systems that used segmentation, with applications that were aware of segmentation, when they designed the 386. It's just that pretty much every OS other than DOS had ambitions to portability to non-intel Architectures, or was modeled on something that already existed that used a flat address space, or both, so nobody really wanted to use 32-bit segmentation for anything other than legacy DOS compatibility. It's not even entirely true that applications can't use/touch segment registers even on OSes that are normally considered to be firmly flat-address space OSes: Linux has a "modify_ldt" system call that lets an application configure its own segments for its address space. I think it's mostly used by DOS/Win16 compatibility programs like Wine and DOSEmu on 32-bit x86 kernels, but *any* x86 Linux application can in principle use it.

linguofreak wrote:

kerravon wrote: Thanks for that interesting comment regarding a potential 32-bit operating system having DPMI as native system calls. But I took another look at that:
http://www.delorie.com/djgpp/doc/libc-2.02/ and as an example there is __dpmi_get_segment_base_address. What business does a 32-bit application have requesting such information from a 32-bit operating system? It doesn't seem to be a match to me. It's a match for a DOS extender messing around with segment registers and needing this service provided by another bit of software. But under a pure 32-bit operating system, where applications are not even aware that they are using segment registers, nor are they supposed to touch them, I don't see the relevance. Am I missing something?

Flat address space does not imply "pure 32-bit operating system". Intel fully intended that it be possible to build 32-bit operating systems that used segmentation, with applications that were aware of segmentation, when they designed the 386. It's just that pretty much every OS other than DOS had ambitions to portability to non-intel Architectures, or was modeled on something that already existed that used a flat address space, or both, so nobody really wanted to use 32-bit segmentation for anything other than legacy DOS compatibility. It's not even entirely true that applications can't use/touch segment registers even on OSes that are normally considered to be firmly flat-address space OSes: Linux has a "modify_ldt" system call that lets an application configure its own segments for its address space. I think it's mostly used by DOS/Win16 compatibility programs like Wine and DOSEmu on 32-bit x86 kernels, but *any* x86 Linux application can in principle use it.

I guess this is my actual question. The fact is that I just upgraded the existing MSDOS API to use 32-bit registers. I didn't expose a new __dpmi_get_segment_base_address facility, nor any of the other DPMI API functions. In fact I don't even allow for applications to know that segment registers even exist. Does my failure to use the DPMI API mean that there is something wrong with my OS design? Looking through the DPMI functions at the above link, most of them do not seem to be relevant to application programs. E.g. I can understand an application wanting to call INT 21H in order to read the contents of a file, and to provide a 32-bit pointer for the destination. But for what reason does an application need to call __dpmi_mark_page_as_demand_paging_candidate? I believe DPMI is an API suited for non-stand-alone DOS extenders, not for stand-alone OSes or their applications.

kerravon wrote:But for what reason does an application need to call __dpmi_mark_page_as_demand_paging_candidate? I believe DPMI is an API suited for non-stand-alone DOS extenders, not for stand-alone OSes or their applications.

OSes do provide apps with some control over their own memory. You can reserve address space, map physical memory into it, unmap, lock, etc etc. Take a look at Windows' VirtualAllocEx(), VirtualLock(), VirtualProtectEx()...

alexfru wrote:

kerravon wrote:But for what reason does an application need to call __dpmi_mark_page_as_demand_paging_candidate? I believe DPMI is an API suited for non-stand-alone DOS extenders, not for stand-alone OSes or their applications.

OSes do provide apps with some control over their own memory. You can reserve address space, map physical memory into it, unmap, lock, etc etc. Take a look at Windows' VirtualAllocEx(), VirtualLock(), VirtualProtectEx()...

Ok, but 16-bit MSDOS does not provide a facility to do such things. And my goal is to create a 32-bit MSDOS, not whatever you call a system that lets an application get involved with the details of paging. And to date my 32-bit applications have worked fine without having access to the DPMI API. Would you expect that at some point I will be porting a 16-bit MSDOS application to 32-bit and suddenly say "damn, I really need that DPMI function now, but I don't have it, so I'm stuck"? If not, then DPMI is probably out of scope for what I am trying to achieve.

kerravon wrote:

alexfru wrote:

kerravon wrote:But for what reason does an application need to call __dpmi_mark_page_as_demand_paging_candidate? I believe DPMI is an API suited for non-stand-alone DOS extenders, not for stand-alone OSes or their applications.

OSes do provide apps with some control over their own memory. You can reserve address space, map physical memory into it, unmap, lock, etc etc. Take a look at Windows' VirtualAllocEx(), VirtualLock(), VirtualProtectEx()...

Ok, but 16-bit MSDOS does not provide a facility to do such things. And my goal is to create a 32-bit MSDOS, not whatever you call a system that lets an application get involved with the details of paging. And to date my 32-bit applications have worked fine without having access to the DPMI API. Would you expect that at some point I will be porting a 16-bit MSDOS application to 32-bit and suddenly say "damn, I really need that DPMI function now, but I don't have it, so I'm stuck"? If not, then DPMI is probably out of scope for what I am trying to achieve.

I'm just saying that some functionality is sought after and that's why it exists. It's up to you to provide support for it or not.

OTOH, I think you could hack Linux or BSD (or even MINIX!) to provide more direct access to hardware as in DOS but without throwing out everything else. Or just port your apps using SDL. Yet OTOH, I see little point in the exercise. You could just run lots of old apps in e.g. DOSBox without doing any development. But if it's fun to you, don't listen to us, go ahead!

alexfru wrote: I'm just saying that some functionality is sought after and that's why it exists. It's up to you to provide support for it or not.

OTOH, I think you could hack Linux or BSD (or even MINIX!) to provide more direct access to hardware as in DOS but without throwing out everything else. Or just port your apps using SDL. Yet OTOH, I see little point in the exercise. You could just run lots of old apps in e.g. DOSBox without doing any development. But if it's fun to you, don't listen to us, go ahead!

I would like to have a public domain operating system, not GPL/BSD, so I don't want to hack Linux/FreeBSD. I would also like to start with the MSDOS API, because it is hopefully the simplest, and also I believe that this particular platform should *exist*. ie I don't think the 16-bit API should have been completely abandoned, I think a simple 32-bit version of the 16-bit API should have been made available by Microsoft at the same time as the 80386 came out. I am interested in seeing "what might have been". Also I don't think Microsoft should have been the only creator of a 32-bit version of MSDOS, competitors should have been doing the same thing, and there should have been a hobbyist version(s) of it too.

Hi,

kerravon wrote:

alexfru wrote: I'm just saying that some functionality is sought after and that's why it exists. It's up to you to provide support for it or not.

OTOH, I think you could hack Linux or BSD (or even MINIX!) to provide more direct access to hardware as in DOS but without throwing out everything else. Or just port your apps using SDL. Yet OTOH, I see little point in the exercise. You could just run lots of old apps in e.g. DOSBox without doing any development. But if it's fun to you, don't listen to us, go ahead!

I would like to have a public domain operating system, not GPL/BSD, so I don't want to hack Linux/FreeBSD. I would also like to start with the MSDOS API, because it is hopefully the simplest, and also I believe that this particular platform should *exist*. ie I don't think the 16-bit API should have been completely abandoned, I think a simple 32-bit version of the 16-bit API should have been made available by Microsoft at the same time as the 80386 came out. I am interested in seeing "what might have been". Also I don't think Microsoft should have been the only creator of a 32-bit version of MSDOS, competitors should have been doing the same thing, and there should have been a hobbyist version(s) of it too.

I would like to start with the bubonic plague, because it's the simplest, and also I beleive that this particular plague should *exist*. I don't think the old plague should have been cured, I think a simple modern version of the plague should have been made available. I'm interested in "what might have been if people were still suffering and dying from the plague". I also don't think one company should be spreading the plague - competing companies should all be spreading the plague, and there should be a hobbyist version of the plague.


Cheers,

Brendan

kerravon wrote:I would like to have a public domain operating system, not GPL/BSD, so I don't want to hack Linux/FreeBSD.

<aside>
I'm not sure you quite grasp the purpose of using a 'public license' rather than simply placing something in the public domain. The point of the license is to prevent someone else from claiming a copyright on what you did and selling it, or worse, suing you over it.

This isn't a hypothetical, at least the first part isn't. It was just this scenario - where code that was written by Richard Stallman and put into public domain was then snapped up by some of the professors at MIT and some of the other developers at Lisp Machines, Inc, who put their own copyright notices on it and claimed to be the authors with ownership of it - that led to him coming up with the idea of a public license in the first place.

And if you don't think someone would sue the actual author for ownership of something they put into the public domain, claiming to be the rightful owners of it (not necessarily the creators, just the owners of the IP rights, though creator claims do happen, too), you haven't been paying enough attention to what patent trolls and copyright trolls do. Attorneys such as Leonard French make a good living fighting such cases, and French's Youtube legal news discussion channel is full of cases where someone had to defend their ownership of their own original work because a lawyer - or even just someone claiming to be a lawyer - tried to shake them down by claiming they owed royalties on (just to repeat for emphasis) the defendant's own original work.

While that is not as common as some of the other IP-rights-trolling methods, it is a serious enough threat that putting something in the public domain without at least a period under a formal copyright and license for documentation purposes is, unfortunately, likely to do more harm than good. It is a sad state of affairs, one which spoils one's good intentions while at the same time blackening the public image of legitimate copyright defense, but it is one that is unlikely to change.

Note that I am not saying that you should dive deep into such 'legal effluvia' - to borrow a phrase from the Popehat legal blog - yourself, or even recommending that watch you all of those videos French made discussing the cases (while French himself is quite engaging, and he does his level best to make the subject interesting to a lay audience, the videos can get very long, and waiting for the legal briefs he's reviewing to get to a point is often like watching paint dry), but I do think you will want to be aware that it happens.
</aside>

Sorry for the long-ish digression, but I just had the feeling you might be setting yourself up for trouble down the road and wanted to warn you about it.

Schol-R-LEA wrote:

kerravon wrote:I would like to have a public domain operating system, not GPL/BSD, so I don't want to hack Linux/FreeBSD.

<aside>
I'm not sure you quite grasp the purpose of using a 'public license' rather than simply placing something in the public domain. The point of the license is to prevent someone else from claiming a copyright on what you did and selling it, or worse, suing you over it.

The original PD work remains in the public domain, the same as Shakespeare's Hamlet. You can't copyright Hamlet and prevent others from using it. Proving that I wrote the original in court makes no difference whether it is PD or GPL, the challenge of proving authorship remains unchanged. I am happy for people to copyright a derived version of my code and selling it, or making it closed source or anything else THEY wish to do.

kerravon wrote:I would like to have a public domain operating system, not GPL/BSD, so I don't want to hack Linux/FreeBSD. I would also like to start with the MSDOS API, because it is hopefully the simplest, and also I believe that this particular platform should *exist*. ie I don't think the 16-bit API should have been completely abandoned, I think a simple 32-bit version of the 16-bit API should have been made available by Microsoft at the same time as the 80386 came out. I am interested in seeing "what might have been".

Well, you can't truly achieve today "what might have been" because the world today is very different. What may have been superior back then is just a toy these days. What didn't happen then for one set of reasons won't happen these days for a very simple other. The end result will be the same.

Just out of curiosity, were you familiar with FreeDOS prior to this, and did you look into it at all?

Also, as I mentioned, an Exokernel would in some ways be even simpler - it wouldn't have an OS interface at all, so the applications and shared libraries would have free run over the system. Is this closer to what you actually want, or was their some specific aspect of MS-DOS you were seeking to revive?

You are not alone in this group in having an interest in MS-DOS or DOS-like systems, and while I am not one of those looking for that myself, you might want to get in touch with some of those who are already here. The wiki even has a developer archetype for such developers, Lino Commando, and while the archetypes are meant in jest (for example, the one that fits me closest is Alta Lang, which I wrote myself but which several others here fit), it does show how often this idea comes up. A few I can mention include ~ (yes, his username is just a tilde, I don't know why), utkarsh, and bellezasolo.

I had sent this to the OP by PM earlier, but they don't seem to have read it, so I might as well ask here. I wanted to avoid cluttering the thread, but in retrospect it would probably have been to ask this in public in the first place. I've deleted the PM, since it would be pointless for them to get it now.