OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Jul 23, 2018 9:56 am

All times are UTC - 6 hours




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

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1236
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
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
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: 273
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

Joined: Fri Nov 17, 2006 5:26 am
Posts: 19
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: 880
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: 273
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  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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