OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 6:24 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: 32-bit MSDOS
PostPosted: Thu Jul 12, 2018 8:54 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
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.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Thu Jul 19, 2018 1:25 am 
Offline
Member
Member

Joined: Wed Mar 09, 2011 3:55 am
Posts: 509
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).


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Thu Jul 19, 2018 1:57 am 
Offline
Member
Member

Joined: Fri Nov 17, 2006 5:26 am
Posts: 232
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?


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Thu Jul 19, 2018 4:36 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
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.


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Sat Jul 21, 2018 1:49 am 
Offline
Member
Member

Joined: Wed Mar 09, 2011 3:55 am
Posts: 509
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.


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Mon Jul 23, 2018 10:44 pm 
Offline
Member
Member

Joined: Fri Nov 17, 2006 5:26 am
Posts: 232
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.


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Mon Jul 23, 2018 11:00 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
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()...


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Mon Jul 23, 2018 11:31 pm 
Offline
Member
Member

Joined: Fri Nov 17, 2006 5:26 am
Posts: 232
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.


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Tue Jul 24, 2018 2:14 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
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! :)


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Tue Jul 24, 2018 2:43 am 
Offline
Member
Member

Joined: Fri Nov 17, 2006 5:26 am
Posts: 232
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.


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Tue Jul 24, 2018 7:22 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Tue Jul 24, 2018 9:00 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
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.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Tue Jul 24, 2018 9:23 pm 
Offline
Member
Member

Joined: Fri Nov 17, 2006 5:26 am
Posts: 232
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.


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Tue Jul 24, 2018 9:51 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
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.


Top
 Profile  
 
 Post subject: Re: 32-bit MSDOS
PostPosted: Sun Jul 29, 2018 9:22 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
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.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 17 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group